Re: Resumable Uploads

[Felix Geisendörfer <[e-mail]>]

On Sat, Apr 20, 2013 at 7:59 AM, Mark Nottingham <[e-mail]> 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 <[e-mail]> 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 tus.io 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.

Cheers,
--
Felix Geisendörfer (felixge.de)
Co-Founder, Transloadit (transloadit.com)