ngx_http_uwsgi_module removes chunked-encoding, but doesn't modify Transfer-Encoding header

[dener.kup@…]

It looks like that ngx_http_uwsgi_module removes chunked encoding from the given request, but doesn't remove 'chunked' word from Transfer-Encoding header.

​Documentation for uwsgi_request_buffering says that chunked encoding is always eliminated before proxying to upstream:

When HTTP/1.1 chunked transfer encoding is used to send the original request body, the request body will be buffered regardless of the directive value.

Upstream receives both CONTENT_LENGTH and HTTP_TRANSFER_ENCODING with 'chunked' specifier inside. In a case of uwsgi + werkzeug/flask as upstream that leads to invalid werkzeug behaviour as it ​ignores Content-Length due to 4.4 of ​RFC2616:

Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored.

Minimal docker-compose project that demonstrates the problem is attached. Following steps reproduce the problem:

1. unpack project
2. docker-compose up --build
3. cat request | nc localhost 8080
4. see headers and request body in service logs:

   app_1    | {'CONTENT_LENGTH': '6',  <--------
   
   app_1    |  'CONTENT_TYPE': 'text/plain',
   app_1    |  'DOCUMENT_ROOT': '/etc/nginx/html',
   app_1    |  'HTTP_ACCEPT': '*/*',
   app_1    |  'HTTP_CONTENT_TYPE': 'text/plain',
   app_1    |  'HTTP_HOST': 'localhost:8080',
   
   app_1    |  'HTTP_TRANSFER_ENCODING': 'chunked', <--------
   
   app_1    |  'PATH_INFO': '/',
   app_1    |  'QUERY_STRING': '',
   app_1    |  'REMOTE_ADDR': '127.0.0.1',
   app_1    |  'REMOTE_PORT': '40198',
   app_1    |  'REQUEST_METHOD': 'POST',
   app_1    |  'REQUEST_SCHEME': 'http',
   app_1    |  'REQUEST_URI': '/',
   app_1    |  'SERVER_NAME': '',
   app_1    |  'SERVER_PORT': '8080',
   app_1    |  'SERVER_PROTOCOL': 'HTTP/1.1',
   app_1    |  'uwsgi.node': b'denisnotebook',
   app_1    |  'uwsgi.version': b'2.0.20',
   app_1    |  'wsgi.errors': <_io.TextIOWrapper name=2 mode='w' encoding='ANSI_X3.4-1968'>,
   app_1    |  'wsgi.file_wrapper': <built-in function uwsgi_sendfile>,
   app_1    |  'wsgi.input': <uwsgi._Input object at 0x7f613291ea30>,
   app_1    |  'wsgi.multiprocess': False,
   app_1    |  'wsgi.multithread': False,
   app_1    |  'wsgi.run_once': False,
   app_1    |  'wsgi.url_scheme': 'http',
   app_1    |  'wsgi.version': (1, 0)}
   
   app_1    | wsgi.input b'foobar' <--------
   

5. The screenshot shows the data that uwsgi receives. You can see there is no chunks lengths in request body. Data was captured by tcpdump and visualized via wireshark.

PS: there is no 1.21.6 in Version dropdown. So I leave it unset.

[Maxim Dounin]

It looks like that ngx_http_uwsgi_module removes chunked encoding from the given request, but doesn't remove 'chunked' word from Transfer-Encoding header.

The HTTP_* uwsgi parameters (AKA environment variables) reflect the request headers of the HTTP request received by nginx. It does contain all the headers received from the client, including hop-by-hop headers, such as Connection and Transfer-Encoding. These variables are not expected to be used by the application to parse the request body: they apply to the HTTP request from the client, not to the uwsgi request from nginx to the application.

To read the request body over uwsgi, the ​CONTENT_LENGTH variable should be used instead, much like with other CGI-like protocols. See also ​RFC 3875 section 4.2, Request Message-Body.

Upstream receives both CONTENT_LENGTH and HTTP_TRANSFER_ENCODING with 'chunked' specifier inside. In a case of uwsgi + werkzeug/flask as upstream that leads to invalid werkzeug behaviour as it ​ignores Content-Length due to 4.4 of ​RFC2616:

This looks like something to be fixed in werkzeug. The request body in uwsgi request does not use any transfer encodings and has nothing do with HTTP/1.1 and chunked transfer encoding, even if it is used between nginx and the client and/or indicated by the HTTP_* variables.

Just in case its not clear, an obvious workaround on nginx side would be to use something like:

uwsgi_param HTTP_TRANSFER_ENCODING "";

This will force-remove the variable in question, see ​uwsgi_param.

[dener.kup@…]

Maxim, thanks for the reply! To be honest, I wasn't completely sure whether it is the nginx problem or uwsgi or werkzeug, as I can't find any good specification on uwsgi protocol.

I will go with this problem to werkzeug team and will post a link to the new issue on their side here.

We have applied similiar to yours workaround in werkzeug middleware. We don't remove all contents of Transfer-Encoding, but remove only 'chunked' words.

[dener.kup@…]

Here is the link to the issue in werkzeug: ​https://github.com/pallets/werkzeug/issues/2346