[hunchentoot-devel] Timing out when reading long post requests?

[Vsevolod Dyomkin]

One thing, that I stumbled upon working with Drakma, is the treatment of EOL
in Chunga.
Maybe, (setf chunga:*accept-bogus-eols* t) might help.

Best,
Vsevolod


On Thu, Jul 7, 2011 at 10:20 AM, Oleg Sivokon <olegsivokon at gmail.com> wrote:

> Hi Austin. I did try parsing the same XML outside the acceptor function,
> but using the same code, and it worked. It also worked if I did like you
> suggested:
>
> (defun analytics-service ()
>   (save-parsed-events
>    (dom:first-child
>     (with-input-from-string
> (stream (hunchentoot:raw-post-data
>  :request hunchentoot:*request*
>  :force-text t))
>       (cxml:parse-stream stream)
>       (cxml-dom:make-dom-builder))))
>   "ok")
>
> i.e. if I change the acceptor to look like this - no error and the data is
> parsed and logged, streams closed etc. It only happens in my original code.
> I also read in docs that
>
> If, however, you provide a true value for want-stream, the other parameters
> are ignored and you'll get the content (flexi) stream to read from it
> yourself. It is then your responsibility to read the correct amount of data,
> because otherwise you won't be able to return a response to the client. The
> stream will have its octet position set to 0. If the client provided a
> Content-Length header, the stream will also have a corresponding bound, so
> no matter whether the client used chunked encoding or not, you can always
> read until EOF.
>
> I've verified that content-length is correct, there isn't a null byte
> (Flash sends null byte if you are using XMLSocket class, but this is an HTTP
> request made by URLLoader). So it looks like something wrong with the stream
> generated by Hunchentoot, or, probably CXML doesn't like that particular
> kind of streams?
>
> Best.
>
> Oleg
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110707/26f39ee0/attachment.html>