Hm... this may or may not be relevant, but I had a problem somewhere in the intersection of drakma, chunga and (possibly) hunchentoot, which turned out to be caused by drakma treating "application/xml" as a binary format. While checking my mailbox to aid my recollection of this, I came across https://github.com/edicl/hunchentoot/issues/1 .

For *my* problem, the solution was simply to add

(pushnew (cons "application" "xml")
drakma:*text-content-types* :test 'equalp)

in the startup block of my code.

Again, I'm not sure if any of this is relevant :-)

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