Skip to content

Conversation

@jpoehnelt
Copy link

@jpoehnelt jpoehnelt commented Nov 18, 2025

closes #13318

  • Conditionally set Accept header in downloadFromGitHubRelease.
  • Use application/vnd.github+json for source tarballs to correctly handle redirects.
  • Retain application/octet-stream for binary release assets.
  • Update downloadFile to support custom headers.
  • Add tests to verify correct content negotiation headers.

@jpoehnelt jpoehnelt requested a review from a team as a code owner November 18, 2025 19:48
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @jpoehnelt, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical issue preventing the successful download of source tarballs from GitHub releases by ensuring the correct Accept header is sent during the HTTP request. By distinguishing between binary assets and source tarballs, the system can now properly negotiate content with the GitHub API, resolving the 415 error and enabling seamless downloads. The underlying download utility was also enhanced to support custom headers, providing a more robust solution.

Highlights

  • GitHub API 415 Error Resolution: Fixed an issue where downloading source tarballs from GitHub releases resulted in a 415 'Unsupported Media Type' error due to incorrect Accept headers.
  • Conditional Accept Header: The downloadFromGitHubRelease function now conditionally sets the Accept header: application/octet-stream for binary release assets and application/vnd.github+json for source tarballs.
  • Custom Headers for Download Function: The downloadFile utility function has been updated to support custom HTTP headers, allowing for more flexible content negotiation.
  • New Test Coverage: Added new tests to verify that the correct Accept headers are used when downloading both binary assets and source tarballs from GitHub releases.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request effectively resolves a GitHub API 415 error by conditionally setting the Accept header for different download types. The changes are logical, with application/vnd.github+json used for source tarballs and application/octet-stream for binary assets. The downloadFile function is correctly updated to handle custom headers, and the new tests provide good coverage for the changes. I have one suggestion to enhance the robustness of redirect handling.

@jpoehnelt
Copy link
Author

/gemini review

- Conditionally set Accept header in downloadFromGitHubRelease.
- Use application/vnd.github+json for source tarballs to correctly handle redirects.
- Retain application/octet-stream for binary release assets.
- Update downloadFile to support custom headers.
- Add tests to verify correct content negotiation headers.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request addresses a GitHub API 415 error for source tarballs by correctly setting the Accept header based on the asset type. The changes are logical, and the inclusion of tests to verify the new header logic is a great addition. I've found one high-severity issue regarding potential infinite redirect loops in the downloadFile function and have provided a comment explaining how to mitigate it.

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

Successfully merging this pull request may close these issues.

GitHub Extension Install Fails with 415 Unsupported Media Type

1 participant