Every developer must understand the HTTP protocol, if you are just starting, don’t despair, you will get all the details, to help I’ll bring you a little bit about the base that I think is important to understand.
What is HTTP?
HTTP (Hypertext Transfer Protocol) are rules for transferring files (text, images, audio, video) over the internet. As soon as a user opens their web browser, they are using HTTP, an application protocol that runs on top of the TCP/IP protocol suite that forms the basis of the Internet. The latest version of HTTP is HTTP/2, but HTTP 1.1, its predecessor, is still in use.
How HTTP works
Through the HTTP protocol, resources are exchanged between client devices and servers over the internet. Client devices send requests and servers send responses that fulfill the request.
A web server in addition to files must run a web server, a service that is always waiting for HTTP requests and responding. The web browser is the HTTP client, it requests a file and the server sends it back.
To illustrate more clearly, when typing the address of my blog in your browser: diegorodrigo.dev, it makes a GET request to the server where the website is hosted.
With this information, the server returns the html content to the blog’s home page, however the images and other files will be obtained by other HTTP connections, the more requests the longer the page is loaded.
Both request and response use TCP/IP to reduce and transport information in small packets of binary sequences that travel in ASCII format, if you want to understand it better, see RFC 2616, RFCs are documentation containing official internet standards and protocols.
HTTP vs. HTTPS
HTTPS is basically HTTP with SSL (Secure Sockets Layer) or TLS (Transport Layer Security) as a sublayer under layers of regular HTTP applications. HTTPS encrypts and decrypts the user’s HTTP page requests as well as the pages that are returned by the web server, creating a secure connection between client and server.
HTTP/2
If HTTP/1.1 is working, why did they invent another version? In fact, just like the transition from HTTP/1.0 to HTTP/1.1, the current version is also in that transition.
The biggest problem is that HTTP/1.1 is a sequential protocol: your browser opens a connection, requests a file from the website’s server, receives the file and only then asks for another file. To minimize this waste of time, browsers typically open multiple connections (somewhere between four and eight) per server. The browser can download several elements at the same time and speed up the loading of the page.
HTTP/2 uses multiplexing, a complicated name for saying that the browser opens a single connection to download multiple files. Requests and responses are parallel and asynchronous: your browser requests multiple files at the same time and receives them as soon as they are ready, on the same connection. But what if an image on the page, for example, is too heavy? No problem: on the same connection, it is possible to mix the data, receiving part of the image, then a completely different file and finally the rest of the missing image.
Also new to HTTP/2 is what is being called server push. Server Push solves the problem of inline directly in the protocol in a simple and elegant way. The idea is that when the user requests the HTML for example, we can send the CSS response along with it even before it requests it.
But with HTTP/2, the server can send these elements before your browser asks for them. That way, as soon as your browser requests our index.html, the server can respond with index.html, style.css and favicon.svg. When your browser realizes that it needs to use these files to render the page, they will already be on your computer, ready to use.
Also, in HTTP/2 the headers will be compressed with a format called HPACK. Whenever your browser requests a file, it needs to download that file’s header, which can contain the file’s size, server information, and a cookie. Generally, a header is no more than 1KB, but imagine that multiplied by dozens of files? With header compression, data usage will be less — and pages will load faster, of course.
HTTP/3
HTTP/3 will be the first major protocol update since HTTP/2 in 2015. A key difference with HTTP/3 is that it runs on QUIC, a new transport protocol.
The QUIC protocol was developed by Google in 2012 and has been adopted by the Internet Engineering Task Force (IETF). After consulting experts around the world, the IETF made a number of changes to develop its own version of QUIC.
QUIC is designed for heavy mobile internet usage, where people carry smartphones that constantly switch from one network to another as they move around during the day. This was not the case when the first internet protocols were introduced: devices were less portable and didn’t change networks very often.
HTTP requests and responses
Each interaction between the client and the server is called a message. HTTP messages are requests or responses. Client devices send HTTP requests to servers, which servers respond by sending HTTP responses back to clients.
HTTP requests. This is when a client device, such as a web browser, asks the server for the information it needs to load the website. The request provides the server with the desired information it needs to adapt its response to the client device. Each HTTP request contains encoded data, with information such as:
GET / HTTP/1.1
Host: diegorodrigo.dev
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate
- The specific version of HTTP followed: HTTP and HTTP/2 are the two versions.
- A URL: This points to the resource on the web.
- An HTTP method. This indicates the specific action the request expects to receive from the server in its response.
- HTTP Request Headers: This includes data such as what type of browser is being used and what data the request is fetching from the server. It may also include cookies, which show information previously sent from the server handling the request.
- An HTTP body: This is optional information that the server needs from the request, such as user forms - username/password logins, short replies, and file uploads - that are being sent to the site.
HTTP Responses: The HTTP response message is the data received by a client device from the web server. As its name suggests, the response is the server’s response to an HTTP request. The information contained in an HTTP response is adapted to the context that the server received from the request. HTTP responses typically include the following data:
HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
<!DOCTYPE html>
......
</html>
- HTTP status code: which indicates the status of the request to the client device. Responses can indicate success, an informational response, a redirect, or server-side or client-side errors.
- HTTP response headers: which send information about the server and the requested resources.
- An HTTP body (optional): If a request is successful, it will contain the requested data in the form of HTML code, which is translated into a web page by the client’s browser.
HTTP Methods
The HTTP protocol uses predefined request methods that tell the server which task it should perform on the desired resource:
- GET: request for a resource
- POST: add/create a resource
- DELETE: removes a specific resource
- PUT: directly modify a resource
- PATCH: Partially modifies a feature
These are the most used methods, you can see them all here.
HTTP status codes
In response to HTTP requests, servers often issue response codes indicating that the request is being processed, there was an error in the request, or that the request is being redirected. Common response codes include:
- 200 OK. This means that the request such as GET or POST has worked and is running.
- 300 permanently moved. This response code means that the requested resource URL has been permanently changed.
- 401 not authorized. The client, or user making the server request, has not been authenticated.
- 403 Forbidden. The client’s identity is known, but has not been granted access authorization.
- 404 not found. This is the most frequent error code. This means the URL is not recognized or the in-place resource does not exist.
- Internal Server Error 500. The server has encountered a situation it doesn’t know how to handle.
As these methods are all some of the most used, you can view them all here.
If you still have any questions about the HTTP protocol, this site explains it in a fun way.