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?

  • I'm afraid that you might get the tumbleweed badge for this. – MathewC Jun 19 '09 at 15:07
  • 1
    Then it may get the Necromancer badge for whoever answers it :) – crb Jun 19 '09 at 15:13
  • And I assume forcing "Save as" is not an option, right? If it is an option, then maybe changing the content type of Office documents to application/octet-stream may remove the "Open" button from the IE download dialog. (Feels more like a hack, and you already got a workaround by hitting Cancel.) – Arjan Jul 18 '09 at 11:57
  • Another thing you may, or may not, need to take into account: would Office interpret any HTTP Expires or Last-Modified headers, if any of those are returned along with your empty response? Like: what would happen if someone selects a file from a Recent Files menu in Office: would it request the document from the server again, or would it use a cached version? (By the way: I would expect the OPTIONS request to include the full path. Apparently not, as your KB article claims that allowing anonymous browse permissions may solve it.) – Arjan Jul 18 '09 at 13:33

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.

| improve this answer | |

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.


| improve this answer | |
  • appcmd.exe is an IIS7 program; we're running IIS6. (We aren't running Sharepoint, but unfortunately I believe we need WebDAV for another part of the application.) – crb Jun 20 '09 at 15:37
  • 1
    You can disable WebDAV without appcmd, but obviously if you need WebDAV you're stuck. Even if you need WebDAV maybe you could still split the site into two separate sites, one with WebDAV enabled and one without. They could point to the same physical directory and you would use the WebDAV disabled site only when you don't want the HTTP OPTIONS verb to be processed. Other than that, your suggestion of an ISAPI filter is the only solution I can think of. Sorry :-( – John Rennie Jun 21 '09 at 6:37
  • Do I get my Necromancer badge? :-) – John Rennie Jun 21 '09 at 6:38
  • Even with WebDAV off, you still get a response to OPTIONS from IIS - in this case, a completely different code path. issociate.de/board/post/232980/…. :( – crb Jun 22 '09 at 15:38

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:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0 [...])

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!)

| improve this answer | |

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"

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.