XMLHttpRequest is an API available to web browser scripting languages such as JavaScript.
It is used to send HTTP or HTTPS requests to a web server and load the server response
data back into the script.
Development versions of all major browsers support URI schemes beyond http: and https:,
in particular, blob: URLs are supported.
The name was standardized to XMLHttpRequest for compatibility.
It may be misleading, in particular because any data may be received from the server,
not just XML.
Data are also commonly received as JSON, HTML, or as plain text.
Data from the response can be used to alter the current document in the browser window
without loading a new web page.
The response data can also be evaluated by client-side scripting.
For example, if it was formatted as JSON by the web server, it can be converted into a
client-side data object for further use.
XMLHttpRequest has an important role in the Ajax web development technique.
It is currently used by many websites to implement responsive and dynamic web applications.
XMLHttpRequest is subject to the browser's same-origin policy: for security reasons,
requests will only succeed if they are made to the same server that served the original
web page.
History and support The concept behind the XMLHttpRequest object
was originally created by the developers of Outlook Web Access for Microsoft Exchange
Server 2000.
An interface called IXMLHTTPRequest was developed and implemented into the second version of
the MSXML library using this concept.
The second version of the MSXML library was shipped with Internet Explorer 5.0 in March
1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP
wrapper of the MSXML library.
The Mozilla project developed and implemented an interface called nsIXMLHttpRequest into
the Gecko layout engine.
This interface was modeled to work as closely to Microsoft's IXMLHTTPRequest interface as
possible.
Mozilla created a wrapper to use this interface through a JavaScript object which they called
XMLHttpRequest.
The XMLHttpRequest object was accessible as early as Gecko version 0.6 released on December
6 of 2000, but it was not completely functional until as late as version 1.0 of Gecko released
on June 5, 2002.
The XMLHttpRequest object became a de facto standard in other major web clients, implemented
in Safari 1.2 released in February 2004, Konqueror, Opera 8.0 released in April 2005, and iCab
3.0b352 released in September 2005.
The World Wide Web Consortium published a Working Draft specification for the XMLHttpRequest
object on April 5, 2006, edited by Anne van Kesteren of Opera Software and Dean Jackson
of W3C.
Its goal is "to document a minimum set of interoperable features based on existing implementations,
allowing Web developers to use these features without platform-specific code."
The last revision to the XMLHttpRequest object specification was on November 19 of 2009,
being a last call working draft.
Microsoft added the XMLHttpRequest object identifier to its scripting languages in Internet
Explorer 7.0 released in October 2006.
With the advent of cross-browser JavaScript libraries such as jQuery and the Prototype
JavaScript Framework, developers can invoke XMLHttpRequest functionality without coding
directly to the API.
Prototype provides an asynchronous requester object called Ajax.Request that wraps the
browser's underlying implementation and provides access to it.
jQuery objects represent or wrap elements from the current client-side DOM.
They all have a .load() method that takes a URI parameter and makes an XMLHttpRequest
to that URI, then by default places any returned HTML into the HTML element represented by
the jQuery object.
The W3C has since published another Working Draft specification for the XMLHttpRequest
object, "XMLHttpRequest Level 2", on February 25 of 2008.
Level 2 consists of extended functionality to the XMLHttpRequest object, including, but
not limited to, progress events, support for cross-site requests, and the handling of byte
streams.
The latest revision of the XMLHttpRequest Level 2 specification is that of 16 August
2011, which is still a working draft.
As of 5 December 2011, XMLHttpRequest version 2 has been merged into the main XMLHttpRequest
specification, and there is no longer a version 1 and a version 2.
Support in Internet Explorer versions 5, 5.5, and 6
Internet Explorer versions 5 and 6 did not define the XMLHttpRequest object identifier
in their scripting languages as the XMLHttpRequest identifier itself was not standard at the
time of their releases.
Backward compatibility can be achieved through object detection if the XMLHttpRequest identifier
does not exist.
Web pages that use XMLHttpRequest or XMLHTTP can mitigate the current minor differences
in the implementations either by encapsulating the XMLHttpRequest object in a JavaScript
wrapper, or by using an existing framework that does so.
In either case, the wrapper should detect the abilities of current implementation and
work within its requirements.
Until 8 April 2014 Microsoft supported Windows XP and so Internet Explorer 6 - a JavaScript
encapsulation example is provided below.
HTTP request The following sections demonstrate how a request
using the XMLHttpRequest object functions within a conforming user agent based on the
W3C Working Draft.
As the W3C standard for the XMLHttpRequest object is still a draft, user agents may not
abide by all the functionings of the W3C definition and any of the following is subject to change.
Extreme care should be taken into consideration when scripting with the XMLHttpRequest object
across multiple user agents.
This article will try to list the inconsistencies between the major user agents.
The open method The HTTP and HTTPS requests of the XMLHttpRequest
object must be initialized through the open method.
This method must be invoked prior to the actual sending of a request to validate and resolve
the request method, URL, and URI user information to be used for the request.
This method does not assure that the URL exists or the user information is correct.
This method can accept up to five parameters, but requires only two, to initialize a request.
open( Method, URL, Asynchronous, UserName, Password )
The first parameter of the method is a text string indicating the HTTP request method
to use.
The request methods that must be supported by a conforming user agent, defined by the
W3C draft for the XMLHttpRequest object, are currently listed as the following.
GET, Mozilla 1+) POST, Mozilla 1)
HEAD) PUT
DELETE OPTIONS)
However, request methods are not limited to the ones listed above.
The W3C draft states that a browser may support additional request methods at their own discretion.
The second parameter of the method is another text string, this one indicating the URL of
the HTTP request.
The W3C recommends that browsers should raise an error and not allow the request of a URL
with either a different port or ihost URI component from the current document.
The third parameter, a boolean value indicating whether or not the request will be asynchronous,
is not a required parameter by the W3C draft.
The default value of this parameter should be assumed to be true by a W3C conforming
user agent if it is not provided.
An asynchronous request will not wait on a server response before continuing on with
the execution of the current script.
It will instead invoke the onreadystatechange event listener of the XMLHttpRequest object
throughout the various stages of the request.
A synchronous request however will block execution of the current script until the request has
been completed, thus not invoking the onreadystatechange event listener.
The fourth and fifth parameters are the username and password, respectively.
These parameters, or just the username, may be provided for authentication and authorization
if required by the server for this request.
The setRequestHeader method Upon successful initialization of a request,
the setRequestHeader method of the XMLHttpRequest object can be invoked to send HTTP headers
with the request.
setRequestHeader( Name, Value )
The first parameter of this method is the text string name of the header.
The second parameter is the text string value.
This method must be invoked for each header that needs to be sent with the request.
Any headers attached here will be removed the next time the open method is invoked in
a W3C conforming user agent.
The send method To send an HTTP request, the send method of
the XMLHttpRequest must be invoked.
This method accepts a single parameter containing the content to be sent with the request.
send( Data )
This parameter may be omitted if no content needs to be sent.
The W3C draft states that this parameter may be any type available to the scripting language
as long as it can be turned into a text string, with the exception of the DOM document object.
If a user agent cannot serialise the parameter, then the parameter should be ignored.
Firefox 3.0.x and previous versions will however throw an exception if send is called without
an argument.
If the parameter is a DOM document object, a user agent should assure the document is
turned into well-formed XML using the encoding indicated by the inputEncoding property of
the document object.
If the Content-Type request header was not added through setRequestHeader yet, it should
automatically be added by a conforming user agent as "application/xml;charset=charset,"
where charset is the encoding used to encode the document.
If the user agent is configured to use a proxy server, then the XMLHttpRequest object will
modify the request appropriately so as to connect to the proxy instead of the origin
server, and send Proxy-Authorization headers as configured.
The onreadystatechange event listener If the open method of the XMLHttpRequest object
was invoked with the third parameter set to true for an asynchronous request, the onreadystatechange
event listener will be automatically invoked for each of the following actions that change
the readyState property of the XMLHttpRequest object.
State changes work like this: After the open method has been invoked successfully,
the readyState property of the XMLHttpRequest object should be assigned a value of 1.
After the send method has been invoked and the HTTP response headers have been received,
the readyState property of the XMLHttpRequest object should be assigned a value of 2.
Once the HTTP response content begins to load, the readyState property of the XMLHttpRequest
object should be assigned a value of 3.
Once the HTTP response content has finished loading, the readyState property of the XMLHttpRequest
object should be assigned a value of 4.
The listener will only respond to state changes which occur after the listener is defined.
To detect states 1 and 2, the listener must be defined before the open method is invoked.
The open method must be invoked before the send method is invoked.
The abort method This method aborts the request if the readyState
of the XMLHttpRequest object has not yet become 4.
The abort method ensures that the callback handler does not get invoked during an asynchronous
request.
abort( )
Some AJAX libraries use the abort method to cancel potential duplicate or out-of-order
requests.
The HTTP response After a successful and completed call to the
send method of the XMLHttpRequest, if the server response was valid XML and the Content-Type
header sent by the server is understood by the user agent as an Internet media type for
XML, the responseXML property of the XMLHttpRequest object will contain a DOM document object.
Another property, responseText will contain the response of the server in plain text by
a conforming user agent, regardless of whether or not it was understood as XML.
Cross-domain requests In the early development of the World Wide
Web, it was found possible to breach users' security by the use of JavaScript to exchange
information from one web site with that from another less reputable one.
All modern browsers therefore implement a same origin policy that prevents many such
attacks, such as cross-site scripting.
XMLHttpRequest data is subject to this security policy, but sometimes web developers want
to intentionally circumvent its restrictions.
This is sometimes due to the legitimate use of subdomains as, for example, making an XMLHttpRequest
from a page created by foo.example.com for information from bar.example.com will normally
fail.
Various alternatives exist to circumvent this security feature, including using JSONP, Cross-Origin
Resource Sharing or alternatives with plugins such as Flash or Silverlight.
Cross-origin XMLHttpRequest is specified in W3C's XMLHttpRequest Level 2 specification.
Internet Explorer did not implement CORS until version 10.
The two previous versions offered similar functionality through the XDomainRequest API.
It is now supported by all modern browsers.
The CORS protocol has several restrictions, with two models of support.
The simple model does not allow setting custom request headers and omits cookies.
Further, only the GET and POST request methods are supported, and POST only allows the following
MIME types: "text/plain", "application/x-www-urlencoded" and "multipart/form-data".
Only "text/plain" was initially supported.
The other model detects when one of the non-simple features are requested and sends a pre-flight
request to the server to negotiate the feature.
See also WebSocket
Hypertext Transfer Protocol Representational State Transfer
Ajax References
External links Specifications
XMLHttpRequest specification from W3C XMLHttpRequest level 2 specification from
W3C Cross-Origin Resource Sharing
Progress Events 1.0
Browsers MSDN Library
Specification of the XMLHttpRequest object for Microsoft developers
XDomainRequest
Specification of the XMLHttpRequest object for Mozilla developers
Specification of the XMLHttpRequest object for Opera developers
Other New Tricks in XMLHttpRequest2, online tutorial
by Eric Bidelman "Attacking AJAX Applications", a presentation
given at the Black Hat security conference.
Discusses several issues involving XHR and the future of cross-domain Ajax.
[1] Support end of Windows XP