OpenLiteSpeed improperly handles requests with both `Transfer-Encoding` and `Content-Length`, in that order

[kenballus]

The HTTP RFCs specify that messages containing both Content-Length and Transfer-Encoding headers are to be handled by either

1. discarding the Content-Length header, or
2. rejecting the request with status 400.

OLS does this correctly when the Transfer-Encoding header comes after the Content-Length header, but not when it comes before.

For example, if you send the following request to OLS, the Content-Length header will be incorrectly prioritized over the Transfer-Encoding header.

POST / HTTP/1.1\r\n
Host: whatever\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 5\r\n
\r\n
0\r\n
\r\n

This behavior exists both when OLS is acting as an origin and as a proxy.

[litespeedtech]

Hi, this should be fixed in 1.8.3 .

[kenballus]

Confirmed.