11

We have an Apache Subversion server that we store (amongst other things) all of our documentation on. We have a lot of Word, Excel, PDF etc. documents in svn, and all of our users use TortoiseSVN as their client interface. A lot of those users will also browse the repo through a web browser, which (unfortunately) is often Internet Explorer.

Recently we started trialling Office 2010 (coming from 2003) and found that documents from the repo are opened differently when browsing with IE. Rather than IE downloading the file and then sending it to the appropriate app (after which it should just be a temporary copy stored locally), it sends the URL for the document to the app. The doc is downloaded by the app and then treated it as if it came from a Sharepoint server, i.e. the app tries to lock it and then upload any saved changes back to the server automatically.

From Googling, it appears that many people want this behaviour. However, we want to disable it - it doesn't fit with our existing processes. How can I go about doing this?

I don't have a lot of control over client machines, so solutions that involve disabling all Office document collaboration features like this for each client are not what I'm looking for. Besides, I couldn't find much that I could do other than disable the Office Document Cache Handler add-on in IE. The only client-side options that may be feasible are those that specifically disable this feature for our named server but leave it on for others.

So that leaves server-side solutions. I'm guessing that Office sees that the svn server has WebDAV support and therefore moves into a Sharepoint-like document management workflow. Is there any way to stop this kind of integration without disabling all WebDAV support on the server (assuming we could even do that)? We actually use svn's autoversioning a bit for other purposes so it's a required feature. I've found discussion of disabling the feature if it's actually a Sharepoint server, but it's not! My understanding of how this kind of thing works (i.e. Office client identifying WebDAV support on the server) is pretty limited, so please explain further if you can.

In case it matters, the server setup is:

Apache v2.2.8 and Subversion v1.4.6 on Ubuntu Hardy 8.04.

James Tisato
  • 373
  • 1
  • 2
  • 8
  • I can't suggest this as an answer, since it's more of a cumbersome workaround. I think you're right about the DFAV, since Apache/SVN uses DAV as its access protocol. With that in mind, you could drop Apache and use `svnserve` instead. – SmallClanger Aug 17 '11 at 13:03
  • Thanks for the suggestion, but svnserver isn't an option for us. We have a lot of customisation in place that depends on us using Apache. – James Tisato Aug 17 '11 at 15:20
  • I found a very useful article from MS (I was surprised!): http://support.microsoft.com/kb/838028 It would appear that the Apache server indicates through its HTTP 1.1 OPTIONS reply that it is capable of WebDAV operations and thus Office uses them. Where's the damn option to say "I want my server to have WebDAV available, but I don't want Office to use it?!" – James Tisato Aug 23 '11 at 03:21

1 Answers1

13

Solved it (finally). http://support.microsoft.com/kb/838028 explains how Office uses Microsoft Office Protocol Discovery to determine if the document server has WebDAV capabilities. It sends a HTTP 1.1 OPTIONS request and expects a 200 OK reply detailing available DAV features. The Subversion server has (limited) DAV support and replies as such, and Office then uses it to write directly back to the server.

The solution we used was to use mod_rewrite on the Apache server to intercept these requests and send back a 405 Method Not Allowed response. The rewrite config is:

# Intercept Microsoft Office Protocol Discovery
RewriteCond %{REQUEST_METHOD} ^OPTIONS
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Protocol\ Discovery [OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Existence\ Discovery [OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\-WebDAV\-MiniRedir.*$
RewriteRule .* - [R=405,L]

It intercepts all requests of method OPTIONS coming from agents with the name "Microsoft Office Protocol Discovery" and sends back a 405. This solution was suggested by the first comment on http://rails.nuvvo.com/lesson/2318-dealing-with-microsoft-office-protocol-discovery-in-rails#comments.

Now Office tries a few OPTIONS requests, gets denied by the 405, then gives up and turns off all DAV support for this particular server, while leaving it enabled for any other servers that clients might want to interact with.

Community
  • 1
James Tisato
  • 373
  • 1
  • 2
  • 8
  • Thank you so much! While I am not using Subversion, I've been fighting the same core issue and unable to find documentation until now. I'm still not 100% sure this is it, or *all* of it, but it sounds like it. Opening Office documents linked on a webpage made the internal hyperlinks (relative, with no path) fully qualified http addresses with pathing even though the copy should be being view from a local cache. This only happened in IE... FF and Chrome showed broken links (as expected) from the local file cache. Thank you once again. – one.beat.consumer Dec 22 '11 at 18:11
  • 1
    Suggested by @chekolyn , add the follwoing three lines to rewrite config: `RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Protocol\ Discovery [OR] RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Existence\ Discovery [OR] RewriteCond %{HTTP_USER_AGENT} ^Microsoft\-WebDAV\-MiniRedir.*$` – HopelessN00b Oct 06 '12 at 00:00
  • Excel HYPERLINK() calls don't generate an OPTIONS request but they do generate an extra GET. The user-agent string to watch for with them is "ms-office". Returning an error 405 made the hyperlinks not work properly at all, but returning a blank 200 response for Office did the trick, it opened the default web browser almost immediately to the URL (I'm using ASP.NET on IIS, so I did this prior to authentication). – richardtallent Jul 10 '14 at 20:21
  • However now some excels no longer have ms-office in them. For example my 2013 does not. – mplungjan Sep 14 '15 at 15:10