Re: Draft for Resumable Uploads

Roy T. Fielding wrote:



>

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

>






Yes, you have, and I'm glad you used the word "defined" and good luck with OPTIONS on this URI:



http://foo.bar/xyzzy



Theoretically is, and always has been even before I just conjured it, a resource *by definition* because maybe one day it will be defined (and damn if that isn't why the Web works where Xanadu etc. failed, conceptually) and have a representation (I posit that it does not, at the time of this writing). But, it is undefinable by today's standards. Colloquially, it's really difficult to explain when HTTP defines resources as "created" if I also insist that said resource always existed in the first place.



>

> A value (the selected representation) is what might or might not exist at

> any single point in time for any given request.

>






And the Periodic Table is a horrifically outdated representation / model which remains the basis of getting work done IRL, regardless of where an "electron" may "be". Short of rewriting HTTP to use "defined" instead of "created" how can we have this resumable-upload discussion without tripping over our own pedantry, I wonder?



>

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

>






The semantics of my hobbyist MONTage protocol's PATCH method (and media types) are defined by DARCS patch theory. Whilst taking your (indirect) advice and separating non-existent (404 in my book) from zero-length (410). Maybe I should call it PILL, or PITA? lol ;)



>

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

>






I'm not interpreting method semantics based on their names, Roy. My opinion is that the right spec is wrong. I always tried to transcend the limitations of HTML's reliance on GET/POST by adopting other methods, but if those methods all have overlapping semantics I don't see the point? The bug up my butt remains partial PUT becoming acceptable due to *changes* in the spec. My opinion that create/replace semantics deserves its own unsullied method could go by any number of names, and I would hope that doesn't change over time.



My opinion that method semantics shouldn't vary by media type, transcends any given method regardless of its name or intent. I did not see that 10 years ago when arguing against RFC 5789. At the remove I have now, it's so obviously wrong I feel I shouldn't even need to explain it, but yeah, that's just my opinion. I hate that my pragmatic advice to the youngsters is stick with GET/POST.



>

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

>






Exactly why I'm taking a purist approach in my opposition to PATCH creating resources? What has been discussed in this thread, is a new media type for that, over a decade on since PATCH started getting used for... well... patching. I don't see a problem with that "method-specific assumption" at all, it's been de facto for a long while.



>

> There are only two options for implementing this while staying

> within HTTP...

>

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

>






I'm done ranching, my herd is sold as of October and I'm on to my next opportunity, which still leaves me a strongly-opinionated HTTP hobbyist. Playing Devil's Advocate,  in this thread, Austin and Guoye are discussing multiple clients completing a failed upload. Hence my 206 suggestion, rather than stating there is no HTTP solution to the problem at hand?



>

> The first is to immediately respond with 202 Accepted

> and the instructions for resuming/finalizing the upload if failed.

>

> Both achieve the goal, are method-independent, and don't change

> the semantics for deployed practice.


>






Both assume only one client attempting to upload. In which case I agree with you entirely. In other cases I'm fine with deferring to your wisdom, but not without question, no disrespect intended.



>

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

>






I've always considered 202 as "comment awaiting moderation" which may take anywhere from a few moments, to never, whether the upload succeeded or not. Out here in the sticks, taking a pic and texting it to someone rarely succeeds. If I have to re-try, I'd rather my UA picks up where it left off. Estonia has better connectivity than rural-mountain Colorado (optical fiber getting close lately tho).


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

>






With you there. May not seem like it given my previous responses to this topic, but I guess I was assuming some generic client like libcurl that reports the 1xx and quits instead of continuing, my bad.


>

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

>






So, you're -1 on distributed uploads from multiple clients? Granted I don't have any use case for this, but apparently others do. Not sure what you mean by "final" status code. My years-long example 206 broken-gif file could at any time have been fixed or replaced to achieve a "final" status of 200 OK. Because I thought I understood the temporal nature of a resource (or its definition I guess).


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

>






And how are other clients informed of the partial resource, if at all, seems to be another problem folks are trying to solve. I have another suggestion using weak validators like I used to, but I'm too damn tired. Calving season went off without a hitch, but the past week has been nothing but blizzards and single-digit temps, now is when folks around my area are busy sending hay by the truckload to Churchill Downs, busy busy busy.



-Eric