This is a problem that has been trialled by millions of programmers, but only a few know the truth. In general search, the Internet about HTTP protocol to maintain the state misleading everyone’s article or some, such as: someone said to use ViewState, that is asp.net unique things, please note “asp.net under how to maintain the state”!

See previous articles on user authentication schemes:

Programmers cut through the hoops — the relationship between cookies and sessions is simple

Programmer pass through — Internet people must know cookie and session authentication

Programmers go through the process — a more elegant Token authentication method JWT

The Http protocol

HTTP is a relatively old protocol for our age, and it was created to allow people to surf the Internet freely. In modern times, THE HTTP protocol has become one of the foundations of distributed networks, from the original 1.0 version to the current 2.0 and even the development of 3.0, it has become more and more important in the field of distributed communication.

No matter what kind of HTTP protocol article, all need to say HTTP in general, here is a simple wordy few sentences

The HTTP protocol adopts the text encoding mode in the packet and the request-response mode from client to server in the communication.

HTTP is an application layer protocol based on TCP, so its transmission speed is bound to be restricted by TCP. Some people say that using HTTP as a text protocol is a big mistake. I don’t think so. First of all, when HTTP was invented, there weren’t many options available. Secondly, text protocol in addition to the transmission performance is worse than the binary way, other good, especially in the intuitiveness of data, it is easy to be understood by us. Programmers, in particular, can generally guess a lot when they see HTTP requests and return text.

In my opinion, HTTP’s biggest flaw is the design of the interaction. In other words, HTTP’s state retention is the biggest problem we face in development. HTTP is stateless by nature, but that doesn’t mean it can’t be solved.

Why do we stay in the state? The fundamental reason lies in the interaction requirements of the current Internet. What is staying in shape? In plain English, when an HTTP request is made by a client, the server needs to know which client it came from. Imagine, if there is no state, when you visit Taobao, cut off his single, how does the server know that you are under the single? If you send your bill to someone else, are you going to curse?

When it comes to maintaining HTTP state, I would like to point out that HTTP is different from a browser. A browser only uses HTTP to communicate. Many students use the browser as an example when referring to HTTP

HTTP maintains state only by using properties defined by the HTTP protocol itself. For example, Header, Body…… As long as the server recognizes it, it can theoretically be used as a state-preserving credential

Parameter hold state

The simplest and most brutal way to maintain HTTP state is to use parameters directly. The server sends the parameter credentials to the client through THE HTTP protocol. No matter where the client stores them, as long as the next request carries this parameter, the server can read the corresponding parameters according to the convention for identification.

This approach is currently mostly used to preserve non-sensitive information, such as the most common paging parameters

https://www.cnblogs.com/#p2
Copy the code

Who would question that? Are paging parameters status? While most articles refer to a user’s login state, in an abstract definition of state, paging is also a definition of state. However, the maintenance of user identity status, because it involves privacy, generally does not adopt the WAY of URL parameters to maintain.

Cookie stays state

A Cookie is an attribute in the header of an HTTP request that is stored on the client side.

A lot of articles say that cookies are sent from the server to the client, isn’t that a bad thing to say? A Cookie is essentially a client thing. Can’t a client create a Cookie itself? Clients can of course create their own cookies!! However, in the process of user authentication, the cookie that identifies the user is issued by the server, so please do not mislead others when introducing the definition of cookie itself.

Using cookies to preserve HTTP state is a common solution these days, for one reason: in cases where there is no cross-domain in the browser, the browser automatically carries cookies with the HTTP request, which is very convenient. In a non-browser environment, you might need to write code to ensure that cookies are carried each time.

After receiving the HTTP request, the server parses the corresponding cookie to obtain the status identification to be maintained. Speaking of the server, many people mentioned that the session will maintain HTTP state, which is not too good, first of all, session is an abstract concept in nature, and secondly, what we usually refer to as user information, such as session is the KV data belonging to the server. Different clients can recognize different sessions and essentially do this through cookies, so I think it’s not clear that sessions can maintain HTTP state.

Anything else?

Is there any other way to keep an HTTP request state besides the above two methods? Of course there is!!

HTTP state preservation requires both the client and the server to work together to ensure that the client uploads a cookie, but the server cannot parse it properly, so it is not state preservation. Theoretically, as long as the server can identify some of the data carried in the HTTP request, it can achieve the purpose of maintaining state.

In a browser, limited by the capabilities of each browser, a browser sends an HTTP request and automatically carries only specified header and body data. Most headers carry only fixed values specified by the protocol, which is one of the reasons why browsers want to keep HTTP state schemes low. Body is typically used in HTTP requests for POST, so its applications are limited.

There are a number of HTTP header attributes that you can explore if you are interested. The name “Authorization” is mentioned here, which is literally related to authentication, and can be used when we want to maintain user login status in HTTP requests. Does it work to stay in other states? Of course, the values in the header are essentially KV data to the server, and each business has the flexibility to control what the data is used for. For example, the “Authorization” header is usually used for user authentication. Can I use it to identify page A or page B? Sure, as long as the client uploads different Authorization values on different pages, the server can identify these values.

No one has ever said that the HTTP protocol can only be used by clients and servers. Server to server communication can also use HTTP, and many distributed systems do so today. As for server to server communication, HTTP maintains state more flexibly (for browsers). Requesters and recipients can agree on any header to indicate state, thanks to the customizable nature of HTTP headers. For example, if you prefer “XXOO”, you can use the “XXOO” header to identify the status

Accept: Application /json Accept-Encoding: gzip, Deflate, BR Accept-language:.. XXOO:10 times/dayCopy the code

Write in the last

There are many solutions to each problem, and there is no perfect solution, only the one that best fits the business scenario. Recognizing the nature of technology is the quickest way to improve our skills. Limited ability, unlimited technology, welcome criticism and correction!

More interesting articles

  • Distributed large concurrent series
  • Architectural Design Series
  • Series of interesting algorithms and data structures
  • Design Pattern series