<div dir="ltr">I'm interested in seeing an actual content-type header value that triggers the problem - Raising an uncaught error in response to some user input is certainly undesirable and warrants a fix, but I would like to understand what valid content types are handled incorrectly.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 8:35 AM, Jingtao Xu <span dir="ltr"><<a href="mailto:jingtaozf@gmail.com" target="_blank">jingtaozf@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have add a log to hunchentoot so I can get the content header when it happens,<br>
<br>
But I think Ron have reproduced the problem:<br>
<div class="im"><br>
? (WITH-INPUT-FROM-VECTOR (s (map '(VECTOR (UNSIGNED-BYTE 8))<br>
'char-code "x=/y"))<br>
<br>
</div>With Best Regards,<br>
jingtao.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, May 22, 2013 at 1:33 PM, Hans Hübner <<a href="mailto:hans.huebner@gmail.com">hans.huebner@gmail.com</a>> wrote:<br>
> Jingtao,<br>
><br>
> before I make any changes to Chunga, I need to have an understanding what<br>
> the problem is and how it can be triggered. As you have already invested<br>
> quite some time in reporting this bug (thanks for that), please go the extra<br>
> mile and determine what the real cause is and how the bug that you have<br>
> found is triggered.<br>
><br>
> Thanks,<br>
> -Hans<br>
><br>
><br>
> On Wed, May 22, 2013 at 7:15 AM, Jingtao Xu <<a href="mailto:jingtaozf@gmail.com">jingtaozf@gmail.com</a>> wrote:<br>
>><br>
>> Hi Hans,<br>
>><br>
>> As hunchentoot have not logged them to message.log,I could not give<br>
>> out the content-type header to you.<br>
>> And this bug don't appear always,so I have no way reproduce this bug<br>
>> at this time.<br>
>><br>
>> But I have made some patch to chunga and hunchentoot by cloning the<br>
>> repository:<br>
>> <a href="https://github.com/jingtaozf/chunga/commits/master" target="_blank">https://github.com/jingtaozf/chunga/commits/master</a><br>
>> <a href="https://github.com/jingtaozf/hunchentoot/commits/master" target="_blank">https://github.com/jingtaozf/hunchentoot/commits/master</a><br>
>><br>
>><br>
>> With Best Regards,<br>
>> jingtao.<br>
>><br>
>><br>
>> On Wed, May 22, 2013 at 1:03 PM, Hans Hübner <<a href="mailto:hans.huebner@gmail.com">hans.huebner@gmail.com</a>><br>
>> wrote:<br>
>> > Jingtao,<br>
>> ><br>
>> > thank you for your bug report. Can you please share the actual value of<br>
>> > the<br>
>> > Content-type header that triggered the bug?<br>
>> ><br>
>> > Thanks,<br>
>> > Hans<br>
>> ><br>
>> ><br>
>> > On Wed, May 22, 2013 at 4:28 AM, Jingtao Xu <<a href="mailto:jingtaozf@gmail.com">jingtaozf@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi All,<br>
>> >><br>
>> >> My website use hunchentoot and allow some external website post url<br>
>> >> request to hunchentoot server(which is necessary),and I found an error<br>
>> >> log in message.log:<br>
>> >><br>
>> >> ---------------------------------------------------<br>
>> >> Error when reading POST parameters from body: Corrupted Content-Type<br>
>> >> header:<br>
>> >> Read character #\/, but expected #\=.<br>
>> >> ---------------------------------------------------<br>
>> >><br>
>> >> I found this bug is caused in function parse-content-type when it want<br>
>> >> to get parameters<br>
>> >> by calling function read-name-value-pairs then read-name-value-pair,in<br>
>> >> lisp function read-name-value-pair,there exist an assert which raise<br>
>> >> this exception:<br>
>> >><br>
>> >> ------------------------------------------<br>
>> >> (when (or value-required-p<br>
>> >> (eql (peek-char* stream nil) #\=))<br>
>> >> (assert-char stream #\=)<br>
>> >> ------------------------------------------<br>
>> >><br>
>> >> And this will make hunchentoot thread stop the request processing and<br>
>> >> exit,which is wrong.<br>
>> >><br>
>> >> When I have a deep investigation,I found that this bug should be<br>
>> >> caused by package chuga<br>
>> >> when try to read-token,its function token-char-p will call function<br>
>> >> separatorp and allow character #\/<br>
>> >> as a token character,which is not practical well,because both java and<br>
>> >> ruby and many other launguage don't allow them as a token<br>
>> >> character,more details you can get in a discussion:<br>
>> >><br>
>> >> <a href="http://bugs.python.org/issue2193" target="_blank">http://bugs.python.org/issue2193</a><br>
>> >><br>
>> >> and a java implemention of token-char-p is like this:<br>
>> >><br>
>> >> -------------------------------------------------------------<br>
>> >><br>
>> >> private static final String tspecials = ",; ";<br>
>> >><br>
>> >> private boolean isToken(String value) {<br>
>> >> int len = value.length();<br>
>> >> for (int i = 0; i < len; i++) {<br>
>> >> char c = value.charAt(i);<br>
>> >> if (c < 0x20 || c >= 0x7f || tspecials.indexOf(c) != -1)<br>
>> >> return false;<br>
>> >> }<br>
>> >> return true;<br>
>> >> }<br>
>> >> -------------------------------------------------------------<br>
>> >><br>
>> >> Anyway, hunchentoot should not raise an exception in<br>
>> >> parse-content-type,which make my site could not receive user's<br>
>> >> request.<br>
>> >> And to be more compatible with other web client/server, hunchentoot<br>
>> >> should read token<br>
>> >> like java/ruby.<br>
>> >><br>
>> >> Hope some patch can be done to package chunga and hunchentoot to fix my<br>
>> >> issue.<br>
>> >><br>
>> >> With Best Regards,<br>
>> >> jingtao.<br>
>> >><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>