- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 22 Apr 2002 08:54:21 -0400
- To: WebDAV <w3c-dist-auth@w3.org>
I'd just do:
...
<D:response>
<D:href>/bla/...</D:href>
<D:status>HTTP/1.1 409 CONFLICT</D:status>
<D:responsedescription>
<D:error>
<D:locked-source>
<D:href>/other/...</D:href>
</D:locked-source>
</D:error>
</D:responsedescription>
</D:response>
This is assuming the MOVE failed because the source was locked.
If it failed because the destination was locked, then it would
just be:
...
<D:response>
<D:href>/bla/...</D:href>
<D:status>HTTP/1.1 423 LOCKED</D:status>
</D:response>
Cheers,
Geoff
-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Monday, April 22, 2002 4:06 AM
To: WebDAV
Subject: Re: need clarification about COPY to locked resource response
cod e
Am Montag den, 22. April 2002, um 02:40, schrieb Clemm, Geoff:
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>
[...]
> - MAY contain response elements for targets that caused the failure.
>
> That would be OK with me but I'd prefer to nest the information
> about targets that caused the failure in the response element for the
> source resource that wasn't moved/copied/deleted. This is a change
> from RFC 2518, but I think it is warranted.
>
> It might be woth thinking to also add some kind of linkage
> between the
> two
> response elements.
>
> I agree. That is the purpose for nesting the information about the
> targets that caused the failure in the response for the target that
> was not copied.
So, as usual I propose a format which will make everyone scream and
come up with a much better one.
...
<D:response>
<D:href>/bla/...</D:href>
<D:status>HTTP/1.1 409 CONFLICT</D:status>
<D:cause>
<D:href>/other/...</D:href>
<D:status>HTTP/1.1 423 LOCKED</D:status>
</D:cause>
</D:response>
//Stefan
Received on Monday, 22 April 2002 08:54:55 UTC