Register to get access to free programming courses with interactive exercises

HTTP 1.0 HTTP Protocol

HTTP is a text protocol used by a client, for example, a browser or a server. It works like this. The user sends a specific request to the server, requesting or passing the necessary data, and the server, depending on the request, performs the necessary logic and returns the result, usually an HTML page or a redirect.

In order to see how HTTP works, we'll make a request to the Google server and analyze how it looks. To do this, a special utility called telnet is used (an example of an HTTP request made using the telnet utility).

# We pass the site address and specify the tcp port
# After that, it connects to the server via the tcp protocol
telnet google.com 80

HTTP is an application layer protocol. In other words, it's designed to communicate between two programs (client and server) located on different computers. But, on its own, HTTP cannot connect two remote computers. Other protocols are used for this, including TCP. It's TCP that allows you to connect programs on remote computers, creating a channel for communicating with each other. To do this, you need to know two parameters: the IP address of the computer to which you want to connect, and the port that the required program is tied to.

The telnet command above does exactly that, it carries out a TCP connection and only then does it enter the HTTP interaction mode. Provided that the correct IP address and port for the connection are given. And at this point, two questions arise:

We passed the site address, where does the IP address come from? Any website address is just a name that covers the IP address. The name is set for convenience, to make it easier to remember. However, all network programs, including browsers and telnet, convert the site name to its IP address. This is done using the DNS system, another pillar of the Internet.

# An example of how you can find out the IP address using the ping utility
# In your case, the address may be different, IP addresses may change
ping google.com # 74.125.21.139

# Then you can use it to connect to the server
telnet 74.125.21.139 80

Why is the port number 80? This is a generally accepted convention. Sites accessible over HTTP are available on port 80, and over HTTPS on port 443. That’s why ports are not specified in browsers.

Now that we've established a connection, we can see that a connection has been made with a web server, a program that serves HTTP requests to google.com:

telnet google.com 80

Trying 74.125.21.139...
Connected to google.com.
Escape character is '^]'.

After connecting, the web server starts to wait for the HTTP address. All that's left is to send it.

What is the request itself?

The request consists of several parts. The first part is the request request line. The second is the header.

In the request line we specify a special word, or verb. HTTP has various verbs, but we won't go into details now. Let's just say that they determine how to respond to this request. And in this case, we'll use the verb HEAD. It'd very simple, and it asks the server to give only headers, no content. GET is more common. It's GET that we use to request the content of the site.

After the verb, we give the path to the resource, request URI. If we specify /, it just means the root of the site. Then all you need to do is give the name of the protocol and its version. In this course, we'll only look at HTTP 1.0 and 1.1, this is the fundamental part of the protocol, and it's worth starting with them. There are fundamental differences between the versions, which you need to know and understand well. Version 1.0 continues to be used for various purposes by command line utilities.

In principle, this is more or less enough, and nothing else needs to be done for 1.0:

HEAD / HTTP/1.0

Then there are the headers. What are they? Headers allow you to send additional information, for example, browsers might provide information about themselves so that it's clear where the request comes from. In addition, they state what compression formats they support, what format they're ready to receive a response in, and so on. The number of standard headings is quite large, and you can add your own too.

Let's take a look at what headers look like. We specify a name and a value, separated by a colon: refer: value. Titles are often given in capital letters, but case isn't important here. The order of the headers is also not specified. Whichever order we pass the headers, the entire body of the response will be parsed at once.

Browsers use many headers, such as user-agent. This header is used for analytics, as well as when you want to adapt the pages of the site for different screens or browsers. But even without it, everything should work:

HEAD / HTTP/1.0
User-Agent: google chrome

It's important to remember that since this is a protocol, and it has certain rules, you mustn't break them. HTTP is a text-based protocol. All rules are based on simple agreements. For example, multiple headings need to be separated from each other by a line break (and you can't get around that!). We can't put them on one line, even if you separate them with commas. Everything is very strict. And how will the server know that you've finished transferring data? There needs to be some kind of marker, something to determine that it's reached the end. In HTTP this is done using two line breaks. After that, the server thinks that all the data has been sent and there'll be no more data. Essentially, the two line breaks (the translation after the last header and an empty line) are basically what causes data to be sent.

What will the response be?

Let's make a request and see what comes back to us as a response. Let's make a HEAD request and see what gets returned:

telnet google.com 80

Trying 64.233.164.100...
Connected to google.com.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.0 200 OK
Date: Sat, 18 Jan 2020 09:24:50 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Server: gws
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Set-Cookie: 1P_JAR=2020-01-18-09; expires=Mon, 17-Feb-2020 09:24:50 GMT; path=/; domain=.google.com; Secure
Set-Cookie: NID=196=wsHLMAMfnAaSyF7zduokI8TJeE5UoIKPHYC58HYH93VMnev9Nc2bAjhRdzoc4UhmuOd7ZVCorDnzGDe51yPefsRMeVyOFnYdHYYgQNqI8A1dYuk4pDK4OJurQgL4lX8kiNGSNi_kkUESFQ-MqLCB_YspxA9JRejhZdkTRtGyHNk; expires=Sun, 19-Jul-2020 09:24:50 GMT; path=/; domain=.google.com; HttpOnly
Accept-Ranges: none
Vary: Accept-Encoding

Connection closed by foreign host.

We got a response. This is the status line HTTP/1.0 200 OK, it specifies the protocol (here it's the same) and gives the response status: 200 OK. Many different statuses are defined in HTTP (400, 500, etc.). They can inform you if information hasn't been found, or if there are errors on the server, etc. All statuses have a mnemonic name, which is also passing by the last value. 200 and OK means that everything went OK - success!

Then a large number of different headings are displayed. There's nothing complicated about them, and you don't have to learn them all (there are some common ones, and they're clear enough). All headers consist of a key, a colon and a value. You may notice that there are things related to coding and caching. Some headers are specific to the current server. For example, X-XSS-Protection: 0, where X indicates a custom header. But no web server or web browser will crash when such additional headers are sent.

In HTTP 1.0, the connection is closed at the end after the data has been received.

At the end we can see one interesting detail: Connection closed by foreign host. The connection request was closed by an external host. That's how almost everything on the Internet works. Normally, servers are set to a 30-second interval and will close the connection if nothing comes in during that interval.

That's why telnet is a bit harder to work with for beginners. They enter the request slowly, and the connection closes before they're finished, which is a bit of a pain. So I always recommend that you make entries in the file and then telnet them afterwards.


Hexlet Experts

Are there any more questions? Ask them in the Discussion section.

The Hexlet support team or other students will answer you.

About Hexlet learning process

For full access to the course you need a professional subscription.

A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.

Get access
130
courses
1000
exercises
2000+
hours of theory
3200
tests

Sign up

Programming courses for beginners and experienced developers. Start training for free

  • 130 courses, 2000+ hours of theory
  • 1000 practical tasks in a browser
  • 360 000 students
By sending this form, you agree to our Personal Policy and Service Conditions

Our graduates work in companies:

<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.bookmate">Bookmate</span>
<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.healthsamurai">Healthsamurai</span>
<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.dualboot">Dualboot</span>
<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.abbyy">Abbyy</span>
Suggested learning programs

From a novice to a developer. Get a job or your money back!

Frontend Developer icon
Profession
beginner
Development of front-end components for web applications
start anytime 10 months

Use Hexlet to the fullest extent!

  • Ask questions about the lesson
  • Test your knowledge in quizzes
  • Practice in your browser
  • Track your progress

Sign up or sign in

By sending this form, you agree to our Personal Policy and Service Conditions
Toto Image

Ask questions if you want to discuss a theory or an exercise. Hexlet Support Team and experienced community members can help find answers and solve a problem.