-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Read response body for TCP connection reuse #1576
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
Conversation
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
Codecov Report
@@ Coverage Diff @@
## master #1576 +/- ##
==========================================
+ Coverage 67.95% 67.98% +0.03%
==========================================
Files 96 96
Lines 8762 8772 +10
==========================================
+ Hits 5954 5964 +10
Misses 1898 1898
Partials 910 910
Continue to review full report at Codecov.
|
@googlebot I fixed it. |
… to reuse the same underlying TCP connection - @itsksaurabh
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @itsksaurabh !
LGTM.
Awaiting second LGTM before merging.
@gmlewis It's my pleasure! :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why this says I haven't reviewed it, which I obviously have in the Conversation thread.
Still awaiting a second LGTM before merging.
github/github.go
Outdated
io.CopyN(ioutil.Discard, resp.Body, maxBodySlurpSize) | ||
} | ||
|
||
if rerr := resp.Body.Close(); err == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, this if condition can be removed because err
is not part of the named return values. Therefore, the error is never returned if any occur.
Nonetheless, it's a really interesting issue you fixed 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@philippfranke Thank you for the review. I am glad that you liked the PR.
Yes, I also agree with your point. There is no need to check for error as it is not part of the named return values. Also, If it fails, the Transport won't reuse it anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@philippfranke I just changed the code. Please let me know if it seems good to you or if some improvements are needed. Thanks! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thank you for the approval @philippfranke |
Thank you, @philippfranke ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if resp.ContentLength == -1
not needed here because it's int64 and it is always less than -1 if less than 2048
Checking resp for nil is unnecessary if the code is written according to Go standards because if err != nil is returned then resp must be nil
Generally you had to write resp.ContentLength <= 2048
instead 565 and 566 strings
Yes, @bvaliev - this PR has issues. PRs are welcome and we'll review proposed changes. |
@bvaliev I am not sure about everything you mentioned above. :)
https://golang.org/pkg/net/http/ Do you have them somewhere specified in the docs? If so I would love to learn from it. Thanks! |
@gmlewis Thank you for your time on this PR. I would like to share with you that the latest official Go Http package does connection reuse internally now in the same way I did in the PR as you could see here. This shows the changes were needed indeed. So now, it is possible to clean up the code. I have created a PR #1645 for it and now we could happily remove the code. Please have a look :) |
According to the official Go docs:
https://golang.org/pkg/net/http/#Body
To ensure http.Client connection reuse, I did the following things:
Closes #1575