Understanding Ajax: Page 2 | WebReference

Understanding Ajax: Page 2


Understanding Ajax: Getting Started

2.1.3 XMLHttpRequest::setRequestHeader()

There are many different cases in which setting a header on a request might be useful. The most common use of setRequestHeader() is to set the Content-type, because most Web applications already know how to deal with certain types, such as URLencoded. The setRequestHeader method signature takes two parameters: the header to set and its value:

Because requests sent using XMLHttpRequest send the same standard headers, including cookie headers and HTTP authentication headers, as a normal browser request, the header name will usually be the name of the HTTP header that you want to override. In addition to overriding default headers, setRequestHeader is useful for setting custom, application-specific headers. Custom headers are generally prefixed with X- to distinguish them from standard ones. The following example makes a synchronous GET request adding a header called X-foo to test.php. If test.php contains <?php var_dump($_SERVER); ?>, you will see the submitted header in the alert:

2.1.4 XMLHttpRequest::getResponseHeader() and getAllResponseHeaders()

The getResponseHeader method allows you to get a single header from the response; this is especially useful when all you need is a header like Content-type; note that the specified header is case-insensitive. The method signature is as follows:

getAllResponseHeaders returns all the headers from the response in a single string; this is useful for debugging or searching for a value. The following example makes a synchronous GET request to test.html. When the client receives a response, the Content-type is alerted and all the headers are alerted:

2.1.5 Other XMLHttpRequest Methods

All browsers implement an abort() method, which is used to cancel an in-progress asynchronous request. (An example of this is shown in the "Sending Asynchronous Requests" section in this chapter.) Mozilla-based browsers also offer some extra methods on top of the basic API; for instance, addEventListener() and removeEventListener() provide a way to catch status events without using the on* properties. There is also an overrideMimeType() method that makes it possible to force the Content-type to text/xml so that it will be parsed into a DOM document even if the server doesn’t report it as such. The Mozilla-specific methods can be useful in certain circumstances, but in most cases, you should stay away from them because not all browsers support them.

2.1.6 XMLHttpRequest Properties

XMLHttpRequest provides a number of properties that provide information or results about the request. Most of the properties are self-explanatory; you simply read the value and act on it. The on* properties are event handlers that are used by assigning a function to them. A list of all the properties follows:

  • status. The HTTP status code of the request response.
  • statusText. The HTTP status code that goes with the code.
  • readyState. The state of the request. (See Table 2-1 in the next section of this chapter for values.)
  • responseText. Unparsed text of the response.
  • responseXML. Response parsed into a DOM Document object; happens only if Content-type is text/xml.
  • onreadystatechange. Event handler that is called when readyState changes.
  • onerror. Mozilla-only event handler that is called when an error happens during a request.
  • onprogress. Mozilla-only event handler that is called at an interval as content is loaded.
  • onload. Mozilla-only event handler that is called when the document is finished loading.


Mozilla resets event handlers, such as onreadystatechange, after a request is completed, so you need to reset them if you are making multiple calls with the same object.