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

Re: [Bug 12] Destination header "consistent"

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 31 Oct 2005 22:16:25 +0100
Message-ID: <436689A9.4060304@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Cullen Jennings <fluffy@cisco.com>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDav <w3c-dist-auth@w3.org>

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?

> header. It was unclear to some client implementors
> - should the URLs in the body be relative to the Location header
> - should they be relative to the Request-URI
> - should they be absolute URLs, always, and if so, should they be 

They should be either absolute, or need to be resolved relative to the 
Reuqest-URI. If this is not clear from RFC2518, let's fix that.

> 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.

> 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).

Best regards, Julian
Received on Monday, 31 October 2005 21:17:04 UTC

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