Hello.
I am still trying to get PHP (and cgi in general) work behind Hunchentoot. The implementation of Cyrus Harmon does (besides not providing some necessary env-vars) not pass the postdata to the cgi-script. Using raw-post-data seems not to work (even when saying :want-stream nil) and always return nil as far as I saw.
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?
Regards, Christoph
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. 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.
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.
-Hans
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:32PM +0100, Christoph Senjak wrote:
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.
I wrote the patch for it some time ago to work with PayPal's "IPN" postback system of payment notification. There is a confirmation step that requires you post their post data back to them exactly as you received it.
The PDF at https://www.paypal.com/ipn has more information.
Zach
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.
-
Christoph Senjak -
Edi Weitz -
Hans Hübner -
Zach Beane