- From: Jim Davis <jdavis@parc.xerox.com>
- Date: Mon, 9 Nov 1998 18:08:03 PST
- To: WEBDAV WG <w3c-dist-auth@w3.org>
I've followed this discussion and at this point I don't see a problem. That is, none of the examples presented seem to have paradoxical or non-sensical consequences. I speak as one who has implemented WebDAV. I will say that in such implementations, allowing multiple URIs to refer to the same resource requires some care in how one stores properties. But this has to do with difficulties in programming, not in understanding the intentions of the spec, which seem to me to be clear. In sum, anyone who thinks there is a problem should present an actual example of inconsistency or paradox that could arise. The remainder of this message comments specifically on the interchange between Larry and Jim Whitehead. At 02:58 PM 11/4/98 PST, Jim Whitehead wrote: >Larry Masinter writes: >> > Internal Member URI - A Member URI that is immediately relative >> to the URI >> > of the collection (the definition of immediately relative is given in >> > section 5.2). >> >> But you say _the_ URI of the collection. I don't think this is a problem. In context, this is talking about the URI of a member of a collection. The collection resource itself may have many URIs, but for the purposes of any single WebDAV request, the other URIs don't matter. Likewise, the URIs of the internal members are specified relative to the URI of the container. >It seems to me there are two ways of handling the issue of multiple URIs for >collections: > >a) disallow them No need for that. >b) allow them, and detail the consequences. >The current definition of a collection is pretty usable even if there are >multiple URIs for the collection, since member URIs are currently defined as >being immediately relative to the base URI of the collection. But, if the >member URIs are immediately relative to *a* base URI of the collection, then >the definition still works. There's no need for that. The only way a client can discover the URIs of the members of a collection is by doing PROPFIND, traversing down the tree. The client provides the URI of the collection, and the URIs in the PROPFIND response are relative to that. >It has one repercussion: if a collection has >more than one URI, then every resource referenced by the member URIs of the >collection also needs to have more than one URI if a collection has more than one URI, then a client will reach it by two paths. >For example: > >A collection resource, R, has the following member URIs: > >mem1.html >mem2.html >mem3.gif > >The collection resource itself has the following URIs: > >http://example.com/collect1/ >http://example.com/collect2/ > >This implies that the resources available via URIs: > >http://example.com/collect1/mem1.html >http://example.com/collect1/mem2.html >http://example.com/collect1/mem3.gif > >Would also have to be available via URIs: > >http://example.com/collect2/mem1.html >http://example.com/collect2/mem2.html >http://example.com/collect2/mem3.gif And what's the problem with that? Isn't this exactly the semantics you want by having two names for the collection? >> If I have a collection with >> URIs >> http://server1.company.com/collection and also >> http://server1.company.com/COLLECTION, then is >> http://server1.company.com:80/Collection/frob an 'internal member'? of "collection"? No. http://server1.company.com/collection/frob is an internal member of http://server1.company.com/collection http://server1.company.com/COLLECTION/frob is an internal member of http://server1.company.com/COLLECTION but nothing is known or knowable about the relation between collection/frob and COLLECTION/frob. You didn't say anything about "Collection" (is this a third name for that collection?) so I don't know about that one. What's the problem? It's not as if the client is getting (from random sources) sets of URLs with randomly permuted upper and lower cases. It's presumably exploring a WebDAV space in an orderly way. We expect the server to be orderly too. It may well be that some WebDAV server would be case insensitive. In this case, for a URL of length n, there are 2^n variations on the name, all of which lead to the same resource. You don't expect the server to list them ALL when enumerating a collection? No, it will list just one of them, unless they are truly being used as synonyms (as for example when one has a set of collections named according to release version and a synonym collection that points to the most recent one.) >> > Any given internal member URI MUST only belong to the collection once, >i.e., >> > it is illegal to have multiple instances of the same URI in a >collection. Yes. This is the only sensible thing to say. The spec 11.9.1 says something close to this, and I think was even intended to say exactly this, but does not quite say it right. >> Do you really mean 'the same URI' or do you mean URIs for the >> same resource? >> If http://foo.com/bar/blah and http://foo.com/bar/BLAH are two URIs for >> the same resource, can both of them belong separately to the >> http://foo.com/bar/ collection? > >The same URI. For example, since every part of a URI which isn't a domain >name is case sensitive, /blah and /BLAH are two different URIs, and hence >could both be part of the same collection. yes. I would say, from the standpoint of a server implementor, that in discussing this example, I would distinguish between 1) The server is doing case folding. URLs are being canonicalized. 2) The server respects case, and these are genuinely two different URLs that happen to resolve to the same resource, because of the way the links happen to be set up. I would say to a server implementor that in case 1 (is it even allowed, by the way? that is, does RFC 2068 *allow* case folding?) you should pick one case and use it consistently in PROPFIND responses. either: a) use the case in the PROPFIND request b) use some canonical case. Case 2 is no difference in principle from http://foo.com/bar/blah and http://foo.com/bar/nusrat or for that matter or http://foo.com/bar/zorba/noise/nusrat
Received on Monday, 9 November 1998 21:10:19 UTC