Hi! Today we'll learn about the HTTP and HTTPS protocols. But first, let's clarify one point: we're talking about protocols for sending data over a network at the application level of the OSI model. You may recall that we got to know the OSI model in one of the previous articles. If you don't remember that, here it is.
What is a data communication protocol?
This what we call the agreed set of rules that allow developers of different services to send information in a format that others can understand.
For example, you can use Google Chrome to get information from both Facebook and Twitter, because the developers send it using the standard HTTP protocol, which allows your browser to process it.
Uniform rules are very convenient for the folks developing the server part: there are a lot of libraries that can convert information for you and send it using the appropriate protocol.
HTTP was initially conceived as a protocol for sending HTML pages. That's the way it was used for a long time, but now programmers often use it to send both strings and media files. In general, this protocol is universally accepted and versatile, and it is really easy to use. And now we'll investigate how to use it.
The structure of HTTP
We should note right away that the HTTP protocol consists only of text. What most interests us is the structure of this text.
Each message consists of three parts:
Start line — This defines some housekeeping data.
Headers — These describe the message parameters.
Body — This is the content of the message. The body must be separated from the headers by an empty line.
The HTTP protocol is used to send requests to a server and receive responses from the server. The parameters of requests and responses are slightly different.
The message body is missing.
In an HTTP request, only the start line and the "Host" header are required.
Now let's look at everything one step at a time. An HTTP request must contain some method. There are nine of them: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. The most common are GET and POST. These two methods will be enough at first.
GET — This method requests content from the server. Accordingly, requests with the GET method do not have a message body. But if you need to, you can pass parameters via the path (in the start line) in the following format:
where
codegym.cc is the host,
/send is the request's path, and
? is a separator that indicates that the query parameters follow.
At the end, key-value pairs ("key=value") are listed, separated by an ampersand.
POST — This method publishes information on the server. A POST request can send various kinds of information: parameters as "key=value" pairs, JSON, HTML code, or even files. All information is sent in the body of the message.
For example:
The request is sent to codegym.cc/user/create/json, and the protocol version is HTTP/1.1. "Accept" indicates the response format the client expects to receive. "Content-Type" indicates the format of the message body sent in the request. "Content-Length" is the number of characters in the body.
An HTTP request can contain a lot of different headers. For more information, take a look at the protocol's specification.
HTTP responses
After receiving a 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 response's start line contains the protocol version (HTTP/1.1), status code (200), and status description (OK). Its headers include the type and length of the content. The response body contains HTML code that the browser renders as an HTML page.
Response status codes
Everything is clear regarding the message body and headers, but we should say a few words about status codes. Response status codes are always three digits. The first digit of the code indicates the category of the response:
1xx — Informational. The request was received. The server is ready to continue.
2xx — Successful. The request was received, understood and processed.
3xx — Redirection. Additional actions 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 request was composed correctly, but the server could not process it.
The second and third digits in the code indicate a more specific response.
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 instance.
301 Moved Permanently — The requested resource was moved permanently. Subsequent requests to it should made be using the new address.
307 Temporary Redirect — The resource has been moved temporarily. For now, it can be accessed using automatic forwarding.
403 Forbidden — The request was understood, 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 the functionality required to respond to the 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. This helps clarify what each specific status means.
The HTTP protocol is very practical: it provides a large number of headers, which you can use to arrange very flexible communication between a client and server. A full consideration of all request and response headers, request methods, and response status codes would be too much for a single article. If you need to, you can read the protocol's official specification, which describes all the nuances.
It is customary to use the HTTP protocol on port 80, so when you see a URL that ends with port 80, you can be confident that you need to use HTTP to access it.
As technology evolved and personal data began to be sent over Internet, it became necessary to think about how to provide additional protection for the information that the client sends to the server. The result of this thinking was the HTTPS protocol.
The difference between HTTPS and HTTP
In terms of syntax, HTTPS is identical to the HTTP protocol. That is, it uses the same start 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 that means, check out the article on the OSI model.
Today's encryption standard is TLS. We won't go into this topic too much, but remember that encryption happens before information reaches the transport layer. In HTTPS, absolutely all information is encrypted, except for the host and port where the request is sent.
Switching a server to use the HTTPS protocol instead of HTTP does not require use to change the server code. This feature is enabled in servlet containers, which we will discuss in subsequent articles.
And that's all for today. Actually, wait a moment. To get your hands on some HTTP requests, open Google Chrome, press F12, and select the "Network" tab. All the requests and responses sent/received by your browser will be displayed here.
Part 4. The basics of MavenPart 5. Servlets and the Java Servlet API. Writing a simple web applicationPart 6. Servlet containersPart 7. Introducing the MVC (Model-View-Controller) pattern
Hi! Today we'll learn about the HTTP and HTTPS protocols. But first, let's clarify one point: we're talking about protocols for sending data over a network at the application level of the OSI model. You may recall that we got to know the OSI model in one of the previous articles. If you don't remember that, here it is.
GO TO FULL VERSION