Re: Resumable Uploads

Kevin Swiber <> Thu, 18 April 2013 21:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDEA121F8C98 for <>; Thu, 18 Apr 2013 14:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BxcKzhGX8fJf for <>; Thu, 18 Apr 2013 14:58:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D567921F8B16 for <>; Thu, 18 Apr 2013 14:58:40 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1USwpn-0007f4-Up for; Thu, 18 Apr 2013 21:57:39 +0000
Resent-Date: Thu, 18 Apr 2013 21:57:39 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1USwpk-0007eO-Lx for; Thu, 18 Apr 2013 21:57:36 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1USwpj-0006pw-SA; Thu, 18 Apr 2013 21:57:36 +0000
Received: by with SMTP id ar20so4008480iec.14 for <multiple recipients>; Thu, 18 Apr 2013 14:57:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=NKF3tQJyNwvDfP0Mkz2wZCeT9Z9tcgBsxJs/JNM2J5c=; b=ikWVVbe+uP44fFrc7cftz9w2IPdQdEbczOR0CLKLecAX1I3zyshjq+7fPeV5ttL2iL ezcn9tzyloFRoGMy5oJg70UCEd8m9hHIQzT99853kzcnRBh3+pgGOIlbEQKqcUvL2BxN 5IaP7NNxh2pGxc7+CleaK1KpsDilEqwN0Ekg8ImcqvIbNVHNUJb8qf5yjwIDFahOHqIv hXBYufdFaz6CciJvb9FACbvWqRtNz/bOBOkoxgoUJ5xvm2jJ6HS8YNZLJkoWtrZOJYYk ChUMTFLz85YU375cuHXnraOIFqBLSwFNLbP+QYKNE6W0MIkgPX0nArTiYAsKvJQUqqPs vklA==
X-Received: by with SMTP id pp8mr13963790igc.57.1366322229748; Thu, 18 Apr 2013 14:57:09 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id ip2sm27333239igc.5.2013. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 14:57:07 -0700 (PDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Kevin Swiber <>
In-Reply-To: <>
Date: Thu, 18 Apr 2013 17:57:04 -0400
Cc: Felix Geisendörfer <>, HTTP Working Group <>, Yves Lafon <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Daniel Stenberg <>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Scan-Sig: 1USwpj-0006pw-SA 5d0ff46dab1a601535139002a62c3a13
Subject: Re: Resumable Uploads
Archived-At: <>
X-Mailing-List: <> archive/latest/17347
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Apr 18, 2013, at 5:18 PM, Daniel Stenberg <> wrote:

> On Thu, 18 Apr 2013, Felix Geisendörfer wrote:
>> The first draft for this can be seen here [1]. I'm new to protocol authorship, so please forgive any ignorance you may see in my work. This is no attempt at competing with existing standards, I merely want to identify the relevant subsets of http and make them easy for people to implement.
> My initial view on this:
> "Resume" would be better replaced with "sending a part of a remote resource to get applied on the remote side", and in your most common case that part of data would modify the end of the remote resource (by adding data to it).
> Said like that, isn't that what PATCH is?

IIRC, PATCH makes no special consideration for byte ranges.  RFC 5789 defines the request body as a "patch document."  Before minting a new media type to support byte-range patch documents, it looks like the authors and interested members of the community are trying to fit this into existing HTTP functionality via byte-range headers and range-related status codes.  

A couple of questions:

1. In the case of a resource being in a known-partial state, what response should be sent when a GET request is received and the request has no Range header?
3. What potential HTTP-compatibility issues do you foresee with such a solution?

While an "application/octet-patch" media type or something like that might be a necessity, I think there's value in fleshing out the other HTTP bits at this time.


Kevin Swiber