Cookies and sessions are designed to maintain user access, on the one hand, in order to facilitate business implementation, on the other hand, to simplify the design of the server, improve access performance. Cookies are the technology of the client (that is, the browser side), and after the cookie is set, every time the server is accessed, the cookie;session is a server-side technology that stores the user's access information on the server side.
The use of cookies to pass information, as the number of cookies and access to increase, it takes up more bandwidth, the use of session to save information, the biggest weakness is not easy to share among multiple servers.
1 cookies
In layman's terms, when a user uses HTTP to access a server, the server returns some key-value information to the client browser and adds some restrictions to the data, and the next time the user accesses the server, it takes the cookie key value pair information that was previously set. When the user enters a URL, the browser looks for the Cookie associated with the URL on the local hard disk. If the cookie exists, the browser sends the cookie to your site along with the page request.
Cookies are associated with a Web site, not with a particular page. Therefore, the browser and the server Exchange Cookie information regardless of which page in the site the user is requesting. When users visit different sites, each site may send a cookie to the user's browser, and the browser stores all cookies separately.
Cookie Property Entry
The current Cookie has 2 versions, version 0 and version 1, which have 2 sets of response header identities, namely "Set-cookie" and "Set-cookie2".
Cookie 0 Property value
Cookie 1 Property value
Example of using cookies in Java
@Override public
void doget (HttpServletRequest request, httpservletresponse response) throws IOException {
Response.setcontenttype ("Text/html;charset=utf-8");
PrintWriter out = Response.getwriter ();
cookie[] cookies = request.getcookies ();
String name = Getcoodie (cookies, "name");
if (name = = null) {
Response.addcookie (new Cookie ("name", "Luoxn28"))
;
else {
System.out.println (name);
}
Out.println ("Hello World");
}
public static String Getcoodie (cookie[] cookies, String key} {
if (cookies!= null) {for
(Cookie Cookie:cooki ES) {
if (Cookie.getname (). Equals (key)) {return
cookie.getvalue ();
}
}} return null;
}
Some considerations for using cookies (for example, in Java usage)
• The name and value of the cookie you create cannot be a assic character, and if it is Chinese, you can encode it by Rrlencoder, or you will throw a java.lang.IllegalArgumentException exception.
• When multiple name and value values appear, they are actually in the same "Cookie" header.
The value of the cookies can be saved except for the ";" Outside of the punctuation. But you can't save Chinese characters. Save Chinese characters will appear garbled.
Some limitations of cookies
A cookie is a field in an HTTP header, and HTTP itself has no restrictions on the field, but the cookie is eventually stored in the browser, and different browsers have some limitations on the storage of the cookie, as shown in the following table:
If you try to store more cookies, the oldest cookies are discarded.
2 session
Session to solve the increase in the number of cookies will be increased client and server data transfer problem, the same client and server interaction, do not need to return all the cookie value every time, but only return an ID value, this ID is the first time the client access to the server generated, And each client is unique, and this ID is usually a cookie named Jsessionid.
How the session is based on cookies, can be based on the URL Path parameter method, or it can be based on cookies, and if the cookie ID in the context container is not modified, it is supported by default. When the browser does not support cookie functionality, the browser overrides the user's sessioncookiename to the URL parameter requested by the user, which is passed in such a way as/path/servlet;name=xxx;name2=xxx2?name3=xxx3. Sessioncookiename If you configure the Session-config configuration entry in Web.xml, the Name property under Cookie-config is the value of this sessioncookiename. If the Session-config configuration entry is not configured, the default Sessioncookienamejiushi "Jsessionid". Note that the cookie associated with the session does not differ from the other cookies. If the client also supports cookies, Tomcat will still resolve the session ID in the cookie and overwrite the session ID in the URL.
How the session Works
With the session ID, the server can create the HttpSession object, call the Request.getsession () method for the first time, and if there is no corresponding HttpSession object, a new one is created, This object is added to the Org.apache.catalina.Manager sessions container for saving. Manage saves all session lifecycle, session expiration is reclaimed, server is closed, session is serialized to disk. Note that a client corresponds to a session object that holds the session value we created.
The standardsession of the Request.getsession () method invocation will always exist, even if the session associated with the client has expired. If it expires, a new one is created, but the previously set session value will be lost.
3 Cookie vs Session security Comparison
Cookies will save the data from the client to the server through the HTTP header, from the server back to the client, all the data are stored in the client browser, the data are accessible, and even through plug-ins to add, modify cookies, all cookies are relatively poor security. In comparison, the session saves data on the server side, which is much more secure, and only requires a cookie to pass back a cookie ID, so the session is better suited to save user privacy and important data.
Distributed Session Framework
Cookies and sessions are not feasible in large Internet applications, because using cookies can be a good solution to the distributed deployment problem of applications, there are hundreds of machines in a large Internet application system, and many different application systems work together, Since cookies store data in a user's browser, the user speaks the data back to the server on each visit, and resolves the cookie inconsistency caused by the same user's request being processed on different servers.
Because the application is a cluster, so you can not save the session in the memory of each server, if each server has hundreds of thousands of access users, server memory can not accommodate, even if there is no guarantee that the session synchronization to other servers, So sharing these sessions needs to be stored in a dedicated distributed cache that can be read and written at any time, and the performance is good enough to meet the requirements, such as Memcache/redis or Taobao Open source distributed framework Tair is a good choice.
Form repeat submit issue
There are many places in the Web site that have duplicate submission forms. In order to prevent form recurrence, it is necessary to identify the user's every access request, making each access request unique to the server, in order to identify each request of the user, you can add a hidden form item in the form field requested by the user, with a value of only token, Such as:
<form id= "form" method= "post" > ...
<input Type=hidden name= "token" value= "xxx"/>
</form>
When a user requests a form, it generates a unique token, and is set to the user's session, and when the user submits it, detects if the token is consistent with the token saved in the session, and if it is consistent, it is not repeated. At the same time, the token in session is updated to a new token value, otherwise the token submitted by the user is not the legitimate token of the current request, and the commit fails.
The above is a small set up to introduce Java cookies and session of those things, I hope to help you, if you have any questions please give me a message, small series will promptly reply to everyone. Here also thank you very much for the cloud Habitat Community website support!