Blog /HTTP Crash Course

Quick tips

HTTP Crash Course

Mailgun Community

• 5 min read

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.

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:

GET /18_tyyp.html HTTP/2.0

Host: the web address or URL

User-Agent: The browser’s name

Using the same connection, the server will then respond:

HTTP/2.0 200 OK

Content-Length: 65635

Content-Type: html/text

Last-Modified: Fri, 24 Jan 2020 08:35:42 GMT

<!doctype html>

…the document's remaining part

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:

GET /18_http.html HTTP/2.0

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.

_{DELIVERABILITY SERVICES}

Learn about our Deliverability Services

Looking to send a high volume of emails? Our email experts can supercharge your email performance. See how we've helped companies like Lyft, Shopify, Github increase their email delivery rates to an average of 97%.

Learn More

Tags: Mailgun Community HTTP HTTPS

Last updated on July 30, 2021