Connections are not closed when chunked message bodies fail to parse.

[kenballus]

I'm submitting a ...

• bug report
• feature request
• question about the decisions made in the repository

Do you want to request a feature or report a bug?
Report a bug.

What is the current behavior?
When CherryPy receives a request pipeline in which the first request has an invalid chunked message body, it makes a guess at where the next request begins, and starts parsing again from there. Becuase there's no good way to know where the invalid chunked message body should end, this is considered bad. This bug can cause CherryPy to issue two responses to some invalid requests, which may lead to response queue desynchronization when CherryPy is paired with a gateway server that forwards chunked messages that CherryPy would consider invalid.

If the current behavior is a bug, please provide the steps to reproduce and if possible a screenshots and logs of the problem. If you can, show us your code.

1. Start a CherryPy server, such as this one.
2. Send it a request with an invalid message body, then pipeline another request after it:

printf 'POST / HTTP/1.1\r\nHost: whatever\r\nTransfer-Encoding: chunked\r\n\r\nINVALID!!\r\nGET / HTTP/1.1\r\nHost: a\r\n\r\n' | nc localhost 80

3. Observe that two responses are received, even though the invalid chunked message body of the first request should invalidate the connection¹:

HTTP/1.1 400 Bad Request
Content-Type: text/html;charset=utf-8
Server: CherryPy/18.9.1.dev25+g6387a2b8
Date: Wed, 14 Feb 2024 22:47:52 GMT
Content-Length: 2440

...
HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
Server: CherryPy/18.9.1.dev25+g6387a2b8
Date: Wed, 14 Feb 2024 22:47:52 GMT
Content-Length: 97

...

What is the expected behavior?
A 400 response should be received, and then the connection should be closed due to the fact that the first request's message body is invalid.

What is the motivation / use case for changing the behavior?
Guessing about where message bodies begin and end is a recipe for semantic gap attacks like request smuggling, cache poisoning, and response queue poisoning.

Please tell us about your environment:

• Cheroot version: 10.0.1.dev35+g0fd16f0c
• CherryPy version: 18.9.1.dev25+g6387a2b8
• Python version: Python 3.11.2
• OS: Linux 28844c43ea34 6.7.2-arch1-2 #1 SMP PREEMPT_DYNAMIC Wed, 31 Jan 2024 09:22:15 +0000 x86_64 GNU/Linux
• Browser: N/A

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, e.g. stackoverflow, gitter, etc.)
This bug was found with the HTTP Garden

Footnotes

1. The 400 error status is due to a try-except block in the linked script. If not for that block, this would be a 500. ↩