HTTP APPEND [Was: Re: [ANN] bzr.webdav: a writable hhtp transport]

[John Arbash Meinel]

Goffredo Baroncelli wrote:
> On Tuesday 22 August 2006 17:48, Vincent LADEUIL wrote:
> Hello Vincent,
> 
> [...]
>>     jam> Does WebDAV not have any sort of Append command?
>>
>> Don't hold your  breath. I don't have the  reference handy, but a
>> draft  exists   (dated  07/2006),  proposing   APPEND  and  PATCH
>> additions to DAV.
> 
> On the basis of my search, in order to write a part of a file we have to use 
> the PUT method + the "Content-Range:" header directive. A typical request 
> should be:
> 
> PUT /path/to/file HTTP/1.1
> Host: www.somehost.net
> Content-Range: bytes 5-14/15
> Content-Length: 10
> [...]
> 
> The example above highlight how append 10 bytes of data to a file with a 
> (initial) length of 5 bytes.
> 
> The enclosed patch implement an example of the append method. The patch was 
> tested on a apache webdav implementation. I don't know if it work with other 
> web servers ( IIS ?? ). If you want understand better the protocol you can 
> watch on what curl does ( see the -C curl option ).
> 
> Open point:
> 1) the append phase is performed in two steps:
>    a) get the length of the destination (via the HEAD method )
>    b) append the content at the end of the file ( via PUT + Content-Range: )
>   We have to prevent that another client update the file between "a" and "b"
> 2) test with other web server
> 3) it is not very clear the meaning of the third parameter of the 
> Contenet-Range option ( the one after the '/' ): is it the length of the old 
> or the new file ?
> 
> Comment are welcome
> Goffredo
> 
> 
> Reference:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 (see the part 
> related to "Content-Range" )
> http://www.hpl.hp.com/personal/ange/archives/archives-97/http-wg-archive/0079.html
> http://www.hpl.hp.com/personal/ange/archives/archives-97/http-wg-archive/2530.html
> 

Interstingly enough Vincent has also come across this information. And
was working on something similar.

As far as the 'prevent someone else from appending content', we do hold
a lock. However, it is possible for someone to break a lock underneath
us. And if someone breaks the lock underneath us, and then races with us
to update files, it would be possible for us to have data loss, and
actual corruption. Because after we write, we would expect that the data
 exists, so we would write the inventory referencing the texts, but not
all of the indexes may exist for those texts (because some were
overwritten).

Now, if the portion after the '/' had the meaning: If this is incorrect,
then puke, and reject the append, we could at least now right away that
something changed, and we could stop. Unfortunately HTTP doesn't seem to
have a track record of ensuring integrity. More of trying to be helpful
and doing what it can, even if it is incorrect/incomplete.

(Well, at least HTML is that way, I won't say *too* much about HTTP).


At least the spec says that if the server *doesn't* support PUT with a
Content-Range, then it must abort and alert the client.

But thanks for the patch. We'll see how it compares with what Vincent
had done.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060829/2071ea56/attachment.pgp