Re: Draft for Resumable Uploads

> On Apr 11, 2022, at 10:45 PM, Julian Reschke <julian.reschke@gmx.de> 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.

....Roy