Update requirements on use of Location during upload creation #3203
Conversation
Previously, there were "mixed" requirements on including a Location in interim or final response to an upload creation request. This created some annoying dealing with 104 responses depending on if they were first or not. The PR proposes more consistency. If you're going to generate a Location, it must always be sent and must always be the same value in all responses. Only a SHOULD requirement is levied on the client to check these - making it MUST seems a bit too onerous. Fixes #3183
|
@Acconut PTAL when you can |
| While the request content is being received, the server MAY send additional interim responses with a `104 (Upload Resumption Supported)` status code and the `Upload-Offset` header field set to the current offset to inform the client about the upload progress. These interim responses MUST NOT include the `Location` header field. | ||
| While the request content is being received, the server MAY send multiple interim responses with a `104 (Upload Resumption Supported)` status code and the `Upload-Offset` header field set to the current offset to inform the client about the upload progress. | ||
|
|
||
| Where a response requires a `Location` header field to be included, all interim and final response messages for the same request MUST contain an identical `Location` value. Clients SHOULD verify the `Location` value does not change between response messages. |
There was a problem hiding this comment.
Should there be a recommendation for the client to abort the upload if it detects a changed Location value? How should a client react in this situation?
In addition, I'm wondering if this is too strict for the final response:
Clients SHOULD verify the
Locationvalue does not change between response messages.
For example, the client uploads a large video in a single request. Since the file is large, the server offers a resumable upload via a 104 response and Location pointing to the upload resource. However, the upload completes fine and the server now wants to indicate the video's URI on the CDN to the client in the Location header. That value would then be different from the Location value in the 104 response. But that's OK because the upload is completed. Should we consider that as well as an exemption?
|
I wholeheartedly agree to this change as I proposed the same thing some years ago ;) I agree with Marius question on how to handle the update location header value. Is there ever a reason for the server to change the location of the upload mid upload? The only thing I can think of is some kind of load balancing between servers but that seems like a risky implementation that just adds complexity. Any other ideas? |
4 participants
Previously, there were "mixed" requirements on including a Location
in interim or final response to an upload creation request. This
created some annoying dealing with 104 responses depending on
if they were first or not.
The PR proposes more consistency. If you're going to generate a
Location, it must always be sent and must always be the same value
in all responses. Only a SHOULD requirement is levied on the client
to check these - making it MUST seems a bit too onerous.
Fixes #3183