Clarify requirements around Content-Type and Content-Length

- Specify that the server must return the MIME type in the Content-Type header for blob retrieval.
- Clarify fallback behaviour for unknown MIME types to application/octet-stream.
- Improve the description of how servers should infer MIME types and handle Content-Length for mirror requests.
This commit is contained in:
Anthony Accioly
2025-06-04 19:58:02 +01:00
parent 5ef2889547
commit cacfa520dd
2 changed files with 10 additions and 2 deletions

View File

@@ -25,9 +25,14 @@ The `/mirror` endpoint MUST download the blob from the specified URL and verify
**Multiple `x` tags in the authorization event MUST NOT be interpreted as the user requesting to mirror multiple blobs.**
The endpoint MUST return a [Blob Descriptor](#blob-descriptor) and a `2xx` status code if the mirroring was successful or a `4xx` status code and error messageif it was not
The endpoint MUST return a [Blob Descriptor](#blob-descriptor) and a `2xx` status code if the mirroring was successful
or a `4xx` status code and error message if it was not.
Servers SHOULD use the `Content-Type` header returned from the requested URL to infer the mime type of the blob. If the `Content-Type` header is not returned they SHOULD attempt to use the file extension in the URL or fallback to `application/octet-stream`.
Servers SHOULD use the `Content-Type` header returned from the requested URL to infer the mime type of the blob. If the
`Content-Type` header is not present they SHOULD attempt to detect the `Content-Type` from the blob contents and file
extension, falling back to `application/octet-stream` if they cannot determine the type.
Servers MAY use the `Content-Length` header to determine the size of the blob.
Servers MAY reject a mirror request for any reason and MUST respond with the appropriate HTTP `4xx` status code and an error message explaining the reason for the rejection.