A bug in functon parse-content-type.

[Raymond Wiker]

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 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/634ec020/attachment.html>