Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add PUT method support for /referrers endpoint #515

Open
dmcgowan opened this issue Feb 15, 2024 · 2 comments
Open

Add PUT method support for /referrers endpoint #515

dmcgowan opened this issue Feb 15, 2024 · 2 comments
Milestone

Comments

@dmcgowan
Copy link
Member

The fallback approach adds many advantages for clients and servers. Having a dedicated /referrers endpoint adds some advantages over the current fallback approach. We can define referrer specific headers, suggest specific validation, and avoid any extra requests from clients when getting referrers. Adding PUT would allow maintaining the advantages of fallback approach with the advantages of having referrers served from a single endpoint.

@dmcgowan dmcgowan added this to the v1.2.0 milestone Feb 15, 2024
@sajayantony
Copy link
Member

Do you have any thoughts about disabling dynamic referrer generation if the referrers have been put? Basically, the set is fixed and this also might mean that a client generated index would disable attaching more referrers to an image.
Trying to see how this would compose with dynamic referrers.

@dmcgowan
Copy link
Member Author

I should probably put up my draft soon to discuss more specifics. My thought is the registry could make that determination per repository and the client would know the correct behavior based on a header returned on PUT of the subject manifest. If the PUT /v2/<name>/referrers/<digest> is accepted, then GET /v2/<name>/referrers/<digest> should return the exact same content. However, a registry could still support dynamic results via GET /v2/<name>/referrers/<digest>?artifactType=<artifactType>.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants