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.