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