RE: need clarification about COPY to locked resource response cod e

Thanks Geoff.

Makes sense.

However, if we replace COPY by MOVE, we indeed get that ambiguity (and this
is actually mentioned in the spec). So I'd say that clients always should be
able to process  multistatus response body.

Julian

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of gclemm@rational.com
> Sent: Friday, January 25, 2002 2:18 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: need clarification about COPY to locked resource response
> cod e
>
>
> I believe a client should accept either behavior.  Section 8.8.5
> explicitly
> states that a 423 indicates that the destination resource was locked,
> so there is no ambiguity about whether the 423 refers to the source
> or the destination.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Friday, January 25, 2002 7:37 AM
> To: WebDAV
> Subject: need clarification about COPY to locked resource response code
>
>
> Hi,
>
> when running the Litmus test suite against our server, we came across the
> following problem for lock test 8 (COPY):
>
> In this test case, a non-locked resource is copied to a locked resource
> without giving the lock token in the If: header.
>
> Litmus expects the server to return 423 LOCKED (and this is what moddav
> does).
>
> Both our server and IIS however return a 207 MULTISTATUS, and have a
> response element for the *destination URI* with an 423 LOCKED status.
>
> I think the latter is correct, because the problem isn't with the request
> URI.
>
> In the section about COPY behaviour for *collections*, RFC2518 says [1]:
>
> "If an error in executing the COPY method occurs with a resource
> other than
> the resource identified in the Request-URI then the response MUST be a 207
> (Multi-Status)."
>
> I think this should apply to copying non-collections as well.
>
> Julian
>
>
>
>
> [1] <http://www.greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.8.3>
>

Received on Friday, 25 January 2002 10:15:42 UTC