Re: Draft for Resumable Uploads

> On Apr 5, 2022, at 00:38, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> Am 05.04.2022 um 08:28 schrieb Eric J Bowman:
>> ---- On Mon, 04 Apr 2022 23:09:32 -0700 *Julian Reschke
>> <julian.reschke@gmx.de>* wrote ----
>> 
>>    Am 05.04.2022 um 08:05 schrieb Eric J Bowman:
>>     > >
>>     > > First, how does it uniquely identify a resumable upload?
>>     > >
>>     >
>>     > A 206 response to a non-range request uniquely, unambiguously, and
>>     > elegantly identifies an incomplete resource. Identifying a
>>    resource as
>>     > both incomplete *and* completeable, introduces tight coupling at the
>>     > protocol layer.
>>     > ...
>> 
>>    It's an interesting idea; but we would need to modify the core specs
>>    for
>>    that (right now it's only defined for responses to range requests).
>> 
>>    Best regards, Julian
>> 
>>    -------------------------------------
>> 
>>    Exploring the undefined aspects of HTTP to flesh out the core specs,
>>    is preferable to me over adding to or even extending HTTP. Y'all
>>    never told me *not* to respond 206 on a non-range request.
>>    Implementations just don't care about 206 being undefined for this;
>>    they just "fall back to 200". As they should. Nothing breaks.
>> 
>>    -Eric
> 
> Hm, no.
> 
> If the client gets a 206 for incomplete content and falls back to 2xx
> handling, it will assume the content is indeed complete.
> 

This is also my understanding.

First, it seems the semantics are different enough that we should mint a new status code for this. 206 implies that the response is not the literal content of the resource; the actual content of the resource is found by parsing the multipart/byteranges response.

Second, the client would have to make the request advertising that it understands such a “sparse document”. Maybe use the “Prefer” header for this:

GET /upload-target HTTP/1.1
Prefer: sparse

Finally, I’m not sure I fully understand what the response would indicate exactly. Shall the server actually support “sparse documents” (where some bytes are undefined)? This would allow users to upload segments out-of-order, and in parallel from different uplinks. If the client does not support sparse documents, how should the server respond? (Fill in the undefined regions with zeros?)

Thanks,

Austin.