A bug in functon parse-content-type.

[Hans Hübner]

Jingtao,

the content-type header "application/x-www-form-urlencoded; text/html;
charset=UTF-8" is just bogus.  I do not want to include code that makes
Hunchentoot work with clearly broken clients.  Better error reporting would
be acceptable, though.

-Hans


On Sat, May 25, 2013 at 12:38 PM, Jingtao Xu <jingtaozf at gmail.com> wrote:

> Hi all,
>
> I found the content type header which raise the bug in my message.log
> generated by hunchentoot.
> It happened when hunchentoot get following content type header:
>
>
> -----------------------------------------------------------------------------------------
> application/x-www-form-urlencoded; text/html; charset=UTF-8
>
> -----------------------------------------------------------------------------------------
>
> I noticed that in package drakma's file read.lisp,function
> 'get-content-type'
> also assumed "/" as a token separator.
>
> I hope package chunga/drakma/hunchentoot could accept such content type
> header
> without raising an exception,As Edl said,a new special variable
> similar to *accept-bogus-eols* or
> *treat-semicolon-as-continuation* which only assume " ,;" as token
> separator may be a good idea and will fix my question.
>
> Any way, RFC standard is not well fit with the read world.
>
> Thanks very much.
>
> WIth Best Regards,
> jingtao.
>
>
> On Thu, May 23, 2013 at 2:01 PM, Edi Weitz <edi at agharta.de> wrote:
> > I'm not the maintainer anymore, but my take is that if some Ruby or
> > Java client misinterprets the RFC I wouldn't change Hunchentoot's (or
> > rather Chunga's) default behavior because of that.  I'd rather
> > introduce a new special variable similar to *accept-bogus-eols* or
> > *treat-semicolon-as-continuation*.
> >
> > Just my .02 Euros,
> > Edi.
> >
> >
> >
> > On Thu, May 23, 2013 at 2:52 AM, Jingtao Xu <jingtaozf at gmail.com> wrote:
> >> Hi All,
> >>
> >> 1. The function `read-name-value-pair' is called by `
> >> parse-content-type' in hunchentoo/util.lisp,not by my codes.
> >> 2. the slash is a token constituent in java/ruby implementation,and I
> >> think some web client/server treat it as a token constituent too,
> >>     but I am waiting for the hunchentoot log to give us a live example.
> >>
> >> With Best Regards,
> >> jingtao
> >>
> >>
> >> On Wed, May 22, 2013 at 11:40 PM, Edi Weitz <edi at agharta.de> wrote:
> >>> If I'm not mistaken, the slash is a "separator" and thus not a token
> >>> constituent according to RFC 2616 which means "path=/foo" is not legal
> >>> input for READ-NAME-VALUE-PAIR.
> >>>
> >>> On Wed, May 22, 2013 at 5:27 PM, Ron Garret <ron at flownet.com> wrote:
> >>>> Very likely Jingtao's code is calling READ-NAME-VALUE-PAIR without
> being wrapped in this macro
> >>>>
> >>>> But there's still a bug in READ-NAME-VALUE-PAIR:
> >>>>
> >>>> ? (WITH-INPUT-FROM-VECTOR (S (MAP '(VECTOR (UNSIGNED-BYTE 8))
> 'CHAR-CODE "path=/foo"))
> >>>>   (chunga:with-character-stream-semantics
> >>>>       (CHUNGA:READ-NAME-VALUE-PAIR S)))
> >>>> ("path" . "")
> >>>>
> >>>> On May 22, 2013, at 8:19 AM, Edi Weitz wrote:
> >>>>
> >>>>> On Wed, May 22, 2013 at 4:18 PM, Ron Garret <ron at flownet.com> wrote:
> >>>>>> I found a bug in CHUNGA:READ-NAME-VALUE-PAIR.
> >>>>>
> >>>>> It's not quite clear to me yet what the bug is supposed to be.
> >>>>>
> >>>>> The documentation clearly says that calls to READ-NAME-VALUE-PAIR and
> >>>>> friends must be wrapped with this macro:
> >>>>>
> >>>>>  http://weitz.de/chunga/#with-character-stream-semantics
> >>>>>
> >>>>> (You might argue that this isn't very user-friendly, but Chunga
> wasn't
> >>>>> really intended to be used that way.)
> >>>>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130525/d83250ee/attachment.html>