This looks good. I'm just wondering about the Connection: close -> is_close being gone. Could we map out all the scenarios on some form like this?

Here's a stab:

HTTP/1.0
- no header                    => close
- content-length               => close
- content-length + keep-alive  => reuse
- connection: close + whatever => close
- te: chunked                  => error?

HTTP/1.1
- no header                    => chunked
- content-length               => reuse
- content-length + keep-alive  => reuse
- connection: close + whatever => close
- te: chunked                  => chunked

What I concluded from my re-reading of the RFCs is that Connection: close / Connection: keep-alive should be separate from body length calculation. Body length calculation determines when we can consider a body "done." But Connection: determines what we can do with the connection once it's done:

https://datatracker.ietf.org/doc/html/rfc9112#name-tear-down

A client that receives a "close" connection option MUST cease sending requests on that connection and close the connection after reading the response message containing the "close" connection option; if additional pipelined requests had been sent on the connection, the client SHOULD NOT assume that they will be processed by the server.

So what we need is a change in the pooling code to honor Connection: close by dropping the connection; otherwise we might try sending a request on a connection that the server has closed. I'll add that to this PR.

Alright, check out the updates for connection_option and see what you think!