Skip to content

RESUMABLE: Include Upload-Limit in response to limit violation #3466

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Acconut wants to merge 1 commit into
base: main
Choose a base branch
from
+3 −0
Open

RESUMABLE: Include Upload-Limit in response to limit violation #3466

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions draft-ietf-httpbis-resumable-upload.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -374,6 +374,8 @@ The following recommendations for limit changes can minimize the risk of causing

Receivers of `Upload-Limit` parse the Dictionary as described in {{Section 4.2 of STRUCTURED-FIELDS}}. Where the Dictionary is successfully parsed, this document places two additional requirements on Dictionary members. First, a member with an unknown key MUST be ignored. Second, a member with a known key but a value of unexpected type MUST cause the entire `Upload-Limit` header field to be ignored, or alternatively the complete HTTP message MUST be treated as malformed.

When a request is rejected because limits were violated, the response MUST include the `Upload-Limit` header field carrying all limits of the corresponding upload resource.

@GrantGryczan GrantGryczan Jun 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a client implementer, I love the "MUST", but this may be excessively restrictive for servers. What if the part of the server that enforces the limit is unaware of resumable uploads? It could be an intermediary, or some general request size limit configuration from a framework, etc. The server would merely use Upload-Limit to communicate these existing limits, at least for max-append-size. Perhaps this should be rephrased to exclude cases like those? Either that, or change it to "SHOULD".

@Acconut Acconut Jun 26, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a valid point. We can reuse the phrasing from a related paragraph in the same section:

A server responding with a 413 (Content Too Large) status code as a result of its upload limits SHOULD include the Upload-Limit header field in this response if possible. This might not be possible if intermediaries enforce content size restrictions.

@GrantGryczan GrantGryczan Jun 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, which reminds me to comment on that excerpt as well.


When responding to an `OPTIONS` request without the `Upload-Complete` header field, if the resource that is the target of the request supports the creation of a resumable upload resource ({{upload-creation}}), the server MUST include the `Upload-Limit` header field with the corresponding limits in the response. If a server is configured such that all of its resources support the creation of upload resources with identical limits, it SHOULD include the `Upload-Limit` header field in response to an `OPTIONS` request for the target `*` (if this target is supported). If the server does not apply any limits, it MUST use `min-size=0` instead of an empty header value.

A client can use an `OPTIONS` request without the `Upload-Complete` header field to discover whether the resource supports resumable uploads and to learn potential limits before creating an upload resource. To reduce the likelihood of failing requests, the limits announced in an `OPTIONS` response SHOULD NOT be less restrictive than the limits applied to an upload once the upload resource has been created, unless the request to create an upload resource included additional information that warrants different limits. For example, a server might announce a general maximum size limit of 1 GB, but reduce it to 100 MB when the media type indicates an image.
Expand Down Expand Up @@ -977,6 +979,7 @@ Reference:
* Redefine Upload-Complete on the server side.
* Recommend incremental delivery.
* Clarify `min-size` limit and its client behavior.
* Include `Upload-Limit` in response to limit violation.

## Since draft-ietf-httpbis-resumable-upload-10
{:numbered="false"}
Expand Down