fix: clarify Content-Type handling for blob retrieval and mirroring

This commit is contained in:
Anthony Accioly 2025-06-04 20:15:03 +01:00
parent cacfa520dd
commit 1a085ed7bf
No known key found for this signature in database
GPG Key ID: 1BADB4682C8DDB3C
2 changed files with 8 additions and 7 deletions

View File

@ -79,8 +79,8 @@ The `GET /<sha256>` endpoint MUST return the contents of the blob in the respons
The endpoint MUST accept an optional file extension in the URL. ie. `.pdf`, `.png`, etc
Regardless of the file extension, the server MUST return the MIME type of the blob in the `Content-Type`
header. If the server does not know the MIME type of the blob, it MUST default to `application/octet-stream`
Regardless of the file extension, the server MUST return the MIME type of the blob in the `Content-Type` header. If the
server does not know the MIME type of the blob, it MUST default to `application/octet-stream`
If the endpoint returns a `301` or `302` redirect it MUST redirect to a URL containing the same sha256 hash as the requested blob.
This ensures that if a user was to copy or reuse the redirect URL it would still contain the original sha256 hash
@ -134,9 +134,10 @@ Example event for retrieving multiple blobs from single server:
## HEAD /sha256 - Has Blob
The `HEAD /<sha256>` endpoint SHOULD be identical to the `GET /<sha256>` endpoint except that it MUST NOT return the blob in the reponse body per [RFC 7231](https://www.rfc-editor.org/rfc/rfc7231#section-4.3.2)
The `HEAD /<sha256>` endpoint SHOULD be identical to the `GET /<sha256>` endpoint except that it MUST NOT return the
blob in the reponse body per [RFC 7231](https://www.rfc-editor.org/rfc/rfc7231#section-4.3.2)
The endpoint MUST respond with the same `Content-Type` and `Content-Length` headers as the `GET /<sha256>` endpoint.
The endpoint MUST respond with the same `Content-Type` and `Content-Length` headerers as the `GET /<sha256>` endpoint
The endpoint MUST accept an optional file extension in the URL similar to the `GET /<sha256>` endpoint. ie. `.pdf`, `.png`, etc

View File

@ -28,9 +28,9 @@ The `/mirror` endpoint MUST download the blob from the specified URL and verify
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 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.
The destination server SHOULD use the `Content-Type` header returned from the origin server to infer the mime type of
the blob. If the `Content-Type` header is not present the destination server SHOULD attempt to detect the `Content-Type`
from the blob contents and file extension, falling back to `application/octet-stream` if it cannot determine the type.
Servers MAY use the `Content-Length` header to determine the size of the blob.