Re: Resumable Uploads

Felix Geisendörfer <> Sat, 20 April 2013 08:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60D7221F9265 for <>; Sat, 20 Apr 2013 01:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.076
X-Spam-Status: No, score=-9.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BalxDxZY+IFp for <>; Sat, 20 Apr 2013 01:31:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A8DAD21F9298 for <>; Sat, 20 Apr 2013 01:31:40 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UTTCd-0006ZP-Ju for; Sat, 20 Apr 2013 08:31:23 +0000
Resent-Date: Sat, 20 Apr 2013 08:31:23 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UTTCZ-0006Ya-MO for; Sat, 20 Apr 2013 08:31:19 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UTTCZ-0003OT-0U for; Sat, 20 Apr 2013 08:31:19 +0000
Received: by with SMTP id hz11so4719888vcb.10 for <>; Sat, 20 Apr 2013 01:30:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:sender:x-originating-ip:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:x-gm-message-state; bh=iYCqUbeP9uuOViadHCx1KK59c1R06KQKXVfS9lLAedI=; b=VuUCh2a08fpM9UqrArxVT83LDYGcx1HjXhEaBJXMAOq2fsQlMUhq0oCFNawNte0MC7 w6M2YqQNtlqbUkS47ci+vYF/iNAx3e/zZu3SIM8U2VI2hFWtPAk0mlJr37r6wh4Q17Jg AJfw7k1XxFVJo2KBcbChZtyTMC/wnBSb7A7hQlg7E/6tGqk5LTQKv3CSTox407dzO1gD SyBv4v3xEL2SgQ6ol1m9nJhF0/1aA8nfXjuzgilCidzfdL0pYGYs5w9Sv0A9PTtfQJeY aNS30OcXaPodRhfoxPBisZKdgTiyj0+9wyLqSuQ3GmblInOk3/gHYsUpy03Q2XzmJVRY h64w==
X-Received: by with SMTP id il10mr14075192vcb.4.1366446653321; Sat, 20 Apr 2013 01:30:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 20 Apr 2013 01:30:33 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
From: Felix Geisendörfer <>
Date: Sat, 20 Apr 2013 10:30:33 +0200
X-Google-Sender-Auth: qxsHPbTS4c9Bo6kjd7Di8t09WmE
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="14dae9cdc487607b2b04dac6a7ad"
X-Gm-Message-State: ALoCoQk1E8aosPr9JltoqmG8HKDFDRquR83UW6N5F8iu+FuEr4qPgs9T3Gz5H/f/J9iVcmKnPV/x
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: AWL=-4.173, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7
X-W3C-Scan-Sig: 1UTTCZ-0003OT-0U 59c77b4015c9efb741679ca445c5a4a8
Subject: Re: Resumable Uploads
Archived-At: <>
X-Mailing-List: <> archive/latest/17410
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Sat, Apr 20, 2013 at 7:59 AM, Mark Nottingham <> wrote:

> 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.

IMO the simplest solution would be an "Offset" header that simply gives the
start offset where the data should be applied. The end offset is implicit
through the message length.

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

That's fantastic, thank you so much! I'm also very interested in helping in
whatever way possible.

On Fri, Apr 19, 2013 at 10:08 PM, Carsten Bormann <> wrote:

Your assumption seems to be that if an upload breaks, it breaks cleanly,
> i.e. all data that have been received by the server are fine up to the last
> byte.

Yes, but IMO we should assume that the underlaying transport layer is not
corrupting data under normal circumstances.

Applications that require stronger guarantess should split their uploads
into small chunk requests with individual checksums and instruct their
servers to not process anything that doesn't match the checksum. This
carries a higher overhead, but such is life : ).

Our goal for is to describe the simplest interoperable resumable
upload strategy over http that will work in most situations (the core). The
rest of the protocol will cover extensions (chunking, checksums, uploading
chunks in parallel, etc.) which clients / servers can choose to implement
as well. Ideally a nice ecosystem of compatible libraries will then
flourish on top.

Felix Geisendörfer (
Co-Founder, Transloadit (