Table of Contents
After the overview of HTTP, SSL/TLS, DNS, and URLs published a few days ago, in this article we will focus on one of the most important mechanisms underlying the functioning of websites and web services based on the HTTP (s) protocol: the HTTP request/response lifecycle.
In order to fully understand the functioning of this fundamental aspect, however, it is necessary to clarify the meaning of HTTP request and HTTP response.
The HTTP Request is the call that the client/browser makes to the web server. It is composed of the following elements:
- URL (possibly including a query string)
- Request Headers
- Request Body
Let's now try to understand its meaning, characteristics, and functioning.
Each request, at the time of being sent, requires the mandatory use of one (and only one) HTTP method, which corresponds to the type of operation performed by the client/browser; These methods are specified in RFC 7231. The main HTTP methods are as follows:
- GET - read data (read-only)
- POST - data modification (insert, modify, delete)
- PUT - complete replacement of data relating to a record
- DELETE - delete a record
There are also other HTTP methods, such as OPTIONS, HEAD, etc, which we will not cover for space reasons. The most important and used in the context of websites and web applications are GET and POST.
Generally, the GET method is used when the client accesses a page in READING, while the POST method is used when the client makes a MODIFICATION on the site data (create, modify, and/or delete a user, an article, etc). Not surprisingly, the POST method is typically used by forms and AJAX calls that have the effect of MODIFYING the server data; since it is a method that makes MODIFICATIONS, the POST method is also typically subject to authentication and/or prior authorization requirements in order to be used (in other words, it is only available for registered users with adequate permissions.
URL (and query string)
This is the URL used to make the call. Example:
As you can see, the URL can also contain a query string, that is a sequence of parameters starting with the "?" and then continues with one or more pairs of keys/values separated from each other by the symbol "&". In the URL above, the query string is made up of a single key/value pair, where the key is "q" and the value is "tennis".
Request headers are a sort of "metadata" that can be sent by the client/browser accompanying an HTTP request to provide information on the context of the request: many of these headers are added "automatically" by the browser and contain parameters relating to the language and/or the settings in use on the system. These headers are also transmitted as a series of key/value pairs. Some examples of the most common request headers:
- Cookies: contains the list of cookies on the client/browser, typically created by the server previously via a Set-Cookie response header (see Response Headers below).
- User-Agent: contains the information of the client/browser used by the user.
- Accept-Encoding: contains a list of the compression algorithms supported by the client, i.e. those that the server can use if it is configured to compress the response.
- Accept-Language: contains a list of languages supported by the server.
The "body" of the request: is almost always present in POST requests, as it contains the parameters that are sent to the server; instead it is typically not present ("empty") in GET requests, as in those cases the parameters are sent to the server through the query string (see above).
Now that we have focused on the main components of an HTTP Request, it is time to examine the HTTP Response, which is the response that the server sends to the client/browser following each request.
The response that the web server sends to the client. It consists of the following elements:
- Status Code (e.g. 200 - OK, or 404 - Page Not Found, etc)
- Response Headers
- Response Body
The next paragraphs are dedicated to the deepening of each of them.
The Status Code (or HTTP Status Code) is a 3-digit numeric code that indicates the outcome of the HTTP request made by the client. The Status Codes are also defined within RFC 7231 and are grouped into five main categories:
- Informative responses (100-199)
- Successful responses (200–299)
- Redirection messages (300–399)
- Client error responses (400–499)
- Server error responses (500–599)
Here are the most frequent:
- 200 - OK: when the request is handled successfully by the server.
- 301 - Moved Permanently: when the request is redirected to another URL permanently.
- 302 - Found: when the request is redirected to another URL on a temporary basis.
- 404 - Not Found: when the server has no way to serve content corresponding to the URL indicated, perhaps because it does not exist or because the file does not have one of the explicitly authorized extensions.
- 500 - Server Error: when the request generated an error on the server.
The response headers are the equivalent of the request headers, that is a sort of "metadata" that is sent by the server in support of an HTTP response to provide information on the context of the response. These headers are also transmitted as a series of key/value pairs. Some examples of the most common response headers:
- Set-Cookie: sets a cookie on the client/browser, typically as a result of certain user behaviors (execution of a login form, click on some button or banner, etc); once created, this cookie will then be "resubmitted" by the client in subsequent requests (see Request Headers paragraph), allowing the server to identify it or to manage the value of the cookie itself.
- Date: contains the date and time of the response.
- Cache-control: contains information on how the client/browser and all the "intermediate actors" between client/browser and server (proxy, reverse proxy, CDN, etc) should manage the response cache. Typical values are Private (no cache), Public (cache), etc.
- Content-Type: contains information on the format of the content transmitted in the response body, which can be used by the client/browser to understand how to open it. It typically contains the Media Type (eg. "text/html") and any charset (eg. UTF8).
The response body is the content that is transmitted from the server to the client, which is what the client typically displays on the screen. It can be in various formats: HTML, text, GIF image, JPG (with EXIF data), WAV, MP4, etc., and is opened by the client/browser using the media type information contained in the Content-Type response header (see above).
IMPORTANT: do not confuse the Response Body, which concerns the HTTP response received from the server, with the <BODY> element of the HTML pages, which concerns the internal structure of the content found within the Response Body.
HTTP Request / Response and E-Commerce
In order to facilitate the understanding of the HTTP Request / Response cycle, we propose - with the inevitable simplifications, differences, and approximations of the case - to imagine the exchange of information between client and server as the mechanism for sending and receiving orders, shipments, and packages on an e-commerce website, such as Amazon.
- The HTTP Request corresponds to each of the activities we carry out on the Amazon site from the selection of the item to the order, namely:
- The method (GET when we view the details of the item we want to order, POST when we send the order confirmation)
- The URL (the product we order)
- The Request Headers (any delivery details, eg "before 2 pm")
- The Request Body (shipping data)
- The HTTP Response corresponds to the package we receive from Amazon, that is:
- HTTP Status Code (200 if the package arrives, 404 if the non-delivery notice arrives, 500 if the address is incorrect, etc)
- HTTP Response Headers (the packing slip containing address, sender, telephone, hours, shipper, the date on which it was stamped, etc)
- HTTP Response Body (the contents of the package, or information on why it did not arrive and/or what to do in case of non-delivery)
That's it for now: we hope that this overview, albeit with the inevitable simplifications of the case, will be useful to those who are approaching these fundamental concepts of the World Wide Web for the first time.