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@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@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@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@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@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.)
>>>>
>>