Subject: WebDAV MOVE

From: Helge Hess <[email-masked]>
Date: Mon, 24 Nov 2003 20:11:01 +0100

Hi,

the specification is a bit unclear on what we are supposed to return in 
the case that a MOVE cannot be completed because request URL and 
destination URL are on different servers or are on different 
subnamespaces on a single server.
I would expect some return value that signals to the client that the 
URLs are on different "drives". The client could then try to implement 
the MOVE logic on the client side (eg using PUT to dest then DELETE in 
src).
Any suggestions?

Thanks,
   Helge
-- 
OpenGroupware.org	http://www.opengroupware.org/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Nov 2003 20:31:33 +0100

> the MOVE logic on the client side (eg using PUT to dest then DELETE in 

Right now, RFC2518 allows both -- rejecting the request, or doing a 
"best effort" approach on the server.

The BIND draft (<http://wwww.webdav.org/bind>) clarifies that a client 
that really wants to move resources (keeping all live properties and 
resource-ids) can do a REBIND method call that is guaranteed to fail if 
a "real" move operation is impossible.

If a server wants to reject MOVE, that's certainly possible although 
existing clients may not be handling this very well. A 403 (Forbidden) 
seems to be the right status code in this case. It would be nice if 
there'd also be a precondition code for this case (Geoff, could we add 
that to BIND as additional MOVE semantics?).

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 25 Nov 2003 09:02:20 -0500

I'm not sure what the benefit would be of this additional error
code for MOVE.  If the client wants to try COPY/DELETE as an
alternative to MOVE, then it should do so.  I don't see that 
the clients decision to do so would be affected by a special
error code here.

Cheers,
Geoff

---

From: Helge Hess <[email-masked]>
Date: Tue, 25 Nov 2003 15:51:17 +0100

> the clients decision to do so would be affected by a special

[maybe we got the method wrong, of course COPY suffers the same issue! 
the alternative to MOVE is GET/PUT/DELETE, not COPY/DELETE]

Well, MOVE is usually a cheap operation on the server and on the 
network while PUT is expensive on the network. So I would assume 
(without having thought through everything, I have to admit), that a 
code which signals the client why it couldn't perform the operation 
would be quite useful (something like out-of-the-namespace-I-process).
With the Forbidden code we do not know whether the request was rejected 
because of access restrictions or just because it is located on a 
different server, right?

Note that I'm assuming that a server is usually "dumb" and will not try 
to act as a proxy with regards to the other namespace (if it does we do 
have the 502 code to detect errors, if I remember right).

Doesn't make sense?

regards,
   Helge
-- 
I'm describing in a paragraph what took 14 hours to figure out. You may 
want to sniff glue for a while, then reread this when you get out of 
rehab. [aLa]

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 25 Nov 2003 10:32:03 -0500

There are 3 obvious alternatives to move one set of resources
to another location:
- MOVE (cheap, least likely to work)
- COPY/DELETE (more expensive, more likely to work)
- PUT*/DELETE (most expensive, most likely to work)

So a client that cares about efficiency will try these three
methods in the above order, until one succeeds.  So what use
would it be for a server to say "out of the namespace I process"?
The client will try the next method in either case.

So is there anything that a server can do to expedite this
sequence?  The only thing I can think of is to have the
server have a special error code for MOVE that says "don't try to fake
MOVE with COPY or PUT*, because I know those will also fail"
and a special code for COPY that says "don't try to fake copy
with PUT*, because I know that will also fail".

But I think the likelihood that the MOVE or COPY implementation
will know this is small, and the benefit of skipping those
attempts is also small, so the overall benefit is very small.

Cheers,
Geoff

---

From: Helge Hess <[email-masked]>
Date: Tue, 25 Nov 2003 16:47:49 +0100

> would it be for a server to say "out of the namespace I process"?

So that the client knows that he should continue with COPY. If the 
client has no read access to the resource to be moved (access is 403 
Forbidden!), it doesn't make sense to continue?!
On the other side you are right, the client will find out about that in 
the last option, GET - if this returns Forbidden, we know that it is 
really an access issue.

> The client will try the next method in either case.

Well, if the server says that access to the resource is forbidden, I as 
the client, would not try the next method.

> with PUT*, because I know that will also fail".

Well, this is 403 (Access) Forbidden ;-) Using that access status code 
to signal some technically completely different issue (the resource 
cannot be moved on the server side due to operational restrictions) 
seems a bit weird to me.
But if I'm supposed to do it that way, I do.

BTW: another status which might be somewhat appropriate from the 
semantics is 501, Not Implemented. But this probably implies in the 
client that the whole method is not implemented which isn't what we 
want either.

> attempts is also small, so the overall benefit is very small.

Well, I think that this is the common case. MOVE will usually map the 
URI to some internal storage URL, eg

   /publicstorage/image.gif         to mod_dav /image.gif
   /dynamicservice/GroupwareFolder/ to servlet /GroupwareFolder

and this mapping process will know whether source and target are going 
to be processed by the same service.

Anyway, no intention to start a huge discussion on that. If there is no 
other way, I simply return 403 - I just wanted to make sure that I'm 
not missing something in the WebDAV spec.

regards,
   Helge

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 25 Nov 2003 10:03:45 -0800

> have the 502 code to detect errors, if I remember right).

I thought the 502 Bad Gateway error was appropriate whenever it's
another server, another namespace, or another domain that can't
be copied to.  It's a fuzzy continuum, after all:

 - One physical machine may be able to copy to another physical
machine if they're in the same security domain and the software 
supports it.  Thus, docs1.example.com and docs2.example.com might 
allow MOVE between them.  If not, however, 502 Bad Gateway is 
appropriate.

 - Two domains might be hosted on the same physical machine.  Thus
if docs.bettysbagels.com and docs.joesjava.com are both hosted by 
the same service provider using the same server software, using 
virtual servers, a MOVE between them might be allowed.  If it's 
not allowed, however, 502 Bad Gateway is appropriate. 

 - Within one domain, two top-level directories might actually 
be mounted from different locations (different file storage servers?), 
and *not* allow move between. E.g. docs.example.com/nfs-mount1 
and docs.example.com/cifs-mount8 might not support MOVE between 
them.  I think this sufficiently meets the definition of "gateway" 
to make 502 Bad Gateway is still appropriate.

Lisa