I've tested the WebDAV URL of IIS 5.0 with IE5.5.
Nontheless, It did't work, even though I tested with MS IIS 5.0 and IE5.5.
I guess probably it could be a bug with IE 5.5?
----- Original Message -----
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 18, 2001 4:00 PM
Subject: Re: IE open as Web Folder now doesn't work with my setup
| > I've largely worked it out now. Here is a summary:
| >
| > 1. "Win 2000 MyNetworkPlaces - Add Network Place", user-agent :
| > Microsoft Data Access Internet Publishing Provider DAV 1.1, tries
| > OPTIONS and PROPFIND on the exact URL you type in, whereas IE5.5,
| > user-agent : Microsoft Data Access Internet Publishing Provider DAV,
| > always truncates that URL and tries OPTIONS on "/" and OPTIONS on the
| > first path segment "/TestDrive".
| >
| > So that's one reason at least why you need the webdav servlet mapped to
| > the default servlet in the context - so that IE5.5's PEOPFIND returns
| > 207. If it gets that, it happily does a PROPFIND on the path you
| > actually typed - in my case PROPFIND /TestDrive/protected/webdav/files.
| >
| > I'm not entirely clear why things have been working for me - certainly i
| > did once have the webdav servlet as the default servlet in the context,
| > and set up some webfolders. I can only think that once i had some web
| > folders set up, i could later set up another without IE5.5 trying to do
| > its errant OPTIONS. I suspect this might be what happens, coz when you
| > try open as web folder in IE5.5, it does somehow look to see what web
| > folders are already set up.
|
| Overall, I'm not that happy about the behavior of the webfolders. I wan't
| aware of the Open as webfolder command. I always used them through the
| Network Places before. As usual with Microsoft (and perhaps even more than
| usual here), the error reporting is just terrible.
I checked that IE5.5 always use PROPFIND, when webfolder open the WebDAV
URL.
|
| > 2. The strange WebdavMethod.getRelativePath output occurs in cases like
| > the following:
| >
| > Path Info : null
| > Path translated : null
| > Query string : null
| > Request URI : /TestDrive/protected/webdav
| > Context path : /TestDrive
| > Servlet path : /protected/webdav
| >
| > getPathInfo() = null so WebdavMethod.getRelativePath sets its result to
| > getServletPath(), which = /protected/webdav
| >
| > Slide then looks for an object found at /protected, which would only be
| > there by coincidence, and logs:
| >
| > 18 Feb 2001 14:44:15 - INFO - GET (time: 113 ms) URI = /protected/webdav
| >
| > In these circumstances, maybe it would be better to return / ?
|
| The problem here is that when path info is null, it usually means the
| servlet is mapped as the default servlet (mapping = "/"), and that you
| should look at the servlet path.
| If the mapping is /webdav/* :
| Request : /webdav then path info = null and servlet path = /webdav
| Request : /webdav/ then path info = / and servlet path = /webdav
| Here, we want the second case to happen. However, MS engineers decided it
| was a good idea to strip the trailing / before making the request.
|
| We can choose to remove the possibility to map the servlet as the default
| servlet, and force to map it as "/*" (if it doesn't cause any other
| problems). If we do that, then both cases are identical, and we can
consider
| that path info = null is equivalent to path info = "/".
|
| Remy
|