Jingtao,

before I make any changes to Chunga, I need to have an understanding what the problem is and how it can be triggered.  As you have already invested quite some time in reporting this bug (thanks for that), please go the extra mile and determine what the real cause is and how the bug that you have found is triggered.

Thanks,
-Hans


On Wed, May 22, 2013 at 7:15 AM, Jingtao Xu <jingtaozf@gmail.com> 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@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@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.
>>
>