Draft v1 Update for Resumable Uploads

Guoye Zhang <guoye_zhang@apple.com> Thu, 16 June 2022 21:36 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 02BC1C15AE2D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Jun 2022 14:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.506
X-Spam-Level:
X-Spam-Status: No, score=-8.506 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, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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); dkim=pass (2048-bit key) header.d=apple.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 L_qie0wk8hM1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Jun 2022 14:35:58 -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 E386DC14F735 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 16 Jun 2022 14:35:58 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o1x5N-000506-RG for ietf-http-wg-dist@listhub.w3.org; Thu, 16 Jun 2022 21:31:29 +0000
Resent-Date: Thu, 16 Jun 2022 21:31:29 +0000
Resent-Message-Id: <E1o1x5N-000506-RG@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <guoye_zhang@apple.com>) id 1o1x5M-0004zC-5g for ietf-http-wg@listhub.w3.org; Thu, 16 Jun 2022 21:31:28 +0000
Received: from rn-mailsvcp-ppex-lapp35.rno.apple.com ([17.179.253.44] helo=rn-mailsvcp-ppex-lapp35.apple.com) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <guoye_zhang@apple.com>) id 1o1x5K-00077Q-I5 for ietf-http-wg@w3.org; Thu, 16 Jun 2022 21:31:28 +0000
Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 25GL9SV7013320 for <ietf-http-wg@w3.org>; Thu, 16 Jun 2022 14:31:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : to; s=20180706; bh=LAj5AfEHJEB3PZicr9no8hEV1guhMy87NCEQwKs3kvk=; b=soAkyBatf6TxAsSLH8Xttv/Q2a36OKKTfM6NL2J903NqUIFy2WA8U79Vr9KN01owQWem 6GNYqa6cXCwyed9YAZhx2mx7lDFu+qxFPqfs2sgiOGE4HaTwLYuEPMQeSBwXXzgzTLA9 21eGWJc86bgDB0HTqPxMMP6yLB+I77UzXH09yrAfFaEwH1Wkbk8lLZWvc+R7H1G/EBHs yPwL0m+ZREiCfZknlTiH7vR0XuYh/PnCV+xo/kEoMR2mfA/yE3AJE5oyCD8CnSwGfnEn Ojsg/kJLQXkvgz70EBGl1rUlXjFSukReLpyAuFeUChTLZez6/YFTiKqsUKO929gvxMDx aA==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3gmpk80j8p-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <ietf-http-wg@w3.org>; Thu, 16 Jun 2022 14:31:14 -0700
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RDL00ZLRAFY6FJ0@rn-mailsvcp-mta-lapp04.rno.apple.com> for ietf-http-wg@w3.org; Thu, 16 Jun 2022 14:31:10 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0RDL00M00A982T00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for ietf-http-wg@w3.org; Thu, 16 Jun 2022 14:31:10 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 2a152226d9ea59fb589454d9ebfae0d8
X-Va-E-CD: be9af0ffbc125e16b46d346c4d5a50eb
X-Va-R-CD: df9cf7a592e30defc3b1ab69fe3e64e3
X-Va-CD: 0
X-Va-ID: ec2f87fe-40a0-4649-9692-d7e926b5af7d
X-V-A:
X-V-T-CD: 2a152226d9ea59fb589454d9ebfae0d8
X-V-E-CD: be9af0ffbc125e16b46d346c4d5a50eb
X-V-R-CD: df9cf7a592e30defc3b1ab69fe3e64e3
X-V-CD: 0
X-V-ID: 045fe638-049c-4109-96dc-46dafc4eaf86
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-06-16_16:2022-06-16,2022-06-16 signatures=0
Received: from smtpclient.apple (unknown [17.11.20.19]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0RDL00SN4AFXQM00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for ietf-http-wg@w3.org; Thu, 16 Jun 2022 14:31:10 -0700 (PDT)
From: Guoye Zhang <guoye_zhang@apple.com>
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3724.0.1.1.11\))
Message-id: <BED5A5BC-3F7F-47E2-815E-DC0483328DFD@apple.com>
Date: Thu, 16 Jun 2022 14:30:59 -0700
To: ietf-http-wg@w3.org
X-Mailer: Apple Mail (2.3724.0.1.1.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-06-16_16:2022-06-16,2022-06-16 signatures=0
Received-SPF: pass client-ip=17.179.253.44; envelope-from=guoye_zhang@apple.com; helo=rn-mailsvcp-ppex-lapp35.apple.com
X-W3C-Hub-DKIM-Status: validation passed: (address=guoye_zhang@apple.com domain=apple.com), 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, RCVD_IN_DNSWL_MED=-2.3, 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: mimas.w3.org 1o1x5K-00077Q-I5 c0d533a5a23ddb916783e92c364f5ce0
X-Original-To: ietf-http-wg@w3.org
Subject: Draft v1 Update for Resumable Uploads
Archived-At: <https://www.w3.org/mid/BED5A5BC-3F7F-47E2-815E-DC0483328DFD@apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40131
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>

Hi all,

Our previous resumable upload draft generated a lot of discussions. I’m glad to announce that we have a new draft ready to address many feedbacks that suggested adopting the PATCH method. In this draft, we split the Upload Transfer Procedure into 2 separate procedures: Upload Creation Procedure and Upload Appending Procedure.

https://datatracker.ietf.org/doc/draft-tus-httpbis-resumable-uploads-protocol/

1. Content-Range

We attempted adopting Content-Range header, however, we realized that it doesn’t support unknown lengths which is an important use case that our clients require. Therefore we kept Upload-Offset and Upload-Incomplete headers.

We are open to discuss other options, such as modifying the semantics of the Content-Range header if that’s preferred, although it might cause more breakages than defining new headers.

2. Media types

PATCH currently doesn’t define a media type. We went through the list of media types but couldn’t find the appropriate category for the Upload Appending Procedure. It is a generic byte-appending operation that can modify any types of media, so we don’t think it fits into an application media type.

We are open to suggestions if a media type is desired.

3. 1xx intermediate response

We surveyed the most popular HTTP libraries in many languages, and nearly all of them consider 1xx responses an internal signaling mechanism so they don’t expose the ability for applications to handle them. (We are also guilty of this as maintainers of URLSession API on Apple platforms.) If we use 1xx response for any critical information, it would prevent nearly all tus-v1 adopters to switch to this new protocol until it’s natively supported in HTTP libraries.

We think having just the feature detection part using 1xx response is a good balance, both eliminating any extra round trips for HTTP libraries implementing this protocol and allowing application adopters to ignore it.

4. Can we PATCH a PATCH?

Yes, Upload Creation Procedure supports any method, including PATCH. We included a section “Request Identification” about the nuances in this area. Unfortunately, this added complexity is the result of splitting the procedures, but we don’t think it will complicate the implementations in most cases. Servers can still decide what methods make sense for their use case and whether to support PATCH.


Looking forward to continuing the discussions and refinements of the draft.

Best regards,
Guoye Zhang