Stopping Microsoft Office 2010 from integrating with Subversion server as if it's Sharepoint
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.
Solution 1:
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.