Re: [Bug 12] Destination header "consistent"

Lisa Dusseault wrote:
> 
> 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.

Is there any record on the mailing list of this issue?

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

I still don't see what problem this solves. The URIs appearing in 
multistatus responses should be either absolute, or relative to the 
Request-URI. If, for instance, in a PROPFIND response, a response 
element comes with a URI that after resolving is not descendant of the 
Request-URI, then the server made a mistake. We can of course discuss 
how a client should handle this. Skipping it is one answer, failing the 
whole request is another. In practice it's unlikely to make a difference 
because if a server get's one response element wrong, it's likely to get 
*all of them* wrong.

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

HTTP defines a range of response codes (3xx) for redirects, and defines 
how the Location header can be used to specify new URIs for subsequent 
requests. I think this feature is completely well-defined, and I'm not 
aware of any problems with that.

If a server implementor chooses to use non-3xx response code for a 
redirect, than that's simply outside what HTTP currently defines; and it 
escapes me why somebody would want to invent something new for a feature 
that already exists.

And finally, Geoff wasn't recommending to use 207 with Location, he just 
made a guess about what a client could conceivably do once it get's a 
response like that.

If this was an interop problem at one point of time, I'd like to see the 
details published, or -- if this isn't possible -- hear from client 
implementors who suffered from that problem. Maybe the servers have been 
fixed since then, and the whole issue has gone away.

Best regards, Julian

Received on Monday, 31 October 2005 22:06:14 UTC