HTTP Request — Response Cycle, a Letter in the Mail (pt.2)
Welcome to part two of this series, in part one our HTTP request was sent, now lets see what we’ll get as a response.
Your HTTP request managed to cross oceans and arrive at its destination. The server (host) looks at the message and despite residing in a different country than your device (the client) it knows how to decipher the message’s content because it’s labeled as following HTTP protocol. In a URL the http can be referred to as the scheme.
In the previous article I didn’t mention HTTP headers…now I will. HTTP headers contain more information to go along with a request or response so that communication between the client and host can occur more smoothly. Each HTTP header has a name followed by a colon and finally the value of that header. Our HTTP request would have had at least one header, a Host header, and would look something like this:
The digits represent the port of the server and are optional. If a port isn’t specified the default port will be used, for HTTPS it’s 443 and for HTTP messages it’s 80. You can think of the syntax structure of headers as being similar to key value pairs in a Ruby hash or a dictionary in Python.
Another important detail I’d like to discuss is that HTTP requests need to contain a path (in addition to the other 2 required parts of the request: a method and location header). I didn’t mention this in the first article since you can enter a URL without a path. An HTTP request, on the other hand, requires a path. When you enter a URL without a path the browser will assume you’re accessing the root/default path. The path looks similar to a local command line path, it references the resource you want to access:
The server has your request and performs some actions on its end based on the request. Taking a deeper dive into what exactly “performs some actions” means, would require a pile of books on it’s own. In this article we’ll continue to focus on the messages being sent back and forth prior to and following the actions taking place on the server side. After the server has completed its activity it has a lovely letter to send to you:
Wow, that seems like a whole lot of nothing. All we see here is a status code - that’s all that is required in the response. A status code is the three digit number that tells us the outcome of our request such as whether the resource was found at the expected path, was found elsewhere on the server or that the request was simply unsuccessful. You can see there’s also a bit more on the one line response that we received: the HTTP version number found prior to the status code and a status text following the status code. The status text is there to give a brief description of the status code to make life easier for us lowly humans.
Here’s a handful of common status codes (accompanied by status text):
404 Not Found
500 Server Side Error
For these codes the text is a reasonable description of the status of a request. They relate to whether a) the resource was found (200 and 302) b) the resource was found elsewhere on the server thanks to URL redirection (302) c) the resource was not found (404) or d) an internal server error occurred (500).
Of course most responses will include more than just one line of text. There is usually a message body that contains the resource you’re hoping to access.
A final note about the HTTP protocol, it’s stateless. This means each HTTP cycle is independent of the cycles that have occurred and will be occurring in the future. There are ways to simulate statefull web applications, such as using cookies, which allows us to stay stay logged in to a site even though the browser refreshes (HTTP cycles occur) as we navigate the site. However in and of itself HTTP remains a stateless protocol.
To recap an HTTP request needs to contain a method, a path and a host name (the value of the host header). An HTTP response needs to contain a status code. A number of different types of headers can be found in both requests and responses, the resources below include other common headers that you are likely to encounter.
I hope you’ve found this overview helpful as a high level understanding of HTTP cycles. The following are some excellent resources that relate to this topic including Launch School’s Open Book Shelf (free to access even if you’re not a student).