I suggest we recommend servers include the Upload-Limits header in all 4xx responses produced because of a client's violation of upload limits. This recommendation already exists for 413 responses, but I ran into a situation where this would be greatly useful for other status codes:
If a server doesn't want to pay the cost of resumable uploads below a certain min-size (as per #3446), I'd expect the server to reject any empty upload creation request that has an Upload-Length under that min-size, since the overhead of an upload resource may be an undesirable. Ideally, an optimistic client should be able to handle that rejection response by resubmitting the request in one non-resumable request rather than as an upload append.
The problem is, the server has no means to communicate that the response failure was due to a min-size violation. Therefore, it seems a generalized, optimistic client has no choice but to handle all 4xx upload creation failures by requesting the upload limits and possibly trying again. Most of the time, this results in extra round trips with no benefit. If the client could see the Upload-Limits in that response, another round trip wouldn't be needed.
I suggest we recommend servers include the
Upload-Limitsheader in all 4xx responses produced because of a client's violation of upload limits. This recommendation already exists for 413 responses, but I ran into a situation where this would be greatly useful for other status codes:If a server doesn't want to pay the cost of resumable uploads below a certain
min-size(as per #3446), I'd expect the server to reject any empty upload creation request that has anUpload-Lengthunder thatmin-size, since the overhead of an upload resource may be an undesirable. Ideally, an optimistic client should be able to handle that rejection response by resubmitting the request in one non-resumable request rather than as an upload append.The problem is, the server has no means to communicate that the response failure was due to a
min-sizeviolation. Therefore, it seems a generalized, optimistic client has no choice but to handle all 4xx upload creation failures by requesting the upload limits and possibly trying again. Most of the time, this results in extra round trips with no benefit. If the client could see theUpload-Limitsin that response, another round trip wouldn't be needed.