The Cyclical Life of an HTTP Request

Accessing a website, any website, is something that most people take for granted, specifically in terms of all the necessary procedures that happen behind the scenes. These procedures make it possible to surf the web quickly and securely. Multiple entities, including your own machine, are utilized to complete this process. Not to mention that all the steps, from the point at which they initialize, to their completion, must occur quickly; very quickly. Fractions of a second separate a functional website, and one deemed to be unusable. These operations are what make the internet, as we know it today, possible.

Access Granted

Have you ever noticed how websites that you’ve never before visited take longer to load than those which you have visited in the past? This is partly due to your browser storing copies of past sites in its cache. However if the website is unrecognized by the browser, a slight delay will occur. The extra time is only a couple seconds, sometimes as low as milliseconds. During this short lag time, many things are happening just behind the internet’s curtain, in order to get you to your desired destination. This is called the HTTP request life cycle.

Say, for instance, you discover a weird rash on your back, and decide to “Google diagnose” yourself (even though we both know it’s a bad idea). Let’s assume you’ve never visited this site before. You start by typing in the name of the website (www.google.com), and thus, an HTTP request is born. Your browser, in this scenario, is called the client. The request life cycle’s first order of business is to, well, send a request to the Domain Name Service (DNS). With this your browser is asking for the Internet Protocol address (IP) of the website that you are trying to access. The IP address is a series of numbers that refer to a specific location on the internet. The DNS is used to match the website’s name to these numbers, before ultimately linking the IP to the location on the web of the website. Basically, the client (your browser) asks for directions to some specific location, and the DNS gives it a map showing how to reach this destination.

Next a socket connection is opened between the client and the specific IP address. And now, we wait. Not very long, most of the time, but this is the delay to which I was referring earlier. The IP is likely located at a host server. The host, after receiving your request, will read over the information sent to it by in the HTTP request. The request will contain everything it needs to know, in order to either grant or deny your entry to the website. The host then makes a decision, forms its response and sends it back to the client. If all goes well, you are then directed to the proper website.

Request/Response Terminology

Within the request message sent by your browser, an HTTP verb is included. The HTTP verb will inform the host to what capacity you will be using their website. The four main HTTP verbs are GET, POST, PUT, and DELETE. GET requests are asking for read only permission from a website, meaning the client will be able to see the information on the page, but will not be able to make any changes to it. POST requests ask read and write permission. A good example of this is posting a new tweet on Twitter. PUT requests are simply used to update the website, and DELETE requests will be used to, well, delete resources from a site.

When the response is received by the browser, a numbered browser code is held within. This is the piece of information that will be most familiar to the average user, in terms of the contents of the HTTP response. One infamous browser code, for example, is the 404 code. The codes are organized by 100’s each individual code meaning a different thing, although sometimes, the different meanings of different codes is quite minor.

Visiting websites is so easy. Being such a simple process for the general public, however, does not mean that the process is simple in general. Behind the scenes there are many resources, from multiple systems, at different locations, all of which must agree and align with one another. Thankfully all of this was put into place in order to make web browsing a safe and likable experience.

Further Reading:
- Fu, Salina. “My Understanding Of: The HTTP Request/Response Life Cycle.” Medium, 11 June 2018, medium.com/@salina_says/my-understanding-of-the-http-request-response-life-cycle-b3268570c6e0.
- Golant, Daniel. “Things I Brushed Up On This Week: The HTTP Request Lifecycle.” DEV Community, 25 July 2017, dev.to/dangolant/things-i-brushed-up-on-this-week-the-http-request-lifecycle-.
- Mandal, Rahul Kumar. “The Lifecycle of an HTTP Request - Rahul Kumar Mandal.” Medium, 7 Feb. 2019, medium.com/@officialrahulmandal/the-lifecycle-of-an-http-request-f6b1c1635312.
- Strong, Jen. “The Request/Response Cycle of the Web - Jen Strong.” Medium, 11 May 2020, medium.com/@jen_strong/the-request-response-cycle-of-the-web-1b7e206e9047.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store