When the XMLHttpRequest object was first released, the Component Object Model (COM)
was ruling the world at Microsoft. The extensibility model of products and applications was
based on COM and implemented through COM components. In the late 1990s, the right and
natural choice was to implement this new component as a reusable automation COM object,
named Microsoft.XmlHttp.
Various versions of the same component (even with slightly different names) were released
over the years, but all of them preserved the original component model—COM. Internet
Explorer 6.0, for example, ships the XMLHttpRequest object in the form of a COM object.
Where’s the problem?
COM objects are external components that require explicit permission to run inside of a Web
browser. In particular, to run the XMLHttpRequest object and subsequently enable any AJAX
functionality built on top of it, at a minimum a client machine needs to accept ActiveX components
marked safe for scripting. (See Figure 1-3.)
The XMLHttpRequest object is certainly a safe component, but to enable it users need to lessen
their security settings and accept any other component “declared” safe for scripting that is
around the Web sites they visit.
Important : The internal implementation of XMLHttpRequest is disjointed from the implementation
of any AJAX-like frameworks, such as Microsoft ASP.NET AJAX. Under the hood,
any framework ends up calling the object as exposed by, or available in, the browser.
