Waitress through version 1.3.1 would parse the Transfer-Encoding header and only look for a single string value, if that value was not chunked it would fall through and use the Content-Length header instead. According to the HTTP standard Transfer-Encoding should be a comma separated list, with the inner-most encoding first, followed by any further transfer codings, ending with chunked. Requests sent with: "Transfer-Encoding: gzip, chunked" would incorrectly get ignored, and the request would use a Content-Length header instead to determine the body size of the HTTP message. This could allow for Waitress to treat a single request as multiple requests in the case of HTTP pipelining. This issue is fixed in Waitress 1.4.0.

Affected: PyPI: waitress

### Impact

Waitress would parse the `Transfer-Encoding` header and only look for a single string value, if that value was not `chunked` it would fall through and use the `Content-Length` header instead.

According to the HTTP standard `Transfer-Encoding` should be a comma separated list, with the inner-most encoding first, followed by any further transfer codings, ending with `chunked`.

Requests sent with:

``` Transfer-Encoding: gzip, chunked ```

Would incorrectly get ignored, and the request would use a `Content-Length` header instead to determine the body size of the HTTP message.

This could allow for Waitress to treat a single request as multiple requests in the case of HTTP pipelining.

### Patches

This issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential HTTP request confusions, and may change the behaviour of Waitress behind non-conformist proxies.

Waitress will now return a 501 Not Implemented error if the `Transfer-Encoding` is not `chunked` or contains multiple elements. Waitress does not support any transfer codings such as `gzip` or `deflate`.

The Pylons Project recommends upgrading as soon as possible, while validating that the changes in Waitress don't cause any changes in behavior.

### Workarounds

Various reverse proxies may have protections against sending potentially bad HTTP requests to the backend, and or hardening against potential issues like this. If the reverse proxy doesn't use HTTP/1.…

Security update for python-waitress

Affected: PyPI: waitress

Waitress through version 1.3.1 would parse the Transfer-Encoding header and only look for a single string value, if that value was not chunked it would fall through and use the Content-Length header instead. According to the HTTP standard Transfer-Encoding should be a comma separated list, with the inner-most encoding first, followed by any further transfer codings, ending with chunked. Requests sent with: "Transfer-Encoding: gzip, chunked" would incorrectly get ignored, and the request would use a Content-Length header instead to determine the body size of the HTTP message. This could allow for Waitress to treat a single request as multiple requests in the case of HTTP pipelining. This issue is fixed in Waitress 1.4.0.

waitress: HTTP request smuggling through LF vs CRLF handling waitress: HTTP request smuggling through invalid Transfer-Encoding waitress: HTTP Request Smuggling through Invalid whitespace characters in headers

Security update for python-waitress

Affected: Ubuntu:16.04:LTS: waitress, Ubuntu:18.04:LTS: waitress

Waitress through version 1.3.1 would parse the Transfer-Encoding header and only look for a single string value, if that value was not chunked it would fall through and use the Content-Length header instead. According to the HTTP standard Transfer-Encoding should be a comma separated list, with the inner-most encoding first, followed by any further transfer codings, ending with chunked. Requests sent with: "Transfer-Encoding: gzip, chunked" would incorrectly get ignored, and the request would use a Content-Length header instead to determine the body size of the HTTP message. This could allow for Waitress to treat a single request as multiple requests in the case of HTTP pipelining. This issue is fixed in Waitress 1.4.0.