- 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