Re: [Bug 12] Destination header "consistent"

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