Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Maybe we should use the default transport directly
https://cs.opensource.google/go/go/+/refs/tags/go1.17.3:src/net/http/transport.go;bpv=1;bpt=1;l=43?gsn=DefaultTransport&gs=kythe%3A%2F%2Fgolang.org%3Flang%3Dgo%3Fpath%3Dnet%2Fhttp%23var%2520DefaultTransport
httpClient := &http.Client{
Transport: http.DefaultTransport
},
I can't remember where these values are coming, if there are no special reasons and the default are more conservative we should use them
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.
Looks like this was implemented to support slow downloads of large files - 19f47d4
Although I'm unsure of the history around this
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 did it, but I can't remember where did I get those values, most probably from some kubernetes code, but they don't seem to apply here so I think that better to use the more conservative values from the default client, that in this case doesn't have any timeout at all for response header.
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 that the diff is removing the
ResponseHeaderTimeout: 30 * time.Second,
and increasing theIdleConnTimeout: 90 * time.Second,
and setForceAttemptHTTP2: true,
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 the goal was to reduce the IdleConnTimeout mostly. Not sure if
ForceAttemptHTTP2
affected things in any way in the past, but don't see a real need for in in the case of downloading various binaries.This change looks pretty good to me.
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.
you know better than me the network requirements here, the change lgtm too, just wanted to add more context in case you think some other change will needed
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 appreciate. Thanks @aojea! 😄