Re: Draft v1 Update for Resumable Uploads

Eric J Bowman <> Mon, 20 June 2022 00:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4182C14F73D for <>; Sun, 19 Jun 2022 17:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.76
X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); domainkeys=pass (768-bit key); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UoFCnEti6jyd for <>; Sun, 19 Jun 2022 17:34:54 -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 9A96AC14F734 for <>; Sun, 19 Jun 2022 17:34:54 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o35Kf-0006Up-1U for; Mon, 20 Jun 2022 00:31:57 +0000
Resent-Date: Mon, 20 Jun 2022 00:31:57 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o35Ke-0006Tw-12 for; Mon, 20 Jun 2022 00:31:56 +0000
Received: from ([]) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1o35Kd-000tzy-4k for; Mon, 20 Jun 2022 00:31:55 +0000
ARC-Seal: i=1; a=rsa-sha256; t=1655685093; cv=none;; s=zohoarc; b=MgXzrzIy2kPU8LXwDy/lwMSZvVIsBjVu9Uv1g1cmpBpDD/VAsHWrq+0E55y6VIdQfMcfeuGVnH70nWklgZDZBZ3UEULhOpkAyDTma7ZyedR3oHIqUanbvMpNeU6aWZWwfmQHw6jA7hbjPhJnoqNYiIdxrxKlbVbqPmnMbJneHq8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=zohoarc; t=1655685093; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=CzhwxG1MpitmwAz7V7s5FDTvNnA1nAeMLoUtfN8DByU=; b=hLltCL+W5ptK0sGOHsNucHZFItbFwrBcVMXl7j38uGtPkxM+mP4D3+yyWn0SBs25ZD3L6tMzVDzLlHi8T6DMHJe3ZU3LWIx1Aq4JUFsrmymWng1bM3Q5EC8Sz0OLfLfEIOTlhxK4VrVRZocZEq96EFkZMmJ6pyy8OfLEzpXEu0U=
ARC-Authentication-Results: i=1;; dkim=pass; spf=pass; dmarc=pass header.from=<>
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768;; h=date:from:to:cc:message-id:in-reply-to:references:subject:mime-version:content-type:user-agent; b=UcaasaxldRfU1y35VV0T8nqOGTGZ2cOQghNZVnz1vUF3IamGOk5cMVvAtL0+n2+ndTqdeyaJYsM/ iYiixMja9oyQTFNl3Uw/mnqbKU9l51KSZgCKU/1WC3EUejvNp1X2
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1655685093; s=zm2022;;; h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Feedback-ID:Reply-To; bh=CzhwxG1MpitmwAz7V7s5FDTvNnA1nAeMLoUtfN8DByU=; b=ckVhKjpaUhrXnsmIqLhefioFLsi4QrtVLYcRt2J+Ihm4S4RQT4uhFhkDfICrYg4l f/PWQ56KzQc+AUXApe/LnBgEXGMmOuQzvP3pNdUaLKJ6PVL/I8j6lyWNrDvI3/U3oWN UGvpl/LVH+Tv2P/XX1mjIG/C3ORIBIZnbg1IjrpA=
Received: from by with SMTP id 1655685092394205.26190125010862; Sun, 19 Jun 2022 17:31:32 -0700 (PDT)
Received: from [] by with HTTP;Sun, 19 Jun 2022 17:31:32 -0700 (PDT)
Date: Sun, 19 Jun 2022 17:31:32 -0700
From: Eric J Bowman <>
To: Guoye Zhang <>
Cc: gs-lists-ietf-http-wg <>, ietf-http-wg <>
Message-Id: <>
In-Reply-To: <>
References: <> <Yq67WGkb0LtJIAP9@xps13> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_94435_1498226428.1655685092367"
Importance: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Feedback-ID: rr080112271255035ecf54f6fbb0b6485900001f6e97502d2f95f30b2d739425ab85d65694f9f715d032b5d7:zu080112273a87b2ef2a2e6fb788b7d4780000a9753476f2dbf039245f4bf9425735687a09f687cce8b81871:rf08011232896ccfb9d90f71cfbd1399380000af321ee9deeec0778e0f56ecb33d9eec5053709c1710d2d2bb7ebce95d1020fac6dfd555:ZohoMail
Received-SPF: pass client-ip=;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1o35Kd-000tzy-4k d5805ec181132a1a548e1af81c34649a
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <>
X-Mailing-List: <> archive/latest/40168
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


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


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.