From a1d41da92a9b171efa2c80772a8faae70034ba2f Mon Sep 17 00:00:00 2001 From: hzrd149 Date: Mon, 9 Sep 2024 14:25:24 -0500 Subject: [PATCH 01/14] add document for returning nip94 tags --- buds/08.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 buds/08.md diff --git a/buds/08.md b/buds/08.md new file mode 100644 index 0000000..0b79e8d --- /dev/null +++ b/buds/08.md @@ -0,0 +1,33 @@ +# Nostr File Metadata Tags + +`draft` `optional` + +Describes how a server could return nostr [NIP-94 File Metadata](https://github.com/nostr-protocol/nips/blob/master/94.md) tags from the `/upload` and `/mirror` endpoints + +## Returning tags + +As described in [BUD-02](./02.md#blob-descriptor) servers MAY add any additional fields to a blob descriptor + +Servers MAY return an additional `nip94` field in the [blob descriptor](./02.md#blob-descriptor) from the `/upload` or `/mirror` endpoints + +The `nip94` field should contain a JSON object with the keys being the tag names defined in [NIP-94](https://github.com/nostr-protocol/nips/blob/master/94.md) + +An example response would look like: + +```json +{ + "url": "https://cdn.example.com/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553.pdf", + "sha256": "b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553", + "size": 184292, + "type": "application/pdf", + "uploaded": 1725909682, + "nip94": { + "url": "https://cdn.example.com/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553.pdf", + "m": "application/pdf", + "x": "b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553", + "size": 184292, + "magnet": "magnet:?xt=urn:btih:9804c5286a3fb07b2244c968b39bc3cc814313bc&dn=bitcoin.pdf", + "i": "9804c5286a3fb07b2244c968b39bc3cc814313bc" + } +} +``` From 45709636481827c31426d5a23055599427e50b05 Mon Sep 17 00:00:00 2001 From: Quentin Date: Tue, 10 Sep 2024 10:23:10 +0200 Subject: [PATCH 02/14] BUD06 - Upload requirements --- README.md | 3 ++- buds/06.md | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+), 1 deletion(-) create mode 100644 buds/06.md diff --git a/README.md b/README.md index 9c9c85c..701180d 100644 --- a/README.md +++ b/README.md @@ -16,9 +16,10 @@ Blossom Servers expose four endpoints for managing blobs - `GET /` (optional file `.ext`) [BUD-01](./buds/01.md#get-sha256---get-blob) - `HEAD /` (optional file `.ext`) [BUD-01](./buds/01.md#head-sha256---has-blob) -- `PUT /upload` [BUD-2](./buds/02.md#put-upload---upload-blob) +- `PUT /upload` [BUD-02](./buds/02.md#put-upload---upload-blob) - `Authentication`: Signed [nostr event](./buds/02.md#upload-authorization-required) - Return a blob descriptor +- `HEAD /upload` [BUD-06](./buds/06.md#head-upload---upload-requirements) - `GET /list/` [BUD-02](./buds/02.md#get-listpubkey---list-blobs) - Returns an array of blob descriptors - `Authentication` _(optional)_: Signed [nostr event](./buds/02.md#list-authorization-optional) diff --git a/buds/06.md b/buds/06.md new file mode 100644 index 0000000..e79b418 --- /dev/null +++ b/buds/06.md @@ -0,0 +1,55 @@ +BUD-06 +====== + +Upload requirements +--------------- + +`draft` `optional` + +Defines how clients can verify if the upload can be completed before sending the blob to the server. This mechanism helps prevent unnecessary traffic to other endpoints by rejecting files based on their hash, size, MIME type or other server-specific requirements. + +## HEAD /upload - Upload requirements + +The `HEAD /upload` endpoint `MUST` use the `Content-Digest`, `X-Content-Type` and `X-Content-Length` headers sent by client to get the SHA-256 hash, MIME type and size of the blob that will be uploaded, returning a HTTP status code and a custom header `X-Upload-Message` to indicate some human readable message about the upload requirements. + +### Headers + +- `Content-Digest`: A string formatted as `sha-256=::`, where `` is the base64-encoded SHA-256 hash of the blob. +- `X-Content-Length`: An integer that represents the blob size in bytes. +- `X-Content-Type`: A string that specifies the fblobile's MIME type, like `application/pdf` or `image/png`. +- `X-Upload-Message`: A human readable message that explains the reason why the upload cannot proceed. + +### Examples + +Example request from the client: + +```http +X-Content-Type: application/pdf +X-Content-Length: 184292 +Content-Digest: SHA-256=:88a74d0b866c8ba79251a11fe5ac807839226870e77355f02eaf68b156522576: +``` + +Example response from the server if the upload can be done: + +```http +HTTP/1.1 200 OK +``` + +If the upload cannot proceed, the server `MUST` return an appropriate HTTP status code and a custom header `X-Upload-Message` with a human readable error message. + +Some examples of error messages: + +```http +HTTP/1.1 400 Bad Request +X-Upload-Message: Invalid Content-Digest header format. Expected format: sha-256=:: +``` + +```http +HTTP/1.1 413 Content Too Large +X-Upload-Message: File too large. Max allowed size is 100MB +``` + +```http +HTTP/1.1 415 Unsupported Media Type +X-Upload-Message: Unsupported file type. +``` \ No newline at end of file From 00a378d81f1b90445797dc7c56f93c3679d73c24 Mon Sep 17 00:00:00 2001 From: Quentin Date: Tue, 10 Sep 2024 11:34:25 +0200 Subject: [PATCH 03/14] Add BUD-06 to readme --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 701180d..72ed62e 100644 --- a/README.md +++ b/README.md @@ -40,6 +40,7 @@ See the [BUDs](./buds) folder and specifically [BUD-01](./buds/01.md) and [BUD-0 - [BUD-02: Blob upload and management](./buds/02.md) - [BUD-03: User Server List](./buds/03.md) - [BUD-04: Mirroring blobs](./buds/04.md) +- [BUD-06: Upload requirements](./buds/06.md) ## Event kinds From 5593e3d38938684ed7281b72915d7d38e1e63c2c Mon Sep 17 00:00:00 2001 From: Quentin <125748180+quentintaranpino@users.noreply.github.com> Date: Thu, 12 Sep 2024 09:30:55 +0200 Subject: [PATCH 04/14] Update buds/06.md Co-authored-by: hzrd149 <8001706+hzrd149@users.noreply.github.com> --- buds/06.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/buds/06.md b/buds/06.md index e79b418..a3bbe16 100644 --- a/buds/06.md +++ b/buds/06.md @@ -35,7 +35,7 @@ Example response from the server if the upload can be done: HTTP/1.1 200 OK ``` -If the upload cannot proceed, the server `MUST` return an appropriate HTTP status code and a custom header `X-Upload-Message` with a human readable error message. +If the upload cannot proceed, the server `MUST` return an appropriate `4xx` HTTP status code and a custom header `X-Upload-Message` with a human readable error message. Some examples of error messages: From 86d8da48703d5e9bbea464c682f34bb591e8759d Mon Sep 17 00:00:00 2001 From: quentintaranpino Date: Thu, 12 Sep 2024 09:35:07 +0200 Subject: [PATCH 05/14] upload authorization. More examples, fix some typo --- buds/06.md | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/buds/06.md b/buds/06.md index e79b418..d302095 100644 --- a/buds/06.md +++ b/buds/06.md @@ -19,6 +19,12 @@ The `HEAD /upload` endpoint `MUST` use the `Content-Digest`, `X-Content-Type` an - `X-Content-Type`: A string that specifies the fblobile's MIME type, like `application/pdf` or `image/png`. - `X-Upload-Message`: A human readable message that explains the reason why the upload cannot proceed. +### Upload Authorization + +The `HEAD /upload` endpoint MAY accept an `upload` authorization event using the `Authorization` header similar to what is used in the [`PUT /upload`](./02.md#upload-authorization-required) endpoint + +If the server requires authorization to upload it may respond with the `401` status code, or if authorization was provided and is invalid or not permitted it may respond with `403` status code + ### Examples Example request from the client: @@ -35,7 +41,8 @@ Example response from the server if the upload can be done: HTTP/1.1 200 OK ``` -If the upload cannot proceed, the server `MUST` return an appropriate HTTP status code and a custom header `X-Upload-Message` with a human readable error message. +If the upload cannot proceed, the server `MUST` return an appropriate `4xx` HTTP status code and a custom header `X-Upload-Message` with a human readable error message. + Some examples of error messages: @@ -44,6 +51,21 @@ HTTP/1.1 400 Bad Request X-Upload-Message: Invalid Content-Digest header format. Expected format: sha-256=:: ``` +```http +HTTP/1.1 401 Unauthorized +X-Upload-Message: Authorization required for uploading video files +``` + +```http +HTTP/1.1 401 Forbidden +X-Upload-Message: Account banned +``` + +```http +HTTP/1.1 411 Length Required +X-Upload-Message: Missing Content-Length or X-Content-Length headers +``` + ```http HTTP/1.1 413 Content Too Large X-Upload-Message: File too large. Max allowed size is 100MB From 8e633d00b9394dc200bac3ec2b30ad4ab5090af7 Mon Sep 17 00:00:00 2001 From: quentintaranpino Date: Thu, 12 Sep 2024 09:44:20 +0200 Subject: [PATCH 06/14] Change X-Content-Digest for X-SHA-256 --- buds/06.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/buds/06.md b/buds/06.md index d302095..0584116 100644 --- a/buds/06.md +++ b/buds/06.md @@ -10,11 +10,11 @@ Defines how clients can verify if the upload can be completed before sending the ## HEAD /upload - Upload requirements -The `HEAD /upload` endpoint `MUST` use the `Content-Digest`, `X-Content-Type` and `X-Content-Length` headers sent by client to get the SHA-256 hash, MIME type and size of the blob that will be uploaded, returning a HTTP status code and a custom header `X-Upload-Message` to indicate some human readable message about the upload requirements. +The `HEAD /upload` endpoint `MUST` use the `X-SHA-256`, `X-Content-Type` and `X-Content-Length` headers sent by client to get the SHA-256 hash, MIME type and size of the blob that will be uploaded, returning a HTTP status code and a custom header `X-Upload-Message` to indicate some human readable message about the upload requirements. ### Headers -- `Content-Digest`: A string formatted as `sha-256=::`, where `` is the base64-encoded SHA-256 hash of the blob. +- `X-SHA-256`: A string that represents the blob's SHA-256 hash. - `X-Content-Length`: An integer that represents the blob size in bytes. - `X-Content-Type`: A string that specifies the fblobile's MIME type, like `application/pdf` or `image/png`. - `X-Upload-Message`: A human readable message that explains the reason why the upload cannot proceed. @@ -32,7 +32,7 @@ Example request from the client: ```http X-Content-Type: application/pdf X-Content-Length: 184292 -Content-Digest: SHA-256=:88a74d0b866c8ba79251a11fe5ac807839226870e77355f02eaf68b156522576: +X-SHA-256: 88a74d0b866c8ba79251a11fe5ac807839226870e77355f02eaf68b156522576 ``` Example response from the server if the upload can be done: @@ -48,27 +48,27 @@ Some examples of error messages: ```http HTTP/1.1 400 Bad Request -X-Upload-Message: Invalid Content-Digest header format. Expected format: sha-256=:: +X-Upload-Message: Invalid X-SHA-256 header format. Expected a string. ``` ```http HTTP/1.1 401 Unauthorized -X-Upload-Message: Authorization required for uploading video files +X-Upload-Message: Authorization required for uploading video files. ``` ```http HTTP/1.1 401 Forbidden -X-Upload-Message: Account banned +X-Upload-Message: SHA-256 hash banned. ``` ```http HTTP/1.1 411 Length Required -X-Upload-Message: Missing Content-Length or X-Content-Length headers +X-Upload-Message: Missing X-Content-Length header. ``` ```http HTTP/1.1 413 Content Too Large -X-Upload-Message: File too large. Max allowed size is 100MB +X-Upload-Message: File too large. Max allowed size is 100MB. ``` ```http From 53472888d30cbb46f234d8fa8e429a54c7c02fdc Mon Sep 17 00:00:00 2001 From: quentintaranpino Date: Mon, 16 Sep 2024 09:21:38 +0200 Subject: [PATCH 07/14] fix forbidden response example status code --- buds/06.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/buds/06.md b/buds/06.md index 0584116..9ffb571 100644 --- a/buds/06.md +++ b/buds/06.md @@ -57,7 +57,7 @@ X-Upload-Message: Authorization required for uploading video files. ``` ```http -HTTP/1.1 401 Forbidden +HTTP/1.1 403 Forbidden X-Upload-Message: SHA-256 hash banned. ``` From f27cd777f2e2fd0998b6576a971a3b3d28c01766 Mon Sep 17 00:00:00 2001 From: hzrd149 Date: Thu, 19 Sep 2024 14:40:32 -0500 Subject: [PATCH 08/14] fix typeo format BUD-06 --- buds/06.md | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/buds/06.md b/buds/06.md index 9ffb571..c587032 100644 --- a/buds/06.md +++ b/buds/06.md @@ -1,8 +1,6 @@ -BUD-06 -====== +# BUD-06 -Upload requirements ---------------- +## Upload requirements `draft` `optional` @@ -16,14 +14,14 @@ The `HEAD /upload` endpoint `MUST` use the `X-SHA-256`, `X-Content-Type` and `X- - `X-SHA-256`: A string that represents the blob's SHA-256 hash. - `X-Content-Length`: An integer that represents the blob size in bytes. -- `X-Content-Type`: A string that specifies the fblobile's MIME type, like `application/pdf` or `image/png`. +- `X-Content-Type`: A string that specifies the blob's MIME type, like `application/pdf` or `image/png`. - `X-Upload-Message`: A human readable message that explains the reason why the upload cannot proceed. -### Upload Authorization +### Upload Authorization -The `HEAD /upload` endpoint MAY accept an `upload` authorization event using the `Authorization` header similar to what is used in the [`PUT /upload`](./02.md#upload-authorization-required) endpoint +The `HEAD /upload` endpoint MAY accept an `upload` authorization event using the `Authorization` header similar to what is used in the [`PUT /upload`](./02.md#upload-authorization-required) endpoint -If the server requires authorization to upload it may respond with the `401` status code, or if authorization was provided and is invalid or not permitted it may respond with `403` status code +If the server requires authorization to upload it may respond with the `401` status code, or if authorization was provided and is invalid or not permitted it may respond with `403` status code ### Examples @@ -41,8 +39,7 @@ Example response from the server if the upload can be done: HTTP/1.1 200 OK ``` -If the upload cannot proceed, the server `MUST` return an appropriate `4xx` HTTP status code and a custom header `X-Upload-Message` with a human readable error message. - +If the upload cannot proceed, the server `MUST` return an appropriate `4xx` HTTP status code and a custom header `X-Upload-Message` with a human readable error message. Some examples of error messages: @@ -52,17 +49,17 @@ X-Upload-Message: Invalid X-SHA-256 header format. Expected a string. ``` ```http -HTTP/1.1 401 Unauthorized +HTTP/1.1 401 Unauthorized X-Upload-Message: Authorization required for uploading video files. ``` ```http -HTTP/1.1 403 Forbidden +HTTP/1.1 403 Forbidden X-Upload-Message: SHA-256 hash banned. ``` ```http -HTTP/1.1 411 Length Required +HTTP/1.1 411 Length Required X-Upload-Message: Missing X-Content-Length header. ``` @@ -74,4 +71,4 @@ X-Upload-Message: File too large. Max allowed size is 100MB. ```http HTTP/1.1 415 Unsupported Media Type X-Upload-Message: Unsupported file type. -``` \ No newline at end of file +``` From d9a53bda1c85ef0f9d74efd69881e683f371e598 Mon Sep 17 00:00:00 2001 From: hzrd149 <8001706+hzrd149@users.noreply.github.com> Date: Tue, 29 Oct 2024 10:06:28 +0000 Subject: [PATCH 09/14] Add BUD-08 to README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 72ed62e..e171a16 100644 --- a/README.md +++ b/README.md @@ -41,6 +41,7 @@ See the [BUDs](./buds) folder and specifically [BUD-01](./buds/01.md) and [BUD-0 - [BUD-03: User Server List](./buds/03.md) - [BUD-04: Mirroring blobs](./buds/04.md) - [BUD-06: Upload requirements](./buds/06.md) +- [BUD-08: Nostr File Metadata Tags](./buds/08.md) ## Event kinds From c746be27e350ec0078d00d63955994c7e500f124 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Tue, 29 Oct 2024 13:11:34 -0300 Subject: [PATCH 10/14] X-Reason, a header for all user-facing error messages to go. --- buds/01.md | 4 ++++ buds/06.md | 17 ++++++++--------- 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/buds/01.md b/buds/01.md index 146717f..f3bed29 100644 --- a/buds/01.md +++ b/buds/01.md @@ -10,6 +10,10 @@ _All pubkeys MUST be in hex format_ Servers MUST set the `Access-Control-Allow-Origin: *`, `Access-Control-Allow-Headers: Authorization,*` and `Access-Control-Allow-Methods: GET, PUT, DELETE` headers on all endpoints to ensure compatibility with apps hosted on other domains +## Error responses + +Every time a server sends an error response (HTTP status codes >=400), it may include a human-readable header `X-Reason` that can be displayed to the user. + ## Authorization events Authorization events are used to identify the users to the server diff --git a/buds/06.md b/buds/06.md index c587032..739404b 100644 --- a/buds/06.md +++ b/buds/06.md @@ -8,14 +8,13 @@ Defines how clients can verify if the upload can be completed before sending the ## HEAD /upload - Upload requirements -The `HEAD /upload` endpoint `MUST` use the `X-SHA-256`, `X-Content-Type` and `X-Content-Length` headers sent by client to get the SHA-256 hash, MIME type and size of the blob that will be uploaded, returning a HTTP status code and a custom header `X-Upload-Message` to indicate some human readable message about the upload requirements. +The `HEAD /upload` endpoint `MUST` use the `X-SHA-256`, `X-Content-Type` and `X-Content-Length` headers sent by client to get the SHA-256 hash, MIME type and size of the blob that will be uploaded, returning a HTTP status code and a custom header `X-Reason` to indicate some human readable message about the upload requirements. ### Headers - `X-SHA-256`: A string that represents the blob's SHA-256 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`. -- `X-Upload-Message`: A human readable message that explains the reason why the upload cannot proceed. ### Upload Authorization @@ -39,36 +38,36 @@ Example response from the server if the upload can be done: HTTP/1.1 200 OK ``` -If the upload cannot proceed, the server `MUST` return an appropriate `4xx` HTTP status code and a custom header `X-Upload-Message` with a human readable error message. +If the upload cannot proceed, the server `MUST` return an appropriate `4xx` HTTP status code and a custom header `X-Reason` with a human readable error message. Some examples of error messages: ```http HTTP/1.1 400 Bad Request -X-Upload-Message: Invalid X-SHA-256 header format. Expected a string. +X-Reason: Invalid X-SHA-256 header format. Expected a string. ``` ```http HTTP/1.1 401 Unauthorized -X-Upload-Message: Authorization required for uploading video files. +X-Reason: Authorization required for uploading video files. ``` ```http HTTP/1.1 403 Forbidden -X-Upload-Message: SHA-256 hash banned. +X-Reason: SHA-256 hash banned. ``` ```http HTTP/1.1 411 Length Required -X-Upload-Message: Missing X-Content-Length header. +X-Reason: Missing X-Content-Length header. ``` ```http HTTP/1.1 413 Content Too Large -X-Upload-Message: File too large. Max allowed size is 100MB. +X-Reason: File too large. Max allowed size is 100MB. ``` ```http HTTP/1.1 415 Unsupported Media Type -X-Upload-Message: Unsupported file type. +X-Reason: Unsupported file type. ``` From 5d774643e83154be2b740cd5a090b6aae134d390 Mon Sep 17 00:00:00 2001 From: leonardo Date: Sat, 2 Nov 2024 13:55:53 +0000 Subject: [PATCH 11/14] auth for upload as optional --- buds/02.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/buds/02.md b/buds/02.md index 3b9b7f0..996f2ce 100644 --- a/buds/02.md +++ b/buds/02.md @@ -42,9 +42,9 @@ The endpoint MUST return a [Blob Descriptor](#blob-descriptor) if the upload was Servers MAY reject an upload for any reason and should respond with the appropriate HTTP `4xx` status code and an error message explaining the reason for the rejection -### Upload Authorization (required) +### Upload Authorization (Optional) -Servers MUST accept an authorization event when uploading blobs and should perform additional checks +Servers MAY accept an authorization event when uploading blobs and should perform additional checks 1. The `t` tag MUST be set to `upload` 2. MUST contain at least one `x` tag matching the sha256 hash of the blob being uploaded @@ -67,7 +67,7 @@ Example Authorization event: } ``` -## GET /list/pubkey - List Blobs +## GET /list/pubkey - List Blobs (Optional) The `/list/` endpoint MUST return a JSON array of [Blob Descriptor](#blob-descriptor) that where uploaded by the specified pubkey From 1262ffa989a62298497637d36bffd36c8e6a97f8 Mon Sep 17 00:00:00 2001 From: Anthony Accioly <1591739+aaccioly@users.noreply.github.com> Date: Tue, 5 Nov 2024 22:14:38 +0000 Subject: [PATCH 12/14] Expand BUD-01 CORS headers documentation --- buds/01.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/buds/01.md b/buds/01.md index 146717f..3595623 100644 --- a/buds/01.md +++ b/buds/01.md @@ -8,7 +8,13 @@ _All pubkeys MUST be in hex format_ ## Cross origin headers -Servers MUST set the `Access-Control-Allow-Origin: *`, `Access-Control-Allow-Headers: Authorization,*` and `Access-Control-Allow-Methods: GET, PUT, DELETE` headers on all endpoints to ensure compatibility with apps hosted on other domains +Servers MUST set the `Access-Control-Allow-Origin: *` header on all responses to ensure compatibility with applications hosted on other domains. + +For [preflight](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests) (`OPTIONS`) requests, +servers MUST also set, at minimum, the `Access-Control-Allow-Headers: Authorization, *` and `Access-Control-Allow-Methods: GET, PUT, +DELETE` headers. + +The header `Access-Control-Max-Age: 86400` MAY be set to cache the results of a preflight request for 24 hours. ## Authorization events From ee1fca7ef543a36dbebb75f6fbfefdc671bed547 Mon Sep 17 00:00:00 2001 From: hzrd149 Date: Mon, 11 Nov 2024 11:54:47 +0000 Subject: [PATCH 13/14] fix headers on BUD-08 --- buds/08.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/buds/08.md b/buds/08.md index 0b79e8d..b5e2ec0 100644 --- a/buds/08.md +++ b/buds/08.md @@ -1,10 +1,12 @@ -# Nostr File Metadata Tags +# BUD-08 + +## Nostr File Metadata Tags `draft` `optional` Describes how a server could return nostr [NIP-94 File Metadata](https://github.com/nostr-protocol/nips/blob/master/94.md) tags from the `/upload` and `/mirror` endpoints -## Returning tags +### Returning tags As described in [BUD-02](./02.md#blob-descriptor) servers MAY add any additional fields to a blob descriptor From b7e4e96ed597351fc17855620b4c50249ac74d97 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 11 Nov 2024 13:03:56 -0300 Subject: [PATCH 14/14] remove old Error Responses section. --- buds/01.md | 20 -------------------- 1 file changed, 20 deletions(-) diff --git a/buds/01.md b/buds/01.md index f3bed29..d78415d 100644 --- a/buds/01.md +++ b/buds/01.md @@ -67,26 +67,6 @@ Authorization: Nostr eyJpZCI6IjhlY2JkY2RkNTMyOTIwMDEwNTUyNGExNDI4NzkxMzg4MWIzOWQ All endpoints MUST be served from the root path (eg. `https://cdn.example.com/upload`, etc). This allows clients to talk to servers interchangeably when uploading or retrieving blobs -## Error Responses - -For HTTP `4xx` and `5xx` status codes servers MUST repond with `Content-Type: application/json` and a JSON object containing `message` - -The `message` field MUST be human readable and should explain the reason for the error. Optionally servers may include other fields for the client with more information about the error - -Example Error response: - -``` -HTTP/2 401 -content-type: application/json; charset=utf-8 -content-length: 32 -access-control-allow-origin: * -access-control-expose-headers: * -access-control-allow-headers: authorization,* -access-control-allow-methods: get, put, delete - -{"message":"Missing Auth event"} -``` - ## GET /sha256 - Get Blob The `GET /` endpoint MUST return the contents of the blob with the `Content-Type` header set to the appropriate MIME type