Re: Draft v1 Update for Resumable Uploads

Guoye Zhang <> Mon, 20 June 2022 01:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D900C14CF0C for <>; Sun, 19 Jun 2022 18:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.502
X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.745, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZZzitmhB6AdT for <>; Sun, 19 Jun 2022 18:13:45 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 74E27C14F73B for <>; Sun, 19 Jun 2022 18:13:45 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o35vn-0003oy-D0 for; Mon, 20 Jun 2022 01:10:19 +0000
Resent-Date: Mon, 20 Jun 2022 01:10:19 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o35vl-0003o5-9O for; Mon, 20 Jun 2022 01:10:17 +0000
Received: from ([]) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1o35vk-0011BF-6H for; Mon, 20 Jun 2022 01:10:16 +0000
Received: from pps.filterd ( []) by ( with SMTP id 25K14QgD003194; Sun, 19 Jun 2022 18:09:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=VmTHUg2O8tVv7QMWSGER53EYwl+hyP6qQB4DY0UEZUE=; b=XYonknxL8/7CndhX7yhi6AywTo/aiJrfM4UUTA9csG8KdZBlC+dwNPaJWgxKPAtcCct4 O0pmXZ5qYCLLjR9FdlMPrkfZJvAebO0iIPj34d1S5SNKb5SL0jCuayOgLU1Vu0bmVE11 /kgxyDCTU4X0bnCUBB05ND/lY4wBstQwaidIMMeEii5s4vdOJ8n/eRwPVFGmgPpBkPiE TwpeQZTogJoNO0+um86ASzO8TzvR9HWWATrtXwi4a4w+ocyhgJH65Xg2uvJ0KXxwapwO PJvH344rXNl1oBMf9Bnue5izb9FwVVzFqznC+J9UqkdvmJpIzw2x7OCeIWncb/X1xsYH tA==
Received: from ( []) by with ESMTP id 3gsdc301ds-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 19 Jun 2022 18:09:56 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Apr 7 2022)) with ESMTPS id <>; Sun, 19 Jun 2022 18:09:56 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Apr 7 2022)) id <>; Sun, 19 Jun 2022 18:09:56 -0700 (PDT)
X-Va-T-CD: 6ce7dffd6ac8afd0af3f738963e57eda
X-Va-E-CD: 7fa589823f194c8498e6df6440bddbf3
X-Va-R-CD: 87a202228b76ae5a02807a21fbbc1b7c
X-Va-CD: 0
X-Va-ID: c114bd8f-14b2-4482-92e8-5efb2f03d853
X-V-T-CD: 6ce7dffd6ac8afd0af3f738963e57eda
X-V-E-CD: 7fa589823f194c8498e6df6440bddbf3
X-V-R-CD: 87a202228b76ae5a02807a21fbbc1b7c
X-V-CD: 0
X-V-ID: a4e4db31-e420-46d6-9b1a-4696b0100d19
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-06-19_12:2022-06-17,2022-06-19 signatures=0
Received: from (unknown []) by (Oracle Communications Messaging Server 64bit (built Apr 7 2022)) with ESMTPSA id <>; Sun, 19 Jun 2022 18:09:56 -0700 (PDT)
From: Guoye Zhang <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_A3E68E7F-4B1D-4F2A-B0AE-A83DF9DBA096"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3724.\))
Date: Sun, 19 Jun 2022 18:09:45 -0700
In-reply-to: <>
Cc: gs-lists-ietf-http-wg <>, ietf-http-wg <>
To: Eric J Bowman <>
References: <> <Yq67WGkb0LtJIAP9@xps13> <> <> <> <>
X-Mailer: Apple Mail (2.3724.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-06-19_12:2022-06-17,2022-06-19 signatures=0
Received-SPF: pass client-ip=;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-7.0
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1o35vk-0011BF-6H ed84bb6aaa7fb69457193f8bce3726c8
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <>
X-Mailing-List: <> archive/latest/40169
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.


> On Jun 19, 2022, at 17:31, Eric J Bowman <> 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]
> 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