Hello. 2009/10/28 Hans Hübner <hans.huebner@gmail.com>:

On Wed, Oct 28, 2009 at 01:42, Christoph Senjak <christoph.senjak@googlemail.com> wrote:

...

Can I somehow tell hunchentoot not to read and parse the post-data, but leaving raw-post-data as a binary stream which I can pass to the cgi-handler?

Hunchentoot is designed as terminating HTTP server, i.e. it does not expect to forward requests.  For this, it is required that any request body is eventually read from the stream during handler processing. Hm. Ok, then I wonder why raw-post-data exists anyway.

It should be possible to make request forwarding work, but that will require tracing the internals of Hunchentoot and finding out where and why the post body is actually read, then come up with a configurable mechanism to supress request body processing for certain requests. To me it seems like this is done inside maybe-read-post-parameters, which is called when using the post-parameters-slot-accessor. I dont see any other part where this is called. But of course, I am not sure. Modifying this function such that it doesnt read anything when - say - some flag like (dont-read-post-data *request*) is set to T, should be easy, but the question is if it is enough then to set it to T in the handler-function itself, or if this has to be done in the dispatcher already?

Before sending patches, please make sure that you've read http://weitz.de/patches.html - You may also want to post your implementation plan here before submitting a patch. Ok.

Regards, Christoph

On Wed, Oct 28, 2009 at 12:13 PM, Christoph Senjak <christoph.senjak@googlemail.com> wrote:

Hm. Ok, then I wonder why raw-post-data exists anyway.

So that you can get at the raw, unparsed data the client sent. There are more content types than multipart/form-data and application/x-www-form-urlencoded. See also what Zach wrote.

To me it seems like this is done inside maybe-read-post-parameters, which is called when using the post-parameters-slot-accessor. I dont see any other part where this is called. But of course, I am not sure. Modifying this function such that it doesnt read anything when - say - some flag like (dont-read-post-data *request*) is set to T, should be easy

But why would you want to do that? If you are forwarding a request, you shouldn't try to access the post parameters at the same time, should you? Unless my memory fails me, the request body will only be read (unless your application code does it, of course), at the beginning of START-OUTPUT to clear the stream. If you have code in place that took care of the request body already (by reading from the stream), that should be a no-op. Right now, I don't really see why you shouldn't be able to do what you want with the current code - although I haven't tried it myself.