A bug in functon parse-content-type.

Edi Weitz edi at agharta.de
Thu May 23 06:01:51 UTC 2013


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



More information about the Tbnl-devel mailing list