- From: Jason Crawford <nn683849@smallcue.com>
- Date: Mon, 23 Sep 2002 19:13:23 -0400
- To: "Clemm, Geoff" <gclemm@Rational.Com>
- Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Wow. What a discussion this has been. I'll try to pull this together. I can't claim to have understood everything said since some comments were terse and were not followed up. There has been a statement that there is an interoperability issue with not having the server always return a trailing slash when refering to a collection. Apparently there were true interoperability problems, but no hard interoperability problems were brought up in the discussion except as noted below. Geoff admitted that it is helpful for a client/server to use the slash for GET requests to collections because it creates the possibility of just returning the content of the ./index.html file (for example) without a redirect. (Otherwise the relative URL's inside the index.html file might need to be fixed up.) There was some additional discussion that the redirect might not even be necessary if browsers better supported the Content-Location header. (Perhaps we need to get the attention of some teams writing some browsers?) Geoff asserted that it can be expensive for a server to determine if a non-slash terminated URL maps to a collection or not. He'd rather not have to make that calculation unless explicitly required. Some folks expressed the thinking that hopefully that cost can be avoided by techniques and that making a second request to the server clearly has a performance price. Geoff asserted that (in my words, not his) that the second request (PROPFIND) is probably necessary anyway if any other information is needed. It was asserted that the server should at least be consistant in what it returns. Although no detail on this point was provided I think the point was that a server shouldn't be passing a mixture of slash terminated and non-terminated URL's for the same resource. By doing so it leaves the client to notice and assume at some risk that they are really the same resource. (An example might help make this case.) No one has protested the returning of the terminating slash. There was just some protesting that it be required. As far as I know, and I know there had previously been discussion that would violate this assertion, if the server sends a URL with a terminating slash, the client can assume there is a collection at that location. If this assertion remains true, the server returning this slash when accessed by a client that leverages this insight, can appear to be a more responsive server than one that doesn't return the trailing slash. I think the remaining issues are... Were there truly some interop issues with not always returning a trailing slash? What were they? Would a requirement of consistancy work just as well as requiring a terminating slash? Certain broken behaviors in existing clients/servers was mentioned. What products, people, etc do we need to follow up with? Can a client assume that, if a server returns a URL that ends in a slash, the resource referenced is a collection? ------------------------------------------ Phone: 914-784-7569
Received on Monday, 23 September 2002 19:34:03 UTC