-
Bug
-
Resolution: Done
-
Major
-
None
-
False
-
None
-
False
-
-
Goal: Provide fallback to the optional last parameter according to OCI tag pagination spec
Why is this important: Quay(.io) currently uses an implementation using the RFC5988 standard to paginate the result set of the /v2/<name>/tags/list OCI endpoint, leveraging a token called next_page containing an encrypted, time-limited token containing the database row identifier of the last tag in the result set. While the OCI distribution spec previously favored the use of the combination of n and last to paginate through the tag list (/v2/<name>/tags/list?n=<int>&last=<tagname> it now recommends the use of the Link header according to RFC5988. spec: https://github.com/opencontainers/distribution-spec/blob/main/spec.md#content-discovery
The use of last is still covered by OCI distribution spec and even though it recommends clients preferring the Link header, there are significant number of older clients out there in enterprise environments, that rely on the usage of last
Required deliverables:
- Support the n parameter as per the OCI spec to drive the amount of tags per page
- Support the last parameter, as a way to drive the tag pagination
- Raise HTTP 413 TAG_LIMIT_EXCEEDED if n is higher than our configured maximum amount of tags per page in Quay (this strictly speaking is not OCI compliant but a conscious choice to protect Quay.io against DoS)
- The amount of maximum tags per page configured in Quay has to minimally be 100
- incorporates
-
RFE-5065 Adopt looming OCI changes regarding pagination in Quay.io
- Accepted
- relates to
-
PROJQUAY-7327 Stage.quay.io should not return latest tag and link header with API "/v2/{repo}/tags/list?n=0"
- Testing
- links to
-
RHBA-2024:133513 Red Hat Quay v3.12.0 bug fix release
- mentioned on