The Basics of HTTP - Part 1 - What is HTTP

I have been dreading this first post about HTTP. So I am going to start it off simply by letting Wikipedia articulate what HTTP is, then I will try to put it into my own words.

Wikiepedia says:

Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems.

HTTP is a request/response standard between a client and a server. A client is the end-user, the server is the web site. The client making a HTTP request--using a web browser, spider, or other end-user tool--is referred to as the user agent. The responding server--which stores or creates resources such as HTML files and images--is called the origin server.

What this means to me

When it is said that HTTP is an "application-level protocol" that means that it belongs to the seventh layer of the Open Systems Interconnection (OSI) model, known as the Application Layer. I am not going to delve into the OSI model, because it is boring. But I will say that the Application Layer is the one closest to the user and is where most of the familiar protocols (Telnet, FTP, HTTP, SMTP) work.

Bored yet? Good. Moving on.

HTTP is usually found working on TCP/IP (Transmission Control Protocol/Internet Protocol). Though it can work on other protocols, TCP and IP are the protocols we are concerned with as web developers. An HTTP server makes a TCP connection on port 80 (or port 443 for SSL) and listens for a client to make an HTTP Request. When it receives that request, it responds with an HTTP Response that includes a status coe letting the client know if the request was successful or not, and if successful, includes the resource that was requested.

Request/Response

HTTP uses a message passing methodology similar to that of 13-year-old girls in science class.

The client (in many cases a web browser) creates a properly formatted HTTP request message and sends it to the server. The server receives the message, gets the requested resource or performs the requested action and returns the requested resource or results of the action along with a status code and explanation.

Here is a diagram of how that works. You can color it if you would like.
State Diagram of an HTTP Request/Response

It really is a simple process, though there are some details that we have not covered yet. We will get to hose in some future posts.

Conclusion

In future posts I will discuss, in more detail, how requests and responses are formed, what request methods are used by clients, and how the server responds to each, and we will look at some of the status codes and how to interpret them.

Comments
Ben Nadel's Gravatar Good post. I think it will be interesting to talk about status codes and which ones should be returned depending on what your ColdFusion application is doing. For example, if someone requests a page that requires a login and the user is presented with a login (rather than the requested content), do they get a 401 or something?
# Posted By Ben Nadel | 2/23/09 8:05 PM
Jason Dean's Gravatar @Ben, Good comment, and good question. I am looking forward into delving deeper into the Status codes and the request methods. I'll be curious to look at your question specifically.
# Posted By Jason Dean | 2/23/09 9:28 PM
Ben Nadel's Gravatar @Jason,

No worries. I think status codes are things that we (ie. I) rarely think about. Some times that we might want to return a special code:

1. When a login page is presented (rather than requested content).

2. When an error page is presented (friendly one rather than CF error).

3. When a "Down for Maintenance" page is presented.
# Posted By Ben Nadel | 2/24/09 5:41 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner