Proposing a Warg-Registry-Hint response header

[calvinrp]

Proposing a new Warg-Registry-Hint response header that clients may use to make further requests with the Warg-Registry request header. Just for the response of POST /v1/fetch/logs API endpoint.

For namespaces not defined in the operator log, the client should still attempt to fetch those logs from the registry. If the registry responds with one or more Warg-Registry-Hint headers of the form, Warg-Registry-Hint: <namespace>=<hostname>, then the client may choose to adopt the given namespace registry mappings temporarily (for the current operation) or permanently, proceeding with subsequent fetch logs requests using the Warg-Registry: <hostname> request header for the respective <namespace>.

This would be a non-breaking, additive change. Only clients that looked for the Warg-Registry-Hint header would adopt the behavior. It is a way of addressing usability concerns when users are trying to download packages that are known to a Warg registry service but aren't yet apart of the operator log namespace imports.

[lann]

the client follows up with subsequent fetch logs requests

I would probably word this as something like "the client may choose to adopt the given namespace registry mappings temporarily (for the current operation) or permanently".

A general-purpose tool might choose to only consider mappings that come from its "home" / default registry, and possibly with some configurability (never/always/prompt).

[calvinrp]

Yeah, we already started prototyping the local config.

This feature proposal is just to make the user experience more intuitive and not require user action of adding entries to the operator log before they can download packages that they expect to be available by default.

[lann]

I believe this should only apply to "top-level" queries, right? If a client is fetching dependencies then it should expect the top-level package's origin registry to serve all dependencies directly.

[lann]

And really it would only be applicable to "bootstrapping" into a log by package name, e.g. cargo component add lann:left-pad? I think that would suggest that this feature should be opt-in at the library API level as well.

[calvinrp]

Yeah, not for resolving dependencies. All dependencies of published packages should have entries in the operator log of the registry that it was published to.