Re: Draft for Resumable Uploads

I agree that 1xx is a great fit for this on paper, and I have also advocated using 1xx to deliver upload-token and upload-offset in the beginning. However, so far we’ve found none of the commonly used HTTP client-side library exposing this to applications today.

Our goal is to unify the many incompatible resumable upload standards currently being widely deployed across the internet, and requiring a feature that’s not useable today would significantly hinder adoption. Even if every library exposes 1xx responses right now, it will take years before library dependencies, browsers, or even OS updates are widely deployed.

I believe the pragmatic approach is to use the basic mechanism of GET/POST requests and 200/204 responses so applications can adopt it today, while also allowing HTTP libraries to gradually take over the responsibility and eventually upgrade every upload to resumable upload automatically without any application change.

Guoye

> On Apr 1, 2022, at 7:46 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 1xx is exposed in node.js and other JS HTTP implementations. I think what you mean is that it won't be implementable using JS in a browser. However, the right thing to do there may very well be to implement natively in the browser -- assuming that it has to be implementable without changes to browsers is an artificial constraint that may not be relevant.
> 
> 
> 
>> On 2 Apr 2022, at 1:40 pm, Guoye Zhang <guoye_zhang@apple.com> wrote:
>> 
>> 
>> 
>>> On Apr 1, 2022, at 6:30 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>> 
>>> 
>>> 
>>>> On 2 Apr 2022, at 6:30 am, Guoye Zhang <guoye_zhang@apple.com> wrote:
>>>> 
>>>> Unfortunately, we’ve determined that 1xx response is too unreliable for critical information. Many middleboxes drop it, and most client frameworks do not expose it. Therefore we only use it for feature detection and none of the critical functionalities depend on it.
>>> 
>>> That's something you should re-examine. When running over HTTPS and especially HTTP/2 (or /3), it's been found sufficiently reliable; e.g., see browsers' emerging deployments of 103 Early Hints.
>>> 
>>> Cheers,
>>> 
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>> 
>> Yes, we have looked at Early Hints. It is a performance optimization and the loss of this response does not prevent any features from working.
>> 
>> We hope that tus-v2 can be implemented either by the HTTP libraries themselves, or applications on top of it. For example, JavaScript `fetch` API does not expose 1xx responses at all. If we put any important info in intermediate responses, it would make the protocol unimplementable in JavaScript.
>> 
>> Guoye
> 
> --
> Mark Nottingham   https://www.mnot.net/
>