why does clicking links in Excel/Word appear to cause my non-IE browser to masquerade as MSIE 7.0?

Question

When clicking a link in Excel/Word, and that link takes you to a site that inspects the User Agent to determine if it's supported or not, the site may incorrectly assume you're using MSIE 7.0 when in fact you're using something else, say Chrome.

When inspecting the User Agent sent along with the request, it shows that the request is from MSIE 7.0 - when from the point of the user, MSIE 7.0 is quite clearly not being used.

What is going on here? How can I stop showing users the wrong message?

Answer 1

The problem appears to be that Excel/Word attempt to pre-load the link when it gets clicked. If it successfully loads, it will open your default browser with the given link. However, it will also follow 302 redirects when pre-loading the link. If the site does not support MSIE7 (which is now becoming rather common), it will most likely redirect you to an info/error page. The pre-loading routine will then open this page in your browser rather than the original link, resulting in a message likely explaining why MSIE 7.0 is not supported - but confusing the user who can clearly see that the page was loaded using Chrome.

Is there a recommended way of coding around this?

If this has been answered before, please let me know. I hope it helps someone.

Answer 2

The simplest solution to this is to place a browser check on the "IE 7 not supported page". The Office program, having followed the redirects (based on the wrong user agent string that it sends) will load the error page, receive a HTTP 200 response and THEN throw the link up to the default browser. The browser then requests the page itself, with its proper user agent string.

1. Office process requests "example.com/example.html" with User Agent "compatible; MSIE 7.0"
2. Server returns http 302 redirect to example.com/notsupported.html
3. Office process requests "example.com/notsupported.html" with User Agent "compatible; MSIE 7.0"
4. Server returns http 200 Found + example.com/notsupported.html
5. Office process passes link to default browser
6. Default browser requests "example.com/notsupported.html" with User Agent "whatever the browser agent is"
7. Server returns http 200 Found + example.com/notsupported.html

So once the browser requests the page you can use the user agent string to see if you really do want to send a "not supported" page back, or redirect the request to real content.

This will, however, raise the problem of finding the original URL that was redirected. There are issues with sharing sessions between the Office process that originally requests the page and the browser that eventually is passed the end point URL. A workaround here would be to include the original request URL as a query string parameter in the redirect response to the "Not supported" page.