The Difference and connection between cookie and session are discussed by JSESSIONID.

In some situations such as voting, we usually require that each person only vote for one vote because of the principles of fairness. In some web development, similar situations are also found. At this time, we usually use cookies to implement such a vote, for example, the following code:
<% Cookie [] cookies = request. getcookies ();
If (cookies. lenght = 0 | cookies = NULL)
Dostufffornewbie ();
// No Access
}

Else
{
Dostuffforreturnvisitor (); // already accessed
}

%>

This is an easy-to-understand principle. Check the existence of a cookie. If the existence of a cookie indicates that the Code that has been written to the cookie has been run. However, after the above Code is run, dostuffforreturnvisitor () is executed whenever the result is returned (), you can use control panel-Internet option-settings-to view the file but cannot see the generated cookie file. It is strange that the code is clearly correct. However, if there is a cookie, it will be displayed.
Cookie [] cookies = request. getcookies ();
If (cookies. lenght = 0 | cookies = NULL)
Out. println ("has not visited this website ");
}

Else
{
For (INT I = 0; I <cookie. length; I ++)
{
Out. println ("Cookie name:" + Cookies [I]. getname () + "cookie value:" +
Cookie [I]. getvalue ());
}
}

Running result:
Cookie name: JSESSIONID cookie value: kwjhug6jjm65hs2k6 why is there a cookie? We all know that HTTP is a stateless protocol. Every time a customer reads a web page, the server opens a new session, in addition, the server does not automatically maintain the customer's context information, so how can we implement the shopping cart in the online store? session is a mechanism to save the context information for every user, the value of the variable is stored on the server side. sessionid is used to distinguish different customers. Session is based on cookie or URL rewriting. Cookie is used by default, the system will create an output cookie named JSESSIONID, called session cookie, to distinguish persistent cookies, which we usually call cookies. Note that session cookies are stored in the browser memory, it is not written to the hard disk, that is, the JSESSIONID we just saw. We usually cannot see JSESSIONID, but when we disable the cookie of the browser, the web server will use URL rewriting to pass the sessionid, we can see strings such as sessionid = kwjhug6jjm65hs2k6 in the address bar.
After understanding the principles, we can easily distinguish the differences between persistent cookies and session cookies. The discussions on the security of the two on the Internet are clear. session cookies are for a session, session Cookie disappears, while the persistent cookie is only a piece of text (usually encrypted) stored on the client's hard disk ), in addition, Cookie spoofing and cross-site scripting attacks against cookies are not as secure as session cookies.
Generally, session cookies cannot be used across windows. When you open a new browser window to enter the same page, the system will give you a new sessionid, in this way, we cannot achieve the purpose of information sharing. At this time, we can first save the sessionid in the persistent cookie, and then read it out in the new window to get the sessionid of the previous window, in this way, session cookie and persistent cookie are combined to achieve cross-window session tracking ).
In some web development books, session and cookie are usually used as two parallel HTTP transmission methods. session cookies are on the server side, and persistent cookies are on the client side, however, session is based on cookies. It is not difficult to select the appropriate technology to develop Web services by understanding the relationship and difference between the two.

Bytes ----------------------------------------------------------------------------------------------------------------------

Differences and connections between cookie and session mechanisms

Specifically, the cookie mechanism adopts the client-side persistence scheme. It is the storage mechanism of session status on the user end. It requires the cookie support from the user to open the client. Cookie is used to solve the stateless defects of HTTP.
The session mechanism adopts a solution that maintains the status between the client and the server. At the same time, we also see that because the server-side persistence scheme also needs to save an identifier on the client, the session mechanism may need to use the COOKIE Mechanism to save the identifier. Session provides a convenient way to manage global variables.

The session is for every user. The value of the variable is stored on the server and a sessionid is used to identify which user session variable is used, this value is returned to the server when the user's browser accesses it. When the customer disables the cookie, this value may also be set to get to return to the server.

In terms of security: When you access a site that uses sessions and create a cookie on your host, it is recommended that the session mechanism on the server be safer. because it does not read the information stored by the customer.

The orthodox cookie distribution is implemented by extending the HTTP protocol. The server adds a special line of instructions to the HTTP response header to prompt the browser to generate the corresponding cookie according to the instructions.

From the network server perspective, all HTTP requests are independent of previous requests. That is to say, each HTTP Response completely relies on the information status management mechanism contained in the corresponding request to overcome some HTTP restrictions and allow the network client and server to maintain the relationship between requests. The period in which this relationship is maintained is called session ).

Cookies are small pieces of text stored by the server on the local machine and are sent to the same server as each request. Ietf rfc 2965 HTTP state management mechanism is a common cookie specification. The network server uses the HTTP header to send cookies to the client. On the client terminal, the browser parses these cookies and saves them as a local file. It will automatically upload these cookies to any requests on the same server.

Bytes ----------------------------------------------------------------------------------------------------

Differences and relationships between cookie and session mechanisms

Specifically, the cookie mechanism adopts the client-side persistence scheme, while the session mechanism adopts the server-side persistence scheme. At the same time, we can also see that because the server-side persistence scheme also needs to save an identifier on the client, the session mechanism may need to use the COOKIE Mechanism to save the identifier, but in fact it has other options. COOKIE Mechanism. The orthodox cookie distribution is implemented by extending the HTTP protocol. The server prompts the browser to generate the corresponding cookie by adding a special line in the HTTP response header. However, pure client scripts such as JavaScript or VBScript can also generate cookies. Cookies are automatically sent to the server in the background by the browser according to certain principles. The browser checks all stored cookies. If the declared range of a cookie is greater than or equal to the location where the requested resource is located, the cookie is attached to the HTTP request header of the requested resource and sent to the server. Cookie content mainly includes: name, value, expiration time, path and domain. The path and the domain form the scope of the cookie. If no expiration time is set, it indicates that the Cookie's life cycle is the browser session period. When the browser window is closed, the cookie disappears. This cookie is called a session cookie. Session cookies are generally stored in the memory instead of on the hard disk. Of course, this behavior is not standardized. If the expiration time is set, the browser will save the cookie to the hard disk, close it, and open the browser again. These cookies are still valid until the preset expiration time is exceeded. Cookies stored on hard disks can be shared among different browser processes, such as two IE Windows. For Cookies stored in the memory, different browsers have different processing methods. Session mechanism. The session mechanism is a server-side mechanism. The server uses a structure similar to a hash (or a hash) to save information. When the program needs to create a session for a client request, the server first checks whether the client request contains a session ID (called session ID ), if it already exists, it indicates that a session has been created for this client. Then, the server retrieves and uses this session according to the session ID (a new session will be created if it cannot be retrieved ), if the client request does not contain the session ID, the client creates a session and generates a session ID associated with the session. The session ID value should be unique, the session ID is returned to the client for saving in this response. The cookie can be used to save the session ID. In this way, the browser can automatically display the ID to the server according to the Rules during the interaction. Generally, the cookie name is similar to seeesionid. However, if a cookie can be artificially disabled, there must be other mechanisms so that the session ID can still be passed back to the server when the cookie is disabled. A frequently used technology called URL rewriting is to directly append the session ID to the end of the URL path. Another technique is form hidden fields. The server automatically modifies the form and adds a hidden field so that the session ID can be passed back to the server when the form is submitted. For example: <Form name = "testform" Action = "/XXX"> <Input type = "hidden" name = "JSESSIONID" value = "byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng! -145788764 "> <Input type = "text"> </Form> In fact, this technology can be simply replaced by rewriting the URL of the action application.