This actually seems like a really smart move on MS's part. I've seen far to many sites that have blanket conditionals for any msie browser, which will potentially disable supported HTML5 / CSS3 features in IE9 +
For the non-clickers: It's Webkit, not Firefox that it will be disguising itself as:
"The 'like Gecko' string has been part of most WebKit-browser UA strings from time immemorial, but has never been used by Firefox, which instead uses 'Gecko'".
> Microsoft also included the command "Like Gecko" which instructs the website to send back the same version of the website as they would to Firefox
seriously, who does that? 'msie5.0 mozilla', good times. 'like gecko' => msie trying to look like webkit, who tries to look like firefox. yeah, makes perfect sense. could anyone give an example of a modern application that checks against the user agent string?
YouTube is a particularly bad offender. Linked to their mobile site on a desktop? You get the ultra-basic WAP-like version, instead of the smartphone version or a redirect to the desktop version. Linked to their mobile site in Opera Mini? Yep, WAP-like version, despite the fact that Opera Mini would have no problems with the smartphone version.
I'm thinking he meant more in terms of who builds a website that respects the "like Gecko" in the UA string as UA sniffing has been considered a sub par method for a while now.
I agree with "who does that" because I've never done UA sniffing so I had to look up the term "like Gecko" to even understand the context. As someone else has pointed out, that's for browsers that are not using the Gecko rendering engine. So essentially, everyone is trying to be "like Gecko" in one way or another.
I haven't seen web servers send back different pages for non-Mozilla browsers since Mozilla browsers were selectively served frames[0], which is why most User-Agent strings contain "Mozilla". Despite whether this is a good idea or not, it's nostalgically entertaining to see history repeat itself like this.
> could anyone give an example of a modern application that checks against the user agent string?
Gmail. Google docs, every single page titled something demo, ... basically every other site. And it should die already. Browser vendors put up with it because there are thousands and thousands of sites that wouldn't work just because you have the wrong user-agent string and the web developer was incompetent. Great examples include Chrome's idiotic string[1] and Opera's version 9.80[2].
RFC 2616[0] says in section 14.43 that user agents SHOULD send a User-Agent field. Is there any particular reason why it is still sensible to send such a field at all, rather than maybe something more generic like ‘Crawler’, ‘Graphical’ and ‘Terminal’ (to distinguish the three cases that might come to mind immediately)?
In other words, what benefit does a User-Agent field have nowadays when people are told to check for capabilities rather than products, apart from allowing fancy statistics which company currently has the long^Whighest bar in the user agent statistics?
But what do you do if the filename contains non-ASCII characters? There are RFCs, but every browser has its own rules about encoding, and IE is especially problematic because it tries to second-guess your intentions at every opportunity. You can't use capability detection to solve this problem, because browsers don't execute CSS/JS when they just download files. If you really want to make it perfect for every user, you'll probably need to write a slightly different version of the download script for every browser, and several for IE 6/7/8/9/10.
Another valid reason for sniffing the user agent string is when you're trying to offer browser-specific instructions. For example, when you go to Dropbox's download page, they show you how to save and run the installer. They wrote different versions for most of the major browsers/platforms.
There are fewer reasons to use the user agent string when you're just trying to compose a web page. But composing web pages is not the only thing you do when you run a web application.
I understand the point about browser-specific instructions, but using the User-Agent to decide how to encode a file name sounds…wrong. Imagine your email client checking the email client of the recipient to decide how to encode the file name of the file you attached – sure, it’s nice if it is possible, but in general, standards are supposed to be, well, standards, and not caring about broken software might help motivate vendors to fix it.
And even for browser-specific instructions, it would make more sense in my opinion to let users choose the browser for which they want to see instructions[0]: The tool I use to query information is not necessarily the tool I need help with. A bicycle shop also doesn’t decide to only sell shoes or cars if you walk or drive there rather than arriving on a bicycle[1].
[0] I didn’t check Dropbox, so it might well be that they also give people a choice here.
[1] Google’s PlayStore specifically annoyed me there recently as it didn’t let me view the description of an extension in Opera, telling me that I would need Chrome to download and use it – I do, but I’d like to know if this extension is worth installing Chrome or not beforehand.
I can vouch for the legitimacy of what he's saying. There are definitely cases where the only way to make browser download operations (whether it be a file download or certain kinds of XHR requests) work right in IE, Chrome, and FireFox is to write a special case for IE or potentially all 3 of them.
> using the User-Agent to decide how to encode a file name sounds…wrong.
Of course it's wrong, and web devs wouldn't have to do it in an ideal world. But when your Chinese users complain right now that their attachment names are getting jumbled, and when your conversion rate is going down right now because people don't run the files they've downloaded, does it really matter whose job it is to clean up Microsoft's mess?
BTW, non-ASCII attachment names still come out weird from time to time because Outlook, Thunderbird, and various webmails follow different RFCs. Most email composing tools just use a compromise that works 99.9% of the time, but I've seen programs that let you customize the filename encoding.
I agree with your point in general, but in that specific case you can use percent-encoded UTF-8 in the URL and send `Content-Disposition: attachment` without filename. In practice index.php/FILENAME trick works in Apache.
A good client will send a distinguishable user agent because the server may want to reject requests from that client. There is no robots.txt equivalent for user-initiated clients, so user agents are the appropriate way to handle the situation.
It is unlikely that you will want to block a traditional web browser, but web browsers are not the only clients available and some will be performing operations that are not necessarily in line with the wishes of your resources.
other browser vendors release new versions on a regular basis, regardless of the operating system number. This enables browser-related technologies to evolve at a more rapid pace. So please do us all a favor and stop locking major IE releases to Windows versions and just try to imitate what others do. We won't judge you for copying, promise.
Things like product release schedules are rarely in the hands of developers. More likely, a product manager and company dictate when new versions will get pushed out.
Internet Explorer usually relies on new OS features which have to be backported. Also, Microsoft never releases IE for versions of Windows that have gone out of support (Windows XP and Vista), because they don't want to have to do the extra work to do so, and because their policy on out-of-support is exactly that: mo new updates.
please stop arbitrarily bumping your version numbers so you don't have to hear complaints about open source contributions being ignored. Do you seriously expect us to believe you got through 25 real, full versions in 4.5 years?
Sincerely, "one guy not trying to talk for everyone".
That's kinda the point, not noticing what the browser version even is, because it's completely irrelevant (except with IE). What's important is that it follows standards and supports new features sooner rather than later.
I tend to agree, I much prefer semantic versioning eg: major.minor.patch for most software but for Chrome it isn't really important because it auto-updates. I haven't checked which version I am running for months.
Well, it does require more effort on Microsoft's part to support old versions of Windows. They always use new APIs, and they often bring big improvements and have to be backported to work. For example, either IE10 or IE9 used DirectWrite, which had to be backported.
Also, it wouldn't make sense for them to release new updates for officially out-of-support OS versions.
Yes. Correct me if I'm mistaken, but whatever client-side code is affected by this violates principals of Progressive Enhancement/Graceful Degradation and the Browser Sniffing anti-pattern.
Though there is the rare case when a browser had supported a feature for a while, and a nasty bug makes its way into public release where you need to hotfix for a specific version (3D-transforms refusing to work in Firefox 18.0, yet being reported as supported, as an example).
This version of IE (11) comes from the leaked Windows Blue build 9364. What you might want to consider is how MS real world test IE11 without broadcasting the user agent. I'm guessing this 'beta' version is reporting itself as Firefox to disguise itself from server logs.
I want to start by saying, this article needs a giant dose of grain-o-salt. The PS4 was leaked like how many times? And, we all know how that went.
However, As someone who is locked into an app that is tied to IE 6-7, I don't relish the idea of being forced to re-write some 50,000+ lines of legacy code.
This does however force our customers to seriously consider putting out an effort to redesign in the first place.
Isn't that what the article is talking about... I.E. this could break a lot of custom CSS within our application. Anything that is hacky and works with ie 6-8 will need to be redone.
Is that right or did I read the premise of this article completely wrong? I know you are right for IE 9/ IE 10, but if they change IE 11 to force us to redo our CSS then... that sucks (but is kinda good too cuz I hate the legacy crap code we have).
The article said that the user-agent string was changing -- it said nothing about quirks mode going away.
If you have an IE6-only intranet application, then by definition you are not depending on user-agent sniffing. In that case, you depend on the continued availability of quirks mode -- not on the user-agent string.
If you have an intranet application that uses user-agent sniffing to support both legacy IE and standards-compliant browsers, then you should simply do nothing. The change in the user-agent string will cause Internet Explorer 11 to be treated as a "like Gecko" browser. This is as it should be, as IE 11 is a standards-compliant browser.
This is good. I just had to add a meta tag to force IE9 and IE10 into IE8 Standards Mode. This was a 5 year old site that was coded to work in IE6 that stopped working properly on IE9.
Considering the task assigned to me was to make it properly on IE9, I don't think so. The meta tag was a piece of cake, though. It was the month or so when one person on the client's staff couldn't use it, before the client reported it to me, that was troubling.
To answer the second part of your question, it worked on IE 6/7/8 and removing the hacks would have required digging into old code. The meta tag was much quicker!
If companies are going to start messing with user agent strings again, can we please try to restore some sanity? How about "Internet Explorer 11.0" as a user agent? Would that be so hard?
Are you being facetious? As far as users are concerned, IE would be broken. Users don't care that it's because of, say, websites with broken useragent sniffing.
I'm sure it's even more complicated than that, to be honest. But the overarching principle something Josh Bloch articulated. He said something to the effect that any interface that you publish, even if it includes strings (e.g. a pretty-printed stack trace), will inevitably become part of the interface.
I'm not being facetious, i'm honestly asking. How many websites are actually still sniffing the user agent and depending on that Mozilla/5.0 bullshit at the beginning? what would break?
anybody who's surfed with a changed user agent for a while care to comment?
"> Microsoft also included the command "Like Gecko" which instructs the website to send back the same version of the website as they would to Firefox"
This is a little misleading. "Like Gecko" is not used in the Firefox UA String. It just says Gecko. "Like Gecko" is a component of Webkit-based browsers. So IE is emulating Webkit emulating Firefox, and dries the "MS" of "MSEI" for their string, and going with just "IE".
69 comments
[ 37.6 ms ] story [ 1008 ms ] thread"The 'like Gecko' string has been part of most WebKit-browser UA strings from time immemorial, but has never been used by Firefox, which instead uses 'Gecko'".
seriously, who does that? 'msie5.0 mozilla', good times. 'like gecko' => msie trying to look like webkit, who tries to look like firefox. yeah, makes perfect sense. could anyone give an example of a modern application that checks against the user agent string?
> Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.40 Safari/537.31
Its a sad situation.
I agree with "who does that" because I've never done UA sniffing so I had to look up the term "like Gecko" to even understand the context. As someone else has pointed out, that's for browsers that are not using the Gecko rendering engine. So essentially, everyone is trying to be "like Gecko" in one way or another.
[0] http://webaim.org/blog/user-agent-string-history/
I don't think this is aimed at fixing modern applications. It is aimed at much older ie 6-8 era code still on the web that has a bunch of hacks.
Gmail. Google docs, every single page titled something demo, ... basically every other site. And it should die already. Browser vendors put up with it because there are thousands and thousands of sites that wouldn't work just because you have the wrong user-agent string and the web developer was incompetent. Great examples include Chrome's idiotic string[1] and Opera's version 9.80[2].
1. Discussed around.
2. http://dev.opera.com/articles/view/opera-ua-string-changes/
In other words, what benefit does a User-Agent field have nowadays when people are told to check for capabilities rather than products, apart from allowing fancy statistics which company currently has the long^Whighest bar in the user agent statistics?
[0] https://www.ietf.org/rfc/rfc2616
For example, when you let a user download a file, you usually send a header such as:
But what do you do if the filename contains non-ASCII characters? There are RFCs, but every browser has its own rules about encoding, and IE is especially problematic because it tries to second-guess your intentions at every opportunity. You can't use capability detection to solve this problem, because browsers don't execute CSS/JS when they just download files. If you really want to make it perfect for every user, you'll probably need to write a slightly different version of the download script for every browser, and several for IE 6/7/8/9/10.Another valid reason for sniffing the user agent string is when you're trying to offer browser-specific instructions. For example, when you go to Dropbox's download page, they show you how to save and run the installer. They wrote different versions for most of the major browsers/platforms.
There are fewer reasons to use the user agent string when you're just trying to compose a web page. But composing web pages is not the only thing you do when you run a web application.
And even for browser-specific instructions, it would make more sense in my opinion to let users choose the browser for which they want to see instructions[0]: The tool I use to query information is not necessarily the tool I need help with. A bicycle shop also doesn’t decide to only sell shoes or cars if you walk or drive there rather than arriving on a bicycle[1].
[0] I didn’t check Dropbox, so it might well be that they also give people a choice here.
[1] Google’s PlayStore specifically annoyed me there recently as it didn’t let me view the description of an extension in Opera, telling me that I would need Chrome to download and use it – I do, but I’d like to know if this extension is worth installing Chrome or not beforehand.
Of course it's wrong, and web devs wouldn't have to do it in an ideal world. But when your Chinese users complain right now that their attachment names are getting jumbled, and when your conversion rate is going down right now because people don't run the files they've downloaded, does it really matter whose job it is to clean up Microsoft's mess?
BTW, non-ASCII attachment names still come out weird from time to time because Outlook, Thunderbird, and various webmails follow different RFCs. Most email composing tools just use a compromise that works 99.9% of the time, but I've seen programs that let you customize the filename encoding.
It is unlikely that you will want to block a traditional web browser, but web browsers are not the only clients available and some will be performing operations that are not necessarily in line with the wishes of your resources.
other browser vendors release new versions on a regular basis, regardless of the operating system number. This enables browser-related technologies to evolve at a more rapid pace. So please do us all a favor and stop locking major IE releases to Windows versions and just try to imitate what others do. We won't judge you for copying, promise.
Sincerely, Web developers
please stop arbitrarily bumping your version numbers so you don't have to hear complaints about open source contributions being ignored. Do you seriously expect us to believe you got through 25 real, full versions in 4.5 years?
Sincerely, "one guy not trying to talk for everyone".
Also, it wouldn't make sense for them to release new updates for officially out-of-support OS versions.
Direct2D. DirectWrite is old technology. Direct2D is used by IE9+.
http://msdn.microsoft.com/en-gb/library/windows/desktop/dd36...
Note the backport:
>Windows 7 or Windows Vista with Service Pack 2 (SP2) and Platform Update for Windows Vista
However, As someone who is locked into an app that is tied to IE 6-7, I don't relish the idea of being forced to re-write some 50,000+ lines of legacy code.
This does however force our customers to seriously consider putting out an effort to redesign in the first place.
You don't have to. Simply set the DOCTYPE to force IE7 quirks mode.
This move is clearly intended to improve compatibility with Internet applications.
Is that right or did I read the premise of this article completely wrong? I know you are right for IE 9/ IE 10, but if they change IE 11 to force us to redo our CSS then... that sucks (but is kinda good too cuz I hate the legacy crap code we have).
If you have an IE6-only intranet application, then by definition you are not depending on user-agent sniffing. In that case, you depend on the continued availability of quirks mode -- not on the user-agent string.
If you have an intranet application that uses user-agent sniffing to support both legacy IE and standards-compliant browsers, then you should simply do nothing. The change in the user-agent string will cause Internet Explorer 11 to be treated as a "like Gecko" browser. This is as it should be, as IE 11 is a standards-compliant browser.
To answer the second part of your question, it worked on IE 6/7/8 and removing the hacks would have required digging into old code. The meta tag was much quicker!
Are you being facetious? As far as users are concerned, IE would be broken. Users don't care that it's because of, say, websites with broken useragent sniffing.
I'm sure it's even more complicated than that, to be honest. But the overarching principle something Josh Bloch articulated. He said something to the effect that any interface that you publish, even if it includes strings (e.g. a pretty-printed stack trace), will inevitably become part of the interface.
anybody who's surfed with a changed user agent for a while care to comment?
Maker, product name and version should be good enough for everyone.
This is a little misleading. "Like Gecko" is not used in the Firefox UA String. It just says Gecko. "Like Gecko" is a component of Webkit-based browsers. So IE is emulating Webkit emulating Firefox, and dries the "MS" of "MSEI" for their string, and going with just "IE".
via Peter Paul-Koch: "IE11 to disguise itself as WebKit (and not Firefox!)", http://mobilism.nl/blog/2013/03/ie11-to-disguise-itself