Skip to content

06.md

Latest commit

 

History

History
73 lines (50 loc) · 4.35 KB

06.md

File metadata and controls

73 lines (50 loc) · 4.35 KB

BUD-06

Upload requirements

draft 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.

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.
402 Payment Required Payment is required before the upload can proceed. See BUD-07.
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:

X-Content-Type: application/pdf
X-Content-Length: 184292
X-SHA-256: 88a74d0b866c8ba79251a11fe5ac807839226870e77355f02eaf68b156522576

Example response from the server if the upload may proceed:

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/1.1 400 Bad Request
X-Reason: Invalid X-SHA-256 header format. Expected a string.
HTTP/1.1 413 Content Too Large
X-Reason: File too large. Max allowed size is 100MB.
⚡