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

DownloadReleaseAsset breaks with renamed repository #3081

Open
mterwill opened this issue Feb 16, 2024 · 3 comments
Open

DownloadReleaseAsset breaks with renamed repository #3081

mterwill opened this issue Feb 16, 2024 · 3 comments

Comments

@mterwill
Copy link

DownloadReleaseAsset breaks when a repository is renamed. You can see a reproduction of this here on a repository that I renamed from go-github-issue-demo to go-github-issue-demo-1.

    main_test.go:57: data differs (-got +want):
          string(
        -       `{"url":"https://api.github.com/repos/mterwill/go-github-issue-demo-1/releases/assets/151970555","id":151970555,"node_id":"RA_kwDOLThgfM4JDuL7","name":"foo.txt","label":null,"uploader":{"login":"mterwill","id":5882053,"node_id":"MDQ6VXNlcjU4ODIwNTM=","avata`...,
        +       "Hello, world!\n",
          )

The code expects to receive exactly 1 redirect, which is to download the asset from the media server. However, if the repository is renamed, GitHub redirects once more to the new repository name. On following the redirect, downloadReleaseAssetFromURL code below sets a different accept header which causes the API server to respond with the release metadata rather than contents (docs):

To download the asset's binary content, set the Accept header of the request to application/octet-stream. The API will either redirect the client to the location, or stream it directly if possible. API clients should handle both a 200 or 302 response.

req.Header.Set("Accept", "*/*")

The test I linked above is a minimal reproduction but it's worth noting that we actually discovered this in a different way: attempting to download a release for a renamed private repository actually returns a 401 Unauthorized, as when the redirect is followed the client also omits authentication (for actual release asset downloads, GitHub puts a token in the query params). We were following the function documentation and passing http.DefaultClient, rather than our authenticating HTTP client that was used to originally construct the GHE API client.

@gmlewis
Copy link
Collaborator

gmlewis commented Feb 16, 2024

Could this be related to #3043 ?

@dnephin
Copy link

dnephin commented Mar 1, 2024

I don't think so, no. The two problems, as I understand them, are:

One:

req.Header.Set("Accept", "*/*")

because this API requires application/octet-stream to download the asset. This line should use that as the Accept header, not */*.

Two:

rc, err := s.downloadReleaseAssetFromURL(ctx, followRedirectsClient, loc)

uses followRedirectsClient instead of s.client.client. The documentation could be more clear about when it's not appropriate to use http.DefaultClient (when you're using private repositories).

#3051 (the PR that closed #3043) could be a problem if DownloadReleaseAsset used s.client.client to follow redirects.

@gmlewis
Copy link
Collaborator

gmlewis commented Mar 1, 2024

@dnephin - thanks for the explanation. Since you seem to have a better grasp of this than myself, would you like to put together a PR to solve these issues?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants