IT & Engineering
HTTP crash course
HTTP stands for Hypertext Transfer Protocol, and it’s a mechanism used to transfer data across the internet between clients (computers, laptops, phones, etc.) and servers.
PUBLISHED ON
It’s been a little while since we’ve taken a deep dive into a more basic technical process, and while the world of email is ever changing, it’s nice to step back and look at how things work. As you can tell from the title, we wanted to go over HTTP – what is is, how it works, and its different functions today. So strap in, it’s time for a crash course.
Table of contents
What is HTTP?
HTTP stands for Hypertext Transfer Protocol, and it’s a mechanism used to transfer data across the internet between clients (computers, laptops, phones, etc.) and servers.
So, if you go to the address bar of your browser and type in a web address, the browser looks for the server’s address that is associated with that URL. From there, the browser tries to establish a connection to the server known as a TCP connection on HTTP traffic’s default port – port 80. If the connection is established with the browser (meaning the server is true,) then your browser sends a request similar to this:
Using the same connection, the server will then respond:
The browser displays its body, the part that follows the blank line in the document, as a document of HTML.
The request
is the information that the client sent. It starts like this:
The request method defines the first word. GET
implies that the resource you're searching for is specified. Other request methods include DELETE
for a resource to be deleted, PUT
for resources to be replaced or created, and POST
for sending information to the resource.
It is important to note that the server doesn't have any obligation to answer all the requests sent to it. All that said, it’s pretty simple communication.
HTTP and Browsers
When you enter a URL in the address bar of a browser, the browser is being asked to make a request. If the HTML page resulting from the request has other files such as JavaScript files, images, etc. they all are retrieved as well and all together create the page you requested.
Some websites can include anywhere between 10 and 200 resources. To fetch all of these quickly, the browser makes multiple simultaneous GET
requests instead of waiting for the responses, one after the other. Otherwise it would take pages forever to load correctly, and nobody has time for that.
HTTP Sandboxing
As you’re likely aware, HTTP isn’t the most secure communication on the planet. There is a cause for concern when one makes an HTTP request in the script of a web page. The person in charge of the script might have different interests to the person running the request. For example, I might visit `themafia.org`, but I do not want the script of that page to send a request to another page using information that it can identify from my browser. Not that I’m looking for the mafia or anything.
This is the reason that browsers do not allow the script of a web page to make HTTP requests to another domain – it protects the user. However, another problem comes in when someone is trying to build a system server that might request access to other domains legitimately. This is easily solved with the server having a header such as this: Access-Control-Allow-Origin in their response. The header indicates explicitly to the browser to allow requests from another domain.
HTTPS and Security
Data can travel a long way on the internet, and the path it takes can be a long and dangerous path. Before getting to its destination, it must go through different things along the route which may inspect or even modify the data.
If you want to make something a secret and keep it a secret (think passwords) or you want the data to get to its destination without modification, then plain HTTP isn’t good enough.
A more secure HTTP protocol is https://. This URL wraps HTTP traffic such that it is harder to tamper with them or read them. Before the exchange of data, the client first confirms the authenticity of the server by asking it to prove that it has its cryptographic certificate, which is usually issued by a browser recognized authority. After this step, all the data that goes over this connection is encrypted so that it is impossible to tamper and/or eavesdrop.
When HTTPS works well, it works by preventing other people from trying to impersonate the website that you are trying to reach – keeping your data safe. It is, however, not perfect. Should software break or certificates be stolen, data can still be at risk. Nevertheless, it is much safer than plain old HTTP.
About the author
Alice Jones is a journalist and freelancer based out of San Francisco who focuses on coursework writing and freelance. Her writing focus is largely based in business and marketing, and she’s received both her Bachelor’s and Master’s degrees from the University of San Francisco.