961c878e0d
Switch to using Go modules. This migrates our vendor.json to use Go 1.11's modules system, and replaces the vendor folder with the output of go mod vendor. The vendored code should remain basically the same; I believe some tree shaking of packages and support scripts/licenses/READMEs/etc. happened. This also fixes Travis and our Makefile to no longer use govendor. |
||
|---|---|---|
| .. | ||
| cleanhttp.go | ||
| doc.go | ||
| go.mod | ||
| handlers.go | ||
| LICENSE | ||
| README.md | ||
cleanhttp
Functions for accessing "clean" Go http.Client values
The Go standard library contains a default http.Client called
http.DefaultClient. It is a common idiom in Go code to start with
http.DefaultClient and tweak it as necessary, and in fact, this is
encouraged; from the http package documentation:
The Client's Transport typically has internal state (cached TCP connections), so Clients should be reused instead of created as needed. Clients are safe for concurrent use by multiple goroutines.
Unfortunately, this is a shared value, and it is not uncommon for libraries to assume that they are free to modify it at will. With enough dependencies, it can be very easy to encounter strange problems and race conditions due to manipulation of this shared value across libraries and goroutines (clients are safe for concurrent use, but writing values to the client struct itself is not protected).
Making things worse is the fact that a bare http.Client will use a default
http.Transport called http.DefaultTransport, which is another global value
that behaves the same way. So it is not simply enough to replace
http.DefaultClient with &http.Client{}.
This repository provides some simple functions to get a "clean" http.Client
-- one that uses the same default values as the Go standard library, but
returns a client that does not share any state with other clients.