XMLHttpRequest

From Wikipedia, the free encyclopedia

This article needs additional citations for verification. Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (June 2008)

This article contains instructions, advice, or how-to content. The purpose of Wikipedia is to present facts, not to train. Please help improve this article either by rewriting the how-to content or by moving it to Wikiversity or Wikibooks.

XMLHttpRequest (XHR) is a DOM API that can be used inside a web browser scripting language, such as JavaScript, to send an HTTP or an HTTPS request directly to a web server and load the server response data directly back into the scripting language ^[1]. Once the data is within the scripting language, it is available as both an XML document, if the response was valid XML markup ^[2], and as plain text ^[3]. The XML data can be used to manipulate the currently active document in the browser window without the need of the client loading a new web page document. Plain text data can be evaluated within the scripting language to manipulate the document, too; in the example of JavaScript, the plain text may be formatted as JSON by the web server and evaluated within JavaScript to create an object of data for use on the current DOM.

This type of AJAX architecture should not be confused with (XDR) XDomainRequest which is a lightweight form of the XMLHttpRequest design by Microsoft which doesn't utilize XML-RPC. ^[4]

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. Examples of these web applications include Gmail, Google Maps, Bing Maps for Enterprise, the MapQuest dynamic map interface, Facebook, and others.

[edit] History and support

The concept behind the XMLHttpRequest object was originally developed by Microsoft as a server side API call for Outlook Web Access 2000.^[5] This API later became an ActiveX object called XMLHTTP, which was shipped with the release of Internet Explorer 5.0^[6], accessible via JScript, VBScript and other scripting languages supporting ActiveX objects.

The Mozilla project reimplemented the concept of the XMLHTTP ActiveX object as a native scripting object called XMLHttpRequest. This object has been available since the release of Mozilla 1.0 in 2002, which quickly became the de facto standard amongst browsers, later implemented by Apple in Safari 1.2, Konqueror, Opera Software in Opera 8.0, and iCab in 3.0b352. Microsoft added support for the native XMLHttpRequest object in Internet Explorer 7.0.^[6]

On April 5, 2006 the World Wide Web Consortium (W3C) released the first draft specification for the object in an attempt to create an official web standard.^[7] 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 draft specification is based upon existing popular implementations, to help improve and ensure interoperability of code across web platforms. As of May 2009, the W3C standard was still a work in progress.

The World Wide Web Consortium has also published a Working Draft for XMLHttpRequest Level 2 on February 25th, 2008. Level 2 consists of extended functionality to the XMLHttpRequest object, including, but not currently limited to, progress events, support for cross-site requests, and the handling of byte streams. As of May 2009, the W3C standard was still a work in progress. ^[8]

Traditionally, there have been other methods to achieve a similar effect of server dynamic applications using scripting languages and/or plugins:

• Invisible IFrames (or Netscape Navigator's equivalent ilayers)
• Remote Scripting
• Netscape's LiveConnect
• Microsoft's ActiveX
• Microsoft's XML Data Islands
• Adobe Flash Player or Shockwave
• Java applets

In addition, the World Wide Web Consortium has several recommendations that also allow for dynamic communication between a server and user agent, though few of them are well supported.^{[citation needed]} These include:

• The object element defined in HTML 4 for embedding arbitrary content types into documents, (replaces inline frames under XHTML 1.1)
• The Document Object Model (DOM) Level 3 Load and Save Specification.^[9]

[edit] HTTP request

The following is how a request using the XMLHttpRequest object functions in 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.

[edit] 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 upto five parameters, but as little as two, to initialize a request.

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. ^[10]

• GET (Supported by IE7+, Mozilla 1+)
• POST (Supported by IE7+, Mozilla 1+)
• HEAD (Supported by IE7+)
• PUT
• DELETE
• OPTIONS (Supported by IE7+)

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") will hang execution of the current script until the request has been completed, not invoking the onreadystatechange event listener.

The fourth and fifth parameters are the URI user and password, respectively. These parameters are not required and should default to the current user and password of the document if not supplied, as defined by the W3C draft.

[edit] 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. 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.

[edit] 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. 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 stringify the parameter, then the parameter should be ignored.

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.

[edit] 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.

• 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 major user agents are inconsistent with the handling of the onreadystatechange event listener.

[edit] 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 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.

[edit] Cross-site HTTP requests

Modern browsers are in the process of implementing cross-site XMLHttpRequests, notably Firefox 3.5. ^[11] An alternate technique for cross-site HTTP requests is AJAST.

[edit] Known problems

[edit] Caching

Most of the implementations also realize HTTP caching. Internet Explorer and Firefox do, but there is a difference in how and when the cached data is revalidated. Firefox revalidates the cached response every time the page is refreshed, issuing an "If-Modified-Since" header with value set to the value of the "Last-Modified" header of the cached response.

Internet Explorer does so only if the cached response is expired (i.e., after the date of received "Expires" header). This raises some issues, since a bug exists in Internet Explorer, where the cached response is never refreshed.^[12]

It is possible to unify the caching behavior on the client. The following script illustrates an example approach (See the history and support section for compatibility with versions of Internet Explorer prior to 7.0):

var request = new XMLHttpRequest();
request.open("GET", url, false);
request.send(null);
if(!request.getResponseHeader("Date")) {
 var cached = request;
 request = new XMLHttpRequest();
 var ifModifiedSince = cached.getResponseHeader("Last-Modified");
 ifModifiedSince = (ifModifiedSince) ?
 ifModifiedSince : new Date(0); // January 1, 1970
 request.open("GET", url, false);
 request.setRequestHeader("If-Modified-Since", ifModifiedSince);
 request.send("");
 if(request.status == 304) {
 request = cached;
 }
}

In Internet Explorer, if the response is returned from the cache without revalidation, the "Date" header is an empty string. The workaround is achieved by checking the "Date" response header and issuing another request if needed. In case a second request is needed, the actual HTTP request is not made twice, as the first call would not produce an actual HTTP request.

The reference to the cached request is preserved, because if the response code/status of the second call is "304 Not Modified", the response body becomes an empty string ("") and then it is needed to go back to the cached object. A way to save memory and expenses of second object creation is to preserve just the needed response data and reuse the XMLHttpRequest object.

The above script relies on the assumption that the "Date" header is always issued by the server, which should be true for most server configurations. Also, it illustrates a synchronous communication between the server and the client. In case of asynchronous communication, the check should be made during the callback.

This problem is often overcome by employing techniques preventing the caching at all. Using these techniques indiscriminately can result in poor performance and waste of network bandwidth.

If script executes operation that has side effects (e.g. adding a comment, marking message as read) which requires that request always reaches the end server, it should use POST method instead.

[edit] Workaround

Internet Explorer will also cache dynamic pages and this is a problem because the URL of the page may not change but the content will (for example a news feed). A workaround for this situation can be achieved by adding a unique time stamp or random number, or possibly both, typically using the Date object and/or Math.random().

For simple document request the query string delimiter '?' can be used, or for existing queries a final sub-query can be added after a final '&' – to append the unique query term to the existing query. The downside is that each such request will fill up the cache with useless (never reused) content that could otherwise be used for other cached content (more useful data will be purged from cache to make room for these one-time responses).

A better workaround can be achieved by adding meta tags to dynamic pages in order to make them no-cachable:

<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="-1" />

[edit] Reusing XMLHttpRequest Object in IE

In IE, if the open method is called after setting the onreadystatechange callback, there will be a problem when trying to reuse the XHR object. To be able to reuse the XHR object properly, use the open method first and set onreadystatechange later. This happens because IE resets the object implicitly in the open method if the status is 'completed'. For more explanation of reuse: Reusing XMLHttpRequest Object in IE. The downside to calling the open method after setting the callback is a loss of cross-browser support for readystates. See the quirksmode article.

[edit] Cross-browser support

Microsoft developers were the first to include the XMLHttp object in their MSXML ActiveX control. Developers at the open source Mozilla project saw this invention and ported their own XMLHttp, not as an ActiveX control but as a native browser object called XMLHttpRequest. Konqueror, Opera and Safari have since implemented similar functionality but more along the lines of an identical XMLHttpRequest. Some Ajax developer and run-time frameworks only support one implementation of XMLHttp while others support both. Developers building Ajax functionality from scratch can provide if/else or try/catch logic within their client-side JavaScript to use the appropriate XMLHttp object as well. Internet Explorer 7 added native support for the XMLHttpRequest object, but retains backward compatibility with the ActiveX implementation.^[6] To avoid excess conditionals, see the source code in the history and support section.

[edit] Frameworks

Because of the complexity of handling cross-browser distinctions between XMLHttpRequest implementations, a number of Ajax frameworks have emerged to abstract these differences into a set of reusable programming constructs.

[edit] References

[edit] See also

• Ajax (programming)
• HTTP
• Representational State Transfer (REST)

[edit] External links

This section includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improve this article by introducing more precise citations where appropriate. (June 2008)

[edit] Documentation/Browser implementations

• The XMLHttpRequest Object — W3C Working Draft
• Apple Safari 1.2
• Microsoft IXMLHTTPRequest
• Mozilla XML Extras
• Opera 9

[edit] Cross-Browser implementations

• Standard-compliant cross-browser implementation of XMLHttpRequest object

[edit] Tutorials

• Very Dynamic Web Interfaces
• Ajax tutorial for creating client-side dynamic web pages

[edit] Security

• "Attacking AJAX Applications", a presentation given at the Black Hat security conference. Discusses several issues involving XHR and the future of cross-domain AJAX.