I've been struggling with the whole issue of Microsoft WebDAV clients failing to including a trailing slash in collection URIs even when I ask nicely. It looks like I can fix this with redirects, but that opens up another can of worms: the Microsoft client redirect bug. I'm trying to get the last word on this, and it looks like Mark Thomas or others may be able to set the record straight.
Not sure I can set the record straight completely as it is a while since I played with any of this.
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.
MS clients have a varied response to the redirect. I didn't record the exact details but from memory IE (XP no SP) then tried the MS specific urls (which TC rejected) whereas IE (XP SP2) seems to be OK with the redirect.
What I found at the time was the simpliest work around was to map the webdav servlet to "/*".
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=2007923
Since the above thread, I have fixed the webDAV servlet so you can map it to (for example) "/editmywebapp/*" which makes http://www.example.com/webapp/mypage.jsp editable via http://www.example.com/webapp/editmywebapp/mypage.jsp
This should make editing a webapp through webDAV a lot easier.
Basically, Microsoft clients will issue a PROPFIND for http://www.example.com/folder instead of http://www.example.com/folder/ , even though the latter is the true name of the collection and the former is a file that doesn't exist. WebDAV servers get around this by issuing a redirect from http://www.example.com/folder to http://www.example.com/folder/ .
It appears that some Microsoft WebFolder implementations will follow up the redirect with a GET instead of a PROPFIND, breaking WebDAV access. For this reason Apache has a redirect-carefully option for user agents such as "Microsoft Data Access Internet Publishing Provider".
So here are my questions:
* What's the most appropriate redirect to send to redirect from http://www.example.com/folder to http://www.example.com/folder/ ? A 301 (permanent) or 302 (temporary)?
Don't know.
> Which does Apache do?
Don't know.
> Which does the Tomcat WebDAV servlet do?
It is actually determined by the mapper and depends on the mapping. For TC4 - returns response for ../folder/ For TC5 mapped to "/" issues a 302 For TC5 mapped to "/*" returns response for .../folder/
* For those clients that do not follow redirects properly, what should be done as a workaround? Should the server simply act as if http://www.example.com/folder/ were requested when http://www.example.com/folder is requested, if the user agent is one of those recognized as buggy?
I think the real question is how does the server get from the request for http://www.example.com/folder to the response for http://www.example.com/folder/. Redirects are just one way of doing it - and they don't work for some clients.
> Is this what Apache does for redirect-carefully?
Don't know.
> What does the Tomcat WebDAV servlet do?
For TC4 - returns response for ../folder/ For TC5 mapped to "/" issues a 302 For TC5 mapped to "/*" returns response for .../folder/
* Currently, in my implementation I'm sending back a 302 redirect, and Microsoft WebFolders handles it fine on Windows XP Professional SP2. But is it true that other versions do not follow redirects?
I have certainly seen IE ignoring redirects but couldn't give you exact version numbers. I think it was IE from XP with no SP I saw this on but I am not sure.
As all versions send the same user agent identification ("Microsoft Data Access Internet Publishing Provider"), what should the WebDAV server do---implement the redirect-carefully hack even with those clients that properly follow redirects, as the server can't tell the difference?
Depends on how much control you have over the clients. The mapping to "/*" approach seems to have fixed all of the 302 issues we were seeing.
> What does the Tomcat WebDAV servlet do?
Uses a mapping that means 302s are never issued.
A lot of this information seems to be on the Internet, but as little pieces scattered about.
As with most useful info on the internet ;). Hopefully this thread will help make this better.
Thanks in advance,
Garret
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
