Section 2a.2. Checking the request s status


2a.2. Checking the request's status

Even though you probably didn't realize it, the browser did try to tell you something went wrong. The browser uses a property of your request object, called status, that you can use to determine whether something went wrong.

Here's how you can check the status of a request:

 function updatePage()   { You've seen most of this code in Chapter 2... this is the updatePage() callback function.    if (request.readyState == 4) {      if (request.status == 200  ) { Here's a new property of the request object. It reports the status code   from the server. The server sends a status of "200" when everything is OK.       var customerAddress = request.responseText;       document.getElementById("address").value = customerAddress;    } else      alert("Error! Request status is " + request.status); In case the status isn't OK, let's output an error message to the screen with the request's status.    } } 

Just Do It

Add the code shown above to your updatePage() function in pizza.html. Now reload your page in a web browser, and enter a phone number. When you change the phone number field, and then move to another field, what happens? Write down the server's status code in the blank:

Now fix the request URL in getCustomerInfo() so that it points to the correct script on the Break Neck server. Reload your page, and see what happens. Did you get another status code? Write down what happened when you used the correct URL:


Wait a second. If there's a mistake in the request URL, is the server even getting our request?

The request URL is a relative URL

Remember the first part of the request URL from getCustomerInfo()?

 lookupCustomer.php We've left off the "phone" request parameter to make this a little shorter. 

This is a relative URL, and doesn't include the domain name of the server that the request should be sent to. So what domain does the browser send this request to? The browser will automatically use the same domain that it requested the pizza.html web page from. So if you entered http://www.breakneckpizza.com/pizza.html to view the Break Neck order form, your web browser would turn the relative URL above into an absolute URL, like this:

 http://www.breakneckpizza.com/lookupCustomer.php 

So the request gets sent to the same server that your browser downloaded the pizza order form from. Even if the program to run on the server is ... mis-spelled ... the request will still get sent by your browser to the right server.

This program could be a Java servlet, or a PHP script, or a Ruby component, or any other bit of code running on the the server.

 This is an absolute URL.   It has a domain name... ...and a path to a program or file on the server. http://www.boardsrus.com/getUpdatesBoardSales.php This is an relative URL. It has no domain name... /getUpdatesBoardSales.php ...and just the path to the program or file on the server. 

OK, so I see how it's getting to the server. But if the server can't find the program in the request URL to run, why does the browser still run our callback? Shouldn't it report an error or something?

The browser always runs your callback... ...and it did report an error.

The browser will always run your callback, because that gives you a chance to respond to whatever the server did to handle your request. Since you're using an asynchronous request, the callback is the only way you have to write code that can deal with a server's response. To help you out with dealing with that response, the browser gives you both the state of your request, and the status of your request.

There's a different between the state of your request, and the status of the same request. Your request's ready state tells the browser what stage of processing the request is in: initialization, processing, completed, etc.. But just because a request is complete doesn't mean that the request was successful... that involves the status of the request.

A server reports any problems with a request by using a status code. The status code indicates what happened during the request, and whether things went as you intended. So even if a request was completed, you still need to make sure the status code for the request indicates that everything went OK.




Head Rush Ajax
Head Rush Ajax (Head First)
ISBN: 0596102259
EAN: 2147483647
Year: 2004
Pages: 241

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net