Part 3: HTTP/HTTPS Protocols

This material is part of the “Introduction to Enterprise Development” series. Previous articles:

• about the network ;
• about software architecture .

Hello! Today we will understand the HTTP and HTTPS protocols. But first, let's clarify one point: we are talking about data transfer protocols over the network at the application layer of the OSI model. As you remember, we discussed the OSI model in one of the previous articles. And if you don’t remember, here it is .

What is a data transfer protocol

This is the name given to the generally accepted agreement, thanks to which developers of different services send information in a single form. For example, using Google Chrome, you can get information from both Facebook and Twitter, because the developers transmit it using the standard HTTP protocol, and your browser can handle it. The uniform rules are also very convenient for the server-side developers themselves: there are many libraries that can convert information for you and send it using the required protocol. HTTP was originally conceived as a protocol for transferring HTML pages. This was the case for a long time, but now programmers often transfer both strings and media files over it. Overall, this protocol is versatile and flexible, and it's really easy to use. Now let’s figure out how to do this.

HTTP structure

It’s worth noting right away that the HTTP protocol consists of text only. Well, we are most interested in the structure in which this text is located. Each message consists of three parts:

1. Starting line—defines service data.
2. Headers - description of message parameters.
3. Message body (Body) - message data. Must be separated from headings by a blank line.

Using the HTTP protocol, you can send a request to the server (request) and receive a response from the server (response). Requests and responses have slightly different parameters.

What a simple HTTP request looks like

GET / HTTP/1.1
Host: javarush.com
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)

The starting line contains:

• GET - request method;
• / — request path (path);
• HTTP/1.1 - version of the data transfer protocol.

Then follow the headings:

• Host — the host to which the request is addressed;
• User-Agent is the client that sends the request.

There is no message body. In an HTTP request, only the start line and the Host header are required. Now let's look at everything in order. An HTTP request must contain some method. There are nine of them in total: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. The most common are GET and POST. These two methods will be sufficient at first. GET - requests content from the server. Therefore, requests with the GET method do not have a message body. But if necessary, you can send parameters via path in this format: https://cdn.javarush.com/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2 Here: javarush.com — host, /send — request path, ? — a separator indicating that the request parameters follow. At the end, the parameters are listed in the key=value format, separated by an ampersand. POST - publishes information on the server. A POST request can transfer various information: parameters in the key=value format, JSON, HTML code, or even files. All information is transmitted in the body of the message. For example:

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: javarush.com

{
  "Id": 12345,
  "User": "John"
}

The request is sent to javarush.com/user/create/json, protocol version is HTTP/1.1. Accept specifies what response format the client expects to receive, Content-Type specifies what format the message body is sent in. Content-Length - the number of characters in the body. An HTTP request can contain many different headers. More details can be found in the protocol specification .

HTTP responses

After receiving the request, the server processes it and sends a response to the client:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>

The starting line in the response contains the protocol version (HTTP/1.1), Status Code (200), Status Description (OK). Headings indicate the type and length of content. The body of the response contains the HTML code that the browser will draw into the HTML page.

Response Status Codes

Everything is clear with the message body and headers, but it’s worth saying a few words about status codes. Response Status Codes are always three digits, and the first digit of the code indicates the category of the response:

• 1xx - informational. The request has been received, the server is ready to continue;
• 2xx - successful. The request has been received, understood and processed;
• 3xx - redirection. The following steps must be performed to process the request;
• 4xx - client error. The request contains errors or does not comply with the protocol;
• 5xx - server error. The server was unable to process the request, although it was composed correctly;

The second and third digits in the code detail the answer. For example:

• 200 OK — the request was received and successfully processed;
• 201 Created — the request was received and successfully processed, resulting in the creation of a new resource or its instance;
• 301 Moved Permanently - the requested resource has been moved permanently, and subsequent requests to it must occur at the new address;
• 307 Temporary Redirect - the resource has been moved temporarily. For now, you can access it using automatic redirection;
• 403 Forbidden - the request is clear, but authorization is required;
• 404 Not Found - the server did not find the resource at this address;
• 501 Not Implemented - the server does not support functionality to respond to this request;
• 505 HTTP Version Not Supported - the server does not support the specified version of the HTTP protocol.

In addition to the response status code, a status description is also sent, making it intuitive to understand what a particular status means. The HTTP protocol is very practical: it provides a large number of headers, using which you can set up flexible communication between the client and the server. All request and response headers, request methods and response status codes cannot be considered in one article. If necessary, you can read the official protocol specification , which describes all the nuances. The HTTP protocol is typically used on port 80, so when you see an address that ends on port 80, you can be sure that it should be accessed via HTTP. With the development of technology and the active movement of personal data on the Internet, we had to think about how to provide additional protection for the information that the client transmits to the server. The result was the HTTPS protocol.

What is the difference between HTTPS and HTTP

HTTPS is syntactically identical to the HTTP protocol, that is, it uses the same starting lines and headers. The only differences are additional encryption and the default port (443) . HTTPS is encrypted between HTTP and TCP, that is, between the application and transport layers. If you forgot what it is, take a look at the article about the OSI model . The modern encryption standard is TLS. We won’t go too deep into this topic, but remember that encryption occurs before the information reaches the transport layer . HTTPS encrypts absolutely all information except the host and port to which the request is sent. To switch the server to use the HTTPS protocol instead of HTTP, we do not need to change the server code. This feature is enabled in servlet containers, which we will talk about in the following articles. That's all for today. But wait a minute. To sense HTTP requests, open Google Chrome, press F12, select the Network tab. All requests and responses sent/received by your browser will be displayed here. Part 4. Maven Basics Part 5. Servlets. Writing a simple web application Part 6. Servlet containers Part 7. Introducing the MVC (Model-View-Controller) pattern Part 8. Writing a small spring-boot application