Presently, if a PATCH request has an invalid range, we should return a 416 Requested Range Not Satisfiable. However, the final PUT request of a chunked blob upload can also contain the final chunk with a range. If that request is received out of order (e.g. the registry did not process the previous chunk for some reason), should we allow (or require) a 416 status code on the PUT?
Here's the relevant section of the spec:
https://github.com/opencontainers/distribution-spec/blob/e612a6e1e1bc717f9fa7e1feb4f05c8b6568754a/spec.md#pushing-a-blob-in-chunks
In my limited testing, Zot and olareg return a 416. However, distribution returns a 400 on the invalid digest, and a subsequent GET request to check the progress indicates the data was appended to the blob (ignoring the invalid range). I believe the behavior of Zot and olareg is correct, but we need to update the spec to reflect that.
Presently, if a PATCH request has an invalid range, we should return a
416 Requested Range Not Satisfiable. However, the final PUT request of a chunked blob upload can also contain the final chunk with a range. If that request is received out of order (e.g. the registry did not process the previous chunk for some reason), should we allow (or require) a416status code on the PUT?Here's the relevant section of the spec:
https://github.com/opencontainers/distribution-spec/blob/e612a6e1e1bc717f9fa7e1feb4f05c8b6568754a/spec.md#pushing-a-blob-in-chunks
In my limited testing, Zot and olareg return a 416. However, distribution returns a 400 on the invalid digest, and a subsequent GET request to check the progress indicates the data was appended to the blob (ignoring the invalid range). I believe the behavior of Zot and olareg is correct, but we need to update the spec to reflect that.