XMLHttpRequest

XMLHttpRequest
Name	XMLHttpRequest
Developer	Microsoft; standardized by WHATWG and W3C
First release	1998
Latest release	web standards
Written in	C++, JavaScript bindings
Platform	Web browsers, Node.js (polyfills)
License	Web standards

XMLHttpRequest is a web API for making HTTP requests from client-side scripts, enabling asynchronous communication between web pages and servers. Created to support interactive features in early web applications, it underpins technologies used in modern Ajax-style applications, works alongside standards produced by the World Wide Web Consortium and the WHATWG, and influenced subsequent network APIs in Web platform evolution. XMLHttpRequest has been implemented across major browser engines and informed interoperability work involving organizations such as Mozilla Foundation and Google.

History

XMLHttpRequest originated in the late 1990s when developers at Microsoft implemented a COM-based ActiveX control to allow dynamic web applications in Internet Explorer 5 and Outlook Web Access. The capability gained prominence in the mid-2000s with projects by teams at Google and others, which led to the popularization of Ajax through applications like Gmail and Google Maps. Standardization efforts were driven by the W3C and later the WHATWG, involving contributors from Mozilla Corporation, Apple Inc., and Opera Software to reconcile proprietary implementations across Gecko, WebKit, and Blink engines. Over time, discussions in venues like the IETF and the W3C Technical Architecture Group shaped cross-origin and streaming behavior.

Architecture and API

The XMLHttpRequest interface is exposed to JavaScript within browser execution contexts such as Window and Worker threads, and binds to networking stacks in engines like Gecko and WebKit. Core concepts include the readyState lifecycle, event handlers like onreadystatechange, and methods such as open(), send(), setRequestHeader(), and abort(). Responses are available through properties responseText, responseXML, and response with typed array support; transmission supports synchronous and asynchronous modes that interact with event loops in HTML5 and ECMAScript specifications. Network-level semantics depend on HTTP and TLS implementations maintained by projects such as OpenSSL and BoringSSL, and are subject to policy controls in components like Service Worker and Content Security Policy.

Usage and Examples

Typical usage in client code constructs an XMLHttpRequest, invokes open('GET','/resource'), sets headers, and processes responses in event callbacks, enabling dynamic interfaces used in applications like Facebook and Twitter. Libraries such as jQuery abstract XMLHttpRequest behind convenience APIs, while frameworks like AngularJS and React-based ecosystems commonly use higher-level abstractions or polyfills to normalize behavior across Internet Explorer and modern browsers. Server-side integrations involve platforms like Node.js via shims, and testing tools from Selenium and WebDriver automate scenarios that exercise network interactions initiated by XMLHttpRequest.

Security and Same-Origin Policy

XMLHttpRequest operates under the Same-Origin Policy enforced by browsers, which restricts cross-origin requests unless servers supply appropriate Cross-Origin Resource Sharing headers. Security concerns led to changes coordinated among stakeholders such as W3C and browser vendors including Mozilla Foundation, Google, Microsoft Corporation, and Apple Inc., who addressed vulnerabilities like CSRF and mixed-content issues discussed in advisories from groups like OWASP. Fine-grained controls intersect with features specified in CORS and with policies such as Content Security Policy that are specified in collaboration with standards bodies and implemented across engines including Blink and Gecko.

Performance and Limitations

XMLHttpRequest supports streaming and progress events but has limitations for modern high-performance use cases, including lack of native promise support and complications in handling streaming bodies compared with newer APIs. Large binary transfers and low-latency bidirectional communication expose constraints; these motivated performance work in browser projects like Chromium and Mozilla to optimize network stacks and integrate HTTP/2 and HTTP/3 features. Benchmarking tools from WebPageTest and synthetic workloads from research labs at institutions such as Stanford University and MIT have evaluated tradeoffs between XMLHttpRequest and alternatives under varied network conditions.

Compatibility and Browser Support

XMLHttpRequest is widely supported across mainstream browsers including Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge, and legacy Internet Explorer versions, with vendor-specific behavior historically addressed via polyfills and transpilers maintained by communities around GitHub projects. Standard conformance testing involves suites from W3C and interoperability meetings at TPAC, while enterprise compatibility concerns have driven shims in ecosystems like Polyfill.io and frameworks maintained by organizations such as Apache Software Foundation and Node.js Foundation.

Alternatives and Evolution (Fetch API, WebSockets)

The Fetch API and Streams API were developed by contributors from WHATWG and implementers at Google and Mozilla to provide promise-based, streamable request primitives that address XMLHttpRequest limitations; these are used in Progressive Web App architectures and in tandem with Service Worker scripts. For bidirectional communication, WebSocket and WebRTC—with standards maintained by groups like the IETF and W3C—offer persistent channels suited for real-time applications such as Slack and Zoom. The ecosystem continues to evolve through contributions from vendors and standards committees including the WHATWG Steering Group and open-source projects on GitHub.

Category:Web APIs