Epic Goal

• Update pagination so that it is compliant with current and upcoming OCI changes

Why is this important?

• Users expect Quay to be fully OCI compliant, it is table stakes for being a registry

Scenarios

1. Allow the use of the n parameter in the API endpoint /v2/<name>/tags/list?n=<integer> and optionally return a Link header in the response
2. Client should now expect the registry to respond with HTTP 413 TAG_LIMIT_EXCEEDED when the registry determines the required amount of requested tags per page is too high
3. The last parameter can be used in combination with the n parameter and Quay will return HTTP 413 if n is higher than our configured limit for tags per page, but never when n is below 100
4. The existing next_page parameter will remain available to retain compatibility with existing client implementations, but its use is mutually exclusive with last.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. https://github.com/opencontainers/distribution-spec/blob/main/spec.md
2. https://github.com/opencontainers/distribution-spec/pull/47

Open questions::

1. Are the above scenarios going to change prior to implementation?
2. Should we wait to merge until OCI adoption?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>