-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Unsafe concurrent modification of http.DefaultClient #1173
Comments
So in cases like the one described, wouldn't the correct (and simplest) solution be to explicitly create a new If not, how do you propose that this issue be solved? |
Ideally these methods would not need to modify the underlying client for each request in order to achieve the desired behavior. At the very least I think the docs need to be explicit about the modifying behavior - currently passing It might make sense to make a new |
When the
RepositoriesService.DownloadReleaseAsset
method is called, thehttp.Client
pointed to bygithub.Client
is modified in order to temporarily overridehttp.Client.CheckRedirect
for the span of a single request. Async.Mutex
is used on thegithub.Client
struct to prevent multiple concurrent modifications by the same instance ofgithub.Client
- however, if multiple instances refer to the samehttp.Client
and each call this method, it becomes unsafe.The intent may be that each
github.Client
receives its ownhttp.Client
to mitigate this type of issue, but the fact thatgithub.NewClient
specifically defaults to usinghttp.DefaultClient
when one is not provided suggests otherwise. This not only affects multiple concurrentgithub.Client
instances, it will also (potentially) impact any other code in the program making use ofhttp.DefaultClient
with no indication.This behavior presented itself in a case where multiple clients were created to download release assets from different sources. The underlying
http.Client
passed toNewClient
wasnil
in the case that authentication was not required, which led to the case above withhttp.DefaultClient
being shared by multiple github clients. The ultimate effect was that redirect URLs returned by different method calls were mismatched (i.e. the request to download repoA
release asset1
instead returned a URL for downloading repoB
's release asset2
), leading to data corruption.Additionally, I did notice this method which performs a similar modification of the underlying
http.Client
without locking the client's mutex.The text was updated successfully, but these errors were encountered: