Nginx removes Content-Length header for chunked content
Unfortunately, I can't comment on cnst's post - so I'm going to answer here.
nginx_http_proxy module by default talks with the upstream in HTTP/1.0.
This can be changed with the directive
This might also be the cause for your script to return a HTTP/1.0 answer, although chunked coding and status code
307 don't exist in this version.
You shouldn't use chunked coding with a redirect either, as this doesn't really make sense.
Additionally, it seems like nginx doesn't pass chunks from the upstream to the client one by one, but it buffers the upstream's response.
Content-Length header field is ignored because it is against the definition.
I had to look at the source code of the module because all this appears to be undocumented.
You may want to try out the
nginx_tcp_proxy_module to proxy the chunked content as raw TCP data: Module at Github
nginx_http_proxymodule has support for
X-Accel-*headers, of which one (
X-Accel-Buffering: yes|no) controls whether the response should be buffered or not.
Adding this header (
X-Accel-Buffering: no) to the backend's response will cause nginx to directly pass chunks to the client.
This header allows to control buffering on an per-request basis.
The module also has a configuration directive
proxy_buffering to enable or disable response buffering (not buffering means sending chunks will work).
Proxy buffering (both header and directive based) is documented here.
As Lukas alludet to, HTTP 1.1 prohibits
Content-Length if there's a
3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
You have not specifically elaborated why your script needs chunked encoding in the first place, especially with a redirect response.
I see a multitude of problems here.
Transfer-Encoding: chunkedis an
HTTP/1.1feature (and your script seems to be replying with an
there is no
the whole purpose of
chunkedis that you don't know what your
Content-Lengthwould have been, so,
chunkedis used in place of providing the length within
Content-Length, where instead lengths are provided within the body of the response, intermixed with the actual content; it would be pointless for a script to be generating both headers upfront
I'm not personally familiar with
chunked, but as per the basic info at http://en.wikipedia.org/wiki/Chunked_transfer_encoding and also http://tools.ietf.org/html/rfc2616#section-3.6.1, I would guesstimate that your script's whole handling of the chunked encoding may be completely wrong.
If the above still doesn't cover it, and in all actuality otherwise, it is also unclear why a reply with a
302 http status code should be provided with a "weird" encoding. There was recently a similar discussion in the nginx mailing list about
410 Gone and other error pages always excluded from
gzip compression, and I think the sentiment would equally apply here. (http://mailman.nginx.org/pipermail/nginx/2013-March/037890.html)