Re: Draft for Resumable Uploads

>

>----------------

...You can upgrade any upload operation with any method to resumable upload using the procedures described in the draft.

>----------------

>







You can also make pigs fly by sewing wings on them, but they'll prolly fly further if you shoot 'em out of a cannon.



>

> There isn’t a huge delta between what you’ve described 

> and what’s currently in the draft.

>



We couldn't be further apart, paradigmatically speaking.


>

>------------------

You’ve also identified the same core procedures for resumable upload: creation, offset retrieval, and resumption. The only extra thing we have is cancellation since we don’t want servers to hold on to resources any longer than necessary if clients already decided to give up.

>------------------

>







Very frustrating that we mean something different by "resource." Like, Oh, you mean server resources not URIs? Best way to solve that problem is to avoid creating it in the first place, by going against the architectural style by assigning UIDs per transaction.



>

>-------------------------

One thing that drove many aspects of the design is our desire to seamlessly upgrade any upload to resumable upload. To us, it’s hugely valuable that a browser or an OS can implement this mechanism under the hood, and all websites and applications would benefit from it without any code change on the client side. This is the reason we have tokens and other newly defined headers, since we don’t want to misinterpret the server supporting something different but happens to use the same header fields.

>-------------------------

>






Ugh. See WS-* and tell me how well that all worked out? Sorry to be glib, but tiring of this argument a decade ago literally drove me to droving.


>

> ...we are not experts in HTTP semantics...

>



But there's no reason for Apple not to be, in 2022. Same discussions, different names, zero institutional knowledge retained over time... same attitude of we're so-and-so and you're not, so let us have our way because surely we couldn't be wrong about something as simple as web architecture. Sigh.







>

> ...feature detection and automatic upgrade [are] core motivations of the draft.

>



Why? You're going down the versioning rabbit-hole. There's no need for /v1/resource, /resource/v1, per-transaction UIDs etc. in your APIs if you're truly embracing Web architecture. If you think I'm pushing back hard, you should meet my goat. 

"Feature negotiation" doesn't chap my hide, but you implementors are rejecting such solutions out-of-hand to save a round-trip. On an unreliable distributed network! Eric.exe has crashed.

-Eric