A bug in functon parse-content-type.

[Ron Garret]

I was able to reproduce the problem -- sort of:

? (WITH-INPUT-FROM-VECTOR (s (map '(VECTOR (UNSIGNED-BYTE 8)) 'char-code "x=/y"))
(chunga:read-name-value-pair s))
> Error: Read character #\/, but expected #\=.

The reason I say "sort of" is that I encountered this bit of rather extreme weirdness:

? l1
(WITH-INPUT-FROM-VECTOR (S (MAP '(VECTOR (UNSIGNED-BYTE 8)) 'CHAR-CODE "x=/y")) (CHUNGA:READ-NAME-VALUE-PAIR S))
? l2
(WITH-INPUT-FROM-VECTOR (S (MAP '(VECTOR (UNSIGNED-BYTE 8)) 'CHAR-CODE "x=/y")) (CHUNGA:READ-NAME-VALUE-PAIR S))
? (equal l1 l2)
T
? (eval l1)
> Error: Read character #\/, but expected #\=.
> While executing: CHUNGA::SIGNAL-UNEXPECTED-CHARS, in process Listener(6).
> Type cmd-. to abort, cmd-\ for a list of available restarts.
> Type :? for other options.
1 > 
? (eval l2)
("x" . "")

I'm still scratching my head over that one.

rg

On May 21, 2013, at 10:15 PM, Jingtao Xu wrote:

> Hi Hans,
> 
> As hunchentoot have not logged them to message.log,I could not give
> out the content-type header to you.
> And this bug don't appear always,so I have no way reproduce this bug
> at this time.
> 
> But I have made some patch to chunga and hunchentoot by cloning the repository:
> https://github.com/jingtaozf/chunga/commits/master
> https://github.com/jingtaozf/hunchentoot/commits/master
> 
> 
> With Best Regards,
> jingtao.
> 
> 
> On Wed, May 22, 2013 at 1:03 PM, Hans Hübner <hans.huebner at gmail.com> wrote:
>> Jingtao,
>> 
>> thank you for your bug report.  Can you please share the actual value of the
>> Content-type header that triggered the bug?
>> 
>> Thanks,
>> Hans
>> 
>> 
>> On Wed, May 22, 2013 at 4:28 AM, Jingtao Xu <jingtaozf at gmail.com> wrote:
>>> 
>>> Hi All,
>>> 
>>> My website use hunchentoot and allow some external website post  url
>>> request to hunchentoot server(which is necessary),and I found an error
>>> log in message.log:
>>> 
>>> ---------------------------------------------------
>>> Error when reading POST parameters from body: Corrupted Content-Type
>>> header:
>>> Read character #\/, but expected #\=.
>>> ---------------------------------------------------
>>> 
>>> I found this bug is caused in function parse-content-type when it want
>>> to get parameters
>>> by calling function read-name-value-pairs then read-name-value-pair,in
>>> lisp function read-name-value-pair,there exist an assert which raise
>>> this exception:
>>> 
>>> ------------------------------------------
>>>          (when (or value-required-p
>>>                    (eql (peek-char* stream nil) #\=))
>>>            (assert-char stream #\=)
>>> ------------------------------------------
>>> 
>>> And this will make hunchentoot thread stop the request processing and
>>> exit,which is wrong.
>>> 
>>> When I have a deep investigation,I found that this bug should be
>>> caused by package chuga
>>> when try to read-token,its function token-char-p will call function
>>> separatorp and allow character #\/
>>> as a token character,which is not practical well,because both java and
>>> ruby and many other launguage don't allow them as a token
>>> character,more details you can get in a discussion:
>>> 
>>> http://bugs.python.org/issue2193
>>> 
>>> and a java implemention of token-char-p is like this:
>>> 
>>> -------------------------------------------------------------
>>> 
>>> private static final String tspecials = ",; ";
>>> 
>>> private boolean isToken(String value) {
>>>    int len = value.length();
>>>    for (int i = 0; i < len; i++) {
>>>        char c = value.charAt(i);
>>>        if (c < 0x20 || c >= 0x7f || tspecials.indexOf(c) != -1)
>>>            return false;
>>>        }
>>>    return true;
>>> }
>>> -------------------------------------------------------------
>>> 
>>> Anyway, hunchentoot should not raise an exception in
>>> parse-content-type,which make my site could not receive user's
>>> request.
>>> And to be more compatible with other web client/server, hunchentoot
>>> should read token
>>> like java/ruby.
>>> 
>>> Hope some patch can be done to package chunga and hunchentoot to fix my
>>> issue.
>>> 
>>> With Best Regards,
>>> jingtao.
>>> 
>> 
>