RESUMABLE: Include Upload-Limit in response to limit violation#3466
RESUMABLE: Include Upload-Limit in response to limit violation#3466Acconut wants to merge 1 commit into
Conversation
|
|
||
| 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. |
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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 theUpload-Limitheader field in this response if possible. This might not be possible if intermediaries enforce content size restrictions.
There was a problem hiding this comment.
Sure, which reminds me to comment on that excerpt as well.
|
This remains unmodified in the text:
Isn't this excerpt redundant now? If there is still value in naming 413 specifically, then perhaps it would be better to use it as an example at the end of the same paragraph as the new, more general recommendation/requirement. You might argue it's better as is for the sake of the surrounding paragraph's flow, but the other stuff related to client handling of 413 responses will (or at least, should) be restructured by #3275 (or a superseding PR) anyway, so that all retry logic is documented in the same place. |
2 participants
Closes #3450.