You’re probably already quite familiar with the 404 Status Code for resources that aren’t found.  Knowing the status codes can give you some pretty powerful insight into the server side of your app when things go wrong.All Errors fit into the following categories

•  1XX Informational Codes
• 2XX Success Codes
• 3XX Redirection
• 4XX Client Error
• 5XX Server Error

The Codes in More Depth Informational Codes 1XX Informational Codes are unique in that they return no body and terminate immediately after the headers.  The most common encountered is “100 Continue”.   Continue responses are roughly equivalent to the server saying I haven’t forgotten about you.  They imply that everything is fine but that the server isn’t prepared to issue a response yet.  If the client is still transmitting data, the client should continue to do so.  If the client is done transmitting, it can ignore the response.  The server is required to send a normal response in the future.   Success Codes 2XX The most common code in this category is 200 OK.  This is what you expect to receive in any http transaction.  Some other common codes are:

• 202 Accepted: The Server has accepted the request but hasn’t finished processing.  It should contain a pointer to more information but isn’t required to do so. 
• 204 No Content: The Server has completed the request but there is no need to return a body entity.  There may be new meta-data to transmit.  Clients should not change their document view when this code is received.
• 206 Partial Content: On Get Requests, this means that the originating GET request included a Range header field and only that range is returned.

3XX Redirection CodesRedirection codes communicate that the previous request was insufficient to complete the request and further action needs to be taken by the client to do so.

• 301 Moved Permanently: The resource has been permanently relocated to a different URI.  Any future references should use this new URI.  The Response Body should contain a short note in HTML with a link to the new location.
• 307 Temporary Redirect: The resource is temporarily relocated at a new URI.  Future references should continue to use the original URI.

4XX Client Error  While we’re all familiar with the infamous 404 not found error.  There are several other client errors that can be encountered on a regular basis.

• 400 Bad Request: The HTTP Request is malformed.  The Client should not repeat the request without modifications
• 401 Unauthorized: Authentication is needed to access the resource
• 403 Forbidden: The Server understood the request but for some reason is refusing to fill it.
• 408 Request Timeout: The Client didn’t complete request in the time the server was willing to give it.  The client may try again some other time

Error Code 402 is a unique case.  It is reserved for future use and indicated Payment Required

500 Server ErrorsWhile 400 errors imply that the Client was the source of the fault, 500 errors imply a problem with the server.  There are 2 that I find a need to wrangle with regularly

•  500 Internal Server Error: Something went wrong and the server is crying uncle
• 503 Service Unavailable: The Server is experiencing technical difficulties.  I usually this is caused by a runaway memory leak in apache or by a sudden spike in load that overwhelms the stack.

While I in no way intend for this to be a comprehensive guide to the http response codes, there’s a much better one available from the W3C.  I thought this might provide a handy refresh and reference.  

It’s official. Web based and Desktop applications have duked it out for over 10 years and it’s pretty obvious that the web is about to run a victory lap. Sure, we still use traditional desktop apps and we may do so for the next 10 years or longer, but web based applications are clearly the winner. The smoother deployment, persistent centralized storage and more consistent deployment environment give web based systems a darwinian advantage in a market ecosystem that favors rapid adaptation and flexibility.Unfortunately, despite its benefits, web based software has several crippling short comings.

• Only available when there’s a net connection
• Reduced client side performance
• Browser quirks
• Bandwidth limitations
• Less flexible environment
• Security sandboxes

Improving technology stands a chance of removing or eliminating many of these issues in the long term. In the short and mid range, hybrid technologies are emerging that will help get us from point A to point B. Site specific browsers, offline storage, desktop integration technologies, mobile sites and widgets all have a roll to play in the years ahead. The web has definitely come full circle and as web developers we need to prepare ourselves for the next frontier of development: the desktop.

As AJAX & Javascript developers we use HTTP daily, but we sometimes forget the actual data that flows down the wire. Our frameworks, toolkits and browsers have abstracted it all away. Although a knowledge of http is not as important as it used to be, it still comes in handy things go pear shaped and you need to debug. Here is the first in a collection of short introductions to HTTP.

So any HTTP request follows a relatively simple format:

• A first line
• An optional collection of header lines
• CRLF ( An Empty Line);
• Message body

All initial lines and headers need to end in CRLF although the specification calls for lines ending LF be gracefully handled. (CR is ASCII Value 13 LF is ASCII Value 10 );

The Initial Request Line

For Requests

A request line has three parts, the method of the request, the path and a reference to the version of HTTP being used.

For example:

POST /blog/action/do_something.php HTTP/1.1

The acceptable actions are GET, POST & HEAD with GET being the most common. Method names are always written in uppercase. Similarly, the HTTP version always takes the demonstrated form.

Response

The initial response line is also known as the status line and contains the HTTP version, followed by a status code and an English “reason phrase” for the code. For example:

HTTP/1.1 301 Moved Permanently

Header Lines

Header lines provide meta-information about the request. If a message body is included they usually contain a Content-Type that returns the mime type of the body and Content-Length which returns the size of the body in bytes.

In HTTP 1.1, the Host header line is required to enable servers to differentiate between various top level domains that may reside within the server when processing requests.

Message Body

The message body contains the actual meat of the transaction. Usually this is going to be an html or xhtml document but could contain any binary or other file.

Next Time: Get Post & Head