Introduction to HTTP

What does HTTP stand for?

HTTP stands for HyperText Transfer Protocol. If the acronym is intimidating, don't worry we'll break these four words down further.

Even if you're brand new to web development, you've likely heard of HTML, which stands for HyperText Markup Language. Any of that acronym seem familiar? (Hint: it's the "hypertext" part).

HTML is a text-based approach to describing the structure of a web page's content. It is the major markup language used across the worldwide web. (W3 Schools)

Okay, so HTML gives us the structure, or essentially, tells us how content on a web page should be organized. HTTP provides the rules (protocol) for how that content should be sent and received or transferred across the web. It is the foundation of any data exchange on the web. Hence, HyperText Transfer Protocol.

To give you an analogy, let's say you want to order a bookcase from a furniture company. You have to provide that company with information about what type of bookcase you want, maybe the size, color, and model. The company has to process this information and get the bookcase to your door somehow. The rules, or protocol, the company uses to get the bookcase to you is HTTP. Once your bookcase arrives, the instructions for how to build the bookcase, how the pieces should be organized, is HTML. (Note: this simple analogy is imperfect but hopefully useful).

How does HTTP work?

Now that we have a better understanding of what HTTP is, let's talk about how it works.

Commonly, HTTP is defined as a stateless, "client-server" protocol or "request-response" protocol. The client-server protocol describes the communication between two computers. The client (maybe a browser or another application) requests data and the server provides a response. This is how we are able to go to a website (make a request) and see information (get the response). With this protocol, the client request always happens first and is followed by the server's response.¹

"Stateless" describes the fact that once the server provides a response, it isn't required to keep information stored about each user. Each request is executed without any knowledge of the requests that were executed before it or after it.¹

HTTP Request

The request is where it all begins. Let's look at the components of a request¹:

1. Request line
2. Request Headers (it is possible to have zero headers)
3. An empty line
4. The message body (optional)

GET /Protocols/rfc2626/rfc2616.htmll HTTP/1.1
Host: www.w3.org
User-Agent: Mozzila/5.0
(empty line)

The first word in the first line (GET) is the request method. This is the action that we want to be done. In this case, we literally want to get some information. GET was the first method and is the most fundamental it is supported with all browsers because it is how we get content.

For your reference, a list of methods taken from TutorialsPoint

The request method is followed by the URI (Uniform Resource Identifier - we'll discuss this later) and the version of HTTP being used (yes, there is more than one version). While the request method holds the desired action, the headers contain other information for the server. Most of them are optional, but the host header field (which provides the name of the server along with the port number) is required.¹

HTTP Response

We discussed how it all begins with a request. Well, every time there is a request an HTTP response is sent. Fortunately for us, the components that make up the HTTP response are very similar to the components that make up the HTTP request¹:

1. Status line
2. Response headers (can be zero)
3. An empty line
4. The message body (optional)

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html

The first line is the status line. It has a status code that provides information on whether or not the success was successfully processed. Followed by response headers. This provides more information to the client the same way request headers provide more information to the server. Another lovely table also take from TutorialsPoint

Status Codes:
Status Code Class|Description
-----------------|--------------
1xx|Informational. It means the request was received and the process is continuing.
2xx|Success.| It means the action was successfully received, understood, and accepted.
3xx|Redirection. It means further action must be taken in order to complete the request.
4xx| Client Error. It means the request contains incorrect syntax or cannot be fulfilled.
5xx|It means the server failed to fulfill an apparently valid request.

URI

Previously, I mentioned the URI (Uniform Resource Identifier). You may be more familiar with the term URL (uniform resource locator). The relationship between URIs and URLs is kind of like the relationship between rectangles and squares. All squares are rectangles, but not all rectangles are squares (Wow, what a throwback to my grade school lessons on shapes). All URLs are URIs but not all URIs are URLs. URIs allow us to identify distinct resources. We can do that with a URL (which tells us exactly where to find a resource ), but we can do that with other things too. Like a URN (uniform resource name), which tells us what a resource is called, but not how to find it.

If this is interesting (or confusing to you. Wikipedia has a great article breaking down the history and usage of all three), but I pretty much use URL and URI interchangeably.

The goal of this article is to walk through HTTP since it's an integral part of web applications that is important to understand. When I was first learning about web development it felt like a topic that was important, but my understanding was kind of fuzzy. Hopefully, this article can provide some clarity.

[1]: Sau Sheong Chang. Go Web Programming