- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 18 Sep 2002 10:38:51 -0400
- To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
From: Lisa Dusseault [mailto:lisa@xythos.com] > ... I need to see some compelling reasons why a > collection requires protocol-imposed naming constraints. Another reason was given by Roy in an older mail: "There are no known examples of HTTP servers for which the URI without a slash is the SAME RESOURCE as the URI with a slash. That is because pre-WebDAV HTTP servers just redirected a request on what WebDAV identifies as a collection (with or without the last slash) to some server-defined member of that collection (e.g. index.html). Automatically providing two different URI for the same resource, particularly when they cross hierarchical syntax, instantly doubles the application name space (bad for IR and QA) and creates holes in access control." If that is in fact a problem, then the server won't do it. On the other hand, if the server's implementation does not support trailing separator characters, and the user expects this equivalence because all other protocols that access this server do so, it may be significantly more complex (for both the implementor and a user of the repository) to try to fake trailing separator characters as indicating a separate resource. That is why the mapping of URIs to types of resources needs to be under the server's control, not predefined by the protocol. If the server consistently uses the same URL for each resource, then it's easier for clients and intermediaries to handle (cache, compare, concatenate paths, etc) those resources. With the presence of multiple bindings to the same resource (something that is explicitly allowed by the rfc2616, and explicitly supported by the BIND protocol extension), the client cannot assume that there is only one URI for a given resource. Any client that assumes otherwise has a serious bug that should be fixed. > Since when is a collection path without a trailing slash a "bad > Request-URI"? RFC-2518 explicitly states in Section 5.2 that "a > resource may accept a URI without a trailing '/' to point to a > collection." If you are proposing to change this semantics, then > I object even more vigorously (but I'll save those objections > until I verify that you are proposing to make this change). I don't think it matters too much which one you pick, with trailing slash or without (with trailing slash is slightly more convenient because it's a marker for collections). However, there was strong opinion that the spec should pick one. Allowing such flexibility, as usual, makes life harder for clients. The only client complexity that we have identified is the need for the client to add a '/' before adding a new segment, if there is not yet a slash there (usually in one line of code). Given that file system clients have dealt with this for years with no issues, I see no reason why this is any harder for HTTP/WebDAV clients. If the spec is ambiguous, or the algorithms required are complex, then certainly one can fix the protocol, but if a client just has a bug with a simple fix, you fix the client -- you don't change the protocol to workaround that bug for a few special cases. > Note also that there is no requirement in 2518 for a server to > redirect a non-GET request (it just needs to return the '/' > terminated name in a Location header). Note that I have no > problem with requiring that a Location header be returned, since > if the server is applying a method to a resource, it will have > had to find out what type of resource it is anyway. Yes. And if the server returns the slash-terminated name in a Location header, it should use the SAME name everywhere else in the response. That is an opinion with which I disagree. > The only real interoperability problem I saw identified above was > the "clients don't redirect properly", and the solution there is > to fix the broken clients, not change URL conventions so that the > broken clients work better in this one case of redirection. (I > consider the addition of a slash when extending a URL to be a > trivial coding issue, not an interoperability problem). Also an interoperability problem found was "clients don't append new child names properly onto collection names". That was the "trivial coding issue" I was referring to. A client that appends a new segment to a URL without ensuring there is a preceding '/' just has a bug, and a bug that is trivial to fix. Cheers, Geoff
Received on Wednesday, 18 September 2002 10:39:23 UTC