nginx 0.7.6 sends original POST body in proxied GET subrequests from SSI

piespy piespy at gmail.com
Tue Jul 8 18:22:45 MSD 2008


Apologies if you get this twice, apparently the first time I sent it my
confirmation hadn't been processed yet.

I have a PHP script (proxied via Apache) that accepts file uploads. These
are then processed by an external batch processor, which may take a long
time. To not keep the PHP script waiting for the batch process to complete,
it writes a temporary file containing SSI include requests, and gives that
file back to nginx via X-Accel-Redirect. This way nginx can wait for
completion (when the first SSI include becomes ready), and then send the
second SSI include to another PHP script that reports the batch process
result to the browser.

However, when contacting the second PHP script, nginx resends the original
POST body even though the subrequest correctly uses the GET method (since
0.6.26). I have verified this using tcpdump, the GET request has a
Content-Length header equal to the original POST body length, and a
Content-Type of e.g. "multipart/form-data;
boundary=----------uwPZJQ9jJJ0O7Q94Bs8ae1", followed by the POST body.

Apparently this confuses PHP or Apache, so it closes the connection before
nginx is ready, which causes nginx to consider the SSI include to have
failed, with the following log message:

2008/07/08 14:29:34 [error] 14064#0: *16 upstream prematurely closed
connection while reading response header from upstream, client: [...]

The basic setup works fine when doing a POST without a file upload. But
still, I think nginx should send neither Content-Length, Content-Type nor
the POST body content in a GET subrequest (i.e., afaict, any of them).


I've tried to fix it by clearing sr->request_body in line 1789 of
ngx_http_core_module.c, but while that gets rid of the actual body content,
the Content-Length and Content-Type headers are still there and I've been
unable to remove these from the subrequest.

Any help is welcome, thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080708/b82fa0fe/attachment.html>


More information about the nginx mailing list