In bug 8161 we replaced the deprecated Lib/cgi.py with our own function for parsing POST requests, called parse_post_request. The parse_post_request function assumes the following: 1. The size of the request body is communicated in the Content-Length header. 2. The request body can be read as one contiguous chunk. 3. If the Content-Length header is missing, the body can be read until the socket returns no more data. This means that we do not handle cases where the Transfer-Encoding header is present. In which case, there could be situations where the request body should not be read as one single chunk. We should therefore add the ability to handle POST requests using the Transfer-Encoding header to make our POST request handling more robust.
Transfer-Encoding and Content-Length should never be present in the same request, and to be able to safely make the third assumption in comment 0, we need to be sure that the request is, in fact, not using Transfer-Encoding. The parse_post_request function will therefore disallow transfer encoded requests entirely, in place of a real implementation.
Since having both Transfer-Encoding and Content-Length headers present can have security implications [1], we decided to treat such requests as "400 Bad Request". This is supported by the clear wording in the specification [2]. Even so, we may want to apply a somewhat relaxed constraint instead of always opting for bad request. The specification suggests that one can take only Transfer-Encoding into account if both headers are present [1], given that the connection is closed directly after handling the request. [1] https://www.rfc-editor.org/rfc/rfc9112#section-6.1-14 [2] https://www.rfc-editor.org/rfc/rfc9112#section-6.2-2
