WebDAV vs HTTP method semantics

Justin Chapweske justin@chapweske.com
Sat, 25 Aug 2001 19:09:17 -0500


Your line of logic is pleasent to follow Mark, but the pragmatist in me 
just isn't convinced:

o Without a LOCK, atomic MOVE, or atomic TAKE, I see no primitives on 
which to build efficient coordination/locking protocols between user 
agents.  Personally I'd prefer to get rid of LOCK and use TAKE instead.

o Your multi-round trip GET+PUT+DELETE just doesn't make sense unless 
method chaining is added to HTTP.

What if an atomic method chaining facility was added to HTTP?  Then you 
could implement TAKE as chain(GET+DELETE) and MOVE as 
chain(GET+PUT+DELETE).  The semantics of the
chain could either be that only the last response of the chain was 
returned, or all of the responses of the chain were returned.

There would of course be a zillion subtleties to work out, but method 
chaining might be a powerful primitive.


Mark Baker wrote:

>I've been thinking more about some of WebDAV's methods, specifically
>LOCK, COPY, and MOVE.
>
>LarryM pointed out this FoRK post[1] on xml-dist-app[2].  Having made the
>"Linda/HTTP mental leap" after that post was made, I wasn't in a position
>to respond.  I feel I am now.  In it, Jim gives a number of alternatives
>that were considered about how to extend HTTP.  Curiously, the only
>mention of using POST or PUT is in point #2 where he talks about
>using RPC and tunneling over POST.  I agree that that approach would have
>been a mistake, but it's not the only possibility for a use of POST.
>There's also an extensibility mechanism not mentioned in that post that
>would have been useful, I believe.
>
>My hypothesis is that, at least in theory, all operations with side
>effects on resources can be represented with only PUT or POST.  Here's
>an attempt to recast LOCK, COPY, and MOVE in that way.
>
>LOCK's side effect is to change the state of the resource identified by
>the Request-URI to one of locked (per WebDAV lock semantics).  It does
>this relative to the current state of the resource, not to the exclusion
>of it (duh), so this should use POST not PUT.  But how do we use POST?
>We POST a lock entity, describing the type of lock.
>
>e.g.
>
><?xml version="1.0">
><lock xmlns="http://www.ietf.org/rfc/rfc2518.txt" />
>
>The use of an XML namespace being the extensibility mechanism I mentioned
>above.  Content-Type on the POST wouldn't have been appropriate because it
>is an attribute of the representation, not the resource itself.  The
>namespace describes the resource.
>
>COPY is a means of taking the state of one resource, and creating a new
>resource with that state.  This can be done with PUT.  2616, 9.6 describes
>exactly this scenario;
>
>   The PUT method requests that the enclosed entity be stored under the
>   supplied Request-URI. If the Request-URI refers to an already
>   existing resource, the enclosed entity SHOULD be considered as a
>   modified version of the one residing on the origin server. If the
>   Request-URI does not point to an existing resource, and that URI is
>   capable of being defined as a new resource by the requesting user
>   agent, the origin server can create the resource with that URI. If a
>   new resource is created, the origin server MUST inform the user agent
>   via the 201 (Created) response.
>
>So COPY would be GET+PUT.  The downside there being the extra hop, but
>I think that is more than compensated for the by simplicity.  Plus,
>as I'm thinking about it now, making an atomic operation like COPY or
>MOVE between two distributed resources seems like it's breaking REST's
>concept of moving state to the user agent, plus it seems to be making
>distribution a lot more transparent than HTTP has.  Hmm..
>
>I believe MOVE would simply be COPY+DELETE, aka GET+PUT+DELETE.
>
>What say ye Jim?
>
> [1] http://www.xent.com/FoRK-archive/feb98/0238.html
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0209.html
>
>(I've gotta put this in the Wiki)
>
>MB
>
>
>http://xent.com/mailman/listinfo/fork
>
--
Justin Chapweske, Lead Swarmcast Developer, OpenCola Inc.
http://www.swarmcast.com/