Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#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: knocte@… 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 Changed 6 years ago by knocte@…

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.

comment:2 Changed 6 years ago by vbart

  • Resolution set to invalid
  • Status changed from new to closed

There's no such thing as "Transfer-Encoding: chunked" in FastCGI protocol. Seems you have 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.

Last edited 6 years ago by vbart (previous) (diff)

comment:3 Changed 6 years ago by knocte@…

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 Changed 6 years ago by knocte@…

(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 Changed 6 years ago by vbart

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?

Note: See TracTickets for help on using tickets.