Here's new news:
Apparently the whole PROPFIND / and Apache proxy things were red herrings. The central issue seems to be that MS Web Folders doesn't know what to do with a 401 Unauthorized response to an OPTIONS request on the WebDAV root folder (when it finally gets around to checking). I reconfigured my WebDAV servlet to bypass authorization for OPTIONS requests (as a test), and once MS Web Folders requested OPTIONS and my servlet sent them back, it issued a PROPFIND and correctly popped up the authorization dialog. (But there are more problems---see below.)
Requiring OPTIONS to forsake authorization is a security risk. If I can't return 401 Unauthorized for OPTIONS, then a client can issue OPTIONS at will and find out which resources exist and which are collections.
But let's say that I open up OPTIONS for all my realms, just to make MS Web Folders work. I'm still not out of the clear. Once MS Web Folders tries to do a PROPFIND and I enter my name and password, it doesn't work.
In fact, MS Web Folder doesn't even send back my credentials! It apparently sends an identical PROPFIND request as the one that just failed, and then shows another dialog box with "user" changed to "www.example.com\user1". (The servers is a virtual host on Apache, proxied to Tomcat.) Now, this I've seen before, with Apache mod_dav on a virtual host. I never found the source of the problem. (I have Apache mod_dav working fine with non-virtual-host SSL domains.)
Now I've opened up a security risk, and there's still another problem to track down.
Thanks for your pointers, and for being a wonderful audience. ;)
Garret
Garret Wilson wrote:
Yeah, that's what I *assume*, anyway. But Ethereal doesn't work on localhost, so I can only assume. There are these possibilities:
* Tomcat returns something other than 501 Not Implemented when configured on localhost. (Not likely.)
* MS Web Folders does different checks when accessing the Internet-at-large than when accessing localhost. (Likely? I don't know what to expect with MS Web Folders anymore.)
I'm guessing the latter is happening, especially as two MS user agents get into the act: "Microsoft-WebDAV-MiniRedir/5.1.2600" and "Microsoft Data Access Internet Publishing Provider Protocol Discovery"
And here's more news: I created a new DefaultServlet mapped to "/" that for PROPFIND simply returns 403 Forbidden. Something different happens. First, "Microsoft-WebDAV-MiniRedir/5.1.2600" does a PROPFIND on /webapp (which gets redirected to /webapp/). MyDefaultServlet returns 403 Forbidden. Fine. Can you guess what "Microsoft-WebDAV-MiniRedir/5.1.2600" does?
"Microsoft-WebDAV-MiniRedir/5.1.2600" then tries to do another PROPFIND on /webapp! And another---for a total of five times! (It's forbidden, you idiot---and /webapp is none of your business anyway; you're supposed to be accessing /webapp/webdav/! Arggg!!!)
Then "Microsoft Data Access Internet Publishing Provider Protocol Discovery" comes along and does its little OPTIONS / (200 OK) OPTIONS /webapp/webdav (401 Unauthorized) dance for three times, and then goes into the FrontPage mumbo-jumbo.
What is left to do---issue a 401 Unauthorized on PROPFIND /webapp ? Issue a 401 Unauthorized on OPTIONS / ? Rewrite the operating system? (Yeah, the latter is probably what I'll have to do to fix all this mess.)
(Grumble grumble grumble...)
Any suggestions on what to do next?
Garret
Varley, Roger wrote:
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.)
But surely Tomcat returns 501 when accessed via Localhost and you've already said that scenario works.
Regards Roger
__________________________________________________________________________
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
__________________________________________________________________________
--------------------------------------------------------------------- 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]
