HTTP is more than just a transfer protocol!

Ok, we all know what the Hypertext Transfer Protocol is and what it can do. .... Or do we?

I consider HTTP to be part of the application stack and as such advocate for the full use of HTTP. This means using HTTP's functionality whenever possible, rather than re-inventing things at a higher layer in the application.

One of the simplest examples of features that HTTP provides is the ability to tell a client that what has been requested has moved to a new location, or is gone. The classic way of telling a client that a resource has moved, if the new location is known, is with either a 301 (permanent) or a 302 (temporary) redirect. These redirects tell the client that it needs to re-request the desired resource at the new location. Since these redirects happen at the HTTP level, they happen at the earliest opportunity. This means that your HTTP redirects operate before and are thus faster than both HTML <meta http-equiv...> and JavaScript document.location redirect methods. HTTP redirects are faster because they operate before the client has downloaded the resource, much less parsed and processed it. As a further benefit, HTTP redirects have the added advantage that (many) search engines will honor the redirect, thereby chasing the resource to it's new location, something they can't / won't do with either HTML <meta http-equiv...> or JavaScript document.location redirects. One very common use of the 301 redirects is to redirect people from http://example.com/ to http://www.example.com/ (or vice versa). This allows web content to seen at a consistent web site, in a search engine friendly manner. For another (selfish / lacy) use of HTTP 302 redirects, see my HTTP redirects are your friend post.

HTTP also offers the 401 "unauthorized" status code that can be used to implement authentication to a web site. - Before you say "but you can't log out of .htpasswd sites...", STOP! Because "Yes, you can log out of .htpasswd protected sites, with out closing your browser. What's more, is it's easy to do. (There will be a future post about how to do this and more, with examples.) - This becomes both apparent and somewhat obvious when you give HTTP it's due respect.

Did you know that HTTP has specifications to help optimize the performance of a website? Yep, ETags and Last-Modified headers. What good are these, well, they can be used by your client, or caching proxies, etc. to help determine if they even need to bother with re-downloading content. Or said another way, these HTTP specifications enable your client to be intelligent about the data that it already has. For example, I use the same CSS file on all of the pages on this site. However, because of judicious use of HTTP features, your browser only needs to download it once and subsequently periodically check to see how fresh (current) it is. These freshness checks are extremely small compared to downloading the entire CSS page again. What's even better is that browsers can check the freshness of a page simply by adding an HTTP header to the request. There's no need to perform a separate step, followed by different cations depending on the result. These and MANY more features are BUILT IN to HTTP.

The problem is that many people don't know what the Hypertext Transfer Protocol is and what it can do. Instead, many people consider HTTP to be a simple transport protocol that they have build on top of, re-invent things along the way.

</soapbox>

Now that you are done, take a moment to go read Ryan Tomayko's "On HTTP Abuse" article which had me mentally cheering him on as I read it. Additionally, you should read Jon Udell's "End HTTP abuse" InfoWorld article which Ryan's article is in response to / agreement with.