Re: Draft for Resumable Uploads

[Stefan Eissing <[e-mail]>]

> Am 12.04.2022 um 20:10 schrieb Roy T. Fielding <[e-mail]>:
> 
>> On Apr 11, 2022, at 10:45 PM, Julian Reschke <[e-mail]> wrote:
>> 
>> Am 12.04.2022 um 02:39 schrieb Eric J Bowman:
>>> >
>>> >>
>>> >> A resource has to exist first, before it can support PATCH.
>>> >>
>>> >
>>> > Says who?
>>> >
>>> 
>>> Common sense? Clearly-defined method semantics is part-and-parcel of a
>>> uniform interface. If we're going to muddy the waters by allowing
>>> partial PUT (or PUT no content to DELETE), and PATCH to create a primary
>>> resource (not sayin' PATCH can't result in a /previous-version resource
>>> being minted), then I guess HTML was right all along to only bother
>>> defining GET and POST in forms.
>> > ...
>> 
>> Well. You are in disagreement with the spec.
>> 
>> The issue here being that "existence" of a resource is somewhat hard to
>> define.
> 
> I've defined this before. A resource is a mapping of a URI to value over time,
> and thus always exists as a function because there is no distinction between
> an origin server that doesn't exist, a resource that is not yet mapped by the
> origin server (but could be), or the network being down. For example,
> OPTIONS can target a resource that has no representation.
> 
> A value (the selected representation) is what might or might not exist at
> any single point in time for any given request.
> 
> The question for PATCH (when I originally proposed it in HTTP/1.1)
> was whether a non-existent representation would be treated equivalent
> to a zero-length representation for the semantics of PATCH.
> I chose to define it as such because that would match the semantics
> of the Unix patch command.  Hence, that's the definition.
> 
> However, I don't think this discussion is relevant to the proposed upload
> mechanism. HTTP's methods are defined by the method spec, not by
> opinions on what the name allows, and Julian pointed to the right spec.
> 
> The problem with extending old methods to do new tricks is that
> such extensions must be defined with respect to what happens when
> the extension is ignored. A partially ignored extension can wreak havoc,
> both within protocol chains and within single server implementations
> that are internally layered with method-specific assumptions.
> 
> There are only two options for implementing this while staying
> within HTTP. The first is to immediately respond with 202 Accepted
> and the instructions for resuming/finalizing the upload if failed.
> The second is to immediately send a 1xx response to the client that
> directs them to a separate temporary resource corresponding to
> *this* request content being uploaded, upon which the client can do
> resumable tricks if this request fails.
> 
> Both achieve the goal, are method-independent, and don't change
> the semantics for deployed practice.
> 
> A 202 response changes the normal response flow, which
> loses whether the initial request succeeded. This is probably
> not desired most of the time, since resuming an upload is rare.
> 
> A 1xx response does not change the normal response flow,
> but requires that the *client* that indicated support for doing
> a resumable upload support also support a 1xx response.
> IMO, that trade-off is obvious.
> 
> Yes, that requires a protocol chain that supports 1xx responses.
> It is completely and utterly irresponsible at this point to allow
> NEW FUNCTIONALITY to be supported by stacks that are
> somehow incapable of understanding the existing protocol defined
> over 25 years ago. They were required to implement support for 1xx
> and 100. They will want to implement support for 103. They will have to
> implement this new 1xx support if they want a resumable upload
> without losing the initial request status, because 1xx is the only
> way to communicate method-specific, resource-based options
> before a final status code is sent.
> 
> If the 1xx is lost, the client will only see the result of the initial
> request in a 2xx or 4xx response, which could also include
> extensions to indicate where the partial upload is kept and how
> to resume/cancel it with further requests. The difference
> is that the client wouldn't receive that information if the
> connection fails before receiving the final response headers.

+1