-
Notifications
You must be signed in to change notification settings - Fork 18k
net/http: Transport should close body on all errors and match Client.Do docs #35015
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
Comments
Change https://golang.org/cl/202237 mentions this issue: |
Updates #35015 Change-Id: Ibfe8f72ed3887ca88ce9c1d8a29dacda72f3fe17 GitHub-Last-Rev: 4bfc56e GitHub-Pull-Request: #35014 Reviewed-on: https://go-review.googlesource.com/c/go/+/202237 Reviewed-by: Emmanuel Odeke <[email protected]> Run-TryBot: Emmanuel Odeke <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>
Change https://golang.org/cl/202239 mentions this issue: |
@odeke-em what do you think about the remaining |
Thanks for the question Luke! So in the follow-up CL I didn’t touch that
either as it is the responsibility of the alternative transport protocol.
Sure, perhaps we could update the docs but finding the right wording is
tricky because there are the first conditions for which an error will
result in a req.closeBody() regardless of the transport/protocol but also
it requires referencing Transport.RegisterProtocol, at which point I think
the prose might cause more confusion. Perhaps we could add to the line
If an alternative protocol and RoundTripper was registered with the
Transport, it is the responsibility of that RoundTripper to close the body.
But am hesitant to add more words. /cc @bradfitz
…On Sun, Oct 20, 2019 at 8:45 PM Luke Young ***@***.***> wrote:
@odeke-em <https://github.com/odeke-em> what do you think about the
remaining useRegisteredProtocol case where an error is returned by the
underlying protocol handler. In my opinion Transport shouldn't handle
that, it should be the responsibility of the protocol handler as the
handler could have already closed the request body before an error
occurred. In that case I think updating the docs so that expectation is
clear would be a good addition.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35015?email_source=notifications&email_token=ABFL3VZERH2YXHGWCY2UOU3QPUQVNA5CNFSM4JCSPOTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBY6ZDY#issuecomment-544337039>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABFL3V3BR65YC6R2W3W63IDQPUQVNANCNFSM4JCSPOTA>
.
|
I just saw CL https://go-review.googlesource.com/c/go/+/202237 by @bored-engineer (thank you Luke!) and was going to review and recommend/create a test for the CL creator.
The docs for http.Client.Do https://golang.org/pkg/net/http/#Client.Do promise that we'll always close the body even on errors and so far we missed a few spots on the trivial cases with minor oversight
go/src/net/http/transport.go
Lines 469 to 495 in 72275c0
that is:
a) if isHTTP {
b) if t.useRegisteredProtocol(req)
c) if req.Method != "" && !validMethod(req.Method) {
and I realize this is because that code has been modified piecemeal over the past decade.
This test is what we can use to bootstrap checks
which currently gives
$ go test --- FAIL: TestInvalidMethodClosesBody (0.00s) it_test.go:39: Expected body to have been closed
This issue will be to send CLs to enforce those closes as well as tests so that we don't regress.
The text was updated successfully, but these errors were encountered: