diff --git a/buds/02.md b/buds/02.md index ffb00b5..4550368 100644 --- a/buds/02.md +++ b/buds/02.md @@ -75,10 +75,12 @@ When storing blobs, servers MAY normalise the file extension to a standard forma ## 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 avoid receiving blobs that are already stored or would fail validation. +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 /` 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 @@ -93,8 +95,7 @@ Servers SHOULD use the following status codes for `HEAD /upload` responses: | Status Code | Meaning | | ---------------------------- | ------------------------------------------------------------------------------------------------------------ | -| `200 OK` | The blob already exists on the server and the client MAY skip the `PUT /upload` request. | -| `204 No Content` | The upload would be accepted and the client MAY proceed with `PUT /upload`. | +| `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). | @@ -107,7 +108,9 @@ Servers SHOULD use the following status codes for `HEAD /upload` responses: 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` after receiving `200 OK`, and servers MUST handle that correctly. +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 @@ -119,16 +122,10 @@ X-Content-Length: 184292 X-SHA-256: 88a74d0b866c8ba79251a11fe5ac807839226870e77355f02eaf68b156522576 ``` -Example response from the server if the blob already exists: - -```http -HTTP/1.1 200 OK -``` - Example response from the server if the upload may proceed: ```http -HTTP/1.1 204 No Content +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.