Resumption of upload

On PATCH for resumption of upload:

On Apr 5, 2008, at 5:33 AM, Bill de hOra wrote:
>
> Then the client can send the rest of the data offset from 'nnn'. But  
> to make the semantics clear I use PATCH (or overloaded POST with X- 
> HTTP-Method-Override). Definitely not PUT.
>
>   PATCH /my/favorites/image5 HTTP/1.1
>   Host: example.com
>   If-None-Match: "e180ee84f0671b1"
>
>   ...nnn+...
>

I've thought about that too; one of the use cases driving the  
submission of version 00 of draft-dusseault-http-patch was talking to  
Adobe engineers doing WebDAV, who wanted better ways for collaborating  
designers to make changes to large documents e.g. Photoshop  
documents.  Some document formats can have changes applied piecemeal,  
which can even be useful when a certain amount of document  
construction or history is retained within the document itself.  So e.g:

	LOCK ourdocument
	PATCH ourdocument
		Add a new layer and upload an image into that layer
	PATCH ourdocument
		Upload an image into an existing layer
	PATCH ourdocument
		specify an algorithm to combine two layers
	UNLOCK ourdocument

(I'm making the internal change details up, please don't quibble with  
the details :)

One of the things that worries me, in the case of PATCH used for  
partial upload of a pre-existing resource, is when there are document  
formats where it's not possible to keep the document valid and also  
break it into upload chunks.  A document should remain valid.  I guess  
I can see a couple solutions to that but I'm not sure what's best.

	1. Change the content-type to application/octet-stream during one  
PATCH, and change it back to the real valid content type at the last  
PATCH -- this requires servers to handle Content-Type as a  
modification on PATCH requests

	2.  Applications are encouraged to create tmp files through PUT and  
multiple PATCHes, then COPY that over top of the previous destination  
file.  This has the drawback of requiring WebDAV, although so does the  
LOCK example above

Lisa

Received on Wednesday, 9 April 2008 16:18:22 UTC