Here's an update---I'm narrowing it down.
I tried to connect directly to Tomcat without Apache in-between. Same problem. So this probably isn't something Apache is doing to mess up communications.
I recompiled Apache so that I could add headers, and I added:
DAV: 1,2 MS-Author-Via: DAV Allow: OPTIONS, PROPFIND, GET, HEAD
This way, even error messages and redirects will show WebDAV support, and even an OPTIONS request for "/" will show WebDAV method support.
It still doesn't work.
The *only* thing that isn't exactly what a WebDAV server would send back is when MS Web Folders tries to do a PROPFIND on /webapp/ and Tomcat sends back: "501 Method PROPFIND is not defined in RFC 2068 and is not supported by the Servlet API." (Again, MS Web Folders shouldn't even try to access /webapp/ directly---it should try to access /webapp/webdav/ .)
About the only thing left to try is to allow the PROPFIND on /webapp/ . So here's the Tomcat question---how can I allow a PROPFIND on /webapp/ and return, for example, a 403 forbidden, rather than a 501 Not Implemented? Do I have to override org.apache.catalina.servlets.DefaultServlet? (There goes container independence.)
Why is it that nothing in this world is straightforward? (That's a rhetorical question---don't feel obliged to answer.)
Cheers,
Garret
Garret Wilson wrote:
Some more info:
When Web Folders first tries to access http://www.example.com/webapp/webdav/ , user agent "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on http://www.example.com/webapp . Apache (from Tomcat?) redirects with 302 to http://www.example.com/webapp/ . "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on http://www.example.com/webapp/ . Apache sends back (from Tomcat, I suppose) a 501 "I don't know what the heck a PROPFIND is" type of response. (MS never should have tried to touch http://www.example.com/webapp/ , as that's a parent directory to what I requested.)
Again "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on http://www.example.com/webapp and goes through the whole procedure again. Finally it gets tired and issues an OPTIONS request on "/", to which Apache/Tomcat issues a 202 OK (but with no DAV header).
So then "Microsoft Data Access Internet Publishing Provider Protocol Discovery" gets into the action and issues its own OPTIONS on "/". (Why MS can't simply try to access http://www.example.com/webapp/webdav/ like I asked in the first place, I'll never know.) Another 200 OK response. Finally MS gets around to doing an OPTIONS on http://www.example.com/webapp/webdav (which it should have done in the very first request). Tomcat (through Apache) issues its 401 Unauthorized response (as it should), along with the DAV: 1,2 header (as it should). MS decides, "Oh, well, I'll issue an OPTIONS on the root path '/' again" and goes through the entire process.
Then I see various attempts at GET /_vti_inf.html and POST /_vti_bin/shtml.exe , indicating that MS Web Folders didn't recognize WebDAV and is trying to use FrontPage extension witchraft. Sending back a MS-Author-Via: DAV header should stop this---but my WebDAV servlet never got the chance because MS Web Folders wouldn't authenticate in the presence of a 401 Unauthorized.
I know that IE, Web Folders, and the whole shebang is a load of (insert expletive here), but I've managed to work around everything else so that it works on pure Tomcat on localhost. There's some little thing that's throwing things off in the Tomcat-behind-Apache-on-Internet scenario, and if I can just find out what it is, I can cut off this last MS bug and get this to working.
Does it have something to do with Apache modifying a HTTP request or response to or from Tomcat?
Does it have something to do with the server being located somewhere other than localhost, altering the behavior of Microsoft-WebDAV-MiniRedir/5.1.2600 or Microsoft Data Access Internet Publishing Provider Protocol Discovery?
An inquiring mind wants to know---but really has to get some sleep right now.
Thanks again to Doug and everyone else for your time.
Garret
Garret Wilson wrote:
I've written a custom WebDAV servlet which works fine configured on Windows XP Professional localhost with Tomcat 5.5.4.
I upload everything to a http://www.example.com/webapp/webdav/ . The domain is served on Red Hat 6 by Apache 2.0.49, which forwards to Tomcat using ProxyPass and ProxyPassReverse.
I try to connect via Microsoft Windows XP Professional Web Folders. (My WebDAV servlet works around all the various Microsoft redirection bugs, and works fine with Web Folders on localhost.) Web Folders doesn't recognize the folder. I whip out Ethereal, and here's what I find:
User agent "Microsoft Data Access Internet Publishing Provider Protocol Discovery" sends an HTTP OPTIONS request to "/". Apache sends back a 200 OK. Then Microsoft Web Folders sends an OPTIONS request to /webapp/webdav/. My servlet sends back a 401 Unauthorized, asking for digest credentials. So far, so good.
Then Microsoft Web Folders starts over again, sending an HTTP OPTIONS request to "/", and then an OPTIONS request to /webapp/webdav/ (never asking me for my username/password), until it finally gives up and says that there must not be a valid WebDAV server at the requested location.
Why doesn't Microsoft Web Folders ask my for my password? Why does it ignore the 401 Unauthorized and go back to asking for OPTIONS on the root? Does this have something to do with using Apache to proxy to Tomcat? Why did a non-proxied Tomcat work find on my Windows XP Professional machine?
(If it has anything to do with it, I'm testing this in a cafe going through Surf and Sip WiFi.)
Thanks in advance for any insight.
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
