Re: Draft v1 Update for Resumable Uploads

[Guoye Zhang <[e-mail]>]

Despite sharing the name, SFTP is not related to FTP at all. It is a completely different binary protocol that transfers files over SSH, and SSH is not a protocol designed for public accessible servers to serve or receive resources.

I think we should focus the topic on resumable upload support for HTTP. We all like HTTP protocols here and hope it can be more powerful and support more use cases.

Guoye

> On Jun 19, 2022, at 17:31, Eric J Bowman <[e-mail]> wrote:
> 
> >
> > I don’t think “just use FTP” is a sentiment shared among the workgroup.
> > Safari removed FTP support last year, and this year FTP support is
> > deprecated on all Apple platforms.
> >
> 
> Look at the reasons why... outdated FTP libraries *should* have been removed from browsers years ago. Or better, updated to support SFTP/FTPS, but oh well, corporate says "find a HTTP solution" but that's just nuts, frankly don't care what "HTTP developers" think, I've always been an Internet developer. Death of GOPHER predicted, film at 11...
> 
> [link] https://gopher.tildeverse.org/tildeverse.org
> 
> FTP is hardly deprecated (given SFTP/FTPS) and remains a viable and valuable tool IRL. SFTP is still how I upload files to my webserver and I highly doubt I'm alone; if you want a stateful upload without the resource/representation dichotomy of HTTP then it's still the appropriate tool in the box for resumable uploads of large files, and seems ideal for your use case, especially considering it's Apple software running on Apple hardware reporting to Apple HQ, in which case I can't fathom any technical reason not to use it.
> 
> >
> > FTP predates TCP/IP networks, and it does not utilize the bidirectional
> > communication of TCP connections. It requires multiple connections to
> > transfer a single resource and does not reuse connections. The inefficiency
> > and the extra round-trips make the protocol unacceptable in modern standards.
> >
> 
> Aside from no, FTP is native to TCP/IP networking, etc...
> 
> Couldn't disagree more, or more vehemently, considering a use-case of uploading "hundreds of megabytes" where a few milliseconds of latency simply does not matter one whit, and is a net-zero proposition vs. your proposal anyway. Nor does re-use of the connection, or anything else HTTP offers for completely different use-cases to provide anarchic scalability in the other direction. There is nothing "unacceptable" about using SFTP to upload large files in a resumable manner -- in fact, it's what FTP was designed for and why it's still in wide use today in the real world.
> 
> Find me one Web developer who uses HTTP PUT to upload HTML/CSS/JS files to their server (or the cloud) instead of SCTP, and I'll give you a cookie. ;)
> 
> >
> > There is no CDN support for FTP, and it didn’t receive the same security or
> > performance optimizations from the decades of work that went into HTTP. 
> > It does not support modern transport protocol QUIC. The list can go on.
> >
> 
> Not sure what benefit is to be gained from using a CDN for large-file uploads? But I'm pretty sure CDN's have FTP download support... maybe Mnot can answer that? Which was never a consideration of HTTP, all the optimizations in HTTP are designed for anarchic scalability of downloads from one server to many clients, not uploads from one client to one server. Bringing up QUIC is deflecting. You can run FTP over a SCTP stack (particularly if you're Apple and control the hardware and software end-to-end) if you so desire and I'm not aware of any "security considerations" let alone any need to fix something that isn't broken just because it's "not modern."
> 
> >
> > FTP belongs in a history museum. It’s not a protocol anybody should still
> > be deploying in production.
> >
> 
> Except Plesk, CPanel, or any other webhosting solution in wide deployment which still relies on FTP (I'm going to stop qualifying it with SFTP/FTPS from here on, ok) for all kinds of good reasons. Maybe because of resumable uploads? Your position is very arrogant and misinformed, sorry.
> 
> >
> > In this case, the resource is an arbitrary binary blob. Maybe we should
> > go with “application/octet-stream” which would be accurate, but we are 
> > hesitant to define a general way to PATCH octet-streams as the only 
> > capability we use is appending.
> >
> 
> I was trying to help you understand the resource/representation dichotomy of HTTP, particularly regarding PATCH, irrespective of the nature of your resource. There is not, and cannot be, any "generic" media type for the method in question, even if you're only appending -- application/octet-stream works for PUT. Not PATCH. Not in any way I can grok.
> 
> -Eric
> 
>