In order to better understand this problem, let's first talk about the past life of Cookie, and see what kind of problems Cookie exists to solve. Can it really be removed?
The stateless feature of HTTP
HTTP is a stateless protocol that does not preserve the state of communication between clients and servers. This allows a large number of transactions to be processed and ensures the scalability of the HTTP protocol.
The stateless nature of the HTTP protocol means that the server has no way of knowing whether two requests are from the same browser, that is, the server does not know what the user did last time, and each request is completely independent of the other.
The early days of the Internet were simply for browsing information in documents, yellow Pages, portals, etc. There was no such thing as interaction. But with the slow development of the Internet, broadband, servers and other hardware facilities have been greatly improved, the Internet allows people to do more things, so the interactive Web slowly rise, and HTTP stateless characteristics are seriously hindered its development!
How to record the user's last action? There are usually two ways:
- carry token in url
Put the last request id in the url by adding an extra field to the url.
- add hidden fields to interactive forms
<input type="hidden" name="requestId" value="idValue" />
These two methods can solve the problem of recording the last operation of the user, but the operation is too complicated and error-prone.
The reason for the birth of cookies?
In 1994, Lou Montulli, an employee of NetScape (Netscape), tried to solve the first shopping cart application on the Web. In order to solve the shopping cart history of users' online shopping, the concept of "cookies" was applied to Network communication, NetScape browser began to support cookies in the first version, and all browsers currently support cookies.
What are cookies?
A cookie is a small text file that a browser stores on a user's computer. Cookies are in plain text format and do not contain any executable code.
A Web page or server tells the browser to store this information according to certain specifications, and sends this information to the server in subsequent requests, and the Web server can use this information to identify different users. Most websites that require login will set a cookie after the user is authenticated successfully. As long as the cookie exists and is available, the user can browse any page of the website freely.
Cookies contain only data and are not harmful by themselves.
How cookies solve the problem of HTTP statelessness
We call a user's access to the service as a session. When the server receives the session request for the first time, it generates a sessionID and stores it on the server, and then tells the browser to store the sessionID through the HTTP Set-Cookie field. Store it in the browser (including which domain name and path can be accessed, and how long it is valid). Then the next time a request is initiated, the sessionID stored in the browser cookie is passed to the service through the Cookie field, and the sessionID brought by the service through the http request matches whether there is a corresponding sessionID in the server, so as to know the user who initiated the request. who is it.
A large amount of personal data is stored in cookies, which will lead to huge cookies, so every http request will bring the cookie information completely, which will put a lot of pressure on the service. At the same time, because the personal data is stored in the cookie in plain text, once the website has an xss vulnerability, it is easy to leak personal information.
However, html5 defines localStorage/sessionStorage, which is specially used to solve the problem of data storage on the browser side, so that cookies can concentrate on doing what they need to do.
cookies will not be removed, at least, on the premise that the stateless nature of the HTTP protocol has not changed, cookies will not be removed.