Internet Explorer 7 User Agent String


Internet Explorer 7 Beta 1 is fast approaching.  A tiny but significant code change was checked in this week: Internet Explorer’s new User-Agent string. 

The User-Agent (or UA) string is sent along in the headers of every HTTP request so the server knows what type of browser is making the request.  For a quick introduction on handling of the User-Agent string, check out George Shephard’s article in MSDN Magazine.

Internet Explorer 7 User-Agent

As we updated the User-Agent, we considered application-compatibility issues, historical precedent, and feedback from the community.  We arrived at a very simple string.

IE7 running on Longhorn will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)

There are three points of interest in this string:

  1. We updated from 6.0 to 7.0 to reflect the new application version.
  2. Consistent with prior betas, a “b” was added following the 7.0, in order to flag this as a beta release.  This “b” will be removed for RTM.
  3. The “SV1” token was removed.  As predicted by the community, this token becomes redundant with the release of IE7.

What does this mean for web developers?

If you use ASP.NET’s HTTPBrowserCapabilities class on your pages, you’ll find that it is already able to correctly interpret the new UA string.  The class will return 7 for the MajorVersion property, and True for the Beta property.

Checks for the IE security features introduced in XP SP2 can be updated as follows:

    System.Web.HttpBrowserCapabilities browser = Request.Browser;
    bool isIESecurityEnhanced = (browser.Browser == “IE” && (browser.MajorVersion > 6 ||
        (browser.MajorVersion == 6 && Request.Headers[“User-Agent”] != null && Request.Headers[“User-Agent”].IndexOf(“SV1”)>-1)));

Can web developers test the new string out before IE7 Beta ships?

My first suggestion was to use a simple rule in Fiddler to change the outbound User-Agent header:

static function OnBeforeRequest(oSession:Fiddler.Session){
    oSession.oRequest[“User-Agent”] = “Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)”;
}

However, this will only report the new User-Agent to the web server; any script in the webpage that calls the navigator object to check the browser version will never notice this change.  Rats.

Fortunately, IE5.0 and later allow you to override the user-agent string used by scripting and sent by the browser.

Simply save the following as IE7UA.REG.  Double-click the file to merge it into your registry and restart the browser to see the change.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet Settings5.0User Agent]
“Version”=”MSIE 7.0b”

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsUser AgentPost Platform]
“SV1″=-

You can easily undo the change by saving and merging the following IE7Undo.reg.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet Settings5.0User Agent]
“Version”=-

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsUser AgentPost Platform]
“SV1″=””

You can test the change using a simple page that echos the User-Agent, e.g.: http://www.fiddlertool.com/useragent.aspx.

-Eric Lawrence

Comments (154)

  1. Anonymous says:

    I admit I was a little concerned about the SV1 token but the 7.0 user agent couldn’t be better. Nice work!

  2. Anonymous says:

    Many web developer believe interpreting the UA string is bad pratice – mostly due to be unreliable and also unnecessary. And when ist it is done, it is usually to overcome incompatibility between different browsers. So is this article saying: IE7 is (still) incompatibile to web standards and requires hacking around interpreting the UA string to make things work?

  3. Anonymous says:

    And what about the Http-Accept header ?

  4. Anonymous says:

    IE ist NOT Mozilla!!!

    IE/7.0 (Windows NT 6.0)

    would be correct (or something like this)

  5. Anonymous says:

    Perhaps this is their way of telling us that there is Mozilla code in there somewhere? Doubtful, I know, but hey…

  6. Anonymous says:

    Ok, ignore my ignorance. I only noticed that Mozilla 4.0 was a part of the user agent string since IE5.

  7. Anonymous says:

    Ok, but why use the string Mozilla/4.0 in IE UA string ?

  8. Anonymous says:

    I really wish you guys would strip the Mozilla stuff from the user-agent, I mean lets face it IE is not Mozilla, this is one of those silly things left over from the browser wars years and years ago.

    Come on guys, stand up and be proud annouce yourselves with your own name! ;o)

  9. Anonymous says:

    I found why there is Mozilla in IE’s user agent string here:

    http://webtips.dan.info/brand-x/useragent.html

  10. Anonymous says:

    Yes, I’m also thinking about the http-accept rule. Are you still going to pretend that IE7 is able to process */* (although obviously, it’s not)?

    Speaking about mozilla4.0, I believe it is because, a long time ago, IE was produced using part of the mozilla code. So recognizing it would be a good thing.

    And yes ! Why are you already preparing to make it possible to identify correctly the browser ! *This is bad practices*, you know it. So, just try not to encourage people doing it, it seems to me that time coding n different pages for n diffent browser is already past !

    Just code your page so as to be readable and not too bad is the old browser, and just wait the old browser vendor like IE5.5 ou IE6 to upgrade their bad product.

  11. Anonymous says:

    There are sooo many sites and tools done by narrow-minded people (including ASP, eh…) that now browsing with other "incompatible" User-Agent string doesn’t make sense.

    UA is a last resort for bug workarounds, not primary way of detecting browser capabilities. This rule has been broken, and there you go – more broken stuff follows.

    Proposed UA is only sensible solution. They could add registry tweak that changes UA to "Internet Explorer/7.0", so kamikaze fans could use it.

  12. Anonymous says:

    Why not have some sort of user switching? Identify using the correct IE string by default but give people the chance to change back to the Mozilla string if they need to?

    It works for Opera.

  13. Anonymous says:

    Admittedly, I’ve got no idea what all that "IE7UA.REG" bit means, so forgive my ignorance.

    Will this new UA string work with IE’s conditional comments? So that developers can sniff out IE 7 (and it’s beta’s) if need be, as has previously been possible in IE?

    Also, where you said "IE7 running on Longhorn will send …", did you mean to say XP, or is a different UA string planned for XP?

    Again, please forgive my ignorance if these are obvious questions with obvious answers.

  14. Anonymous says:

    IE7 running on Windows XP would send "Windows NT 5.1" in place of the one above, if I am not mistaken.

  15. Anonymous says:

    I believe IE7 on XP will produce Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1)

    and on XP x64/Server 2003 Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.2)

  16. Anonymous says:

    Lets see… dissection time:

    Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)

    a) IE is not Mozilla… get over it

    b) Mozilla/5.0 is standards compliant, Mozilla/4.0 isn’t, I think this says something

    c) "compatible" uh-oh… so you’re keeping all the bugs IE5.5/6 had then?

    d) NT6.0? I thought you said IE7 would be available for WindowsXP users.

  17. Anonymous says:

    I think the "Windows NT 6.0" part is just here to provide an example.

  18. Anonymous says:

    The reason for mozilla is historical. Back in the day when IE1 was out, websites checked for "mozilla" and gave them a snazzy version. Microsoft found out that they were getting the ugly version, despite the fact that the advanced version worked fine. So in IE2 they made it look like Mozilla in order to get the good pages.

    Very antiquated nowadays, but the intertia is enormous, and lots of scripts look for the entire UA string, including the Mozilla/4.0. So removing is not an option.

    MSIE was never based on mozilla, it was based off Mosaic, via spyglass. Look at the about page and they still credit Spyglass!

  19. Anonymous says:

    UA string is just unusable (just check an Apache or an IIS log to get an idea). But what about conditional comments ? My XHTML assume [if lte IE 7], is it OK?

    By the way the old Mozilla/4.0 string is very revealing and during that time… http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008042

  20. Anonymous says:

    Instead of talking about this minor stuff, why don’t you go to coding? Lots of thing need to be fixed.

  21. Anonymous says:

    > MSIE was never based on mozilla, it was based off Mosaic, via spyglass. Look at the about page and they still credit Spyglass!

    Partially correct. According to Wikipedia (http://en.wikipedia.org/wiki/Mosaic_%28web_browser%29):

    > Spyglass licensed the technology and trademarks from NCSA for producing their own web browser but never used any of the NCSA Mosaic source code. (http://biztech.ericsink.com/Browser_Wars.html) Spyglass Mosaic was later licensed by Microsoft, and it was modified and renamed Internet Explorer.

  22. Anonymous says:

    Have you thought of the implications of dropping the Mozilla/4.0 part off of the UA string? Do sites still use validation against this part of the string anymore? If not, it would seem like a great time to drop it.

  23. Anonymous says:

    i disagree with robin on post

    http://blogs.msdn.com/ie/archive/2005/04/27/412813.aspx#412856

    it’s incorrect for you to assume that IE doesnt support webstands, all browsers have their own bugs, and some may not be discovered for a while!

    however, UA string detection is probably the wrong way to go about things… browser capability tests should be used instead

    software is never perfect, so a unique userstring would be handy for certain situations.

    it’s also useful for site logs, to check UA penetration in the browser-market

  24. Anonymous says:

    much of the web still relies on the mozilla parameter, and so leaving this out would cause a handful of sites to fail… it’s not an option for the IE team

    people concerned about CSS hacks… what have we not learnt about hacks?

    it seems ironic that people criticise the IE team for using a ‘mozilla’ hack in their UAString, but continue to use CSS hacks to browser-sniff

    ultimately, it’s the webdevelopers that have ruined the web now. we had to use hacks to negotiate the standardless-browsers… and now the browser makers have to negotiate our non-standard code!

    the lesson learnt… ?

  25. Anonymous says:

    Isn’t it about time you used a proper UA – one that doesn’t contain ‘Mozilla’.

    We know why it was used in the past – that was a decade ago.

    Fix your UA – and if people’s scripts fail with the new browser – then they should update them – after all – they’re not going to stop working with the old versions of IE.

    You can’t keep supporting people who think it’s still 1995. Life moves on. Proper sites no longer sniff UA’s to see if the browser is "IE or NetScape 4" – these days there are many browsers on all sorts of devices.

  26. Anonymous says:

    All of you complaining about the ‘mozilla’ useragent prefix would be wise to modify your UA string in the way outlined above and spend a week browsing the web. I expect you will see a whole host of problems. Would you expect Microsoft to produce such an incompatible product that legions of end users are up in arms and defect to a competitor?

  27. Anonymous says:

    To all the stupid noobs who’ve contributed to the comments here, the fact the words "Mozilla" is part of the UA is no referrence to the current Mozilla project/browser. "Mozilla" was in fact the codename of the original Netscape browser, and is a pun of Mosaic Killer, which is what NS did.

    Now, in the original browser wars – when NS was much much better than IE (version 2 sucked big time) – web developers used to redirect browsers which did not detect Mozilla as part of the UA, hence MS included it so as not be left out. Fair play, though, since excluding certain browsers is just not good accessibility practice.

    However, now that we’re over that – there are other ways to reject browsers anyway – perhaps it is time for MS to remove "Mozilla" from the UA. After all, given the hoo-ha about Mozilla being superior on the CSS front, it was IE which introduced the web development community to the power of CSS in IE3, long before NS ditched the rather powerful-if-also-cumbersome Javascript Stylesheets (JSS).

  28. Anonymous says:

    jbot, we know about that, don’t think you know all, and others not.

  29. Anonymous says:

    Great. Now when will you fix the box model bug?

  30. UnexpectedBill says:

    First off, did anyone else find it…complicated to get in here and post comments?

    That said, I’m really looking forward to the beta release of IE7. I have arranged to get an XP computer around to test it.

    However, while I see the effort being put into "proper" PNG support and even revisions to CSS, I don’t see much talk about Windows 2000 support or backporting efforts. This bothers me greatly. I’m administering a bunch of computers for a company and we’re just not ready or particularly interested in upgrading to XP at this point. I don’t have a great fondness for Windows XP. I really hope that even while nothing is being said that Windows 2000 support for IE7 is being seriously considered.

    It was my hope that the first beta would run on Windows 2000. Now it doesn’t look like that will happen.

    In regards to Diggory Laycock’s earlier comment about the Mozilla/4.0 portion of the user-agent string…yes, I agree that it was "ten years ago". However, I do take exception to the part about not supporting people who think it is still 1995. Webservers aren’t people–and there are more than a few that have more or less gone to autopilot-like operation. Some webservers are still living in 1995 and nothing will be done about it. Someone is keeping the power turned on and paying for the connection no doubt–but nobody is really updating the content any longer. These are certainly a minority but even then I don’t see a reason to break compatibility with them.

  31. Anonymous says:

    I know this is a bit OT, but has there been any success in getting IE 7 to render the Acid2 (http://webstandards.org/act/acid2/)test? This would be a great time to work towards that.

  32. Anonymous says:

    That’s too minor to refect.

    Any really interesting changes?

  33. Anonymous says:

    <<Instead of talking about this minor stuff, why don’t you go to coding? Lots of thing need to be fixed.>>

    As stated at the very beginning, "A tiny but significant code change" was made. It’s tiny for us on the IE team, but it has a non-trivial impact on websites. If sites are coded not to accept that IE7 is a later version of IE6, they often break. There are quite a few sites like this out there.

    Hence, we’re providing early notice of the change so you can test your sites even before beta if you’d like.

  34. Anonymous says:

    Please remove "Mozilla/4.0" from the User-Agent string.

    IE on Windows is the largest browser out there. 90% or more of web developers respect it when designing sites, thus you have a great oppertunity here to use a proper UA string which doesn’t claim to be someone else! People who do UA string sniffing check for ‘MSIE’ anyway, so having Mozilla in there just makes things unnecessarilly complicated in our log files. Please, do the Right Thingโ„ข.

    I suggest "MSIE/7.0b (Windows NT 6.0)" (the ‘compatable’ bit is not necessary either these days, perhaps so in 1997 but we have moved on since then, one would hope).

  35. Anonymous says:

    I just wanted to add another positive voice – thanks for all the work your team is doing on IE 7. I’m in the quiet bunch that hasn’t defected to Firefox (yes, I tried Firefox; please, no flames). IE has its bugs, but what large piece of software doesn’t? As a fellow software engineer I believe in your commitment to high quality and backward compatibility, both of which are important. I’m sure the IE team is overcoming many obstacles none of us on the outside can truly appreciate.

    I look forward to reading more about IE development from the inside and to exploring the beta!

  36. Anonymous says:

    Thanks Eric – good to know in advance.

    I’m told that IE7 will fix a lot of bugs, which means we’ll have to write our CSS with a few CSS workarounds so that hacks etc will get picked up in IE6, but not 7.

    In the past we’ve used a lot of standard hacks, like using ‘!important’ with duplicate rules, and the Mac comment hiding markup.

    Using the user-agent, I could get my server to output a new stylesheet for IE7, but it would be better to keep my rules together.

    With this in mind, can we have a way to markup CSS for IE7 only? This is not as daft as it sounds – Mozilla had -moz additions for new (non-standard) rules like opacity.

    I’d suggest:

    +ie7 attribute-name:red; /* ie7 only rule */

    -ie7 attribute-name:blue; /* ie7 ignores this */

    However, I can’t see a way to retrospectively add the first – but the second ‘ignore’ rule would be very useful.

    More document-focused readers may know a standards compliant way to do this – is there a way to target specific browsers?

  37. PatriotB says:

    Windows NT 6.0. Has a good sound to it. Would make a good, simple product name for Longhorn. ๐Ÿ™‚ Enough with these year-names (which quickly get outdated). (Good thing XP wasn’t called Windows 2001, would make it seem even older nowadays).

  38. Anonymous says:

    "With this in mind, can we have a way to markup CSS for IE7 only? This is not as daft as it sounds – Mozilla had -moz additions for new (non-standard) rules like opacity."

    I’d have no problems with IE having vendor-specific extensions, but they should do it properly. Also, many of those "non-standard" rules are actually testing versions of CSS3 (like opacity).

    Vendor-specific extensions

    http://www.w3.org/TR/CSS21/syndata.html#q4

    CSS3: Opacity

    http://www.w3.org/TR/2003/CR-css3-color-20030514/#transparency

  39. Anonymous says:

    I also would vote to drop this "Mozilla/4.0 (compatible; …)" notation.

    How long should this go on? If all browsers in the future include this string, it’s simply redundant information and could also be dropped.

    Of course it’s for the sake of compability, but it gets worse with the time: The code fragments needed to determine the browser version becoming more and more unnecessarily complex. All these functions will have to be touched after MSIE 7.0 is released anyways.

    So adopting for a proper "MSIE/7.0 (NT 6.0; …)" string might make this even a bit easier for everyone.

    Sooner or later this disguise-as-Mozilla-madness has to end – the sooner the better. In the long term, everyone will benefit from this …

  40. Anonymous says:

    Trying to steal something from the Firefox winning browser, even only a part of the name, ridiculous :p

    It’s NOT Mozilla, why use that?

    So, Windows will always BE based on the very OLD sucking "Windows NT" for the next 1000000 centuries.

    Stop calling it NT 5.1, NT 6, NT 6.1, NT 6.2, NT 7 etc. makes no sense.

    Try to abandon the NT words…..

    That’s my opinion.

  41. Anonymous says:

    @Kenneth:

    The easiest and most efficient way to provide CSS hacks for various IE versions, which amy include everything from box-model hacks for IE 5/5.5 to other bugs in IE 6.0 is to use conditional comments.

    More info here: http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp

  42. Anonymous says:

    Good question about the conditional comments! My .REG scripts weren’t quite complete; you need to update one more registry key to simulate IE7 for conditional comments.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerVersion Vector]

    "IE"="7.0000"

  43. Anonymous says:

    Stole from Firefox? Hardly. If you read the comments you’d understand it happened 10 years ago. Firefox wasn’t even a wet dream in a developer’s head back then.

    I think MS should test dropping the Mozilla part of the user agent but if it breaks too many sites, I know for a fact they won’t change it. They care a LOT about backwards compatibility (I would say too much to a degree but luckily it doesn’t trump security). They’re not going to break a bunch of websites just because people wanted IE to reflect "the truth". Eventually things will have to break due to all the hacks and rehacks that have been done over the years. I just hope MS realizes this at some point in time because the hacks for the hacks are starting to be a little too much. Does this desperately need to change for IE7? I don’t think so but it should be on the radar possibly introduced with Longhorn since you’re already going to break a little bit with that OS, might as well do some spring cleaning while you’re at it.

  44. Anonymous says:

    Please, do change the user-agent string to remove "Mozilla". It’s not that I care anything about IE (seeing how obsolete and unfriendly it is), but I’d like to see it changed in other browsers too, and if IE did it the rest of them could all do it at the same time.

  45. Anonymous says:

    Better idea:

    Why not get IE7 to make two requests… one with the "proper" IE/7.0 UA string, and again with the Mozilla/4.0 string… if it detects different checksums or hashes between responses, then it goes with the Mozilla/4.0 one, else it sticks with IE7.0

    Besides… does /anyone/ still sniff for "Mozilla/4.0" anymore anyway? Name ONE website, IEBlog, just one…

    If anything, they’re sniffing for non-IE browsers so they can serve them up-level content.

  46. Anonymous says:

    ^^ Argh, that is stupid.

    Leave User-Agent string alone. Leave Mozilla alone.

    Instead consider user-friendly Settings dialog with compatibility options. Its concept hasn’t changed since IE1.

  47. Anonymous says:

    <<Why not get IE7 to make two requests… one with the "proper" IE/7.0 UA string, and again with the Mozilla/4.0 string… if it detects different checksums or hashes between responses, then it goes with the Mozilla/4.0 one, else it sticks with IE7.0>>

    I assume you’re kidding. This would be unbelievably horrendous for performance.

    <<Besides… does /anyone/ still sniff for "Mozilla/4.0" anymore anyway? Name ONE website, IEBlog, just one… >>

    Yes, most browser detection classes do sniff for this string. ASPNET’s BrowserCapabilities object, for one, would no longer see this as IE without code changes.

  48. Anonymous says:

    Eric Lawrence:

    <<<Simply save the following as IE7UA.REG. Double-click the file to merge it into your registry and restart the browser to see the change.>>>

    Just out of interest, is a .REG file a method for editing the registry? So where you say "Double-click the file to merge", does this simply mean that double clicking the .REG file will execute it and apply the registry settings within that file to the registry itself?

    Thanks for any clarification (I’ve never heard of .REG files until now).

  49. Anonymous says:

    What everbody has failed to mention so far is that according the the HTTP spec everything in parenthesis is a comment and technically can be ingnored, thus the only string that should be used for interpretation should be ‘Mozilla/4.0’ which is clearly wrong.

  50. PatriotB says:

    Chris H:

    That’s correct, .reg files are used to edit the registry. Double-clicking them will (after prompting you for confirmation) apply the changes to the registry. (Assuming, in this case, that you have admin security in order to edit HKEY_LOCAL_MACHINE.)

  51. Anonymous says:

    Yep, how about

    InternetExplorer/7.0 (winxp; …)

    because the product in question is Internet Explorer, not Netscape 4 (eventough the standards support is on the same level).

    Eric Lawrence: easier way might be typing

    javascript:alert(navigator.userAgent);

    to the address bar and pressing enter.

  52. Anonymous says:

    Perhaps if people start using UA-sniffing for "Mozilla/4.0" to indicate "NS4, can’t support CSS1 properly, give it plain HTML" the devs would rethink their position.

  53. PatriotB says:

    Samuel: That’s an easy way to display the user agent being used. What Eric is showing is how to test for IE7 within ASP.NET, and how to edit your registry to modify the user agent that’s shown.

  54. Anonymous says:

    <<according the the HTTP spec everything in parenthesis is a comment and technically can be ignored>>

    I believe you’ve misread the spec. Section 14.43 of RFC2616 (http://www.faqs.org/rfcs/rfc2616.html) states that the data in the parenthesis is either a comment, OR a product.

    There’s nothing in the RFC that indicates that this data is ignorable, although there are also not requirements to respect ANY part of the user agent header.

  55. Anonymous says:

    Thanks for the note on the blocking of IE7 at our chat site, Colin. I’ve contacted the site owner.

  56. Anonymous says:

    > Perhaps if people start using UA-sniffing for "Mozilla/4.0" to indicate "NS4, can’t support CSS1 properly, give it plain HTML" the devs would rethink their position.

    > ant

    I rather like that idea, but why stop there? Lying in user agent strings is bad, so why not return ugly content to all user agents that provide known fraudulent user agent strings? Or partial content? Or just disapproving comments?

    Any page that breaks because of a new user agent string is a page that does not deserve to be read. Still, I am glad that you are releasing your user agent string–deceptive and poorly decided as it is–so people can plan and test for it in advance. I wish user agent sniffing were not necessary, but since it is a necessary evil, it seems better to know what is coming now rather than later.

    That all said, I would like to share my thoughts on the issue of how Internet Explorer handles broken content. Web developers are demanding of browser developers, so why not be demanding of Web developers in return? As a Web developer, I invite you–no, I *IMPLORE* you–to show NO MERCY WHATSOEVER for invalid code of any kind. I *WANT* user agents to yell at me and pull three fingers and a thumb in if I make a mistake. Perfect code is my goal; if I fall short of that goal, please help me correct my mistakes and reach it by *NOT* telling me that I have succeeded when I have not. Garbage is garbage. If browser developers would treat garbage code as it deserves to be treated–by refusing to use it–the Web as a whole would be in much better shape.

  57. Anonymous says:

    Luckily HTML and CSS, JavaScript can be programmed to degrade gracefully. There should be no need to change the meaning of the content (which HTML descibes) depending on through what kind of glasses the user views it.

    The easy steps are

    – Write the HTML to describe the content, headlines with h?, paragraphs with p, quotes with blockquote, cite and q, et cetera

    – Make several style sheets for different mediatypes (screen, print and handheld) which flow the page layout differently and hide portions of content if necessary. For example, for print layout you don’t need the navigation, just the article in question.

    Sharp-eyed people might notice that this is what ASP.NET does wrong, for example on its default configuration, the text writer changes DIV elements to TABLEs, which is totally retarded. Fortunately one can configure the browser detection as it should:

    <system.web>

    <browserCaps>tagWriter=System.Web.UI.HtmlTextWriter</browserCaps>

    <!– … –>

    </system.web

  58. Anonymous says:

    I think this is a mistake.

    You should leave the UA as it is and introduce new XML schema for communicating this information.

  59. Anonymous says:

    >> Write the HTML to describe the content, headlines with h?, paragraphs with p, quotes with blockquote, cite and q, et cetera

    You might want to rethink that – IIRC <q> is one of the several HTML4 tags that IE doesn’t support correctly/at all.

  60. Anonymous says:

    Hello, I know this isn’t the right place to post this, but I need to know if there will be any development and work on the hover pseudo element in CSS for tags other than an anchor tag, I’d appreciate any response about it. Thanks, and hopefully I can remember this place so I can get back to it, lol.

  61. Anonymous says:

    Eric,

    I was wondering what your take on the whole Mozilla in the UA was and what you think the fallout would be if it were changed.

    Thanks

  62. Anonymous says:

    <<I was wondering what your take on the whole Mozilla in the UA was and what you think the fallout would be if it were changed.>>

    Well, the biggest problem is that a TON of sites that work correctly today would stop working.

    For better or worse, the HTTPBrowserCapabilities class in ASPNET (as well as plenty of third-party code of similar purpose) expects an IE browser to send in Mozilla/4.0 as the start of the UA string.

    As noted above, you could play with this yourself by writing a Fiddler rule– I’ve found that quite a few sites fail to work correctly.

    So, in order to pull this off, we’d have to put our customers in a lot of pain, for very questionable benefits (e.g. saving a few bytes over the wire).

  63. Anonymous says:

    So, you think now as we move to longhorn it is a bad time to clean up ones act and it is ok continue misbehaving to the eternity. Do you think it becomes easier to fix this in the future?

  64. Anonymous says:

    See what happen when you don’t use recomendations you make with others groups.

    You are forced of using a UA hack for your passed mistakes.

    Respects the standards, don’t use IE special JS/CSS/HTML codes specifics, and you will have a better Internet, for you and for all people.

  65. Anonymous says:

    Eric,

    Just out of curiosity, if web sites werenโ€™t so reliant on the Mozilla UA string being part of the IE UA, what sting would you have gone for, if you did in fact consider a fresh one?

    Also, have you considered altering the "HTTP ACCEPT" header to reflect IE 7โ€™s true abilities?

  66. Anonymous says:

    <<what string would you have gone for, if you did in fact consider a fresh one?>>

    In a world where compatibility didn’t matter, I’d say that:

    IE/7.0 (NT 6.0; …)

    would have been my choice.

    << have you considered altering the "HTTP ACCEPT" header to reflect IE 7โ€™s true abilities?>>

    Well, ACCEPT doesn’t necessarily do everything that User-Agent does. For better or worse, user-agent is used to track browser metrics, workaround user-agent limitations, indicate the bitness (16/32/64) of the platform, and so on. Updating ACCEPT wouldn’t really help there.

    It’s also unclear how practical ACCEPT really is for its stated purpose: "Accept headers can be used to indicate that the request is specifically limited to a small set of desired types"

    The problem is that the request is only very rarely limited to a "small set" of desired types… Most modern browsers can handle at least dozens of MIME types, and sending them all in the ACCEPT header entails a bandwidth cost on every request for a questionable benefit.

  67. Anonymous says:

    @ Eric :

    Just look at FireFox’s Http-Accept header : text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

    It just tells what type of pages does it accept (there’s just an exception with image/png).

    With this, we can use content-negociation to send web pages with the correct XHTML MIME type (ie application/xhtml+xml) to user agents that supports it). If the header contains ‘application/xhtml+xml’ (with a higher q-rating than text/html), send the page with this type, and enjoy full-compliant XHTML.

    Now, imagine IE7 supports the XHTML MIME type. And imagine it has only */* in his Http-Accept header. How may we detect that it supports the XHTML MIME type ? A content-negociation script will not be able to see that the user agent supports the right type, and will send pages with the compatible type (text/html)…

    So we will need to rely on user agent sniffing… Pretty bad ๐Ÿ˜‰

  68. Anonymous says:

    <<It just tells what type of pages does it accept>>

    Yes, although as you observe, it’s a somewhat random subset of the supported MIME types. Internet Explorer supports HTML, Text, XML, all of the Office document formats, the vast majority of image formats, and dozens and dozens of other formats added by extensibility.

    Furthermore the weighting system is broken. Consider the following Firefox request:

    GET /foo.png HTTP/1.1

    Host: http://www.bayden.com

    Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

    Why should a request for foo.png indicate that it prefers to receive text/xml over image/png? How should a server interpret this request?

    And that’s just the easy case– what should be sent when no file extension is present on the URL?

  69. Anonymous says:

    @Eric :

    There is of course little reasons to have image/png in Http-Accept.

    But as I said, how can I do content-negociation if the user agent doesn’t tell me some basic types it accepts ?

  70. Anonymous says:

    > Why should a request for foo.png indicate that it prefers to receive text/xml over image/png?

    File extensions are meaningless on the web. /foo.png could be HTML, a Word document, Flash, anything. If I configure my server to have multiple resources available at /foo.png, then I don’t want the browser to second guess me. While it may be probable that the resource is image/png, you shouldn’t assume it.

    IIRC, one SEO technique is to separate keywords in the URI with periods. The URI http://www.example.com/reasons.to.use.jpeg.instead.of.png is perfectly valid and there is nothing wrong with it referring to a text/html document.

    I suspect image/png is present in the generic Firefox Accept header merely to indicate preference over image/gif. I wouldn’t have bothered, personally, not for generic requests.

    Don’t be fooled into thinking this is the Accept header sent by Firefox when it wants an image. This is merely the Accept header sent for generic requests. When it actually has a valid reason to not request types like text/xml (and pulling magic letters out of the URI is not a valid reason), then it does not do so.

    > And that’s just the easy case– what should be sent when no file extension is present on the URL?

    Please stop thinking in terms of file extensions. They aren’t something an HTTP client should deal with.

    What should be sent when no file extension is present? Whatever you normally send. There should be no difference between a generic request for a URI that happens to end in "/document.foo" and a generic request for a URL that happens to end in "/document".

    On a related note, are you going to fix the bug that sends an Accept: */* header when you hit refresh?

  71. Anonymous says:

    I’m well aware of the fact that "file extensions" on the web can be misleading– I should have been more clear on this point.

    <<Don’t be fooled into thinking this is the Accept header sent by Firefox when it wants an image.>>

    For images, it ACCEPTs: image/png; */* q=.5

    It’s hard to argue that this is much of an improvement.

    <<Whatever you normally send.>>

    What do you propose is the correct subset of the dozens or hundreds of supported MIME types that should be announced via this header?

  72. Anonymous says:

    I apologize for not posting much lately. I have the next installment of JavaScript 101 almost ready and…

  73. Anonymous says:

    > For images, it ACCEPTs: image/png; */* q=.5

    > It’s hard to argue that this is much of an improvement.

    Your point was that Firefox was broken for asking for text/xml in preference to image/png. But in the context of loading an image, it doesn’t do that, and in the context of opening a generic URI, that isn’t broken behaviour.

    > What do you propose is the correct subset of the dozens or hundreds of supported MIME types that should be announced via this header?

    The ones that will be useful in content negotiation – basically, the ones that are likely to be chosen over other alternatives, or are likely to be commonplace on the web.

    For instance, the fact that Internet Explorer can handle BMPs isn’t likely to be useful to web developers in practice – how often is it that they’ll want to send BMP when an alternative is available? When when BMP is the only resource available, the server will see the */* and still be able to provide it.

    I have no real complaint with the initial Accept header as it stands now – just the bug on refresh. I do think it wuld be a step backwards and another source of frustration if you start modifying your Accept header based on file extensions you think you see in the URI though.

  74. Anonymous says:

    The */* in Firefox is more of a last resort (hence the q=0.5), unlike the Accept header IE sends which gives everything including "*/*" equal weighting (and doesn’t mention text/html at all?!)

  75. Anonymous says:

    Jim, could you give me a site that serves different content for different Accept tokens?

    The only use I see for this is for text based browsers asking for plain/text respondes.

    Since both ie and firefox support *almost* any format on the web, why should they worry about asking for a specific response type?

  76. Anonymous says:

    Eric,

    I would like to show appreciation for your active participation in this blog and forum.

    You put up with a lot of crap from people and yet you always post a calm and informed view.

    Thanks

  77. Anonymous says:

    > Jim, could you give me a site that serves different content for different Accept tokens?

    There are loads of them. Practically every site that uses application/xhtml+xml, for instance. This is the whole purpose of the Accept header. If you need an example, the W3C does it.

    > The only use I see for this is for text based browsers asking for plain/text respondes.

    Text-based browsers don’t want text/plain, they want text/html.

    There are loads of reasons why content negotiation is useful. It’s basically impossible to use XHTML properly unless you use conneg. The same went for PNG a few years back. The same will apply to SVG in the future (if not already).

    > Since both ie and firefox support *almost* any format on the web

    I would love it if this were true, but unfortunately it isn’t, not by a long shot.

    > why should they worry about asking for a specific response type?

    Because even if they support multiple media types, it doesn’t mean that they don’t care which they get.

    For instance, where there is a choice of SVG and PNG available, even if the browser can handle both perfectly, it will want to tell the server that it prefers the scalable image.

  78. Anonymous says:

    This Accept header would be good for IE7 (assuming IE7 fully supports PNG and doesn’t support application/xhtml+xml at all):

    Accept: text/html,text/plain,text/css,text/xml;q=0.7,text/x-xslt,text/javascript,text/vbscript,image/png,image/gif,image/jpeg,image/pjpeg,*/*;q=0.2

    You can add Office types to this header.

    This is needed for content negotiation.

    text/xml is 0.7 because IE doesn’t support XHTML in that MIME-type (only displays source)

    */* is 0.2 because IE can’t display these types (only save to disk or open in external application)

  79. Anonymous says:

    Hi

    Can you please tell E-Eye to remove the lies they are spreading about Internet Explorer security holes:

    http://www.eeye.com/html/research/upcoming/index.html

    Monthly security patches were issued _after_ the first two were disclosed, but they are still saying "unpatched" on that page!

    Saying ‘Microsoft leaves security holes unpatched for 2 months’ is typical of the sort of lie that the FireFox kiddies will use to try to unfairly discredit Microsoft’s security record.

  80. Anonymous says:

    If you want to save bandwidth, you can send:

    Accept: text/css when downloading stylesheets,

    Accept: image/png,image/gif,image/jpeg,image/pjpeg when downloading images,

    Accept: text/javascript,text/vbscript when downloading scripts

    and Accept: text/html,text/plain,text/css,text/xml;q=0.7,text/x-xslt,*/*;q=0.2 when downloading documents/files.

  81. Anonymous says:

    Thanks for the suggestions about the Accept header. I’ll look into this.

  82. Anonymous says:

    "Internet Explorer 7 Beta 1 is fast approaching." so when would we be expecting the release of this beta?

    Also if IE uses Mozilla’s code, then why the hell didn’t you guys implement Mozilla’s PNG support into IE??? would have saved years of frustration and higher quality of web interfaces. It’s good to here that PNG works though

  83. Anonymous says:

    <<Also if IE uses Mozilla’s code>>

    It doesn’t. Don’t believe everything you read.

  84. Anonymous says:

    One thing that really strucked me:

    Why do so many people write about things they don’t really understand. There should be a requirement of understending UA string and it’s history as well as client/server side scripting before posting…

    @Eric: Is there any distant possibility that IE7 will provide some UA string changing mechanism, like that in Opera browser. This would make kids happy – IE introduces itself as Mozilla/4.0 (compatible;… OR IE7.

  85. Anonymous says:

    Would this work for the majority of UA checkers?

    MSIE/7.0 (compatiable; Mozilla/4.0; Windows NT 6.0)

    It should, if it’s just doing a string-in-string check.

  86. Anonymous says:

    "@Eric: Is there any distant possibility that IE7 will provide some UA string changing mechanism, like that in Opera browser."

    That sounds pretty unlikely to me. Besides, the statistical mess that Opera has created by defaulting as IE is not something to strive for.

  87. Anonymous says:

    There have been many comments about the unreliability of UA sniffing in this post already,

    but I was sufficiently amused by the results of my having clicked on the Fiddler link to post it here.

    I’m definitely an outlier as far as browsing goes, but I sure hope people use a little common sense and if they use UA sniffing to disable site capabilities, also offer links to alternate pages as well.

    โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€

    The browser sent the following headers:

    โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€

    Connection=keep-alive

    Accept=text/*, image/*, application/*, audio/*, message/*, video/*, */*

    Accept-Encoding=gzip, compress, bzip, bzip2, deflate

    Accept-Language=en;q=1.0

    Host=www.fiddlertool.com

    Referer=http://blogs.msdn.com/ie/default.aspx

    User-Agent=w3m/0.5.1

    โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€

    ASPNET’s HTTPBrowserCapabilities object reports that based on the User-Agent, your Browser has the

    following capabilities:

    โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€

    Type = Unknown

    Name = Unknown

    Version = 0.0

    Major Version = 0

    Minor Version = 0

    Platform = Unknown

    Is Beta = False

    Is Crawler = False

    Is AOL = False

    Is Win16 = False

    Is Win32 = False

    Supports Frames = False

    Supports Tables = False

    Supports Cookies = False

    Supports VBScript = False

    Supports JavaScript = False

    Supports Java Applets = False

    Supports ActiveX Controls = False

  88. Anonymous says:

    Regarding the Accept header, it’s actually not a silly idea to disallow types that are not supported in the context they’re used in.

    I.e. if you are using an ‘img’ tag then it’s not sane to return non-image data, so specifying */* anywhere in the accept header is not sane (but image/* is).

    Similarly, most HTML objects that reference a URI like ‘link’, ‘object’, ‘a’, etc. allow a content type to be specified with them. In these cases, the browser knows what type to accept and anything else is invalid so it should send that type in the accept header. (I don’t think any browsers do this ATM but it would be a Good Thing IMHO).

    By supplying this kind of contextual accept header it also allows error messages, etc to be served in an appropriate type – for example, if you get a 404 most servers will just send a text/html error but with an appropriate accept header the server could send the error message as a PNG if the 404 happened when the browser was downloading an object referenced by the ‘img’ tag.

    However, if IE7 _does_ support XHTML 1.1 (please tell me it does), you definately need to supply the application/xml+xhtml type in the accepts header so that web servers know to send the content with the correct header.

    For the most part, the current implementation of accept is not very useful. It would be more useful to supply separate lists for types that are handled in the browser, types that are handled through plugins and types that are saved to disk. As you rightly point out, sending the web server a list of *every* supported mime type is unfeasable since the list would be huge – in the long run it might be better to provide a challenge-response model whereby the server can ask the browser for information about the supported mime types and then store it server-side for future reference (linking it with the browser through a SID stored in a cookie, for example). Of course that’s something for the W3C to think about. ๐Ÿ™‚

    It’s good to see active development on IE once again – as a web developer who has cursed IE with every web page I write I hope IE7 is all that is promised.

  89. Anonymous says:

    Steve, I agree almost completely with everything you say, but:

    > I.e. if you are using an ‘img’ tag then it’s not sane to return non-image data, so specifying */* anywhere in the accept header is not sane (but image/* is).

    In this specific instance, this would exclude video/x-mng. As far as I know, Internet Explorer 7.0 won’t support this image type, but it’s something to bear in mind. Perhaps a video/* or */* with a low quality weighting would be appropriate too in this particular instance.

  90. Anonymous says:

    IEBlog : Internet Explorer 7 User Agent String My first suggestion was to use a simple rule in Fiddler to change the outbound User-Agent header: static function OnBeforeRequest(oSession:Fiddler.Session){ oSession.oRequest[&quot;User-Agent&quot;] = &quot;Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)&quot;; } As it…

  91. Anonymous says:

    He said the new version will be built on the work they did in SP2, and other things. Gates mentioned they will go further to defend IE users from phishing and other deceptive software.

  92. Anonymous says:

    IE7 has a new user agent string. See http://blogs.msdn.com/ie/archive/2005/04/27/412813.aspx for details….

  93. Anonymous says:

    Just read on the IE blogs that MSFT have decided to change the IE

    user-agent string which may/may not…

  94. Anonymous says:

    i have used it to my work .

    &#160;http://blogs.msdn.com/ie/archive/2005/04/27/412813.aspx

    What does this…

  95. Anonymous says:

    One of the purposes of releasing the IE7 beta is to collect feedback on compatibility with both websites…

  96. IE 7 Beta 2ใงWebใƒ‡ใ‚ถใ‚คใƒŠใƒผใจ้–‹็™บ่€…ใŒ็ขบ่ชใ™ในใ็‚นใŒใƒใ‚งใƒƒใ‚ฏใƒชใ‚นใƒˆใซ…

  97. IEBlog says:

    At the end of April of last year, we blogged about the new Internet Explorer 7 User Agent string.&amp;nbsp;…

  98. &lt;p&gt;
    I just posted a plea for browser producers to advertise their IDNA capability in the User-Agent HTTP header:

    &lt;/p&gt;
    &lt;p&gt;
    &lt;blockquote&gt;

    &lt;/p&gt;
    &lt;p&gt;
    This is a proposal to the major browser producers supporting IDNA to

  99. I bank with the National. I use their

    online banking service to pay bills.

    I keep getting presented…

  100. World 0.1 says:

    (Yes, a string can be โ€œarrogantโ€). I have to give a thumbs up to the developers of Internet&amp;nbsp;Explorer&amp;nbsp;7. Even if the developpers have just done a โ€œpaint job on their Pintoโ€, in my opinion, they have done a rather good paint job. Obviously,

  101. IE7 was released yesterday. If you’re a web site owner, developer or designer, and find that your site or application is encountering problems, fret not. Here is a list of resources for you: Read the Checklists Download the IE7 Readiness…

  102. IE7 was released yesterday. If youโ€™re a web site owner, developer or designer, and find that your site or application is encountering problems, fret not. Here is a list of resources for you: 1. Checklists 2. Download the IE7…

  103. iDeas wHizz says:

    From now on, we have to test our web application on another version of browser. Source: http://dotnet.csdn.net/n/20061019/96467.html Microsoft IE7ๅทฒไบŽไปŠๆ—ฅๆญฃๅผๅ‘ๅธƒใ€‚ๅพฎ่ฝฏๅœจ็ฝ‘็ซ™ไธŠๅ…ฌๅธƒไบ†ๅผ€ๅ‘่€…ๅ’ŒWebๅˆถไฝœไบบๅ‘˜่ฆๆณจๆ„็š„ไธ€ไบ›ไบ‹้กนใ€‚็ฟป่ฏ‘ๅฆ‚ไธ‹๏ผš ็กฎ่ฎคไฝ ็š„็จ‹ๅบไธญๅ…ณ

  104. Dear National Australia Bank, I am one of your customers. I’ve banked with you for the past 15 years.

  105. The studies show that people on a diet almost always put the weight back on. This blog gives you great solution to turn eating into a healthy habit. No dieting required.

  106. I got a couple of cases about this problem recently… Imagine this scenario: you install the .NET Framework

  107. I got a couple of cases about this problem recently… Imagine this scenario: you install the .NET Framework

  108. IEBlog says:

    As Dean announced , a beta version of Internet Explorer 8 will be released in the first half of 2008.

  109. As Dean announced , a beta version of Internet Explorer 8 will be released in the first half of 2008

  110. Valium multiple sclerosis. Valium statistics. Antidote soma valium. Internet-rx.com valium. Valium. Generic valium no prescription.