tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garret Wilson <>
Subject Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
Date Tue, 11 Jan 2005 17:16:36 GMT
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 

I recompiled Apache so that I could add headers, and I added:

DAV: 1,2
MS-Author-Via: DAV

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 

Why is it that nothing in this world is straightforward? (That's a 
rhetorical question---don't feel obliged to answer.)



Garret Wilson wrote:
> Some more info:
> When Web Folders first tries to access 
> , user agent 
> "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on 
> . Apache (from Tomcat?) redirects with 302 
> to . 
> "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on 
> . 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 
> , as that's a parent directory to what I 
> requested.)
> Again "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on 
> 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 like 
> I asked in the first place, I'll never know.) Another 200 OK response. 
> Finally MS gets around to doing an OPTIONS on 
> (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 . 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message