Re: Resumable Uploads

Mark Nottingham <> Sat, 20 April 2013 06:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79E0721F8B9C for <>; Fri, 19 Apr 2013 23:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.349
X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id psMbrnBjuhGq for <>; Fri, 19 Apr 2013 23:00:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA3E621F892B for <>; Fri, 19 Apr 2013 23:00:41 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UTQq4-000723-UO for; Sat, 20 Apr 2013 05:59:56 +0000
Resent-Date: Sat, 20 Apr 2013 05:59:56 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UTQq1-00071K-Pg for; Sat, 20 Apr 2013 05:59:53 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1UTQq0-0007UN-Vd for; Sat, 20 Apr 2013 05:59:53 +0000
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C0528509B6; Sat, 20 Apr 2013 01:59:30 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Sat, 20 Apr 2013 15:59:27 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Felix Geisendörfer <>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-3.310, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UTQq0-0007UN-Vd c712e60545e92db21f4d61ac95ae8c06
Subject: Re: Resumable Uploads
Archived-At: <>
X-Mailing-List: <> archive/latest/17381
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 18/04/2013, at 11:37 PM, Felix Geisendörfer <> wrote:

> Hi,
> I'm interested in finding out how to perform resumable uploads over http while being compliant with existing specifications. The result of this work will be shared with the community to create interopable server/client software to simplify file uploading on the web.


Daniel wrote:

>> "An origin server SHOULD reject any PUT request that contains a Content-Range header field (Section 4.2 of [Part5]), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full representation).
> This explanation basically rules out PUT completely for upload resume, as even if this would instead be done with an imaginary new header called Partial-update-of-remote-thing-please:, it could also become subject of getting handled as a full representation by mistake.

I agree. You can't guarantee that a new header is understood by the recipient (M-PUT died long, long ago), and this isn't a backwards-compatible change in the semantics of PUT.

Martin then said:

> I'd have thought that this is a perfect fit for PATCH.  Nothing new needed.

Agreed, except a new PATCH format that's range-friendly would be necessary. That's not a huge undertaking, because it could reuse at least some of the existing syntax.

I'd be willing to help work on this, or just provide input / reviews.


Mark Nottingham