The trouble is you would also have to parse the Transfer-Encoding field, and have special logic for responses where Content-Length is not needed or irrelevant (certain combinations of method and status code). And even then you risk breaking rare or custom methods and status codes. All this seems complex and at the wrong layer. A server shouldn’t be parsing the header fields it just generated.

Perhaps there could be a new HTTP 1.1 mode (separate from protocol_version) that still closed the connection by default, but had a clearer API for keeping the connection open that the programmer can use in the right circumstances. But I had this thought before (see Issue 21224), and it didn’t seem beneficial.

What’s your use case? Why not just stick with HTTP 1.0, or update the server code to either close the connection or use chunked encoding?