W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2003


From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 25 Nov 2003 09:02:20 -0500
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <OF69D8148A.583D3988-ON85256DE9.004C52A1-85256DE9.004D1A45@us.ibm.com>
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.


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 
> > 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?).
Received on Tuesday, 25 November 2003 09:04:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC