HTTP libraries in general are tough because HTTP in practice requires understanding of at least DNS and TLS and in a lot of cases L4 networking as well. If you try to target application developers you end up with leaky abstractions (unread H/1 body draining behavior when you don't even know what HTTP version you're using) or a library low level enough that application developers don't know how to use it. See rust's hyper and reqwest as an example of an attempt at that split.
replyAs someone who once attempted implementing a http library, I can assure you that the protocol itself is at least equally tough as being aware of all the TLS / L4 edge cases.
replyI’d argue that implementing both TCP and IP from scratch is easier than implementing an HTTP library.
https://pkg.go.dev/net/http#Client.Do
reply> Note, however, that Transport will automatically try to read a Response Body to EOF asynchronously up to a conservative limit when a Body is closed.
Similar wording appears in a few other places; search for “asynchronously”.
Oh, good. Not exactly where I expected it but it's there at least.
replyI think it is reasonable for it to not be documented directly on Close. Close is arguably too high level for this: for example, on HTTP/2 this doesn't do what you would intend at all, since the request lifecycle is completely untethered from any underlying socket. If you really wanted to slam the connection closed ASAP it does actually seem more logical to grab the underlying connection and directly force it closed, even though this feels uglier since it requires knowing the underlying layers. To me this "Close" is logically from the perspective of the HTTP request itself and if I'm not getting myself confused and misunderstanding it doesn't really close the connection anyways (e.g. if there is no body and the connection is keep-alive'd, this wouldn't close the underlying connection, right?)
replyA CloseNow() error method would make sense.
reply