From 87f4a24c0d72d16c0117f4b7e23916ade58ff3ae Mon Sep 17 00:00:00 2001 From: Sargun Dhillon Date: Wed, 16 Jun 2021 19:45:15 -0700 Subject: [PATCH] Explain how clients can adopt automatic content discovery Although the specification states that registries should start an upload on a failed mount, certain registry implementations may not properly implement this behaviour. This explicitly states that clients MAY adopt the automatic content discovery behaviour immediately, but MAY want to be defensive to non-compliant registries. Signed-off-by: Sargun Dhillon --- FAQ.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/FAQ.md b/FAQ.md index 0cf6496e..58ba46ce 100644 --- a/FAQ.md +++ b/FAQ.md @@ -68,3 +68,10 @@ choose to expire it after, for example, a minute or an hour, in the case that yo **Q: What happens if the `` (last) parameter does not exist?** There is no suggested behavior in the specification for what to do if the tag does not exist. Registries might consider ignoring te parameter, or assuming a non-existing tag is at the start or the end of the sorted list. In the first case, at the start of the list would imply returning the entire set of tags. In the second cast, at the end of the list would imply returningan empty list, as it references the last tag onward (an empty set). + +**Q: How are clients expected to adopt (and probe for) automatic mount origin discovery?** + +The process of mounting a blob is supposed to fail in such a way that if a blob cannot be cross-mounted, the registry the registry initiates an upload. +Clients should try to use the automatic content mount origin discovery mechanism when they do not know of an origin in the registry with the requisite blob. +Nonconformant registries may return a non-201 or non-202 error code. +If the client is trying to be defensive to nonconformant registries, and receives a non-201 or non-202 error code, it should fall back to [pushing the blob](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#pushing-blobs).