Mark,
Mark Thomas wrote:
TC4 and TC5 handle requests for http://www.example.com/folder differently. TC4 does a forward to http://www.example.com/folder/ whereas TC5 issues a redirect....
...For TC4 - returns response for ../folder/ For TC5 mapped to "/" issues a 302 For TC5 mapped to "/*" returns response for .../folder/
Uses a mapping that means 302s are never issued.
Thanks so much for the response. If I could just summarize here, I think what you're saying is that, with the correct servlet mapping, the Tomcat WebDAV servlet will *always* do the equivalent of a forward from http://www.example.com/folder to http://www.example.com/folder/ , and this seems to be a consequence of using the Tomcat-derived directory context as a source of the files on the back-end.
This is compliant with the letter of RFC 2518 (5.2):
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.
The problem with this approach, as explained on the thread http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0190.html , is that http://www.example.com/folder and http://www.example.com/folder/ could represent distinct resources. Well-behaved WebDAV clients could distinguish between the two---this is why Apache apparently uses redirect-carefully *only* for enumerated broken user agents.
The Tomcat WebDAV servlet as you've described, however, forces this behavior for *all* user agents, meaning that even completely compliant WebDAV clients would not be able to distinguish between an existing http://www.example.com/folder/ collection and a non-existent http://www.example.com/folder resource. (Presumably a nice client would be able to create a http://www.example.com/folder with the Tomcat WebDAV servlet even if the http://www.example.com/folder/ collection existed, but that's just a guess---and that ignores the Linux limitation of file/directory name equality, but that's a deployment issue.)
In my implementation, I'm trying to be rigorous with http://www.example.com/folder and http://www.example.com/folder/ distinction. (I'm actually using WebDAV to serve an RDF-based repository, which could have a file system, a database, or anything on the back-end, so any URI is theoretically possible.) I'll probably wind up sending back a 301 permanent redirect for everyone but a few listed rogue clients, which means that unfortunately I'll have to consider even updated MS clients as rogue as they give no version number in their User-Agent header.
Cheers,
Garret
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
