Re: [Bug 12] Destination header "consistent"

Lisa Dusseault wrote:
> Sept 15, 2002, mail from me entitled "*Issues from Interop/Interim WG 
> Meeting".*
> 
> 
> "- Clients get confused if host names change; Clients expect
> full/relative URLs? Dealt with in text on multistatus response"
> 
> The Location header was what the server was using to indicate the host 
> name redirection in this case, which I didn't mention in this brief 
> summary unfortunately.
> 
> The full details of the Interop -- e.g which client this was, and which 
> server -- were never published, a decision we made in order to get 
> broader participation in the Interop.

Lisa,

it would be really helpful if you could just add the URL to the archive 
message, to save people the trouble to look it up.

That being said, I indeed found a better summary in "Notes for Sept 9 WG 
meeting (by Dennis Hamilton)" 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0276.html>): 
which says:

> 5.2.1.4 PropFind Responses for Collections
> 
> 
> Are relative URLs allowed in propfind responses?
> 
> Jim W: So is this a spec language issue or is something needed in the
> protocol?
> 
> Brotsky: Servers must not be confusing to clients and we need to see how
> to do that.  We probably ought to do relatives more, it needs to be
> relative to the URI in the request: relative, absolute, or fully
> qualified (anything not fully qualified is considered a relative URI in
> the specification) -- we have to be really careful about the
> specification language
> 
> Difficulties are with the client handling the different cases of what
> comes back.  
> 
> Brotsky says that servers must use proper internal URIs, and it is
> strictly defined, in terms of internal member URI.  The question is can
> the top level URI be different than the one the client offered.
> 
> Lots of discussion on prefixes of URIs, how to get around this.  And
> whether servers are allowed to optimize the client's future behavior.
> Brotsky wants the server to be gentle with the client.  In the case at
> hand, the client is asking "tell me what the internal members of this
> collection are."  If the server can return whatever it wants, the client
> is under a terrible burden.
> 
> Lisa has some language for a MUST to add to the specification based on
> presence of a content location header.
> 
> In the absence of a content location header, there is discussion about
> not having the same level of MUST-ness for the request URL.
> 
> Conversation about what a client is, and Brotsky says that HTTP says.
> Needs more discussion, and RFC 2518 may need to be more emphatic that it
> is relying on the HTTP 1.1 definition of client and have people be clear
> about the implications.

So from what I can see here, the issue was about a server that was using 
URLs in PROPFIND responses that weren't descendants of the Request-URI. 
This is a server bug, and if RFC2518 needs to be clearer about this, I'm 
+1 on doing that.

Anyway: I'm not aware of any current server with that bug (it would 
affect our client in the same way), so I'd really like to know whether 
this is just an academic discussion, or whether the problematic server 
is still doing that.

Finally, the meeting notes say that what was dicussed was 
"Content-Location", not "Location". That's of course something 
completely different, and it's already mentioned in RFC2518 
<(http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.5.2.p.6>):

"There is a standing convention that when a collection is referred to by 
its name without a trailing slash, the trailing slash is automatically 
appended. Due to this, a resource may accept a URI without a trailing 
"/" to point to a collection. In this case it SHOULD return a 
content-location header in the response pointing to the URI ending with 
the "/". For example, if a client invokes a method on 
http://foo.bar/blah (no trailing slash), the resource 
http://foo.bar/blah/ (trailing slash) may respond as if the operation 
were invoked on it, and should return a content-location header with 
http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form 
of collection names."


Best regards, Julian

Received on Tuesday, 1 November 2005 09:33:30 UTC