[BUG]: Tarball/Zipball - Return a Task not any content

[MarkEnverus]

What happened?

https://docs.github.com/en/rest/repos/contents?apiVersion=2022-11-28#download-a-repository-archive-tar
downloading a repo gets a Location header and downloads the binary content in Zip/Tar - currently the API only returns a Task so not data is returned

dotnet-sdk/src/GitHub/Repos/Item/Item/Tarball/Item/WithRefItemRequestBuilder.cs

Line 48 in 239513d

await RequestAdapter.SendNoContentAsync(requestInfo, default, cancellationToken).ConfigureAwait(false);

Versions

.net v8
0.0.14 dotnet-sdk

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[kfcampbell]

This is interesting! GitHub returns a 302 that redirects to the actual content. That 302 (and the type of the actual content) isn't getting picked up at generation time. Kiota does follow 302s in the redirect handler by default, which we do implement, so the redirect should be getting followed.

What's interesting is that in the specification, the redirect looks like this:

        "responses": {
          "302": {
            "description": "Response",
            "headers": {
              "Location": {
                "example": "https://codeload.github.com/me/myprivate/legacy.zip/master?login=me&token=thistokenexpires",
                "schema": {
                  "type": "string"
                }
              }
            }
          }
        },

[kfcampbell]

I've filed microsoft/kiota#5208 with Kiota to double-check, but I believe this is a spec issue: we shouldn't be showing the redirect as a response in the spec, and instead we should be showing where the redirect lands us.