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