From 1a085ed7bf8d4ae86abc17cb9c737df6ff7c6f05 Mon Sep 17 00:00:00 2001
From: Anthony Accioly <1591739+aaccioly@users.noreply.github.com>
Date: Wed, 4 Jun 2025 20:15:03 +0100
Subject: [PATCH] fix: clarify Content-Type handling for blob retrieval and
 mirroring

---
 buds/01.md | 9 +++++----
 buds/04.md | 6 +++---
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/buds/01.md b/buds/01.md
index 1b17cc5..f45d497 100644
--- a/buds/01.md
+++ b/buds/01.md
@@ -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
 
diff --git a/buds/04.md b/buds/04.md
index 4f323c9..6165ed4 100644
--- a/buds/04.md
+++ b/buds/04.md
@@ -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.