Re: Resumable Uploads

Felix Geisendörfer <> Sun, 21 April 2013 10:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBA7421F8EBE for <>; Sun, 21 Apr 2013 03:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.376
X-Spam-Status: No, score=-9.376 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BhN9ZZIf4qQv for <>; Sun, 21 Apr 2013 03:15:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9A35021F8E4B for <>; Sun, 21 Apr 2013 03:15:24 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UTrH9-0003cP-2B for; Sun, 21 Apr 2013 10:13:39 +0000
Resent-Date: Sun, 21 Apr 2013 10:13:39 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UTrH3-0003bg-Ge for; Sun, 21 Apr 2013 10:13:33 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UTrH2-0004Gj-HU for; Sun, 21 Apr 2013 10:13:33 +0000
Received: by with SMTP id lf11so3014221vcb.6 for <>; Sun, 21 Apr 2013 03:13:06 -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=SbawEWmmFE61cTtxu1Kc7MtjLNuWM7Qj4io7wh6E4Vk=; b=gZ9XoEQqZW5RfmfdjCVC+w3T3k90dr98v2XT3yUlZRjz+E3kGoZyotNWkBpz2yKJ0B YkXve1g0QK9jeKsCdjvQON1x7UNnIlzPqSd2Bicv12oQGjN/ATzZUWDM41bSojQp0MgR Xab0tHtbiy4Lc5JHquZN97vUDF2H2XJnPreTlGBBYdWV66CTz/W4PRyO8VEvNBU/Pmd8 vUqr5tExUFlp+cnTU0o+Ufi8+uAEASGUiOKYNz9tYCoIlvc+m1lY4g1Af6n24Mn4z39O DZ9Fx0JIpVn06zuf+mTGgIX1YFOuWRCxm8Jtmq8DMeDWDNDWD7r1/OvuT0kXfNXspFFB 2T1g==
X-Received: by with SMTP id ft18mr5842496vdb.108.1366539186707; Sun, 21 Apr 2013 03:13:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 21 Apr 2013 03:12:45 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Felix Geisendörfer <>
Date: Sun, 21 Apr 2013 12:12:45 +0200
X-Google-Sender-Auth: -46QglEqDQDbXAa3o43WJACh_aE
Message-ID: <>
To: Amos Jeffries <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="047d7bacb7e4cbe1bb04dadc320c"
X-Gm-Message-State: ALoCoQmZsE5RkmjN4lS73dR4ICMObhb52gWW0iwgJsf6397sNODK5PfJ6e8ljehA8HWB3ILxqNSR
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.3
X-W3C-Hub-Spam-Report: AWL=-2.687, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7
X-W3C-Scan-Sig: 1UTrH2-0004Gj-HU c12a7beec89ffcecd8017cad1a02dcbc
Subject: Re: Resumable Uploads
Archived-At: <>
X-Mailing-List: <> archive/latest/17446
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Sat, Apr 20, 2013 at 11:09 PM, Ilari Liusvaara <> wrote:

> This is because JS code can't read huge chunks of file at once[1].

AFAIK that's not true. File API 8.1 says: "The File interface, which
inherits from Blob, is immutable, and thus represents file data that can be
read into memory at the time a read operation is initiated." [1]. In my
testing this optimization is found in all browser implementations.

On Sat, Apr 20, 2013 at 11:20 PM, Daniel Stenberg <> wrote:
> I agree with Fredrik's statement that a simple PUT + offset header would
> be easiest for a client (and possibly server too), but I just previously
> quoted the reasoning in the spec as to why it currently doesn't think that
> is a good idea. It would be more productive if we would instead counter
> that argument or present an alternative way.

My proposal is to use PATCH + Offset header. PUT could still be used for
creating the resource initially and setting expectations for final size,
checksum, etc.

Overall I think there are a few separate things that are currently lacking
http primitives. In order of priority:

1. Defining a simple way to insert data at a given offset of a resource.
(PATCH + Offset header seems nice/simple)
2. Defining a fixed file size for a resource when creating it (suggestion:
"Final-Length" header), regardless of how much data will be transmitted
with the creation request.
3. Defining a way for a server to provide the state of a partial resource
via HEAD requests. (could also be a "Offset" header)

(I've left out checksums, EOF/Upload-Complete and a few other things on
this list, just to keep it simple for now.)

These primitives could then be combined into various client/server patterns
depending on application requirements.

I don't think the http spec should define the server behavior of GET
requests on partially uploaded resources, as there are many patterns that
would make sense for different applications.


Felix Geisendörfer (
Co-Founder, Transloadit (