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 uses... "/> <scripttype =" text/javascript "src =" ht

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 is completely dependent on the information contained in the corresponding request.
The status management mechanism overcomes HTTP restrictions and allows network clients and servers 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.
Certificate -------------------------------------------------------------------------------------------------------------------------------------------------------------------
Understanding 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 the session id, if a session id is included, it indicates that a session has been created for this client before, and the server uses the session id to retrieve the session. (if the session id is not found, a new one may be created ), 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. For example, for weblogic cookies generated by web applications, JSESSIONID = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng! -145788764, whose name is JSESSIONID.

Because cookies can be artificially disabled, there must be other mechanisms so that session IDs can still be passed back to the server when cookies are disabled. A frequently used technology called URL rewriting is to directly append the session id to the end of the URL path. There are two additional methods, one is as the additional information of the URL path, the format is http ://..... /xxx; jsessionid = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng! -145788764
The other is appended to the URL as a query string, in the form of http: //.../xxx? Jsessionid = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng! -145788764
There is no difference between the two methods for users, but they are handled differently by servers during parsing, the first method also helps to distinguish the session id information from the normal program parameters.
To maintain the status throughout the interaction process, the session id must be included after the path that each client may request.

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, the following form

It will be rewritten

This technology is rarely used now. I have used iPlanet6, the predecessor of the SunONE application server.
In fact, this technology can be simply replaced by rewriting the URL of the action application.

When talking about the session mechanism, we often hear the misunderstanding that "the session disappears as long as the browser is closed ". In fact, you can imagine the example of a membership card. unless the customer initiates a card sales proposal for the store, the store will never easily delete the customer's information. The same applies to Sessions. unless the program notifies the server to delete a session, the server will keep it. Generally, the program sends a command to delete the session when the user logs off. However, the browser will never notify the server that it is about to close before it closes, so the server will not have the opportunity to know that the browser has been closed, most session mechanisms use session cookies to save session ids. when the browser is closed, the session id disappears, and the original session cannot be found when the server is connected again. If the cookie set by the server is saved to the hard disk, or the HTTP request header sent by the browser is rewritten by some means, the original session id is sent to the server, then you can still find the original session when you open the browser again.

It is precisely because closing the browser will not cause the session to be deleted, forcing the server to set an expiration time for the seesion. when the last time the session was used by the client exceeds this Expiration Time, the server considers that the client has stopped the activity before deleting the session to save storage space.
Certificate -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.