IE content-type logic

The information published in this post is now out-of-date and one or more links are invalid.

—IEBlog Editor, 21 August 2012

This being my first post on the IE blog, I should introduce myself quickly. My name is Vishu Gupta; I am a developer on the IE team.

There have been several posts in the recent past asking for more information on how does Internet Explorer sniff the content-type of a downloaded file. The whole thing looks totally inconsistent or should I say…non-compliant! Before reaching any conclusions here, let’s dig just a little bit deeper.

During XPSP2, we gave a real hard look at the IE’s content-type handling code path and how to make it more secure and reasonable. The whole idea of the mime-sniffing logic was to make it easier for an average Joe to put up a personal website without worrying about mimetype details even when web servers and ISPs have random default configurations. IE does mime-sniffing only if either the server doesn’t specify a content-type or if the server claims that the file is something that IE knows about. For example, if there is a new mimetype abc/xyz and the server reports that to IE, IE will consider the mimetype of the file to be abc/xyz only. In addition to the content-type sniffing, IE also does clsid sniffing, which actually decides which component handles the file within IE. The clsid can be either sniffed from the document itself or it can be obtained from the mimetype (decided previously with or without sniffing) or can be obtained from the extension. For example, if the mimetype abc/xyz doesn’t have a clsid corresponding to itself in the registry, IE will try to obtain the clsid from the extension or from the document itself, and use that to host the file. If it cannot find the clsid, the file will be Shell Executed and shell will use the extension to determine the application to handle the file.

Now comes:
The question: “Do we really need to sniff a file if the server says it is text/plain?”
Short answer: No.
Long answer: Probably, we do.

During XPSP2 betas, we had the mimesniffing mitigation enabled in all zones by default. We tested the waters with applying the “server knows best, so treat the server-suggested mimetype as authoritative” concept for text/plain mimetype. This led to an outcry on the newsgroups about different file types being rendered as text on XPSP2, and we had to disable the mitigation in the internet zone. One can only imagine the app-compat backlash if we stopped sniffing for all reported mimetypes. Yes, instead of handling that by sniffing in the browser, we could go about asking everybody to fix their servers but not everyone can do that easily. In addition to this, several apps depend on IE to launch them after sniffing the correct clsid from their compound file (OLE structured storage). Its one thing to ask new apps to do the right thing, but a whole different ball-game if you want to switch the entire installed base.

Mimesniffing doesn’t mean that there is no way for a server to control how a file is handled. <Content-disposition: attachment; filename=”filename.ext”> header enables a server to do precisely that. With this however, IE makes sure that the user gets prompted with the file type information (based on the extension specified by the server here) before the file is opened/saved.


Comments (64)

  1. Anonymous says:

    Some might have noticed that the Keyhole link on the Marketplace Maps demo was servicing an inline XML…

  2. Anonymous says:

    Thanks Vishu, this is exactly the sort of info I read IEBlog for. I may not agree with you but being open about motives and compromises only helps developer relations in the long run.

    On another media type note, are there any plans to add application/xhtml+xml as a valid option for developers any time soon? Even if IE didn’t do strict validity parsing it’d remove a barrier of entry for a lot of developers who’d like to serve XHTML properly. Incidentally, I agree with Anne Van Kesteren when he suggested using application/xhtml+xml as a ‘strict strict mode’ switch – an analogue of todays doctype switch – to push IE into a validating parser mode.

  3. Anonymous says:

    Ahhh… Mimetypes…

    This has little to do with your post, but it seems this is a good place to whine about my issue anyway :)

    Recently I needed a file upload component. I wrote a simple ASP.NET page for that (it’s piece of cake to do file uploads in .NET Framework). Then I wanted to limit the types of files that can be uploaded to JPEG images. You can do this by examining the file extension and the mime type that you get from the browser. Filtering out file extensions – piece of cake. Playing around with mime types sucks.

    First, <input type="file"> is supposed to have an attribute named ‘accept’ which takes a comma-separated list of mime types the browser will allow you to upload. The browser should not even upload files that don’t match the given mime types. Internet Explorer totally ignores this attribute.

    Second, any normal person would expect IE to upload jpeg images with the mime type image/jpeg. No way! IE sends image/pjpeg instead. Not only there is no way to convince IE to send image/jpeg as the mime type, there is no such thing as image/pjpeg in all the web standards I looked into.

    I still use IE mostly for its performance. It’s also reasonably secure once you disable ActiveX completely and once you remove several insecure scripting features. However, issues like the one above still make IE a big pain in the neck.

  4. Anonymous says:

    Why don’t you give people the choice?

    Home users (and most business users) will be happy with the default. In a larger enterprise environment control over how MIME-types are handled would cure many a sysadmin headache. Put it in the advanced preferences, integrate with Group Policy, and happiness will ensue, with flowers thrown at your feet.

    The only choice which should be ‘hardwired’ is the default – why not let me run things the way I want to?

  5. Anonymous says:

    > <Content-disposition; attachment="filename.ext">

    Did you mean:

    <Content-disposition: attachment; filename="filename.ext">?

    Also, while I sympathize with the problem you face now in switching to compliant treatment of MIME types, I’d like to point out that this is a self-created problem. The only reason so many places serve random junk as text/plain is because IE second-guesses the type anyway…. Were that not happening, the servers would have been fixed years ago.

  6. Anonymous says:

    Let’s create a MIME type text/plain-no-really so that we can serve HTML-looking pages as plaintext even for IE.


  7. Anonymous says:

    I have cursed IE’s mime type sniffing in the past. There have been a number of occasions when I’ve struggled to get Admins to configure their web servers correctly, only to have them deny there is a problem because the pages work ok in IE. But I understand what you are saying about backwards compatibility. If IE were to change its behaviour in this respect I can appreciate it would cause a lot of headaches.

    But it seems to me that xhtml offers an ideal opportunity to shift behaviour. When you introduce support for the mime type application/xhtml+xml don’t do any mime sniffing. Trust what the server says if it claims to be that mime type. This won’t cause any compatibility issues with older sites and applications. But does allow us to move to a more sensible way of operating. Everyone’s happy.

  8. Anonymous says:

    Thanks, finally an article that actually means something to us devs.

    I know this is off topic, but with the re-launch of msn, perhaps you should explain to the devs over there that target="_blank" is not part of the XHTML strict spec.

  9. Anonymous says:

    Bruce, Thanks for the correction. Yes I meant <content-disposition: attachment; filename="filename.ext">

  10. Anonymous says:

    Boris, Thanks for the correction with the content-disposition header.

    KGaleon, you can disable sniffing files reported to be text/plain and disable sniffing text/html for anything that is not specified as html by the server, by changing the value for urlaction "2100" to 0x3 under the regkey:

    (HKCU/HKLM)SoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones<zoneid>

    <zoneid> = 0 (local-machine),1 (intranet), 2(trusted), 3(internet)

  11. Anonymous says:

    > One can only imagine the app-compat backlash if we stopped sniffing for all reported mimetypes.

    You made your bed, now lie in it. If you had complied with RFC 2616 from day one, there would be zero backlash. It’s not a hard thing to do; it’s actually *extra* work to sniff than it is to comply with the specification.

    Having said that, if XPSP2 had have fixed the issue once and for all, those broken websites would have been fixed straight away – as somebody else said, the only reason they are broken in the first place is because Internet Explorer hides the error. But now you are stuck with problems because you didn’t follow the standard.

    And the rest of us are still stuck dealing with a browser that doesn’t believe us when we say a file is of a certain media type.

    > Yes, instead of handling that by sniffing in the browser, we could go about asking everybody to fix their servers but not everyone can do that easily.

    I appreciate that. But their websites are *already broken* in other browsers. Fixing Internet Explorer merely brings it to their attention. And hosting providers that don’t give their customers the ability to fix it themselves soon get complaints.

    It happened already with misconfigured servers labelling CSS files wrongly – when browsers started ignoring stylesheets that weren’t served as text/css, hosts quickly updated their configurations to match. Those that don’t will generally do so as soon as you email them.

    > Mimesniffing doesn’t mean that there is no way for a server to control how a file is handled.

    According to the document you cited, a text/plain document is sniffed, and if Internet Explorer thinks it looks like, say, HTML, it’s treated as HTML, complete with executing Javascript. Pretty incorrect behaviour for plain text, wouldn’t you say?

    How are web authors to tell Internet Explorer that it is, in fact, plain text?

    > <Content-disposition: attachment; filename="filename.ext"> header enables a server to do precisely that.

    This tells Internet Explorer that the file should not be displayed inline and supplies a default filename. It does not tell Internet Explorer what media type the resource is. The Content-Type header does, but you ignore that.

    Fiddling around in the registry is a fix if you are a client. It is not a fix if you are a web developer.

    > On another media type note, are there any plans to add application/xhtml+xml as a valid option for developers any time soon?

    Supporting XHTML isn’t as simple as dumping the code through a tag-soup parser. There are important differences, for instance, differences in how CSS is handled.

    I’ve already suggested an explicit "X-IE-Follow-Standards: true" HTTP header to signify that Internet Explorer should do the right thing. That’s a lot less work (and a lot less to cock up) than XHTML support, and a lot more reliable and backwards-compatible than doctype switching.

    > Even if IE didn’t do strict validity parsing

    If you are referring to the well-formed requirement of the XML 1.0 specification, then breaking that rule would be extremely obnoxious. Comply with the specifications, or you’ll just end up with yet more "backlash" worries when the time comes to fix *that* screw-up.

  12. Anonymous says:

    >><Content-disposition: attachment; filename="filename.ext">

    Ah, one of those wonderful additions to IE that worked better and better with every edition. If only everyone had XP2/IE6 etc!

    My question is:

    If you’ve changed things in IE for XP2 (which you undoubtedly have), why did you not increment the IE version (to 7)? As far as I know, there is no great tax on numerals, and this would persuade people (especially those *!&&%s on IE5) to upgrade sooner.

    It is often hard to persuade your PHB to upgrade when the ancient IE5 is ‘only’ one version behind.

  13. Anonymous says:

    Sorry to be a bit off-topic, but as a quick addition, I’d like to say that I totally back the IE structure of supporting and doing the best it can with bad and old code. Gotcha. Understood. And it helped a great deal in the old days.

    Of course now, we have simple IDEs for the beginners to get started in HTML (I’m not counting Frontpage). And most sites work in Firefox. They didn’t work in NS6, and I thought Mozilla would be a mistake, but I was wrong. Most sites work, and FF is really nice. I’m talking 99% or similar.

    Having said all this, why not, for IE8 say, abandon your engine, adopt the Mozilla codebase, and then bolt the miracles of Microsoft on top?

    I know it would break my programmers heart to throw something like that away, but we all know that sometimes it’s necessary. Otherwise you’ll end up progressively re-coding IE to match Mozilla over the next 10 years, and always be playing catchup.

    Mozilla’s good. It really is. And adopting it wouldn’t cause as much of a ruckus as you think.

    It’s not a bad idea – I’m not suggesting basing Longhorn on Linux or anything. And you’ll have yourself a real upgrade instead of a bug-fixed, more secure, more wizardy, more gimmicky version of what you already have.

  14. Anonymous says:

    Unfortunately, this sniffing behavior pushes an extra security burden on web application developers; when we accept user-supplied data and show it to other users, we have to go through extra gyrations to guess whether Internet Explorer might render it in an unsafe way (eg, JavaScript execution from what is claimed to be plain text or a PNG image).

    I was very surprised and disappointed to learn that the fix for this security bug was turned off by default in XP SP2, particularly so since it was specifically listed as a new security feature!

    Would it be possible to publish more details of the sniffing heuristics so that developers have a better chance at protecting their users against scripting exploits? The classic ‘Appendix A’ page (which you linked to above) is very vague and for instance doesn’t list the strings which trigger the HTML heuristic or its priority compared to the heuristics for other formats. If this is already online somewhere I’d very much appreciate a pointer to it, thanks…

  15. Anonymous says:

    Vishu, thanks for explaining. Unfortunately, it’s not remotely close to being good enough for the world we are in today. Consider sites like LiveJournal or Wikipedia, where one end user embeds or uploads material which is presented to other end users. What practical way does such a site (or the other image or whatever hosting sites involved) have to ensure that IE is completely prohibited from interpreting the content as anything other than the declared type, so they can maintain their contract with their users, which is to prevent one user from presenting malicious content which will atack other users? For a simple embedded image, popping up a dialog just doenn’t do the job. The site has to have a way of saying "under no circumstances are you to do anything other than treat this as exactly what I tell you it is". They simply can’t do their job unless they can do that, not even when they are doing their best to filter known trouble sources.

    Brion asks for the sniffing heuristics and that would be good (and I’d love sites to use them to ensure that none of those heuristics can be tripped) but that’s really not the way to be doing this. It’s far too convoluted for what’s now required as a basic security step.

    It’s sad that it’s necessary, but it is. If you have to use a new attribute for the tag or new whatever on the page or in the headers, do it. Just find some backwards compatible way to say "no, don’t go off and expose our end users to whatever new exploit someone comes up with".

  16. Anonymous says:

    Thank you for explaining how IE’s content sniffing broke the web! At least Microsoft is now happy to admit their mistakes, fix them and move on.

    I think the only way to handle this now would be to always accept what the server says, no matter what, but provide user friendly warnings that explain the problem and let the user decide.

    So, for example, when file.html is served as text/plain from the server, IE should render it as plain text, but provide a message to the user stating something like this:

    "The web server indicated that this file should be treated as plain text; however, Internet Explorer has detected that this file may actually be HTML. How would you like Internet Explorer to render this document?"

    (Advanced messages should also be available which also show the real HTTP headers so developers have a chance to debug the thing properly)

    Then provide both sample renderings to the user and allow the user to pick the most appropriate. IE could then remember that choice on a page-by-page, or server-wide basis, so that it doesn’t break legitimate text/plain HTML documents, intended to render the source code, by default.

    IE should also indicate whenever content-sniffing has occurred, perhaps through an icon in the status bar or something for the user to override at any time.

    Lastly, this is a little off-topic, but still a MIME type issue. Why did XPSP2 break the uploading of text/html documents, by automatically changing the content-type to text/plain. This has caused so many IE users problems when they try to validate their HTML [1].

    Although there is a registry hack to get around the problem, one good thing is that it has enabled us to recommend they switch a descent standards compliant browser instead; some of which did :-).


  17. Anonymous says:

    > First, <input type="file"> is supposed to

    > have an attribute named ‘accept’ which takes

    > a comma-separated list of mime types the

    > browser will allow you to upload.

    For security you would still need to check the extension on the server anyway, else naughty people could just upload files with unwanted extensions through direct http connections rather than going through a browser.

  18. Anonymous says:

    Lachlan, displaying as text and giving the user an option to go back and sniff is a great suggestion! In fact, if you switch on the mimesniffing mitigation (using the regkey I specified previously), you do see such pages in text/plain and the information bar allows you to go back and reload with sniffing.

    The only problem with that is: if the file is a 10Mb media file with text/plain header, the browser takes its own sweet time to load that much text and the user gives up.

    Giving users the technical description of what the webserver suggested makes sense but I am not sure how many will read and follow it. And I didnt really understand your point about sample rendering. That sounds interesting. pls clarify?

  19. Anonymous says:

    Vishu, all I meant about the sample renderings was to give a clear, visual distinction between the two content types because some users may not even know what HTML (or any other content-type) is, and, therefore, have difficulty understanding the choices.

    This could be done by giving a thumbnail view of each within the dialog box. So, for HTML served as text/plain, the user would see a thumbnail of the page rendered as plain text and a thumbnail of the page rendered as HTML.

    Regarding the 10MB file as text/plain scenario you gave, I’m not quite sure what you mean. I never said the choice couldn’t be given before the file finishes loading. If IE can detect a potentially more suitable MIME type before it finishes, it should be able to continue loading in the background while the user makes up their mind. That way, no user is going to impatiently give up while IE takes it’s own sweet time.

  20. Anonymous says:

    IE should not do any sniffing. IE developers should advocate that people fix their servers. IE should throw in errors when it is treating a file different than the server says it should. (Some error console or so.)

    However, becoming compliant with the RFC, as Jim said, would be the best solution. That way everyone is forced to fix their MIME types. Problems that arise should be solved not private but in public so everyone knows the problem is there.

  21. Anonymous says:


    Thats right MS, keep making excuses to not properly support standards. We’ll enjoy their appropriate support on other browsers.

  22. Anonymous says:

    > We’ll enjoy their appropriate support on other browsers.

    Actually, no we won’t. Because Internet Explorer ignores the standard, a large number of websites have cropped up that are unusable in web browsers that conform to the standard.

    In order for these websites to work in other browsers, they must also break standards. Recently both Firefox and Opera have started sniffing.

    If Internet Explorer had have conformed to the standards, these sites wouldn’t have been broken in the first place, and other browsers wouldn’t be forced to break standards to make these sites work.

    It’s a classic example of Microsoft ruining it for everyone.

  23. Anonymous says:

    Firefox and Opera are under no obligation to sniff. It is their prerogative.

    After all, I’m sure their much touted market share will single-handedly cure all compatibility issues…

  24. Anonymous says:

    > Firefox and Opera are under no obligation to sniff. It is their prerogative.

    No obligation? If they don’t do it, they expose their users to large numbers of errors. I’d hardly call that "no obligation" (and I disagree with their stance on the issue, btw).

    > After all, I’m sure their much touted market share will single-handedly cure all compatibility issues…

    I’m sick of that too (and it’s just Firefox that is shouting so loud about it, not Opera).

  25. Anonymous says:

    Randy: I think it’s better to explain the "Probably, we do" with an example. Sniff this HTTP GET request.

  26. Anonymous says:

    Why not just sniff everything? Who cares what the server says. Please explain why I should trust a completely unknown webserver!

    This sounds to me like the start of a security nightmare.

  27. Anonymous says:

    Firefox doesn’t do content-type sniff unless the server supplies completely nonsense content-type, e.g, server says text/html but firefox found binary data.

  28. Anonymous says:

    Thanks guys for the responses.

    Lachlan, showing thumbnails for the types essentially means that we have opened the file in both possible ways without asking for user consent.

  29. Anonymous says:

    > Why not just sniff everything?

    That would simply break things further. For instance, I’d guess application/xhtml+xml would be treated as HTML, violating the XML specification.

    > Who cares what the server says.

    The web developers are the only people who are able to say definitively what media type a resource is. If you don’t listen to the web developers, you *will* make mistakes.

    > Please explain why I should trust a completely unknown webserver!

    You are trusting a completely unknown web server to describe what media type a resource is. How is that a bad thing? If anything, the security hole is when you sniff.

    > Lachlan, showing thumbnails for the types essentially means that we have opened the file in both possible ways without asking for user consent.

    Konqueror has the ability to switch views for a page, so if, for example, I’m viewing a rendered HTML document, I can go to View | View Mode | Embedded Advanced Text Editor and it will change to a plain text view.

    If you really insist on sniffing, on the first instance of a media type being sniffed for a particular domain, pop up a box saying "It’s possible this server is misconfigured, if you have problems viewing the page, please select an alternative view from the View menu", have a tick box to ignore these warnings in future, and then display the content as the server tells you to.

    If the server provides the wrong media type, the users have a clear way of working around it, and the developers get notified instantly.

  30. Anonymous says:

    Jim, my prediction is that the dialog you propose would be seen exactly once, just like the "you are sending data over the internet that can be seen by everyone" dialog.

    Back when we were doing XPSP2, we had a hell of a time getting a dialog that people in usability testing wouldn’t just instantly click "go away". Delaying the "go away" button for 3 seconeds doesn’t solve the problem; it just annoys people for 3 seconds as they wonder why the dialog doesn’t go away.

    Hence the invention of the gold bar.

  31. Anonymous says:

    I have a couple of questions about Internet Explorer.

    1) Is there a way to set IE up so it only changes its own connection settings, not global settings? For example, we use a SOCKS proxy at work, but for various reasons we have different settings for each program. However, if I make changes in IE it changes connection settings for other programs too!

    2) Is there any IE extension which lets you use Google Suggest in the Google toolbar? Google Suggest is fantastic but I don’t want to have to actually go to the web page every time.

    I’m completely lost trying to read the blog post, but hey, it sounds like you know what you’re talking about!

  32. Anonymous says:

    I second what Richard said. It’s pointless to argue about whether Microsoft "broke the web" or laugh about how they have to "lie in the bed they made". What’s done is done, and they have an unquestionable responsibility to backwards compatability. However, XHTML is still on the leading edge of acceptance (at least, strict XHTML). So, there’s no backwards compatability involved in supporting application/xhtml+xml. Sniff text/plain for the possibility that it’s text/html, if you must — but start supporting application/xhtml+xml, and trust that if the server gives that header, that’s the MIME type you should use.

    I also think that if backwards compatability is the "necessary evil" that you see preventing you from supporting MIME types literally, there’s no reason not to add support for a header like X-Prevent-ContentType-Detection that would turn on literal content type detection.

  33. Anonymous says:

    Kate Sanderstead, welcome to the anti-competitive behaviour which is so typical of Microsoft. It is my opinion that we should report such findings to all national and international competition watchdogs so they they will be punished to the fullest extent of the law.

    There is absolutely no reason for the browser to be part of the underlying operating system except to extend their market by using monopoly. By all means re-use the codes from the rendering engine and other libraries, for example, for your Windows Update application, but to force Internet Explorer specifically? Completely shameless. Some humility and decency when it comes to interoperations is obviously too much to expect from these scoundrels.

  34. Anonymous says:

    Kate, Raja: the problem is that Kate’s other applications have chosen to use the system proxy settings. Like it or not, Internet Explorer’s dialogs expose the system proxy settings.

    The other applications – which are using the same WinInet library for HTTP connections as Internet Explorer does, since Microsoft has exposed it as part of the _Windows_ Platform SDK – may offer facilities to override the system proxy settings for this application. My source control tool, SourceGear’s Vault, offers this facility.

    IE could likewise offer this facility, but some other UI would then have to be designed for configuring the system proxy settings.

    You should contact the vendors of your other applications, to see if they’re willing to add the necessary facilities to use alternative proxy settings. Or, if you’re like Raja, to ask them to write and maintain their own HTTP connection layer rather than taking advantage of Microsoft’s design, code and testing of the WinInet library. Be prepared to pay for the development and testing costs.

  35. Anonymous says:

    I don’t think its necessarily a monopoly or anti-competative issue, but it is a bit naive to have not have per app settings for Microsofts own software.

    I can definately see uses (eg in workplaces monitoring communications for legal reasons) for using different connection settings for different programs.

    Each application should be able to choose its own settings (under the ‘Advanced’ section of the preferences, obviously) but use the global ones by default. Seems like a better solution all round.

    To be fair, most non-MS software that relies heavily on networks comes with its own config settings these days. Interestingly, Opera doesn’t have a SOCKS proxy yet!

  36. Anonymous says:

    Although I’d much like to see application/xhtml+xml support in IE, I’d much rather wait for IE7/Longhorn and have it be a switch for a strict well-formed XML standards compliance mode, than to have a patch released tomorrow that makes IE treat it the same as text/html.

    If IE starts treating application/xhtml+xml as html, it really defeats the purpose of having a separate mime-type for xhtml in the first place.

  37. Anonymous says:

    Hi, how can I delete Internet Explorer? I don’t want it any more.

  38. Anonymous says:

    Disgruntled, I see no reason to let stand the kind of crap you’ve been posting. I’m going to keep deleting your comments as long as they contain nothing but insults and personal attacks.

    If you want to have a real discussion, then stop being an anonymous coward and/or stop being nothing but insulting.

    Your other choice is to say anything you want on your own blog and trackback it here. I won’t delete that.

  39. Anonymous says:

    Just wondering, is anybody on the Internet Exploder coding team subscribed to BugTraq or like-minded mailing lists? When viewing that particular list, in Firefox/Opera/Moz 1.7 – whatever browser I have handy (OTHER than IE6.x), I notice a new exploits for IE and I get to thinking:

    &#187;There are a lot of problems with IE and security.

    &#187;Most of the problems related to IE tend to have something to do with how tightly IE4 was integrated with win98.

    &#187;For some reason, in the last *7* years, Microsoft hasn’t gotten a _SINGLE_ thing done right in the eyes of the security staff that must deal with the nightmare that is IE/Explorer integration.

    From a web-developers perspective:

    &#187;Opera 5.x has more accurate rendering than IE 6

    &#187;CSS2 support is a lost cause if you want to support IE users.

    &#187;It’s often easier to build non-standards compliant *copies* of your sites, detect the user agent, and keep the users of *decent* browsers segregated from IE (because the *compliant* site breaks IE just as much as a "built for IE" site breaks compliant browsers.)

    &#187;Sorry, client-xyz, without some crazy hacks, I can’t make that happy floating menu thing that you want. (*cough* that I can impliment with 2 lines of css in a standards compliant browser*cough*)

    In regards to ActiveX:

    &#187;you want to execute *WHAT* on my machine?

    Oh, this might be news to you guys, but ActiveX controls (as well as being insecure) aren’t cross-platform ;-) If you think I’m mistaken, I suggest you download a copy of Solaris 10 – x86 (for personal use) from and load up the JDS (Java Desktop System – built on gnome2), fire up Mozilla 1.x (system default) and see how well works for you ;-) If it’s worthless other than as a security risk, trash it!

    The point is:

    When I’m forced by customer demand to run incompatible, non-standards-compliant, insecure software (like windows) I stay as far away from the biggest security holes in the system (namely IE – btw, have you guys changed the about page since 4.0? I’m willing to bet that if I diff’d the entirety of IE4’s codebase against IE6, the large majority would match). I realize that while most people want things to "just work," most of them aren’t capable of fixing things when they break.

    I have very bad news for you gentlemen… Solaris 10 is now open source. Novell owns SuSE (the dominant *DESKTOP* Linux distribution) My grandmother just installed SuSE 9 on her computer at home… by herself… because *she* is intelligent enough to ask me about articles she reads at OpenOffice isn’t that different from Word98 in regards to look and feel, reads all her old word documents, exports to PDF, and is faster than Word was on her system.

    Listen UP Mr. Gates, Mr. Ballmer!

    Your company-wide programming practices are losing you market share and customer confidence. The same excuses aren’t going to work anymore. The public is starting to realize exactly what kind of quality comes with the Microsoft name. Please, Mr. Gupta, Mr. Morgan, I invite you to defend yourselves, I won’t see your replies. The public is starting to become disallusioned… if Microsoft produced an automobile, mark my words, Mr. Gates would be living in a cardboard box after all the liability lawsuits.

    As a consultant, I do what I can to prevent my clients from using Microsoft products, just as Microsoft prevents major-name PC suppliers from shipping me a laptop without an operating system on it (call Dell and tell them you don’t want an operating system, they’ll refuse and you’re screwed paying Microsoft Licensing fees anyway). Not only are there alternatives available for anything a person would want to run a Microsoft product for, but 99% of the time, the alternatives have cleaner code and a distinct lack of security problems.

    Thank you all for your time, I just wanted my opinion voiced.

    Side Note: Mr. Dimmick, please see your doctor about that cranial-rectal inversion you seem to be suffering from. WinInet isn’t the only available framework for making tcp connections to port 80 (http) NOR should Internet Explorer’s proxy preferences mess with say, an instant messaging application, ssh client, etc etc. In regards to R&D costs related to making simple http connections, unless I’m attempting to display parsed/rendered language like html/css/xhtml+xml/xml over http, you don’t *need* some stupid library that just happens to piggyback IE’s rendering engine. In regards to it being available in the "_Windows_ Platform SDK," I was under the impression that the US Department of Justice had a few words with Microsoft over Anti-Trust. If you’d like to look into programming like a big boy, learn to code with vi.


    (Propaganda is only effective when the masses collectively refuse to think for themselves.)

  40. Anonymous says:

    When I specify another browser than IE to be the standard browser on the OS I expect this to be used for everything.

    However, a lot of MS applications STILL launch Internet Explorer, despite my EXPLICIT request to use another product as the standard browser.

    And as a web developer, I will add to this that we code for web standards. Why? Because it just makes good old economic sense for us (bandwitdh, re-usability of code, …) . We ensure that the websites we make are functional in all browsers. But the better standards support from Mozilla/Opera/Safari often means the websites display better in these browsers which support standards better.

    Ironically, Internet Explorers poor implementation of certain standards stops us from being able to fully use those benefits.

    Another pet peeve of mine is the ‘alt’ attribute. Internet Explorer shows a tooltip is you hover your mouse over an element with this attribute. However, ‘alt’ attribute is meant especially for accessibility purposes. If people want to specify a tooltip, they can use ‘ title="…" ‘ . Also, title attribute can be used on all elements. So if we try to do the right thing, certain website designs look like a patch job in Internet Explorer, since EVERY freakin’ element with an alt-tag gets a tooltip!!

    Please follow web standards, so we can all benefit… you’re not the only player on the block.

    If it’s not possible with the curreny IE code, maybe it’s time to use other code. Might be a bitter pill to swallow, but at least it’ll take care of the disease and not the symptoms.

  41. Anonymous says:


    It probably breaks with SP2 and I’ve only used it experimentally but I think it does what you want.

  42. Anonymous says:

    What is the logic in having the IE by default allocate 15 GB (gigs, not megs) to temporary internet files. I noticed this too late and deleting the temp files took a Longhour not to mention a need for defragmenting the array.

  43. Anonymous says:

    Darkelve, you can use title="" to not show a tooltip on any element in IE as it only displays alt text if there is no title text.

    Yes, this is just a hack and wastes bandwidth.

  44. Anonymous says:

    @zzz, I understand that by default IE allocates about 10% of the total disk space as the maximum size of its temporary area.

    I suppose that, in these days of huge hard disks, reserving a percentage of the disk size can get a bit silly.

  45. Anonymous says:

    Does MS have a document somewhere describing this behaviour for each version of IE?

    A big table describing the order of detection steps and whether ‘Content-disposition: attachment’ headers are treated properly for each version would be handy.

  46. Anonymous says:

    The algorithm Windows uses for setting initial WinInet cache size doesn’t work very well with large hard drives that are common today.

    We plan on changing that in a future IE.

  47. Anonymous says:

    "@zzz, I understand that by default IE allocates about 10% of the total disk space as the maximum size of its temporary area."

    This has affected some of my clients quite often: they don’t change the default setting and end up with gigabytes of cache data; then every time they scan for viruses the scanner plows through that directory and the scan will literally take hours to complete due to thousands of small files in the cache. I think we can all agree that something like 20 Mb of cache is a more reasonable default? :)

  48. Anonymous says:

    If IE starts treating application/xhtml+xml as html, it really defeats the purpose of having a separate mime-type for xhtml in the first place.

  49. IEBlog says:

    Hi! I’m Eric Lawrence, Security Program Manager for Internet Explorer. Last Tuesday, Dean wrote about