5

I am not sure if this is an Excel (SuperUser) or WebMasters question since I may have exhausted the server option.

Use case

Our site allows downloading a result list in XLS format. A hyperlink is present for each result which will load the result into the default browser.

Looking in our log file we find several requests per click:

  1. OPTIONS (which I have now generating a 405 - when I started this quest it was returning all options with a 200OK, but then I read Stopping Microsoft Office 2010 from integrating with Subversion server as if it's Sharepoint and KB838028 )

  2. Link Pre-fetching HTTP GET from MSIE 7.0 user agent (Microsoft's built-in URL handler) - 200 OK - 2/3rds of the actual data

  3. HTTP GET from IE 11 user agent - 200 OK - full data

Log file entries

1.2.3.4 - - [17/Oct/2014:11:20:02 +0200] "OPTIONS /myfolder/ HTTP/1.1" 405 36 "-" "Microsoft Office Protocol Discovery" - -
1.2.3.4 - - [17/Oct/2014:11:20:02 +0200] "GET /myfolder/mypage?myparm=myvalue HTTP/1.1" 200 57288 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; ....; InfoPath.3; ms-office)" - -
1.2.3.4 - - [17/Oct/2014:11:20:03 +0200] "GET /myfolder/mypage?myparm=myvalue HTTP/1.1" 200 75326 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" - -

The second request is a waste of bandwidth and likely server processing

Is there a way on the server to not serve data on the 2nd request which I guess Excel loads just in case it was something it could show and then gives up when it isn't?

In the link Microsoft Office Link Pre-fetching and Single Sign-On given by @Perry I see an enticing

RewriteCond %{HTTP_USER_AGENT} ;\sms-office(\)|;) [I] ...

but I cannot see how I can leverage this to have Execel NOT partly download the file we need to open in the default browser

UPDATE

I saw some office clients actually send ms-office as part of the user agent But not mine. My win7 Office 2013 sends

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3)

UPDATE: Will abandon this, but with a suggestion:

If you produce links in an actual excel sheet and you are certain you do not want to support IE7 for the actual page, add a parameter to the link and return 200OK with empty payload to MSIE 7 user agents.

  • really no one?? – mplungjan Sep 7 '15 at 15:03
6

Interesting - I never knew that!

Just tested from my custom web server (Rapid Server) and got the same results (3 GET requests after clicking on a hyperlink), so we know it's not the web server:

127.0.0.1:1062 - - [17/Oct/2014:03:57:45 -0700] "GET / HTTP/1.1" 0 
127.0.0.1:1063 - - [17/Oct/2014:03:57:47 -0700] "GET / HTTP/1.1" 0 
127.0.0.1:1064 - - [17/Oct/2014:03:57:47 -0700] "GET /favicon.ico HTTP/1.1" 404

What I have observed is that it won't make the extra request repeatedly, just the first time and then it gets cached.

It seems to be related to the way Office Protocol Discovery works. KB838028 explains it:

The decision about how to open the Web resource is resolved by investigating the folder path where the document comes from and by investigating the capabilities of the server that manages that path. To determine what capabilities the server supports, Office 2003 issues an HTTP 1.1 standard OPTIONS command. The OPTIONS command requests that the server identify what commands and what methods that the server supports for the folder where the document is located. The server identification is done according to the rules that are outlined in RFC 2616.

Office also tries to determine the Web-server type. This determination is based on header information that is returned by the OPTIONS call. Specifically, Office looks for header values that indicate communications with a SharePoint document library or an Exchange WebStore folder.

Basically it happens due to the way Office tries to play nicely or provide extensibility for other collaborative software that may be related to these hyperlinks.

You could create a rewrite rule to intercept the OPTIONS request and return a 405, see here.

EDIT: looks like I missed some of the details in your question when I first posted this answer, and I haven't really provided a useful answer. Our HTTP results are similar, but also a bit different. In the interim, these articles appear to offer some additional insights: 1, 2, 3. Looking at your results again, the second request's user agent is "older" which could mean that it's an internal web client in Office making that request, as you suspected. Oddly, I see a GET for favicon.ico in my results, but not yours.

From this article:

When you click a hyperlink in an Office file (Word document, Excel spreadsheet, PowerPoint presentation, etc.), the URL is not immediately passed to your browser. First, Office will internally fetch the address. If the link returns a 3xx Redirection code, Office will request the new address and repeat. If the link returns a 4xx Client Error code, Office will abort the request and tell the user that the link is unavailable, having never opened a browser (I’m guessing that’s the whole point of this “feature”). And if the link returns a 2xx Success code, the URL is finally opened in a browser. Only the final URL is passed to the browser; any redirects are masked by Office.

To sum it up, when you click a hyperlink in a Microsoft Office program, up to 4 HTTP requests could be made:

  1. Office makes an HTTP OPTIONS request using an internal web client to check the web server capabilities - user agent is "Microsoft Office Protocol Discovery".
  2. Office makes an HTTP GET request for the clicked hyperlink URL using an internal web client to ensure the web server returns 200 OK before launching the URL in the web browser - user agent is "Mozilla/4.0" aka "ms-office".
  3. Office launches the URL in the web browser, and the web browser makes the third HTTP GET request for the clicked hyperlink URL - user agent is "Mozilla/5.0".
  4. The web browser (not always, apparently) makes an HTTP GET request for the favicon.ico - user agent is "Mozilla/5.0".

References:

  • Welcome to the site! Nicely detailed answer here, with lots of references for more info too! – dan Oct 18 '14 at 3:14
  • Hi Perry, thanks for the detailed investigation which alas does not actually answer my question. I apologise for not including my own investigation of KB articles which match a few of yours but did not tell me WHY excel needs to download some of the data before handing the request off to IE. As mentioned I expect Excel wants to see if the data might be displayable in a spreadsheet and then gives up – mplungjan Oct 18 '14 at 4:49
  • I will see if your link wimpyprogrammer.com/… gives some more insight – mplungjan Oct 18 '14 at 5:01
  • 1
    Well it seems that Rapid Server does not ever receive the OPTIONS request (not sure why), but knowing that this req simply checks for server caps, I'm almost positive now that your 2nd GET is Office's internal web client making sure the web page can be reached before it sends the user there so as not to accidentally send them to a broken site or 404 page, and the 3rd GET is your actual browser. Anyhow have you tried KB218153? You might be able to change the default handling for URLs via regedit so Office passes hyperlinks straight to the browser. Here support.microsoft.com/kb/218153 – perry Oct 18 '14 at 13:42
  • 1
    Appreciate it dan. – perry Oct 18 '14 at 13:55

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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