The relevant part of the max-age limit definition is:
Specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response. After the resource's lifetime is reached, the server might make the upload resource inaccessible and a client SHOULD NOT attempt to access the upload resource as these requests will likely fail.
The recommendation against accessing the upload resource can very easily lead to a bad end user experience.
Suppose a client application receives a 201 creation response with Upload-Limit: max-age=600, and it begins appending the rest of the file. It will take 20 minutes in total due to being a large file on a poor connection. 15 minutes in, the user's network connection fails. The server received 15 minutes' worth of data, but the 104 responses don't include Upload-Limit or the client can't see 104 responses (e.g., since it's a browser client). Because it's been over 600 seconds since the generation of the previous response, the client believes the upload is expired despite that it really isn't. The upload is needlessly restarted instead of resumed.
The same problem would occur if the end user decided to abort the request by using a pause button in the application. They'll probably want to resume again shortly, but because the last response was received more than max-age seconds ago, the client will consider the upload expired.
I'm not sure what the best way to fix this is. Perhaps in the absence of a response after request termination, clients should assume the last max-age applies again? Alternatively, for simplicity and guaranteed accuracy, this recommendation could simply be removed, letting the server inform the client of the missing resource (e.g., via 404 or 410) in the event it actually did expire.
Either way, it may be worth adding an explicit note about this situation to inform clients to consider this common edge case.
The relevant part of the
max-agelimit definition is:The recommendation against accessing the upload resource can very easily lead to a bad end user experience.
Suppose a client application receives a 201 creation response with
Upload-Limit: max-age=600, and it begins appending the rest of the file. It will take 20 minutes in total due to being a large file on a poor connection. 15 minutes in, the user's network connection fails. The server received 15 minutes' worth of data, but the 104 responses don't includeUpload-Limitor the client can't see 104 responses (e.g., since it's a browser client). Because it's been over 600 seconds since the generation of the previous response, the client believes the upload is expired despite that it really isn't. The upload is needlessly restarted instead of resumed.The same problem would occur if the end user decided to abort the request by using a pause button in the application. They'll probably want to resume again shortly, but because the last response was received more than
max-ageseconds ago, the client will consider the upload expired.I'm not sure what the best way to fix this is. Perhaps in the absence of a response after request termination, clients should assume the last
max-ageapplies again? Alternatively, for simplicity and guaranteed accuracy, this recommendation could simply be removed, letting the server inform the client of the missing resource (e.g., via 404 or 410) in the event it actually did expire.Either way, it may be worth adding an explicit note about this situation to inform clients to consider this common edge case.