5

Microsoft finally added the native XMLHttpRequest object in Internet Explorer 7, but I found out that it can be disabled in the Internet Options dialog. So what benefit is there using XMLHttpRequest() vs ActiveXObject("Microsoft.XMLHTTP")?

If it can be disabled, that means we have to keep our browser compatibility checks in forever, doesn't it? Would XMLHttpRequest() initialize quicker than ActiveXObject("Microsoft.XMLHTTP") or what? Why would Microsoft add it and make it optional?

Andy E
  • 338,112
  • 86
  • 474
  • 445
  • may be for compatibility for Firefox specific pages ? – Xinus Oct 21 '09 at 12:16
  • @Rubens Farias, it's intended to be. I only work with IE7+ (no other browsers) so I really want to know if I should even check for XMLHttpRequest or just go straight for ActiveXObject() – Andy E Oct 21 '09 at 12:24
  • If you only work with IE7+ you can work with XmlHttpRequest directly, just catch the security exception in a try/catch, which means it is directly or indirectly disabled. If you choose for ActiveX approach, be aware that the internal implementation is quite different (incompatible with loaded DOM, need to convert to/from) and slower and that ActiveX is disabled quite often. – Abel Oct 21 '09 at 12:30
  • @Abel: thanks, I think that's the answer I'm looking for, XMLHttpRequest and Microsoft.XMLHTTP aren't the same thing? – Andy E Oct 21 '09 at 12:33
  • 1
    Yes, it is very different. I.e., XHR understands the JS `this` and it can be expanded through `prototype` or normal custom properties, this is not possible with ActiveX. The performance is *much* better and its security is decoupled from ActiveX. The properties have been updated to reflect the XHR standard (of course, IE always has gotchas, but that's another story). In short: it is a coherent part of the DOM and JS, instead of some external object, see also: http://msdn.microsoft.com/en-us/library/ms537505(VS.85).aspx#_id – Abel Oct 22 '09 at 23:32

2 Answers2

5

The ActiveXObject can also be disabled. Note that other browsers can disable this and other settings as well. This is not about browser compatibility, but about user preference. Users can allow / disallow cross-domain requests, can allow / disallow scripts, can allow Flash or not etc.

You'll always have to check whether your page still runs smooth (or falls back gracefully) when users have disabled certain browser's features that you need.

The good news is: it is enabled by default, most users will have it on.

Update: by default, scripting and external requests (i.e. document(), xsl:include with XSLT or external entities in XML) are not supported by XmlHttpRequest-retrieved objects and must be enabled explicitly. This is different from non-IE browsers, where external requests from XHR-loaded documents are allowed (or don't exist, like in Safari and Chrome).

Abel
  • 56,041
  • 24
  • 146
  • 247
  • 1
    `The good news is: it is enabled by default, most users will have it on.` - That's why I asked the question, I found out one of my users didn't have it switched on and it was causing the application to fail. I didn't even realize it could be disabled until then. – Andy E Oct 21 '09 at 12:29
2

This is a guess, but I would assume they allow it to be disabled for the same reason they allow JavaScript to be disabled. Some people believe the risks (privacy, security, whatever) outweigh the benefit and thus want it disabled.

Mayo
  • 10,544
  • 6
  • 45
  • 90
  • I could understand this, if it were disabled along with ActiveXObject. But you can actually disable XMLHttpRequest and still use ActiveXObject("Microsoft.XMLHttpRequest"). – Andy E Oct 21 '09 at 12:27