Re: WebDAV MOVE

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

Julian wrote on 11/24/2003 02:31:33 PM:
> Helge Hess wrote:
> 
> > 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?
> 
> 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?).