laantungir/blossom
1
0
Fork 0
mirror of https://github.com/hzrd149/blossom.git synced 2026-07-22 07:48:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

Move HEAD /upload back into BUD-06

Browse Source
This commit is contained in:
hzrd149
2026-04-16 10:36:39 -05:00
parent c996e37aa6
commit 94d04be9fc
4 changed files with 70 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@@ -22,7 +22,7 @@ BUDs or **Blossom Upgrade Documents** are short documents that outline an additi
- [BUD-03: User Server List](./buds/03.md)
- [BUD-04: Mirroring blobs](./buds/04.md)
- [BUD-05: Media optimization](./buds/05.md)
- [BUD-06: Upload requirements](./buds/06.md) _(moved to [BUD-02](./buds/02.md#head-upload---upload-requirements-optional))_
- [BUD-06: Upload requirements](./buds/06.md)
- [BUD-07: Payment required](./buds/07.md)
- [BUD-08: Nostr File Metadata Tags](./buds/08.md)
- [BUD-09: Blob Report](./buds/09.md)
@@ -37,7 +37,7 @@ Blossom Servers expose a few endpoints for managing blobs
- `GET /<sha256>` (optional file `.ext`) [BUD-01](./buds/01.md#get-sha256---get-blob)
- `HEAD /<sha256>` (optional file `.ext`) [BUD-01](./buds/01.md#head-sha256---has-blob)
- `PUT /upload` [BUD-02](./buds/02.md#put-upload---upload-blob)
- `HEAD /upload` [BUD-02](./buds/02.md#head-upload---upload-requirements-optional)
- `HEAD /upload` [BUD-06](./buds/06.md)
- `GET /list/<pubkey>` [BUD-12](./buds/12.md#get-listpubkey---list-blobs-unrecommended) _(unrecommended)_
- `DELETE /<sha256>` [BUD-12](./buds/12.md#delete-sha256---delete-blob)
- `PUT /mirror` [BUD-04](./buds/04.md#put-mirror---mirror-blob)

72
buds/02.md
View File

@@ -6,7 +6,7 @@
_All pubkeys MUST be in hex format_
Defines the `HEAD /upload` and `PUT /upload` endpoints.
Defines the `PUT /upload` endpoint.
The `/list/<pubkey>` and `DELETE /<sha256>` endpoints are defined in [BUD-12](./12.md).
@@ -71,73 +71,3 @@ If included, `X-Reason` MUST be treated as a human readable diagnostic message o
### File extension normalization (Optional)
When storing blobs, servers MAY normalise the file extension to a standard format (e.g. `.pdf`, `.png`, etc.) based on the MIME type of the blob. This can be especially useful when the `GET /<sha256>` endpoint is redirected to an external URL (see the [proxying and redirection section from BUD-01](./01.md#proxying-and-redirection-optional)), as external servers may rely on the file extension to serve the blob correctly.
## HEAD /upload - Upload requirements (Optional)
Servers MAY implement `HEAD /upload` as an optimization step before `PUT /upload`.
Clients can use it to avoid uploading blobs that would be rejected, and servers can use it to evaluate whether an upload attempt would be accepted based on the supplied metadata and current server policy.
This pre-flight request is only an optimization. Clients MAY skip it entirely, and the result is not a guarantee of the eventual `PUT /upload` outcome because server state may change between requests.
Clients that want to check whether a blob already exists on the server SHOULD use [`HEAD /<sha256>` from BUD-01](./01.md#head-sha256---has-blob).
The `HEAD /upload` endpoint MUST use the `X-SHA-256`, `X-Content-Type` and `X-Content-Length` headers sent by client to get the sha256 hash, MIME type and size of the blob that will be uploaded, returning an HTTP status code and an optional custom header `X-Reason` to indicate a human readable message about the upload requirements. Because `HEAD` responses do not include a message body, clients MUST determine the result from the status code and response headers alone.
### Headers
- `X-SHA-256`: A lowercase hex-encoded sha256 string that represents the blob's hash.
- `X-Content-Length`: An integer that represents the blob size in bytes.
- `X-Content-Type`: A string that specifies the blob's MIME type, like `application/pdf` or `image/png`.
### Status codes
Servers SHOULD use the following status codes for `HEAD /upload` responses:
| Status Code | Meaning |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------ |
| `200 OK` | Based on the supplied headers and current server policy, the upload would be accepted and the client MAY proceed with `PUT /upload`. |
| `400 Bad Request` | The request headers are malformed. |
| `401 Unauthorized` | Authorization is required and missing or invalid. See [BUD-11](./11.md#endpoint-authorization-requirements). |
| `402 Payment Required` | Payment is required before the upload can proceed. See [BUD-07](./07.md). |
| `403 Forbidden` | The request is understood but not allowed by server policy. |
| `411 Length Required` | A required `X-Content-Length` header is missing. |
| `413 Content Too Large` | The blob would exceed server size limits. |
| `415 Unsupported Media Type` | The blob type is not supported. |
| `429 Too Many Requests` | The client has exceeded a rate limit or quota. |
| `503 Service Unavailable` | The upload service is temporarily unavailable. |
If included, `X-Reason` MUST be treated as a human readable diagnostic message only and clients MUST NOT parse it for control flow.
Clients that do not implement this optimization may still perform `PUT /upload` directly, and servers MUST handle that correctly.
After receiving `200 OK` from `HEAD /upload`, clients MUST still be prepared for `PUT /upload` to return either `200 OK` or `201 Created`, depending on whether the blob already existed when the upload was processed.
### Examples
Example request from the client:
```http
X-Content-Type: application/pdf
X-Content-Length: 184292
X-SHA-256: 88a74d0b866c8ba79251a11fe5ac807839226870e77355f02eaf68b156522576
```
Example response from the server if the upload may proceed:
```http
HTTP/1.1 200 OK
```
If the upload cannot proceed, the server SHOULD return one of the status codes defined above. The server MAY include `X-Reason` with a human readable error message.
Some examples of error messages:
```http
HTTP/1.1 400 Bad Request
X-Reason: Invalid X-SHA-256 header format. Expected a string.
```
```http
HTTP/1.1 413 Content Too Large
X-Reason: File too large. Max allowed size is 100MB.
```

68
buds/06.md
View File

@@ -4,6 +4,70 @@
`draft` `optional`
The `HEAD /upload` endpoint definition has been merged into [BUD-02](./02.md#head-upload---upload-requirements-optional) so it lives next to `PUT /upload`.
Servers MAY implement `HEAD /upload` as an optimization step before `PUT /upload`.
Clients can use it to avoid uploading blobs that would be rejected, and servers can use it to evaluate whether an upload attempt would be accepted based on the supplied metadata and current server policy.
This optional preflight endpoint remains intended as an optimization so clients and servers can avoid uploading blobs that would be rejected or that already exist.
This pre-flight request is only an optimization. Clients MAY skip it entirely, and the result is not a guarantee of the eventual `PUT /upload` outcome because server state may change between requests.
Clients that want to check whether a blob already exists on the server SHOULD use [`HEAD /<sha256>` from BUD-01](./01.md#head-sha256---has-blob).
The `HEAD /upload` endpoint MUST use the `X-SHA-256`, `X-Content-Type` and `X-Content-Length` headers sent by client to get the sha256 hash, MIME type and size of the blob that will be uploaded, returning an HTTP status code and an optional custom header `X-Reason` to indicate a human readable message about the upload requirements. Because `HEAD` responses do not include a message body, clients MUST determine the result from the status code and response headers alone.
### Headers
- `X-SHA-256`: A lowercase hex-encoded sha256 string that represents the blob's hash.
- `X-Content-Length`: An integer that represents the blob size in bytes.
- `X-Content-Type`: A string that specifies the blob's MIME type, like `application/pdf` or `image/png`.
### Status codes
Servers SHOULD use the following status codes for `HEAD /upload` responses:
| Status Code | Meaning |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------ |
| `200 OK` | Based on the supplied headers and current server policy, the upload would be accepted and the client MAY proceed with `PUT /upload`. |
| `400 Bad Request` | The request headers are malformed. |
| `401 Unauthorized` | Authorization is required and missing or invalid. See [BUD-11](./11.md#endpoint-authorization-requirements). |
| `402 Payment Required` | Payment is required before the upload can proceed. See [BUD-07](./07.md). |
| `403 Forbidden` | The request is understood but not allowed by server policy. |
| `411 Length Required` | A required `X-Content-Length` header is missing. |
| `413 Content Too Large` | The blob would exceed server size limits. |
| `415 Unsupported Media Type` | The blob type is not supported. |
| `429 Too Many Requests` | The client has exceeded a rate limit or quota. |
| `503 Service Unavailable` | The upload service is temporarily unavailable. |
If included, `X-Reason` MUST be treated as a human readable diagnostic message only and clients MUST NOT parse it for control flow.
Clients that do not implement this optimization may still perform `PUT /upload` directly, and servers MUST handle that correctly.
After receiving `200 OK` from `HEAD /upload`, clients MUST still be prepared for `PUT /upload` to return either `200 OK` or `201 Created`, depending on whether the blob already existed when the upload was processed.
### Examples
Example request from the client:
```http
X-Content-Type: application/pdf
X-Content-Length: 184292
X-SHA-256: 88a74d0b866c8ba79251a11fe5ac807839226870e77355f02eaf68b156522576
```
Example response from the server if the upload may proceed:
```http
HTTP/1.1 200 OK
```
If the upload cannot proceed, the server SHOULD return one of the status codes defined above. The server MAY include `X-Reason` with a human readable error message.
Some examples of error messages:
```http
HTTP/1.1 400 Bad Request
X-Reason: Invalid X-SHA-256 header format. Expected a string.
```
```http
HTTP/1.1 413 Content Too Large
X-Reason: File too large. Max allowed size is 100MB.
```

2
buds/07.md
View File

@@ -12,7 +12,7 @@ Some servers MAY require payment for uploads, downloads, or any other endpoint.
Some endpoints a server may require payment for:
- [`HEAD /upload`](./02.md#head-upload---upload-requirements-optional) to signal that payment is required for the `PUT` request ( if that optional endpoint is supported )
- [`HEAD /upload`](./06.md) to signal that payment is required for the `PUT` request ( if that optional endpoint is supported )
- [`PUT /upload`](./02.md#put-upload---upload-blob) to require payment for uploads
- [`HEAD /<sha256>`](./01.md#head-sha256---has-blob) to signal that payment is required for the `GET` request
- [`GET /<sha256>`](./01.md#get-sha256---get-blob) to require payment for downloads ( maybe charge by MB downloaded? )