Re: Draft v1 Update for Resumable Uploads

Eric J Bowman <> Mon, 20 June 2022 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1C5FC159490 for <>; Mon, 20 Jun 2022 01:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.76
X-Spam-Status: No, score=-7.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_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: (amavisd-new); domainkeys=pass (768-bit key); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i3RprG2MJ1by for <>; Mon, 20 Jun 2022 01:40:52 -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 E33DDC14CF18 for <>; Mon, 20 Jun 2022 01:40:51 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o3Cuy-0003qg-KR for; Mon, 20 Jun 2022 08:37:56 +0000
Resent-Date: Mon, 20 Jun 2022 08:37:56 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o3Cux-0003pn-5f for; Mon, 20 Jun 2022 08:37:55 +0000
Received: from ([]) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1o3Cuw-001GcK-Fj for; Mon, 20 Jun 2022 08:37:54 +0000
ARC-Seal: i=1; a=rsa-sha256; t=1655714260; cv=none;; s=zohoarc; b=XzZQWcIOI5lt6Qr6UDAVeSxP4ZiJnYsVfMukEilyWY/JI1q/9Dnq6Svzmlc1A5ZBJIv67Rkuc5lZbI1EeqtHkkDhWPttowWpH4/QBvODxsopTubMwSjCr1a4Pp/VGtY2nddSwPybwckbu+JBSEZjwDuDRp1NuJCpAnwlz/jYycw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=zohoarc; t=1655714260; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=3rf1qB9maqqHF64NHUGJHWfWsGHw7+nBdzHA784MrV8=; b=nxuteAfzqWbviMZbzhJUFcV+LWgHVnTTQyEkfMwfBDLkW8kgOgF6pHk5xUF/Z1oL/eVbjIg68CDk7UYd6P1HEGvCq9iULiem8FUZVdI8UcXJXsP+RW75fSZfEPurtbjL97h5sqGYZbiuIrXDhnUna1yIQCb4e3FGfU/ckE0GCZ4=
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=ewuoWCAhBQZtcA50+Z9nOEbCHQt42PbBd0PlRw6wxWx/YMG7nmyI/LYL3aJ7Mhr3+SROw+XXlRm5 JjqWw9+l3DdHeEqfJeV6kbW00lfHu4uvFvn44Cwn+IcT6ItIAAf1
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1655714260; 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=3rf1qB9maqqHF64NHUGJHWfWsGHw7+nBdzHA784MrV8=; b=Y4MO17o6ByoNmuQqrc4mqSOedPTeDbzaBd7R4qLS1lgBgZJklgbMs7wBFhqnPitR SPpXxWFv30w06ReppgAVRs+6oaALUVZZIbmmWxJiC63l2Y5n80tCFNMKutyZqkjSYcN xDVeLjC7QI9H9HZNgl80BDKhVad5NfCTeuS2feV0=
Received: from by with SMTP id 1655714258508375.55205621323296; Mon, 20 Jun 2022 01:37:38 -0700 (PDT)
Received: from [] by with HTTP;Mon, 20 Jun 2022 01:37:38 -0700 (PDT)
Date: Mon, 20 Jun 2022 01:37:38 -0700
From: Eric J Bowman <>
To: Julian Reschke <>
Cc: ietf-http-wg <>
Message-Id: <>
In-Reply-To: <>
References: <> <Yq67WGkb0LtJIAP9@xps13> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_104244_1306555486.1655714258478"
Importance: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Feedback-ID: rr08011227b76c1b82d5a1b3491a38024300007a266274cacba6b8d8fff80b2e90ec26e7b2d9279f8a3fff44:zu080112277d9a8349e80065cddc8973170000d7afd1394072eddb1ce50302d1d96b7ed29b0c3df300d04bc3:rf08011232e5899fc708b4f4fb423494a500007afa051d2848ce8005d505721360c76c7d1bdd85439fa24b599d795018bc1504eda222a1: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: 1o3Cuw-001GcK-Fj c6e06dfdb113ac26e019ed6ec6eff2ae
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <>
X-Mailing-List: <> archive/latest/40188
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

>> Why I suggested FTP. But accepting what you said, wouldn't you also have 
>> to enforce PATCH = append to use application/octet-stream? 

> I think it would be clearer to use a new type.


From my ongoing project since the aughties (still don't care to share the code), an HTTP API for DARCS... a DARCS patch file may contain one or both of filesystem directives and deltas. Crying out for a polyglot format with multiple media types to define processing.

What I have now, as informed by this thread...

Consider a DARCS patch file consisting of fileops, text deltas (metadata) and, in some or all cases, a BLOB delta.

PUT text/vnd.darcs OR multipart/vnd.darcs

Creates a text-based patch file which may annotate a blob.

OR creates a multipart patch file containing partial blob...

OR filter instructions for a blob.

PATCH {target URI} text/vnd.darcs OR text/vnd.darcs-invert

Applies or reverts only all text deltas in the patch file.

PATCH {target URI} application/vnd.darcs OR application/vnd.darcs-invert

Executes or reverts only all fileops in the patch file.

I'm 415 on the inverse and in no hurry to implement.

PATCH {target URI} multipart/vnd.darcs OR multipart/vnd.darcs-invert

Applies or reverts only all deltas in the patch file, text and/or blob.

I'm 415 on the inverse, but it's top priority to implement. Undo a blob filter.

Yes, this means applying a patch file with fileops and deltas, requires two operations. Who cares. I'm more interested in data integrity than anarchically scaling PATCH requests.

I am violating the wording, if not the spirit, of RFC 5789 so I'm going to have some things to say about updating PATCH to allow what I just described... furthermore, what if I want to link to my patch file instead of enclosing it as the request entity?

Bound to be fresh if it's resident on the origin server, no? Come to think of it, the entity body could list additional target URIs... apply googly-eye filter to all kitty pics. Haha, lolz, now revert on all non-Hitler kitties.