#208 closed defect (invalid)
Nginx should give an error claiming lack of support for chunked encoding when Transfer-Encoding: chunked header is found
| Reported by: | Andrés .G Aragoneses | Owned by: | somebody |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | 1.1.x |
| Keywords: | Cc: | ||
| uname -a: | Linux andresubuntu 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.1.19
TLS SNI support enabled configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-auth-pam --add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-upstream-fair --add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-dav-ext-module |
||
Description
Been banging my head against the wall for hours, and I want to prevent the same to others.
After a lot of investigation, I found out that nginx doesn't support Transfer-Encoding: chunked from the source (tested with fastcgi). Yes, nginx will send responses with Transfer-Encoding: chunked, but when receiving them it will wrap them incorrectly.
My guess is that I need this module for it to work: http://wiki.nginx.org/HttpChunkinModule
That's fine, but to prevent others to bang their heads against the wall, nginx should error out if that module is not installed and the response received from fastcgi contains a Transfer-Encoding: chunked header.
That's all.
If I receive any hints of how to fix this bug, I may have a crack at it, although my C skills are a bit rusty at the moment.
Thanks
Change History (5)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
There's no such thing as "Transfer-Encoding: chunked" in FastCGI protocol. Seems you have just shot yourself in the foot.
Furthermore, see RFC 3875 (section 6.3.4):
The script MUST NOT return any header fields that relate to
client-side communication issues and could affect the server's
ability to send the response to the client. The server MAY remove
any such header fields returned by the client. It SHOULD resolve any
conflicts between header fields returned by the script and header
fields that it would otherwise send itself.
and nginx does, it removes Transfer-Encoding header from the FastCGI response.
The HttpChunkinModule is about chunked transfer-encoding in POST/PUT requests from a client.
comment:3 by , 12 years ago
Sorry, I didn't mean that in my scenario the "Transfer-Encoding: chunked" element is sent through FastCGI. I meant that the HTTP responses from my application server contain the "Transfer-Encoding: chunked" header.
nginx not only does not remove the Transfer-Encoding header, it exposes it, but interprets the response wrongly. The source response is, as an example:
3\r\nFoo\r\n0\r\n
(size of next chunk, separator, chunk data, separator, size of last chunk --zero--, sepatator, separator)
What nginx does is, instead of exposing the HTTP response as is, it returns:
11\r\n3\r\nFoo\r\n0\r\n\r\n0\r\n
So this is obviously a bug in nginx. You see what I mean?
comment:4 by , 12 years ago
(It's interpreting the whole chunk-sequence as a chunk itself, 11 is the size of the chunks plus the metadata of the chunks)
comment:5 by , 12 years ago
Could you clarify things a bit, how does your application communicate with nginx? Or what nginx upstream module do you use? Is it ngx_http_proxy_module?
Googling a bit, it seems that nginx should be sending 411 errors already when this happens.
But maybe those errors are only sent when nginx receives a POST/PUT request (from the user-agent)?
In my case, I'm talking about a GET (not POST/PUT) response (not request) from fastcgi.