17:01 When you don't close a request body in Go
From reddit:
when you close after full body read, net/http puts the connection to the idle pool(tryPutIdle). net/http does this to reuse TCP connections with keep-alive(HTTP 1.1 ) for better performance.
when you close without a full body read just terminates the TCP connection when you neither read the body fully nor close the response body, net/http will just keep the read loop hanging(a channel wait basically). The underlying socket will be open but unused. The consequences of this are:
you'll exhaust MaxConnsPerHost. Maybe even exhaust the file descriptors limit if you somehow don't have any timeouts
the socket will stay open until you nuke the app, the timeout fires, context is canceled(e.g. browser refresh)
And finally, when you fully read but don't close, then it may get weird. If you just use http1.1, don't use gzip, and don't use any custom http.RoundTripper(tracing, metrics, etc), then… nothing will break, trust me. You'll violate the contract, however. Anything beyond that will break something. For example, with gzip enabled, not calling Close will prevent the gzip.Reader to be returned to the sync.Pool and that will decrease your performance. Some other library may do some additional cleanup/teardown that won't execute without Close on the body