- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 17 Feb 2006 09:29:23 +0100
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: webdav WG <w3c-dist-auth@w3.org>
Lisa Dusseault wrote: > > From bug 227 <http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=227>: > > For all WebDAV compliant resources A and B, identified by URLs "U" > and "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST > be a collection that contains a mapping from "SEGMENT" to B. So, if > resource B with URL "http://example.com/bar/blah" is WebDAV compliant > and if resource A with URL "http://example.com/bar/" is WebDAV > compliant, then resource A must be a collection and must contain a > mapping from "blah" to B. > > and an example from just after: > > An example for this case are servers that support multiple alias URLs > for each WebDAV compliant resource. For instance, a server may > implement case-insensitive URLs, thus "/col/a" and "/col/A" identify > the same resource, yet only either "a" or "A" are reported upon > listing the members of "/col". > > This example may be inconsistent with the requirement just stated. We > can argue that '/col/a' maps to a WebDAV compliant resource and "/col" > maps to a WebDAV collection, thus "/col" MUST have a mapping from "a" to > the child resource. We can argue the same for "/col/A". Following > that logic could make URL-case-insensitive servers rather difficult ... Correct. Note however that this is also a problem with the original definition. > It may *not* be inconsistent if we claim that "/col/a" and "/col/A" are > the same URL. It also may not be inconsistent if we say that resource B > is identified by one of "/col/a" or "/col/A" but not the other, but that > wouldn't be the meaning of "identified by" that I'd expect. But they aren't the same URL. And even if they would, are "/col/a." and "/col/a" the same URL? Or "/col/%20a"? All of these map to the same resource on IIS. > Not proposing what to do about this just yet. We need to relax the language such that the server is allowed to suppress alias URLs. Let's just note this problem right now and fix it during WGLC. Best regards, Julian
Received on Friday, 17 February 2006 08:32:05 UTC