Skip to content
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

Closed
andybons opened this issue Mar 26, 2020 · 4 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@andybons
Copy link
Member

With https://golang.org/cl/221818, we do explicit checks to see if a Response from a RoundTripper is nil or has a nil Body, returning an error if so. This is causing some test code to fail. A contrived example:

type fakeTransport func(*http.Request) (*http.Response, error)

func (f fakeTransport) RoundTrip(req *http.Request) (*http.Response, error) {
  return f(req)
}

...

func TestFoo(t *testing.T) {
  transport := fakeTransport(func(req *http.Request) (*http.Response, error) {
    return &http.Response{StatusCode: http.StatusOK}, nil
  })
  client := &http.Client{Transport: transport}
  // use client, get panic
  ...
}

It’s documented that http.Client.Do will always return a non-nil Body if its error is nil.

Should we be enforcing a non-nil Body in these scenarios? My general feeling is yes, though creating a NopCloser body pulls in ioutil and likely another package like strings or bytes for their NewReader functions in these cases.

Thoughts, @bcmills?

@andybons andybons added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker labels Mar 26, 2020
@andybons andybons added this to the Go1.15 milestone Mar 26, 2020
@bcmills
Copy link
Contributor

bcmills commented Mar 26, 2020

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:

 // … Callers
 // should not mutate or reuse the request until the Response's
 // Body has been closed.

which to me implies a non-nil Body. But perhaps it could be construed to mean “until the Response's body has been closed if non-nil”.

@andybons
Copy link
Member Author

Whatever you think is best.

@ianlancetaylor
Copy link
Contributor

Also CC @bradfitz

@bcmills bcmills self-assigned this Mar 27, 2020
@gopherbot
Copy link

Change https://golang.org/cl/225717 mentions this issue: net/http: treat a nil Body from a custom RoundTripper as an empty one

@bcmills bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 27, 2020
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 27, 2020
atc0005 added a commit to atc0005/go-teams-notify that referenced this issue Aug 27, 2020
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
@golang golang locked and limited conversation to collaborators Mar 31, 2021
@rsc rsc unassigned bcmills Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

4 participants