W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Resumable Uploads

From: Felix Geisendörfer <felix@transloadit.com>
Date: Sun, 21 Apr 2013 12:12:45 +0200
Message-ID: <CADZbJ9eEeBUYP_5dDXvqd-grY035-QSeyyGZrUR=2VviB6CGCw@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Apr 20, 2013 at 11:09 PM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> 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 <daniel@haxx.se> 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.

[1]: http://www.w3.org/TR/FileAPI/#file-attrs

--
Felix Geisendörfer (felixge.de)
Co-Founder, Transloadit (transloadit.com)
Received on Sunday, 21 April 2013 10:13:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC