W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2022

Re: Draft for Resumable Uploads

From: Austin Wright <aaa@bzfx.net>
Date: Tue, 5 Apr 2022 17:45:50 -0700
Message-Id: <892B7A86-57D0-4B21-9899-65EF3FA84A12@bzfx.net>
Cc: Eric J Bowman <mellowmutt@zoho.com>, Guoye Zhang <guoye_zhang@apple.com>, ietf-http-wg <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>


> 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.


Received on Wednesday, 6 April 2022 00:47:06 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 6 April 2022 00:47:06 UTC