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

Resumable Uploads

From: Felix Geisendörfer <felix@transloadit.com>
Date: Thu, 18 Apr 2013 13:37:51 +0000
Message-ID: <CADZbJ9dYFGyrceh03M3B0KdKto7160Dis_geh9um0BhVe1re0g@mail.gmail.com>
To: ietf-http-wg@w3.org
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.

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.

Anyway, here are the things I'm wondering about specifically:

- How should a http client transfer a partial byte range of a given
resource? Specifically:
- Should the PUT or PATCH method be used? (neither seem fully appropiate
according to my research)
- What header should be used to indicate the transfered range for the
upload? Julian Reschke pointed out that Content-Range may not be appropiate
[2].
- What header should be used to indicate the received range of an
interrupted upload?

Ideally clients should be able to transfer multiple parts of a file using
parallel requests (to fully utilize long fat pipes). This will require
servers to indicate which parts of a file have previously been received.
Another thing I'd like for servers, is to process partially received
requests, otherwise small chunk sizes would have to be used for mobile
which would lead to significant overhead.

Thanks in advance for any insights you might be able to provide!

[1]: http://www.tus.io/protocols/resumable-upload.html
[2]: https://twitter.com/jreschke/status/324872511697326080

--
Felix Geisendörfer (felixge.de)
Co-Founder, Transloadit (transloadit.com)
Received on Thursday, 18 April 2013 17:37:42 UTC

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