Subject: Re: [Bug 12] Destination header "consistent"

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Nov 2005 10:33:00 +0100

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 1 Nov 2005 07:13:50 -0500

> +1 on doing that.

I agree.  If we do need to be clearer on this, we could add a sentence to
the following paragraph from section 8.1 (PROPFIND) of 2518:

"Consequently, the multistatus XML element for a collection resource with 
member URIs MUST
 include a response XML element for each member URI of the collection, to 
whatever depth was
 requested. Each response XML element MUST contain an href XML element 
that gives the URI of the
 resource on which the properties in the prop XML element are defined. 
Results for a PROPFIND on a
 collection resource with internal member URIs are returned as a flat list 
whose order of entries is not
 significant."

I'd be happy to add a sentence to the effect that:

"Note that the URI in the response XML element must consist of 
 the request-URI of the collection resource extended by a sequence
 of 0 or more slash separated pathname segments."

Cheers,
Geoff