In this article we'll look inside the messages exchanged in an HTTP transaction. We'll learn about message types, HTTP headers, and status codes. Understanding what is inside an HTTP message is vitally important for developers who work on the web. Not only will you build better applications by responding with the right types of messages, but you'll also be able to spot problems and debug issues when web applications aren't working.
The Series:Part I: Resources
Part II: Messages (you are here)
Part III: Connections
Part IV: Architecture
Part V: Security
Requests and Responses
Imagine walking up to someone in an airport and asking "Do you know what time it is?". In order for the person to respond with the correct time, a few things have to be in place. First, the other person has to understand your question, because if they do not know English, they might not make any response. Secondly, the other person will need access to a watch or time keeping device.
This airport analogy is similar to how HTTP works. You need a resource from some other party (the resource being information about the time of day). So, you make a request to the other party using a language and vocabulary the other party might understand. If the other party understands your request and has the resource available, they can reply. If they understand the request, but they don't have the resource, they can still respond and tell you they can't help you. If they don't understand what you are saying, you might not get any response.
HTTP is a request and response protocol. A client sends an HTTP request message to a server using a carefully formatted message that the server will understand. A server responds by sending an HTTP response message that the client will understand. The request and the response are two different message types that are exchanged in a single HTTP transaction. The HTTP standards define what goes into these request and response messages so that everyone who speaks "HTTP" will understand each other and be able to exchange resources (or when a resource doesn't exist – a server can respond with an error message).
A Raw Request and Response
A web browser knows how to send an HTTP request by opening a network connection and writing out an HTTP message. There is nothing magical about the message – it uses plain ASCII text and a format conforming to the HTTP specification. Any application that can send data over a network can make an HTTP request. You can even make a manual request using an application like Telnet from the command line. A normal Telnet session connects over port 23, but as we learned in the first article, the default network port for HTTP is port 80. Below is a screen shot of a telnet session that connects to odetocode.com on port 80, makes an HTTP request, and receives an HTTP response.
The telnet session starts by typing "telnet www.odetocode.com 80" on the command line. The command tells the operating system to launch the telnet application, and tells the Telnet application to connect to www.odetocode.com on port 80.
Once telnet connects, we can type out an HTTP request message. The first line is "GET / HTTP/1.1" followed by the enter key. The first line tells the server we want to retrieve the resource located at "/" (the home page), and we will be using the HTTP 1.1 standard. The next line is "Host: www.odetocode.com". The host information is a required piece of information in an HTTP 1.1 request message. The technical reason for requiring host information is to help servers that support multiple web sites. Both www.odetocode.com and www.ode-to-food.com could be hosted on the same server, but the host information in the message will help the web server direct the request to the proper web application.
At this point we've formulated the message we want to send and we can press the enter key twice to send the message to the server. What you see next in the telnet window is the HTTP response from the web server. We'll break down the response later in the article, but I'll give you the high level overview now. The response says that the resource we want (the home page of www.odetocode.com), has moved. The home page has moved to the location odetocode.com (without the www). It's up to the client to parse this response message and send a new request to odetocode.com instead of www.odetocode.com (if it wants to retrieve the home page).
These "redirects" are common in web programming. In this scenario the reason is to make sure all requests go through odetocode.com and not www.odetocode.com. The redirection is part of a search engine optimization known as "url canonicalization".
Now that we've seen a raw HTTP request and response, let's dig into specific pieces.
HTTP Request Methods
The "GET" word typed into the telnet session shown above is one of the primary HTTP methods. Every request message must include one of the HTTP methods, and the method tells the server what the client wants to do with a resource. An HTTP GET wants to fetch and retrieve a resource. You could GET an image (GET /logo.png), or GET a pdf file, (GET /documents/report.pdf), or any other retrievable resource the server might hold. A list of common HTTP operators is shown in the table below.
|GET||Retrieve a resource|
|PUT||Store a resource|
|DELETE||Remove a resource|
|POST||Update a resource|
|HEAD||Retrieve just the headers for a resource|
Of these 5 methods, just 2 are the primary workhorses of the web: GET and POST. A web browser issues a GET request when it wants to retrieve a resource like a page, an image, a video, or a document. GET requests are the most common type of request.
A web browser sends a POST request when it has data to send to the server. For example, clicking "Add to Cart" on a site like amazon.com will POST information to Amazon about what we want to purchase. POST requests are typically generated by a