laantungir/blossom
1
0
Fork 0
mirror of https://github.com/hzrd149/blossom.git synced 2025-12-14 08:18:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Anthony Accioly
2025-06-04 20:15:03 +01:00
parent cacfa520dd
commit 1a085ed7bf
2 changed files with 8 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
buds/01.md
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