From (in-depth analysis of the inside story of JavaWeb technology, and Amway this book to everyone, author: Xu Lingbo)
Session and cookie are simply HTTP configuration items, which only correspond to a class in the servlet specification; but when our system is large enough to require a lot of cookies, we have to consider HTTP's restrictions on the number and size of cookies; Session also encounters such a problem. When one of our application systems has hundreds of servers, how to solve the problem of session sharing between servers? There are also some security issues, such as how to avoid cookie theft and cookie forgery?
Both sessions and cookies are used to maintain the interaction between the visiting user and the backend server, and each has its own advantages and disadvantages. However, ironically, their advantages and their, for example, when using cookies to transmit information, increase with the number of cookies. With the increase of the number of visits and the increase of the number of visits, it occupies more and more network bandwidth; and the Achilles heel of the session is that it is not easy to be shared among multiple servers, which also limits the use of the session.
Deep understanding of cookies
The role of cookies: Generally speaking, when a user accesses a server through http, the server will return some Key/Value key-value pairs to the client browser, and add some restrictions to the data, when the conditions are met The next time the user accesses the server, the data is brought back to the server in its entirety. A more common example is: when you go shopping in the supermarket, you get a shopping card for the first time, put some personal information in this shopping card, and next time you come to this supermarket, just swipe the card directly.
The current cookie has two versions, Version 0 and Version 1, and they have two types of audit response header identifiers, namely "Set-Cookie" and "Set-Cookie2". There are some differences in the properties of the two versions:
The identifiers of the Header headers of the above two versions are different. We commonly use Set-Cookie: userName = "haha"; Domain = "taoyongpan.xin", which is the form of Version 0. For Set-Cookie2 is set like this: Set-Cookie2: userName = "haha";
Domain = "taoyongpan.xin";Max-Age = 1000. However, in the Servlet specification of JavaWeb and support the response header in Set-Cookie2, in practical applications, some attribute items of Set-Cookie2 can be set in Set-Cookie, such as this configuration: Set-Cookie: userName="haha "; Version = "1"; Domain = "taoyongpan.xin"; Max-Age = 1000. But when we use the Servlet3.0 specification to create a Cookie object, the Cookie supports both Version1 and Version 0;
But when we create cookies, we should pay attention to the following points:
1. The name of the created cookie cannot be the same as the attribute value of Set-Cookie and Set-Cookie2. If the same, an IllegalArgumentException will be thrown.
2. The value of the NAME and VALUE of the created cookie cannot be set to ASSIC characters. If you want to use Chinese, you can use URLEncoder to encode it, otherwise an IllegalArgumentException will be thrown.
3. When some TOKEN characters (such as "\", ",", etc.) appear in the values of NAME and VALUE, the build return header will automatically set the Cookie's Version to 1;
4. When the attribute item of Version1 appears in the attribute item of the cookie, the construction of the HTTP response header will also set the Version to 1.