Send a User-Agent header on registry requests#753
Open
adityasingh2400 wants to merge 1 commit into
Open
Conversation
Registry requests built by RegistryClient went out without a User-Agent
header. The central request() method constructed an HTTPClientRequest and
only ever set Authorization plus any caller-supplied headers, and
AsyncHTTPClient does not add a default User-Agent of its own, so every
registry operation (manifest resolves, blob fetches, token exchanges, and
pushes) was anonymous on the wire.
HTTP/1.1 only recommends User-Agent rather than requiring it, but in
practice some registries and forward proxies reject, rate-limit, or
otherwise mishandle requests that omit it, and operators rely on it for
attribution and debugging.
The client already carried a clientID ("containerization-registry-client"
by default), but it was only used as the OAuth client_id form field when
fetching tokens, never as an HTTP header. Set the User-Agent from clientID
at the single point where requests are constructed so it applies uniformly
to every registry call including retries and token fetches. A caller that
passes its own User-Agent in the per-request headers still takes
precedence, and no duplicate header is emitted.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Registry requests built by
RegistryClientgo out without aUser-Agentheader. The centralrequest()method constructs anHTTPClientRequestand only ever setsAuthorizationplus whatever caller headers are passed, andAsyncHTTPClientdoes not add a defaultUser-Agentof its own. As a result every registry operation (manifest resolves, blob fetches, token exchanges, and pushes) is anonymous on the wire, which is what the issue reporter saw when proxying the traffic.HTTP/1.1 only recommends
User-Agentrather than requiring it, but in practice some registries and forward proxies reject, rate-limit, or otherwise mishandle requests that omit it, and operators rely on it for attribution and debugging.The client already carries a
clientID(containerization-registry-clientby default), but it was only used as the OAuthclient_idform field when fetching tokens, never as an HTTP header. This sets theUser-AgentfromclientIDat the single point where requests are constructed, so it applies uniformly to every registry call including retries and token fetches. A caller that supplies its ownUser-Agentin the per-request headers still takes precedence, and no duplicate header is emitted.Added unit tests in
ContainerizationOCITestscovering the defaultUser-Agent, propagation of a customclientID, caller override, and coexistence with other headers. With the header omitted the new tests fail (the header reads as empty); with the fix they pass. Verified locally withswift test --filter RegistryRequestHeaderTests -Xswiftc -warnings-as-errors.Reported in apple/container#1583 (the registry client lives in this repository).