Comparison of cookie and session mechanisms

first, let's look at an example. I often went to a coffee shop and offered a free discount for five coffee cups. There is very little chance of consuming five cups of coffee. In this case, you need to record the consumption quantity of a customer in some way. Imagine the following solutions:

1. The store clerk is very good. Remember the number of consumers each day. As soon as the customer enters the coffee shop, the clerk will know What should I do. This method is supported by the Protocol itself.
2. Send a card to the customer, which records the consumption quantity and generally has a validity period. For each consumption, if the customer shows this card, the current consumption will be associated with the previous or later consumption. This approach is to maintain the status on the client.
3. Send a membership card to the customer. No information except the card number is recorded, if the customer shows the card, the clerk finds the corresponding log of the card number in the store and adds some consumption information. This approach is to maintain the status on the server side.

Because the HTTP protocol is stateless and does not need to be stateful for various reasons, the next two solutions have become a realistic choice. SpecificallyThe cookie mechanism adopts the client-side persistence scheme., AndThe 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. 

(1) Understanding the COOKIE Mechanism 
The basic principle of the cookie mechanism is as simple as the above example, but there are several problems to solve: how to distribute "membership cards", the content of "membership cards", and how customers use "membership cards ". 

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.. 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. This means that the McDonald's membership card can only be presented in the McDonald's store. If a branch still has its own membership card, in addition to the McDonald's membership card, the store's membership card is also presented. 

cookie content mainly includes: name, value, expiration time, path, and domain .
A domain can specify a domain such as .google.com, which is equivalent to a main store sign, such as Procter & Gamble, you can also specify a specific machine in a domain, such as www.google.com or froog ...... you can use rejoice for comparison.
the path is the URL path following the domain name, for example,/or/Foo. You can use a rejoice counter for comparison.
the combination of paths and domains constitutes the scope of cookie.

If the expiration time is not set, It indicates that the life cycle of the cookie is the browser session, and the cookie disappears as long as the browser window is closed. 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, and then 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. For IE, pressing Ctrl-N (or from the File menu) in an open window can share the window with the original window, other new ie processes cannot share the memory cookies of opened windows. for Mozilla firefox0.8, all processes and tabs can share the same cookies. Generally, the window opened with window. Open in Javascript will share the memory cookie with the original window. The browser often uses session cookies for Web applications.ProgramDevelopers cause great troubles. 

The following is an example of how goolge sets the cookie response header.The browser automatically sends a cookie when accessing goolge resources again.

 
HTTP/1.1 302 found location: http://www.google.com/intl/zh-CN/ set-COOKIE: Pref = id = 0565f77e132de138: nw = 1: TM = 1098082649: LM = 1098082649: S = kaeacfpo49ria_d8; expires = sun, 17-Jan-2038 19:14:07 GMT; Path =/; domain = .google.com Content-Type: text/html
 

 (2) Understanding the 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 automatically sends 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 is URL rewriting.The session ID is directly appended to the URL path, and there are two additional methods. One is as the URL path additional information, in the form of http: //..... /xxx; JSESSIONID = byok... 99 zwpbng! -145788764 The other is appended to the URL as a query string, in the form of http: //.../XXX? JSESSIONID = byok... 99 zwpbng! -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 

 
<Form name = "testform" Action = "/XXX"> <input type = "text"> </form>
 

It will be rewritten 

<Form name = "testform" Action = "/XXX"> <input type = "hidden" name = "JSESSIONID" value = "byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng! -145788764 "> <input type =" text "> </form>
 

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 sales card to 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 ID 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 does not cause the session to be deleted, forcing the server to set an expiration time for the seesion, when the last time the client used the session exceeds the expiration time, the server can think that the client has stopped the activity before deleting the session to save storage space.