Re: Resumable Uploads

[Amos Jeffries <[e-mail]>]

On 21/04/2013 2:08 p.m., Mark Nottingham wrote:
> On 21/04/2013, at 5:43 AM, Yoav Nir <[e-mail]> wrote:
>
>> On Apr 20, 2013, at 11:30 AM, Felix Geisendörfer <[e-mail]> wrote:
>>
>>> 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.
>> How does the server know when the whole thing has been uploaded?  Wouldn't we need some kind of "total-length" header, perhaps in the initial PUT?
>>
>> Or are we assuming that the initial PUT is trying to upload everything, and only failure leads to sending the PATCH?
> One possibility would be to have a flag in the request (header or body) that indicates that after this PATCH, it's complete. E.g.,
>
>
> PUT /foo HTTP/1.1  # create the new resource
>
> PATCH /foo HTTP/1.1  # start uploading it...
> PATCH /foo HTTP/1.1  # continue...
> ...
>
> PATCH /foo HTTP/1.1
> Upload-Complete: 1  # we're done!
>
> You'd need conditionals (probably, if-match) on each PATCH to make sure it hasn't changed since the last PATCH (or PUT).
>
> The PUT give the server an opportunity to refuse the request, and its response can advertise the details of how to PATCH it.
>
> The only difficult part I can see is figuring out what to return to a GET that occurs before the upload is complete. And maybe how long to keep these partially-uploaded resources around (although that's really a server implementation detail).

Not too difficult. The processing model for these type of systems falls 
into two categories of locked or lockless. The GEt on locked must be 
responded with some form of error-because-locked response, and GET on 
lockless must always return the current representation with recipient 
system able to cope with corrupted/incomplete representations on its own 
outside of the delivery protocol.

Amos