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.