Testers Say IE11 Includes 'Like Gecko' in User Agent String | Hacker News Reader

Testers Say IE11 Includes 'Like Gecko' in User Agent String

news.slashdot.org

60 pointssomethingnew65 comments

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?

[0] https://www.ietf.org/rfc/rfc2616

There are several situations where a web app has no choice but to rely on the user agent string to vary its behavior.

For example, when you let a user download a file, you usually send a header such as:

    Content-Disposition: attachment; filename=FILENAME

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.

Dear Microsoft,

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

Aren't they making releases faster with IE11 compared to earlier cycles of taking years between versions? IE10 is from 5 or 6 months ago.

I thought IE10 had the ability to auto-update?

Unless you're using Windows 7, in which case that was on Feb 23 (30 days ago.)

Is this because it is tied to Window Explorer (the Windows file system)? Or is it because the developers are dense.

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.

Out of mainstream support. See http://support.microsoft.com/lifecycle/

Yes. Extended support means no updates aside from security.

Dear Google,

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.

>For example, either IE10 or IE9 used DirectWrite

Direct2D. DirectWrite is old technology. Direct2D is used by IE9+.

No, they re-used a trademark. DirectWrite refers to their new text rendering subsystem:

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

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 +

Check what @ppk says: http://mobilism.nl/blog/2013/03/ie11-to-disguise-itself

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'".

The first versions of Safari had "like Gecko," so its WebKit heritage is long indeed. Maybe MSIE should use "sort of like Gecko" instead?

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?

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?

Good idea. I'd prefer it to be slightly more structured e.g. "Microsoft; Internet Explorer; 11.0"

Maker, product name and version should be good enough for everyone.

The syntax is [product/version (comment)?]+, so InternetExplorer/11.0 (like Gecko!) Windows/8 (like MacOS!;)

> 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?

Chrome?

> Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.40 Safari/537.31

I meant 'who does check that user agent', edited to clarify.

A lot of people, on Firefox OS we have a blacklist of sites we have to send Android like user agents to so we are served mobile friendly content: https://github.com/mozilla-b2g/gaia/blob/master/build/ua-ove...

Its a sad situation.

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.

For those who wonder how we ended up with such a mess of a user-agent string, this one is a classic: http://webaim.org/blog/user-agent-string-history

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.

[0] http://webaim.org/blog/user-agent-string-history/

> example of a modern application that checks against the user agent string?

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.

> 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].

1. Discussed around.

2. http://dev.opera.com/articles/view/opera-ua-string-changes/

Last I checked, Google+ had an User-Agent whitelist. Anything not in the list would get a "Your browser is too old, please upgrade" page.

"> 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".

via Peter Paul-Koch: "IE11 to disguise itself as WebKit (and not Firefox!)", http://mobilism.nl/blog/2013/03/ie11-to-disguise-itself

Wasn't it once that other browsers sent MSIE UA to look like IE? How times change.

Oh, wonderful, another quirks mode. The moment FF implements something that IE doesn't, we're right back into the shit.

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.

It still clearly identifies itself as "IE 11.0". They aren't trying to hide anything.

Because changing the user agent for this has worked to great effect before. /s

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.

Could you not just fix it? Or drop support for IE6/7/8 and only support the newer IE browsers?

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 you're checking versions and not features, you're doing it wrong.

Unfortunately, lots of stuff in HTTP headers and such can't be checked by feature detection. Additionally, you want your site to load fast.

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.

Really. How about iOS 6 safari having support for fixed elements that breaks every time the keyboard pops up?

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).

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.

> I don't relish the idea of being forced to re-write some 50,000+ lines of legacy code.

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.

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.

Thanks man! After doing some research on the User Agent (of which I was woefully uninformed) I've found out that I have more research to do...

I misread this and got excited thinking IE was going to drop Trident in favor of Gecko, in the same way Opera is switching to Webkit.

We will pile hacks on top of hacks until the web is indistinguishable from a very drunk and very angry magician.

April 1st already? I know I'm terrible at keeping track of time, but I could've sworn we were still about a week away x_x

Reply on news.ycombinator.com