concept response header in category javascript

This is an excerpt from Manning's book CORS in Action: Creating and consuming cross-origin APIs. Login to get full access to this book.

Once the browser receives the response, it checks the response headers to verify that the cross-origin request is valid. If the request isn’t valid, the browser will log an error to the console, then fire the XMLHttpRequest’s onerror event. But because the response here is valid, the browser fires the XMLHttpRequest’s onload event:

xhr.onload = function() {
  var data = JSON.parse(xhr.responseText);

  if (data.stat == 'ok') {
    var photosDiv = document.getElementById('photos');
    photosDiv.innerHTML = '';
    var photos = data.photos.photo;
    for (var i = 0; i < photos.length; i++) {
      var img = document.createElement('img');
      img.src = photos[i].url_q;
      photosDiv.appendChild(img);
    }
  } else {
    alert(data.message);
  }
};

copy

This code parses the response text into a JavaScript Serialized Object Notation (JSON) object, grabs the images from the object, and displays them on the page. In addition to the response text, the XMLHttpRequest object also has properties for the HTTP status, HTTP status text, and methods that retrieve response headers.

We’ll start by having you add a login page to the sample blogging app. The login page will include a cookie that needs to be validated in order to delete blog posts. Next, you’ll modify the sample to display a response header on the page. By setting the Access-Control-Allow-Credentials and Access-Control-Expose-Headers headers on the response, the sample app will enable support for each of these features.

5.2. Exposing response headers to the client

All the CORS-specific headers introduced so far handle how an incoming request behaves. The Access-Control-Allow-Methods header specifies the valid request methods, while the Access-Control-Allow-Headers header specifies the valid request headers. Now we’ll turn our attention to the HTTP response behavior. Specifically, you’ll learn how client JavaScript code can access the response headers.

By now you may be discerning a pattern to how CORS works: for the client to do anything, the server must first give its permission. This behavior extends to the headers in the HTTP response. Response headers are the headers the server sends back to the client. Figure 5.7 shows a request from the sample’s client.html page to the API. The response headers are the headers from the API back to the client.

Figure 5.7. The distinction between request and response headers

The XMLHttpRequest object exposes two methods for reading the response headers: getResponseHeader and getAllResponseHeaders. Same-origin requests can use these methods to read headers from the response. But cross-origin requests have limitations on which response headers can be viewed by the client. By default, only a few response headers are visible to clients on cross-origin requests (these are called simple response headers; see the sidebar “Simple response headers” later in the chapter for more details). The server must give its permission to read any of the other response headers. Let’s modify the sample app to read one of these headers.

Figure 5.8. X-Powered-By response header

This is an excerpt from Manning's book Prototype and Scriptaculous in Action. Login to get full access to this book.

This is why we set up a response header to return the validation status—we didn’t want to use a response error code, and we didn’t want to use the response body. We named the header “x-valid”, using the prefix “x-” to avoid accidentally stepping on a response header name defined by the HTTP protocol (none of which begin with “x-”), and we can use the getResponseHeader() method of XMLHttpRequest to get its value.

To set a response header in PHP, we call the header() function. To set the response MIME type to text/xml, for example, we would write this: