IEInternals

A look at Internet Explorer from the inside out. @EricLaw left Microsoft in 2012, but was named an IE MVP in '13 & an IE userAgent (http://useragents.ie) in '14

Internet Explorer 11’s Many User-Agent Strings

Internet Explorer 11’s Many User-Agent Strings

  • Comments 35

If you found this post, chances are good that you’re searching for IE11’s User-Agent string.

Why?

Were you planning to control your website’s behavior based on the browser “sniffed” from the User-Agent (UA) string?

Please don’t; use feature detection instead (Ref1, Ref2).

Poorly implemented (non-futureproof) User-Agent sniffing has proven to be the top compatibility problem encountered each time a new version of Internet Explorer ships. As a consequence, the logic around the user-agent string has grown increasingly complicated over the years; the introduction of Compatibility Modes has meant that the browser now has more than one UA string, and legacy extensibility of the string was deprecated after years of abuse.

By way of example, consider...

ASP.NET User-Agent Sniffing

Pages running on ASP.NET might use UA sniffing to decide what content to return to browsers. You will need to ensure that hotfix is installed on your servers for ASP.NET to recognize IE11 as a browser that supports JavaScript:

  • 2836939 .NET 4 - Win7SP1/Win2K3SP2/Win2K8R2SP1/Win2K8SP2/VistaSP2/WinXPSP3
  • 2836940 .NET 3.5 SP1 - Win2K3SP2/Win2K8SP2/VistaSP2/WinXPSP3
  • 2836941 .NET 2.0 SP2 - Win2K3SP2/WinXPSP3
  • 2836942 .NET 3.5 SP1 - Win7SP1/Win2K8R2SP1
  • 2836943 .NET 2.0 SP2 - Win7SP1/Win2K8R2SP1
  • 2836945 .NET 2.0 SP2 - Win2K8SP2/VistaSP2
  • 2836946 .NET 2.0 SP2 - Win8RTM/WinRTRTM/Win2K12RTM
  • 2836947 .NET 3.5 SP1 - Win8RTM/WinRTRTM/Win2K12RTM

Without the hotfix's updated browser definition file, your pages might omit the script blocks from all pages sent to an IE11 client.

See why UA-sniffing is evil?

IE11's Default UA String

By default, Internet Explorer 11 on Windows 8.1 sends the following User-Agent string:

    Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko

This string is deliberately designed to cause most UA-string sniffing logic to interpret it either Gecko or WebKit. This design choice was a careful one—the IE team tested many UA string variants to find out which would cause the majority of sites to “just work” for IE11 users.

Contrast this string with the old IE10 on Windows 8 UA string:

    Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

Many websites would scan for the MSIE token and, if present, return non-standard markup which would not render properly in modern versions of IE.

DOM userAgent Property

Internet Explorer 11 continues the IE9 tradition of exposing extensible tokens in the navigator.userAgent property but not sending those tokens in the request header. For instance, by default this property returns the following on IE11/Win8.1:

    Mozilla/5.0 (Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko

The .NET tokens here were pulled from the registry and allow JavaScript to detect that the .NET Framework is installed on the computer. (They’re a bit misleading because Windows 8.1 includes the 4.5 version of the Framework.)

Compatibility View

If the user chooses to render a site in Compatibility View (click Tools > Compatibility View Settings) then IE will send a User-Agent string that mimics Internet Explorer 7’s UA string:

    Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C)

By default, sites in the Intranet Zone render in Compatibility view, so this is the User-Agent string they’ll see.

Compatibility View List

Internet Explorer 10 introduced the ability for the downloaded Compatibility View List to specify arbitrary UA strings on a per-site basis, to handle cases where a given website only works with a particular UA string.

If you use Fiddler to examine the XML of IE11’s Compatibility View List (e.g. https://iecvlist.microsoft.com/IE11/1375395130872/iecompatviewlist.xml) you will see that it contains a number of UA strings:

image

…each of which can be sent to a particular domain to help ensure that it renders properly in IE10+:

image

 

Obviously, maintaining Compatibility View Lists requires a significant investment on the part of the IE team—resources which could be used to implement more new standards, performance improvements, etc. Please please please: use feature detection rather than User-Agent sniffing.

thanks,

-Eric

PS: Also note that in IE11 mode, the navigator.appName property returns Netscape; older versions returned Microsoft Internet Explorer. The new value matches all major browsers including Safari, Chrome, and Firefox.

  • This issue seems to cause an infinite redirect loop if you are using forms authentication in asp.net 4. I believe its because asp.net thinks ie11 doesn't support cookies and so redirects user to login app, which then recognises that the user is already logged in and redirects back to original app, starting the loop.

  • Is there a version of this hotfix for .NET 4.5?

    [EricLaw] Per Scott Hanselman, ASP.NET4.5 doesn't have this issue. If you're having problems, you might read his post to see if there are outdated configuration files on your server.

  • How do we use feature detections to properly work around the fact that IE still doesn't handle "application/json" per internet standards?

    EricLaw: I'd love to learn what standard you believe is violated and specifically how.

  • I guess that RFC (www.ietf.org/.../rfc4627.txt) states that it is not actually an Internet standard.  However appears to be widespread agreement that "application/json" is the correct content type for json responses.  However, if you send documents to IE with that type, it will prompt the user to download the response.  This does not play well with AJAX applications.

    EricLaw: There's nothing in RFC4627 that states what a user-agent should do when attempting to navigate to application/json, and for good reason. Generally speaking, browsers *should* treat as downloads anything they don't have a particular native rendering for (e.g. an iCAL appointment file, etc). There are a number of reasons for this, security is one of them. By treating the file as a download rather than a very poorly formatted HTML document, for instance, you prevent script-injection attacks against JSON services.

    The claim "This does not play well with AJAX applications." is nonsensical. AJAX applications download JSON using the XmlHttpRequest object, which doesn't care about what the target MIME type is, and which will never trigger a file download dialog, regardless of the MIME type. A File Download dialog only renders if you attempt to *navigate* to a document of a MIME type for which the browser does not have a native renderer (or if it does have a native renderer but you've specified Content-Disposition: attachment).

     

  • That is all great and wonderful for future development, but when you're trying to maintain hundreds of thousands of lines of code and have to change every place where the browser is sniffed, it becomes a major, major undertaking.

    [EricLaw]: Indeed, ongoing maintenance cost is one of the reasons that browser sniffing is discouraged. Rather than updating sniffing, it's best to remove it and replace with feature detection.

  • How do you feature detect whether this will work? addEventListener('DOMAttrModified' ....addEventListener is present in IE and Chrome, yet DOMAttrModified is not supported by Chrome, only IE.

    [EricLaw] For scenarios like this, the obvious approach would be to add the event handler, add a temporary DOM element, modify its attribute, and if the event doesn't fire you know that it's not supported. There may be a better approach, but that pattern is used by modern feature detection frameworks.

  • Your tip for 'DOMAttrModified' is helpful, thanks.  However there are still other times that it's not possible - eg I'm updating code relating to selections, in Chrome if you do sel.addRange(range) then focus is not put back in the iframe, whereas for IE it is (which makes a difference for me).  Don't see how you can detect that in code.  I don't expect you to have a way to do that, my point is really that while homogeneity is a nice ideal, in reality you can't escape the fact that browsers are different and even with perfect adherence to standards, there will always be fuzzy edges.

  • @Jim -

    I suppose the focus event is fired within the iFrame, if it acquires the focus. Have you tried checking that?

  • To answer the question that headlines the post:

    "If you found this post, chances are good that you’re searching for IE11’s User-Agent string.

    Why?"

    I'm the guy that reads the weblogs from IIS and tries to determine how to allocate testing resources.

  • We have a need to know if the browser is IE10 or IE11 in order to disable a feature in our Silverlight app.  Our pages emulate IE9.  When we run HTML reports using Crystal Reports, they fail if the browser is IE10 or IE11.  The failure occurs no matter what IE Emulation we use (or none) and compatibility view makes no difference.  This is a known bug in Microsoft IE that some POSTs to the server don't include the body because they expect the server is going to return a redirect (which it does not).  

    [EricLaw] No such bug exists. Perhaps you're referring to a server-configuration problem, I wrote about here: http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx? I'd be happy to see a repro of this as a Fiddler log; simply email it to me.

    So, in short, we would like to put logic in our code to say if the browser is IE10 or IE11, disable the feature (since it can't be made to work).  As it stands, we are planning to just disable the feature if it is any version of IE because we can't tell if it is just 10 or 11.  

    Is there any way?

    [EricLaw] Modern IE versions, including IE11 include a Trident token in the User-Agent string.  

  • We've managed to remove 99% of legacy user agent-driven logic from our product over the years, but the application -- which is basically an e-learning web app using media delivered by either a CDN or an intranet-hosted media server -- is still just complex enough that we need to be able to do advance triage for a prospective client and  troubleshoot effectively when clients have issues. (Our clients generally come with anywhere between 100 and 10,000 users)

    Even though the delta between actual usable configs and our official line of supported browsers has gotten smaller and smaller, for years Internet Explorer has been the only browser we technically support. The reason for this is that most of our customers can be guaranteed to have MSIE on their corporate desktop/laptop/etc. and -- in general -- the application we developed had been easiest to support with IE (though this has become less reliably so, admittedly). Anyway, drawing the line at MSIE has made life much easier on our support team, who can point to our requirements and say if you're not using IE, we can't spend valuable time working out whatever issue you're having with Firefox, Chrome, etc.

    So we have a simple self-help web application (called a "QuickCheck") whose sole purpose is to diagnose whether a client's browser/OS/plugin configuration meets our minimum requirements, and we've happily been spitting out the browser type and version just as a matter of course, since it provides a simple baseline requirement that can point people in the right direction if they are having an issue with our product.

    Even though the application our clients pay for doesn't shut the door on, or otherwise tailor the experience for, browsers other than MSIE (and when we do it's a feature-based switch, not a sniff), in the QuickCheck we DO want to identify the browser specifically, and we've been doing this reliably with the user agent. (User agent spoofers can sometimes get around it, but this is not a big problem for us.) You can see that this is all going to change shortly.

    It's a changing world out there, and since our app is over 10 years old now you can guess we've had to scramble to adapt more than once. Personally, I am so glad that most core browser functionality is pretty well supported in a standard way.

    However I just wanted to point out that there are, at times, legitimate uses for a user agent sniff.

  • IE11 on Win7 UserAgent is IE10, not distinguishable from IE10.

    [EricLaw] That is incorrect.

    IE11 has a bug in Date.toLocaleTimeString(): Date().toLocaleTimeString().length is 13, should be 8, here IE11 can be distinguished from IE10.

    [EricLaw] That doesn't really make sense. toLocaleTimeString's length depends on the time-of-day. If the string in question changed from IE10 to IE11, that's probably because IE11 better supports the standard for internationalization.

  • @Richard:

    No need to add the Page.ClientTarget to each page. Instead, add to Global.asax.cs

    protected void Application_PreRequestHandlerExecute(Object sender, EventArgs e)
    {
    var page = (Context.Handler as System.Web.UI.Page);
     if (page != null)  {                
        page.ClientTarget = "chrome19";
     }
    }

  • And what features should I detect if I need to know, whether the browser supports clickonce (as we unfortunately need it at the moment)?

    [EricLaw] You don't need the browser to "support" ClickOnce if you author your .application file properly. Any browser (e.g. IE, Chrome, Firefox, Opera, etc) will download the file and allow the user to execute it.

  • @Ivo - Maybe msdn.microsoft.com/.../dn423948(v=vs.85).aspx would be of help in this situation? (Check navigator.plugins for the ClickOnce plugin)

Page 2 of 3 (35 items) 123
Leave a Comment
  • Please add 5 and 7 and type the answer here:
  • Post