XMLHttpRequest


XMLHttpRequest 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 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
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.
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. Note that starting with Gecko 30.0, Blink 39.0, 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

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
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
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:
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.
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 ;
request.open;
request.setRequestHeader; // Tells server that this call is made for ajax purposes.
// Most libraries like jQuery/Prototype/Dojo do this
request.send; // 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 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. CORS 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 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 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.