I have add a log to hunchentoot so I can get the content header when it happens,

But I think Ron have reproduced the problem:

? (WITH-INPUT-FROM-VECTOR (s (map '(VECTOR (UNSIGNED-BYTE 8))
'char-code "x=/y"))

With Best Regards,
jingtao.

On Wed, May 22, 2013 at 1:33 PM, Hans Hübner <hans.huebner@gmail.com> wrote:
> 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.
>> >>
>> >
>
>