Subject: COPY of a binding onto another binding of same resource

From: Lisa Dusseault <[email-masked]>
Date: Wed, 24 Mar 2004 09:11:45 -0800

When a user does a COPY or MOVE from one binding to another binding to 
the same resource, this should be flagged as an error.  Since this has 
to interoperate with existing clients that won't look at the error 
body, the status code would have to stand alone.  409 is already used 
for non-existent parent collections, so that can't be reused.  Possibly 
403 which in 2518 for COPY means "_ The source and destination URIs are 
the same."

Lisa

---

From: Ted Hardie <[email-masked]>
Date: Wed, 24 Mar 2004 09:34:42 -0800

At 9:11 AM -0800 03/24/2004, Lisa Dusseault wrote:
>When a user does a COPY or MOVE from one binding to another binding 
>to the same resource, this should be flagged as an error.  Since 
>this has to interoperate with existing clients that won't look at 
>the error body, the status code would have to stand alone.  409 is 
>already used for non-existent parent collections, so that can't be 
>reused.  Possibly 403 which in 2518 for COPY means "_ The source and 
>destination URIs are the same."

Unfortunately, I think it is pretty clear that the source and 
destination URIs are not
the same; the resource to which they are bound is the same.  Some other error
condition (4xx "Source and target bound to the same resource"?) seems more
appropriate to me.
			regards,
				Ted

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Mar 2004 18:38:16 +0100

Lisa Dusseault wrote:
> to interoperate with existing clients that won't look at the error body, 
> the status code would have to stand alone.  409 is already used for 
> non-existent parent collections, so that can't be reused.  Possibly 403 
> which in 2518 for COPY means "_ The source and destination URIs are the 
> same."

Why would that be an error?

If I have two bindings b1 and b2 to the same resource B, MOVE b1 -> b2 
will either fail (for Overwrite: F) or will first remove binding b2, 
then execute the rename. The result will be that there'll be one 
remaining binding (b2).

For the same situation, COPY seems to be no-op. Dead properties and 
content will be "replaced" by their current values (with possible side 
effects on ETag and so on...).

What am I missing?

Regards, Julian

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Mar 2004 19:23:30 +0100

> which in 2518 for COPY means "_ The source and destination URIs are the 

...btw, I disagree with the sentiment that specific new error conditions 
must use HTTP status codes different from any status code used 
previously for that operation (in fact, the whole point is that by 
sending the same status code like for another situation I can trigger 
the same error recovery/treatment on the client).

In particular, note that 409 can occur for many other reasons, and a 
client that somehow equates 409 with "parent collection does not exist" 
is plain broken (this is why it would be a good thing ifg RFC2518bis 
associated that with a specific precondition name).

The advantage of RFC3253's HTTP status code / DAV:error body extension 
is that existing clients will continue to see well-defined HTTP status 
codes (usually defined by RFC2616, not RFC2518), while new, 
WebDAV-specific clients can take advantage of additional information 
sent with the body (for instance, in ACL this enables the client to 
state which privilege was missing causing the 403 Access Denied).

Julian