We have a web site hosting Office documents behind IIS6 Basic authentication.
IE has an authentication token for basic auth, which it presents to download the file. The user clicks "Open", and then Microsoft Office Protocol Discovery does a HTTP OPTIONS request on the directory the file was served from. However, Office does not have the auth token that IE does, so it prompts again for credentials. Hitting Cancel will then show you the file in Office.
As we are not a Sharepoint-like application, and we don't have a way of responding to OPTIONS, I would like to reply to all requests with the OPTIONS method (that are sent with a user-agent of "Microsoft Office Protocol Discovery") with something like an empty 200, as RFC 2616 states:
If no response body is included, the response MUST include a Content-Length field with a field-value of "0".
I am leaning towards an ISAPI filter that responds with 200 - before the Basic authentication happens. Windows auth or anonymous access are not options. Are there any alternatives I am missing?
Is the draconian approach of just denying the OPTIONS verb in IIS globally a possibility? You could install URLScan and put OPTIONS in the [DenyVerbs] configuration.
I think you can disable WebDAV for a web site using appcmd.exe. Could you create a separate web site to hold the documents and disable WebDAV on it? That shouldn't affect any Sharepoint sites running on the same server.
JR
A bit too long for a comment, so I'll abuse an answer. In fact it does not apply to your question, and I don't think this behaviour will trouble you, but just to be sure you know about it.
The other way around, when clicking URLs in an Office document, Office (2007) first tries to determine what the URL does. If this yields some 301 Redirect to a login page because the visitor (being Office) is not authorized, then Office will in fact ignore the original URL. Instead, it opens the 301 URL in the default browser, which is not always IE.
This may direct people to a login page even when they already had their default browser running and authorized. This is a minor annoyance when the URL that was clicked is still available in some GET parameter of the 301 URL, like
login?goto=original-url. However, if the original URL is stored in some session (for which then Office holds the cookie, not the browser), then the user will even get stuck on the login page as the web server does not know which page to show after the extra login...I've only tested using Office 2007, which at the time used the following User Agent for its hidden request towards an Apache server:
So I assume that Office 2007 actually uses IE itself to do the request. I have also noticed that Office 2007 can access the cookies from IE. For example: when the user is authorized using IE (using a cookie; I've not tested using Basic Authentication), then Office does not receive the 301 Redirect to a login page. So, when Office makes the funny request then it passes the cookie from IE to the server. It may also pass any received cookies back to IE (I've not tested that).
(Thanks for the link to that KB article!)
Perhaps, you should verify your iis6 configuration.
in the website configuration ->home dir -> configuration ->mappings Do you have a mapping to the .doc extension.
another thing: website configuration ->home dir -> configuration ->mappings -> options: the enable session state option, is it active?
another thing: Are you using more "workers" in the app pool? (don't use more than one) - Application pools -> properties -> performance -> web garden maximum number of workers -> set it to "1"
Sometimes if it has more than one worker process the "auth" can be "lost"