Re: Draft v1 Update for Resumable Uploads

Eric J Bowman <mellowmutt@zoho.com> Mon, 20 June 2022 00:34 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4182C14F73D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 Jun 2022 17:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.76
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); domainkeys=pass (768-bit key) header.from=mellowmutt@zoho.com header.d=zoho.com; dkim=pass (1024-bit key) header.d=zoho.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoFCnEti6jyd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 Jun 2022 17:34:54 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 9A96AC14F734 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 19 Jun 2022 17:34:54 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o35Kf-0006Up-1U for ietf-http-wg-dist@listhub.w3.org; Mon, 20 Jun 2022 00:31:57 +0000
Resent-Date: Mon, 20 Jun 2022 00:31:57 +0000
Resent-Message-Id: <E1o35Kf-0006Up-1U@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mellowmutt@zoho.com>) id 1o35Ke-0006Tw-12 for ietf-http-wg@listhub.w3.org; Mon, 20 Jun 2022 00:31:56 +0000
Received: from sender4-pp-o91.zoho.com ([136.143.188.91]) by titan.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mellowmutt@zoho.com>) id 1o35Kd-000tzy-4k for ietf-http-wg@w3.org; Mon, 20 Jun 2022 00:31:55 +0000
ARC-Seal: i=1; a=rsa-sha256; t=1655685093; cv=none; d=zohomail.com; s=zohoarc; b=MgXzrzIy2kPU8LXwDy/lwMSZvVIsBjVu9Uv1g1cmpBpDD/VAsHWrq+0E55y6VIdQfMcfeuGVnH70nWklgZDZBZ3UEULhOpkAyDTma7ZyedR3oHIqUanbvMpNeU6aWZWwfmQHw6jA7hbjPhJnoqNYiIdxrxKlbVbqPmnMbJneHq8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; 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; mx.zohomail.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=mellowmutt@zoho.com; dmarc=pass header.from=<mellowmutt@zoho.com>
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; 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; d=zoho.com; i=mellowmutt@zoho.com; 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 mail.zoho.com by mx.zohomail.com with SMTP id 1655685092394205.26190125010862; Sun, 19 Jun 2022 17:31:32 -0700 (PDT)
Received: from [65.117.211.248] by mail.zoho.com with HTTP;Sun, 19 Jun 2022 17:31:32 -0700 (PDT)
Date: Sun, 19 Jun 2022 17:31:32 -0700
From: Eric J Bowman <mellowmutt@zoho.com>
To: "Guoye Zhang" <guoye_zhang@apple.com>
Cc: "gs-lists-ietf-http-wg" <gs-lists-ietf-http-wg@gluelogic.com>, "ietf-http-wg" <ietf-http-wg@w3.org>
Message-Id: <1817e85940f.12286c1b038392.8521566759651991951@zoho.com>
In-Reply-To: <AB2CA3AA-FB53-4B3B-BC96-A87C175D19EE@apple.com>
References: <BED5A5BC-3F7F-47E2-815E-DC0483328DFD@apple.com> <Yq67WGkb0LtJIAP9@xps13> <D149DCFE-A5C9-418D-80B4-3B5F138AA497@apple.com> <1817b8ce1c8.12200c57b32105.652822867537979220@zoho.com> <AB2CA3AA-FB53-4B3B-BC96-A87C175D19EE@apple.com>
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=136.143.188.91; envelope-from=mellowmutt@zoho.com; helo=sender4-pp-o91.zoho.com
X-W3C-Hub-DKIM-Status: validation passed: (address=mellowmutt@zoho.com domain=zoho.com), signature is good
X-W3C-Hub-DKIM-Status: validation passed: (address=mellowmutt@zoho.com domain=mellowmutt@zoho.com), 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: titan.w3.org 1o35Kd-000tzy-4k d5805ec181132a1a548e1af81c34649a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <https://www.w3.org/mid/1817e85940f.12286c1b038392.8521566759651991951@zoho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40168
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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...



[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