From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org Sun Jun 19 17:34:58 2022 Return-Path: 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 ; 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 ; 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 ; Sun, 19 Jun 2022 17:34:54 -0700 (PDT) Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from ) 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: 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 ) 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 ) 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= 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 To: "Guoye Zhang" Cc: "gs-lists-ietf-http-wg" , "ietf-http-wg" Message-Id: <1817e85940f.12286c1b038392.8521566759651991951@zoho.com> In-Reply-To: References: <1817b8ce1c8.12200c57b32105.652822867537979220@zoho.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: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/40168 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: ------=_Part_94435_1498226428.1655685092367 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I don=E2=80=99t think =E2=80=9Cjust use FTP=E2=80=9D is a sentiment share= d 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 remove= d 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 d= on't care what "HTTP developers" think, I've always been an Internet develo= per. Death of GOPHER predicted, film at 11... [link]=C2=A0https://gopher.tildeverse.org/tildeverse.org FTP is hardly deprecated (given SFTP/FTPS) and remains a viable and valuabl= e tool IRL. SFTP is still how I upload files to my webserver and I highly d= oubt I'm alone; if you want a stateful upload without the resource/represen= tation dichotomy of HTTP then it's still the appropriate tool in the box fo= r resumable uploads of large files, and seems ideal for your use case, espe= cially 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 i= t. > > 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 inefficien= cy > and the extra round-trips make the protocol unacceptable in modern standa= rds. > Aside from no, FTP is native to TCP/IP networking, etc... Couldn't disagree more, or more vehemently, considering a use-case of uploa= ding "hundreds of megabytes" where a few milliseconds of latency simply doe= s not matter one whit, and is a net-zero proposition vs. your proposal anyw= ay. Nor does re-use of the connection, or anything else HTTP offers for com= pletely different use-cases to provide anarchic scalability in the other di= rection. There is nothing "unacceptable" about using SFTP to upload large f= iles in a resumable manner -- in fact, it's what FTP was designed for and w= hy 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=E2=80=99t receive the same s= ecurity or > performance optimizations from the decades of work that went into HTTP.= =20 > 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 uploa= ds? But I'm pretty sure CDN's have FTP download support... maybe Mnot can a= nswer 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 QUI= C 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 an= d 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=E2=80=99s not a protocol anybody shou= ld still > be deploying in production. > Except Plesk, CPanel, or any other webhosting solution in wide deployment w= hich still relies on FTP (I'm going to stop qualifying it with SFTP/FTPS fr= om here on, ok) for all kinds of good reasons. Maybe because of resumable u= ploads? Your position is very arrogant and misinformed, sorry. > > In this case, the resource is an arbitrary binary blob. Maybe we should > go with =E2=80=9Capplication/octet-stream=E2=80=9D which would be accurat= e, but we are=20 > hesitant to define a general way to PATCH octet-streams as the only=20 > capability we use is appending. > I was trying to help you understand the resource/representation dichotomy o= f HTTP, particularly regarding PATCH, irrespective of the nature of your re= source. There is not, and cannot be, any "generic" media type for the metho= d in question, even if you're only appending -- application/octet-stream wo= rks for PUT. Not PATCH. Not in any way I can grok. -Eric ------=_Part_94435_1498226428.1655685092367 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
>
> I don=E2=80=99t think =E2= =80=9Cjust use FTP=E2=80=9D is a sentiment shared among the workgroup.
<= /div>
> Safari removed FTP support last year, and this year FTP supp= ort is
> deprecated on all Apple platforms.
= >

Look at the reasons why... outdated FTP l= ibraries *should* have been removed from browsers years ago. Or better, upd= ated to support SFTP/FTPS, but oh well, corporate says "find a HTTP solutio= n" 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 1= 1...


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 wan= t a stateful upload without the resource/representation dichotomy of HTTP t= hen it's still the appropriate tool in the box for resumable uploads of lar= ge files, and seems ideal for your use case, especially considering it's Ap= ple 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 connecti= ons. It requires multiple connections to
> transfer a sing= le resource and does not reuse connections. The inefficiency
= > and the extra round-trips make the protocol unacceptable in modern sta= ndards.
>

Aside from no, FTP = is native to TCP/IP networking, etc...

Couldn't di= sagree more, or more vehemently, considering a use-case of uploading "hundr= eds of megabytes" where a few milliseconds of latency simply does not matte= r one whit, and is a net-zero proposition vs. your proposal anyway. Nor doe= s re-use of the connection, or anything else HTTP offers for completely dif= ferent use-cases to provide anarchic scalability in the other direction. Th= ere is nothing "unacceptable" about using SFTP to upload large files in a r= esumable manner -- in fact, it's what FTP was designed for and why it's sti= ll in wide use today in the real world.

Find m= e 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=E2=80=99t receive the same security or
> per= formance 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 be= nefit is to be gained from using a CDN for large-file uploads? But I'm pret= ty sure CDN's have FTP download support... maybe Mnot can answer that? Whic= h was never a consideration of HTTP, all the optimizations in HTTP are desi= gned 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 contro= l 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 i= sn't broken just because it's "not modern."

>
> FTP belongs in a history museum. It=E2=80=99s not a proto= col anybody should still
> be deploying in production.
=
>

Except Plesk, CPanel, or any o= ther 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 resou= rce is an arbitrary binary blob. Maybe we should
> go with= =E2=80=9Capplication/octet-stream=E2=80=9D which would be accurate, but we= are
> hesitant to define a general way to PATCH octet-st= reams 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 q= uestion, even if you're only appending -- application/octet-stream works fo= r PUT. Not PATCH. Not in any way I can grok.

-Eric


------=_Part_94435_1498226428.1655685092367--