HTTP Errors

HTTP Errors are caused by problems with the HTTP request, HTTP server, or application server. HTTP errors are delivered to the requesting client via a status code in the HTTP response.

A 404 status is a common example of an HTTP error. It indicates that the resource specified in the URL cannot be found. The HTTP header shown in the following code snippet is an example of the raw output from an HTTP server when it cannot find the requested resource.

HTTP/1.1 404 Not Found
Date: Sat, 04 Feb 2012 18:32:25 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 248
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

You can fi nd the status code in the fi rst line of the response. An HTTP response may have an associated message body containing friendly human readable content describing what happened. You should not use the presence or absence of a response body as an indicator as to whether the HTTP request succeeded.

There are fi ve categories of HTTP errors:

Informational 100-level - Solely informational from the HTTP server and indicates that the processing of the request will continue but with a caveat.
Successful 200-level - The server processed the request. Each 200-level status indicates a different result of the successful request. For example, a 204 indicates that the request was successful, but no payload was returned to the client.
Redirection needed 300-level - Indicates that the client must perform some action to continue the request because the desired resource has moved. The synchronous request methods of the URL loading system handle redirects automatically without your code being notified. If your application needs to do custom handling with redirects, it should use asynchronous requests.
Client Errors 400-level - Indicates that the client has sent erroneous data that the server cannot correctly handle. For example, an unknown URL or a malformed HTTP header causes errors in this range.
Downstream errors 500-level - Indicates that an error occurred between the HTTP server and any downstream application servers. For example, if the web server calls a JavaEE application server and the servlet fails with a NullPointerException, then the client receives a 500-level error.

The URL loading system in iOS handles the parsing of HTTP headers and makes it easy to retrieve the HTTP status. If your code makes a synchronous call using an HTTP or HTTPS URL, then the returned response object will be an instance of NSHTTPURLResponse. The NSHTTPURLResponse object has a statusCode property that returns the numeric HTTP status of the request. The following code demonstrates the validation of both the NSError object and the return of a successful status from the HTTP server.

NSHTTPURLResponse *response=nil;
NSError *error=nil;
NSData *myData = [NSURLConnection sendSynchronousRequest:request
				     returningResponse:&response
						error:&error];
// Check the return
if ((!error) && ([response statusCode] == 200)) {
    // looks like things worked
} else {
    // things broke, again.
}

If the URL of the request could be something other than HTTP, the application should validate that the response object is actually an NSHTTPURLResponse. The preferred method to validate the type of the object is using the isKindOfClass: method on the returned object, as shown in the following code:

if ([response isKindOfClass:[NSHTTPURLResponse class]]) {
    // It is a HTTP response, so we can check the status code
   ...

For definitive information on HTTP status codes see W3 RFC 2616 at http://www.w3.org/Protocols/rfc2616/rfc2616.html.

[Previous] [Contents] [Next]

HTTP Errors

In this tutorial: