repository_ctx: avoid duplicate Accept headers when user specifies one

[ijuren8]

Bazel’s repository download implementation currently always adds a default Accept: */* header and then appends any user-provided Accept header. As a result, when a user specifies a custom Accept header, Bazel sends multiple Accept headers instead of allowing the user’s value to override the default.

This behavior breaks use cases where correct content negotiation depends on an explicit Accept value.

One such example is mentioned in #24420 downloading private release assets from GitHub via the GitHub API, which requires Accept: application/octet-stream in order to receive the raw binary asset rather than JSON metadata.

Current Behavior
• Bazel always adds Accept: / to repository download requests.
• If the user specifies an Accept header, it is appended rather than replacing the default.
• This results in duplicate Accept headers and prevents full override of the default value.

New Behavior
• If the user explicitly specifies an Accept header, Bazel sends only that header.
• The default Accept: */* header is added only when the user does not specify one.
• This restores expected override semantics and avoids unintended content negotiation.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request extracts Accept header handling into a reusable method, addAcceptHeaders, and applies it consistently across HttpDownloadHandler and HttpUploadHandler. This is a good refactoring that improves code reuse. However, the new method subtly changes the behavior from unconditionally setting the header to conditionally adding it. My review includes a suggestion to align the new method's implementation with the original, more direct semantics to prevent potential confusion in the future.

[gemini-code-assist]

The new addAcceptHeaders method changes the behavior from unconditionally setting the Accept header (using set) to conditionally adding it only if it's not already present. While this doesn't alter functionality for the current call sites, it introduces a subtle semantic change for a protected method. To maintain the original, simpler semantics and avoid potential confusion for future developers using this method, it's recommended to use set unconditionally. This makes the method's behavior more explicit: it ensures the Accept header is set to */*.

    request.headers().set(HttpHeaderNames.ACCEPT, "*/*");

[ijuren8]

Regarding set vs add: in this context both behave the same due to the surrounding if check, so the choice is largely stylistic. The method conditionally adds a default header, and using add matches the existing add* methods in the request-building chain.

Using set here could also be read as enforcing a value, even though the guard already prevents overwriting. A conditional setAccept(...) would feel a bit odd, whereas an add* method that conditionally calls .add() aligns better with the intent and naming.

That said, I’m happy to switch to set if that’s preferred for consistency or readability.

[iancha1992]

@ijuren8 Could you please sign the CLA?