A bug in functon parse-content-type.

[Hans Hübner]

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 at 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 at 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 at 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.
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130522/4de5598b/attachment.html>