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

Re: [Bug 12] Destination header "consistent"

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 31 Oct 2005 13:29:00 -0800
Message-Id: <8d2dc10867f989a1244c5ee4fe5672cd@osafoundation.org>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDav <w3c-dist-auth@w3.org>, Cullen Jennings <fluffy@cisco.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Oct 31, 2005, at 1:16 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> The original question that brought up this issue was how to interpret 
>> the URLs inside the body of the Multi-Status if there was a Location
> Is there any record on the mailing list of this issue? Has anybody 
> ever *seen* a 207 with a Location header? That is, why was this 
> question asked in the first place?
Yes.  At an Interop event.

>> consistent with the Location header or the Request-URI
> What does "consistent" mean here? Note that this is the original 
> reason why I raised this issue.

What I meant by "consistent" (and maybe somebody can find a better way 
to word this or we can just define it) was:  In a PROPFIND or PROPPATCH 
response, for the URLs in the body to be consistent with the 
Request-URI, all URLs would all begin with the exact URL used in the 
Request-URI.   I believe the same would be true for MOVE and COPY 
responses -- the URLs would be consistent with the Request URI, not 
with the Destination request header or the Location reply header.

>> There was an actual interoperability problem that uncovered this. 
>> Some server returned a Location header and a bunch of URLs in the 
>> body, that used the new location. The client errored because the 
>> client never expected to query a Collection for its children and find 
>> a bunch of URLs that didn't begin with the URL used in the request 
>> URI.
> As far as I can tell, that's a server bug. Clients aren't expected to 
> handle PROPFIND responses with URLs that identify resources are then 
> the one identified by the Request-URI (and its descendants). If a 
> server wants to redirect clients, it will have to use a 3xx status 
> code (as defined in RFC2616).
It may be a server bug under some models or readings of RFC2518.  The 
server implementor certainly would have a case for interpreting RFC2518 
as allowing their "solution".  This past week, Geoff seemed to be 
arguing for allowing Location with 207 and not only with 3xx.

Received on Monday, 31 October 2005 21:29:20 UTC

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