https://en.wikipedia.org/wiki/XMLHttpRequest
XMLHttpRequest (XHR) is an API in the form of an object whose methods transfer data between a web browser and a web server. The object is provided by the browser's JavaScript environment. Particularly, retrieval of data from XHR for the purpose of continually modifying a loaded web page is the underlying concept of Ajax design. Despite the name, XHR can be used with protocols other than HTTP and data can be in the form of not only XML, but also JSON, HTML or plain text.
WHATWG maintains an XHR standard as a living document. Ongoing work at the W3C to create a stable specification is based on snapshots of the WHATWG standard.
XMLHttpRequest (XHR) is an API in the form of an object whose methods transfer data between a web browser and a web server. The object is provided by the browser's JavaScript environment. Particularly, retrieval of data from XHR for the purpose of continually modifying a loaded web page is the underlying concept of Ajax design. Despite the name, XHR can be used with protocols other than HTTP and data can be in the form of not only XML, but also JSON, HTML or plain text.
WHATWG maintains an XHR standard as a living document. Ongoing work at the W3C to create a stable specification is based on snapshots of the WHATWG standard.
History
The concept behind the XMLHttpRequest object was originally created by the developers of Outlook Web Access (by Microsoft) 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.
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. Microsoft added the XMLHttpRequest object identifier to its scripting languages in Internet Explorer 7.0 released in October 2006.
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.
With the advent of cross-browser JavaScript libraries such as jQuery, developers can invoke XMLHttpRequest functionality indirectly.
Standards
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 W3C also 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. At the end of
2011, the Level 2 specification was abandoned and absorbed into the
original specification.
At the end of 2012, the WHATWG took over development and maintains a living standard using Web IDL. W3C's current drafts are based on snapshots of the WHATWG standard.
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 (supported by Internet Explorer 7 (and later), Mozilla 1+)
- POST (supported by IE7 (and later), Mozilla 1 (and later))
- HEAD (supported by IE7 (and later))
- PUT
- DELETE
- OPTIONS (supported by IE7 (and later))
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 ("true") 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 ("false") however will block execution of
the current script until the request has been completed, thus not
invoking the onreadystatechange event listener. Note that
starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey
2.27), Blink 39.0 (Chrome), and Edge 13, synchronous requests on the
main thread have been deprecated due to their negative impact on the
user experience as they will cause freezing of the UI while the thread
performs the request.
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.
var xmlhttp;
if (window.XMLHttpRequest) {
xmlhttp = new XMLHttpRequest();
xmlhttp.open("GET", filepath, false);
xmlhttp.send(null);
}
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:
- State Description
0 The request is not initialized. 1 The request has been set up. 2 The request has been sent. 3 The request is in process. 4 The request is completed.
- After the open method has been invoked successfully, the readyState property of the XMLHttpRequest object should be assigned a value of 1 (OPENED).
- 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 (HEADERS_RECEIVED).
- Once the HTTP response content begins to load, the readyState property of the XMLHttpRequest object should be assigned a value of 3 (LOADING).
- Once the HTTP response content has finished loading, the readyState property of the XMLHttpRequest object should be assigned a value of 4 (DONE).
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.
var request = new XMLHttpRequest();
request.onreadystatechange = function () {
var DONE = this.DONE || 4;
if (this.readyState === DONE){
alert(this.readyState);
}
};
request.open('GET', 'somepage.xml', true);
request.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
// Tells server that this call is made for ajax purposes.
// Most libraries like jQuery/Prototype/Dojo do this
request.send(null); // No data needs to be sent along with the request.
The HTTP response
After a successful and completed call to the send method of the XMLHttpRequest, if the server response was well-formed 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
(CORS) 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 (8 and 9) offered similar functionality through the
XDomainRequest (XDR) API. CORS is now supported by all modern browsers
(desktop and mobile).
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 HEAD, 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.
Fetch alternative
Program flow using asynchronous XHR callbacks can present difficulty with readability and maintenance. ECMAScript 2015 (ES6) added the promise construct to simplify asynchronous logic. Browsers have since implemented the alternative
fetch()
interface to achieve the same functionality as XHR using promises instead of callbacks.
Fetch is also standardized by WHATWG.