- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 21 Apr 2013 12:08:39 +1000
- To: Yoav Nir <ynir@checkpoint.com>
- Cc: Felix Geisendörfer <felix@transloadit.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 21/04/2013, at 5:43 AM, Yoav Nir <ynir@checkpoint.com> wrote: > > On Apr 20, 2013, at 11:30 AM, Felix Geisendörfer <felix@transloadit.com> wrote: > >> On Sat, Apr 20, 2013 at 7:59 AM, Mark Nottingham <mnot@mnot.net> 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). It'd be nice if the PATCH format could modify headers cleanly too. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Sunday, 21 April 2013 02:09:06 UTC