-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: checks for nil Response or Response.Body in Client.send causing some internal Google tests to fail #38095
Comments
Reading the package docs, perhaps we could relax this check. https://golang.org/pkg/net/http/#Response says (emphasis mine): // The http Client and Transport guarantee that Body is always // non-nil, even on responses without a body or responses with // a zero-length body. It is the caller's responsibility to // close Body. The default HTTP client's Transport may not // reuse HTTP/1.x "keep-alive" TCP connections if the Body is // not read to completion and closed. But https://golang.org/pkg/net/http/#RoundTripper says:
which to me implies a non-nil |
Whatever you think is best. |
Also CC @bradfitz |
Change https://golang.org/cl/225717 mentions this issue: |
CHANGES Apply fix provided by @davecheney in order to properly implement the RoundTripper interface's expected behavior: - return response and nil error OR - return nil and a non-nil error to explain failures to obtain a response I likely *over* explained this with doc comments, but I am still very much in "learning" mode here. REFERENCES - GH-46 - 2ce144f - 6db6217 - http://hassansin.github.io/Unit-Testing-http-client-in-Go - golang/go#41071 - golang/go#38095 - golang/go@2d77d33 - golang/go@12d02e7 - https://godoc.org/net/http#RoundTripper - https://godoc.org/net/http#Response - https://godoc.org/net/http#Response.Body
With https://golang.org/cl/221818, we do explicit checks to see if a
Response
from aRoundTripper
is nil or has a nilBody
, returning an error if so. This is causing some test code to fail. A contrived example:It’s documented that
http.Client.Do
will always return a non-nilBody
if its error is nil.Should we be enforcing a non-nil
Body
in these scenarios? My general feeling is yes, though creating aNopCloser
body pulls inioutil
and likely another package likestrings
orbytes
for theirNewReader
functions in these cases.Thoughts, @bcmills?
The text was updated successfully, but these errors were encountered: