Feedback for Resumable Uploads

Hello HTTP WG and Resumable Uploads authors,

This document moved in a very good direction since I last reviewed it! The fundamental design is on point, and my comments mostly relate to expanding the interoperability with other applications of HTTP:



4.2.1. Client Behavior

The section says "All request methods that allow content are possible.” Do you anticipate compatibility with QUERY?



5. Status Code 104 (Upload Resumption Supported)

Is the “Upload-Offset” field found in an Upload Resumption Supported response usable by the client in place of making the Offset Retrieval request?

Considering that the server does not acknowledge every single byte it receives, how does this work if Upload-Offset in an Upload Append operation is expected to exactly match the current upload offset?

Now even if the client can’t reliably use Upload Resumption Supported alone to determine where to start an upload append operation, section 4.3.1. Client Behavior says “The client is expected to handle backtracking of a reasonable length”. I think this would be a good place to explain the Upload-Offset field in a 104 (Resumption Supported) response indicates data that has been committed to the upload resource, and need not be stored by the client for future use by this upload resource, but can be freed.

In general, the ability for a server to signal that a certain amount of the input has been committed and processed would be very useful to have more generally. The only similar functionality I know of is the 102 (Processing) status, and it doesn’t actually have a way of indicating progress, just activity. Could this use of Upload-Offset be defined more generally?



6. Media Type application/partial-upload

After our early discussions I floated a substantially similar media type for draft-httpapi-patch-byterange, essentially being “apply the enclosed bytes to the range of bytes in the Content-Range header”, but I recall there was some push-back that a media type would rely on out-of-band information in HTTP header fields.

It appears this document satisfies that concern by instead reading the `Upload-Offset` header first, and evaluating it as a condition, before proceeding with evaluating the contents of the body (at which point, the specific value of the header does not come into play).

Such a header, a new conditional request header that tests the length of the existing resource, could be useful in other applications, especially log writing and journal synchronization applications. What if “Upload-Offset” for making requests was called “If-Length”?

And likewise, the media type itself could be a generic media type that represents “content to append to the target”, so it could be re-used more generally outside the resumable uploads protocol?



11. Responses to Uploads

Content-Location specifies the URI of the attached response body. Normally, it’s for Content-Type negotiation, but as a consequence of its definition, if it were found in a 4xx response, I would expect it to identify a permanent URI that I can use to reference that error later.

Likewise, if included in 1xx, this would suggest that the client has the URI where it can re-request the result of the operation, whether it’s an error or a success. This doesn’t let you retrieve the status code, but for API applications that can infer success or error from the response body, so this may still be an improvement.

So, to assist in recovering the response in the case the response is lost, would there be a benefit to mentioning Content-Location field for 104 (Upload Resumption Supported)?



Are resumable upload resources resumable?

The answer seems to be “no,” as there is a separate, well-defined process for recovering from a failed upload append. However, it may still be worth noting something like:

 An upload resource MUST NOT itself be resumable. An interrupted request to an upload resource is simply retried from the “Offset Retrieval” step.



Preserving Incomplete Uploads with `Incremental: ?1` and/or `Prefer: transaction=persist`

Resumable uploads are necessarily incremental messages, in that every byte uploaded necessarily changes the state of the server. So, would it be worth suggesting the use of the `Incremental: ?1` field from draft-ietf-httpbis-incremental-latest <https://httpwg.org/http-extensions/draft-ietf-httpbis-incremental.html>, and/or the `Prefer: transaction=persist` preference in draft-ietf-httpapi-patch-byterange <https://www.ietf.org/archive/id/draft-ietf-httpapi-patch-byterange-03.html#name-preserving-incomplete-uploa>, in the request headers?



Thanks,

Austin Wright.