proposal: net/http: make nil *Client equivalent to zero Client #26036
Comments
One concern imo is that this reduces to the problem with DefaultTransport. Specifically, DefaultClient uses DefaultTransport which uses DefaultMaxIdleConnsPerHost which frequently bites/surprises people due to its small size (2) especially relative to DefaultTransport's MaxIdleConns (100). This proposal would add another layer of obscurity from that unfortunate default. (If we decided to increase DefaultMaxIdleConnsPerHost in Go2, this wouldn't be an issue.) You could argue that nil Resolver has a similar issue, but for stdlib's clients/transports you have the alternate option to create your own with better parameters. Also, dns is much more lightweight than http so regular usage shouldn't run into the resolver's file descriptor limitation as much as DefaultTransport runs into DefaultMaxIdleConnsPerHost limitation. Anyway, maybe the convenience is worth it. |
I think this would've been fine (and probably good) had we started with this, but doing it at this point would cause a bunch of previously-correct code in the wild to now be crash-prone. Anything that currently checks, say, an *http.Client's Per discussion with the proposal review group, I think we should decline this. |
I wonder if proposals of the type "we wish we had done this from the start" could be reconsidered for Go2 in bulk. |
net.Resolver in currently allows the following (ignoring #24330):
Note that nil *Resolver is equivalent to the zero Resolver.
I propose that using the nil net/http.*Client also be permitted. This is useful when allowing callers to specify a *Client to use for HTTP operations:
The text was updated successfully, but these errors were encountered: