Brief analysis of web session mechanism __web

Although the session mechanism has been used in Web applications for a long time, there are still many people who are not clear about the nature of the session mechanism to apply the technology correctly. This article discusses the working mechanism of the session in detail and answers common questions about applying the session mechanism to the Java Web application.

first, the term session

In my experience, the term "session" is probably second only to transaction, and it is more interesting that transaction and session have the same meaning in some contexts.

Session, Chinese often translated as a conversation, its original meaning is the beginning and end of a series of actions/messages, such as phone calls from the pick up the phone to hang up the phone in the middle of a series of processes can be called a sessions. Sometimes we can see the words "during a browser session, ...", where the term "session" is used in its original meaning, refers to from a browser window open to the closure of this period ①. The most confusing is "the user (client) during one session" in such a sentence, it may refer to a series of actions by a user (typically a series of actions related to a specific purpose, such as a process of online shopping from login to checkout, sometimes referred to as a transaction) , however, it is sometimes possible to refer only to a single connection, or to a meaning ①, in which the difference can only be inferred from the context ②.

However, when the term session is associated with a network protocol, it also tends to imply "connection-oriented" and/or "maintain state" such two meanings, "connection-oriented" refers to the communication between the two parties before communication to establish a communication channel, such as telephone, until the other side of the telephone communication to start, In contrast to this is a letter, when you send the letter out of the time you can not confirm the correct address, communication channels may not be established, but for the sender, communication has begun. "Staying state" means that one side of the communication can associate a series of messages so that the messages can be interdependent, such as a waiter who can recognize the old customer again and remember that the last time the customer owed the store a dollar. Examples in this category are "one TCP session" or "one POP3 session" ③.

In the era of Web server booming, the semantics of session in the context of web development has a new extension, meaning refers to a class of solutions used to maintain state between client and server ④. Sometimes the session is also used to refer to the storage structure of this solution, such as "Save XXX in Session" ⑤. Because various languages for web development provide some support for this solution, in a particular language context, the session is also used to refer to the solution of the language, For example, often the Java provided javax.servlet.http.HttpSession abbreviation for Session⑥.

In view of this confusion is not changed, the use of the Word session in this article will have different meanings according to the context, please pay attention to distinguish.

In this article, use the Chinese "browser session" to express the meaning of ①, use the "sessional mechanism" to express the meaning of ④, use "sessions" to express the meaning of ⑤, use the specific "HttpSession" to express the meaning ⑥

HTTP protocol and state retention

The HTTP protocol itself is stateless, which is consistent with the HTTP protocol, the client simply requests to the server to download some files, whether the client or the server is not necessary to record each other's past behavior, each request is independent, Like the relationship between a customer and a vending machine or an ordinary (Non-member) hypermarket.

However clever (or greedy.) People quickly find that if you can provide some dynamic information on demand, it will make the web more useful, just as you would for cable TV with on-demand functionality. This demand, on the one hand, forced HTML to incrementally add forms, scripts, Dom and other client behavior, on the other hand, on the server side of the CGI specification in response to client dynamic request, as the transport carrier of the HTTP protocol also added file upload, cookies these characteristics. The role of cookies is to solve the HTTP protocol stateless defects made efforts. The subsequent session mechanism is another solution that maintains state between the client and the server.

Let's use a few examples to describe the differences and relationships between cookies and session mechanisms. The author used to go to a coffee shop to drink 5 cups of coffee free of charge a cup of coffee, but a one-time consumption of 5 cups of coffee, there is little chance, then need some way to record the number of customers consumption. Imagine that there are no alternatives to the following:

1, the store's staff is very powerful, can remember each customer's consumption quantity, as long as the customer enters the coffee shop, the clerk knows how to treat. This approach is the support state of the Protocol itself.

2, to send customers a card, which records the amount of consumption, generally there is an effective period. Each time the consumer shows this card, the consumption will be associated with previous or future consumption. This approach is to keep the state on the client.

3, to the customer a membership card, in addition to the card number of what information is not recorded, each time consumption, if the customer to show the card, the clerk in the store in the records of this card number to find the corresponding record add some consumer information. This approach is to maintain state on the server side.

Since the HTTP protocol is stateless and does not want to make it stateful for various reasons, the next two scenarios become a realistic choice. Specifically, the cookie mechanism is a scheme for maintaining state on the client side, and the session mechanism uses the scheme of maintaining state at the server end. At the same time, we also see that because the server-side retention scheme also needs to be stored in the client, the session mechanism may need to use the cookie mechanism to save the identity, but in fact it has other options.

Iii. Understanding Cookie mechanism

The basic principle of the cookie mechanism is as simple as the example above, but there are several questions to be resolved: "Membership card" How to distribute, "membership card" content, and how the customer uses the "membership card".

Orthodox cookie distribution is implemented by extending the HTTP protocol, and the server prompts the browser to generate the appropriate cookie by adding a special line of instructions to the HTTP response header. However, pure client script such as JavaScript or VBScript can also generate cookies.

And the use of cookies by the browser in accordance with certain principles in the background automatically sent to the server. The browser checks all stored cookies and sends the cookie to the server on the HTTP request header of the requesting resource if the cookie is declared to be more than equal to the location of the resource being requested. McDonald's membership card can only be produced in the McDonald's store, if a branch also issued its own membership card, then enter this shop in addition to show McDonald's membership card, but also to show the membership card of the store.

The contents of the cookie mainly include: name, value, expiration time, path and domain.

Where a domain can specify a domain, such as. google.com, the equivalent of the head office signs, such as Procter and Gamble, you can also specify a specific machine under a domain such as www.google.com or froogle.google.com, can be used to do than the float.

The path is to follow the domain name after the URL path, such as/or/foo, and so on, you can use a floating soft counter to do than.

The path is combined with the domain to form the scope of the cookie.

If you do not set an expiration time, the cookie's lifetime is during a browser session, and the cookie disappears as soon as the browser window is closed. This lifetime is known as a session cookie for a browser session-time cookie. Session cookies are generally not stored on the hard disk but are kept in memory, although this behavior is not regulated by the specification. If an expiration time is set, the browser saves the cookie to the hard disk, turns it back on and opens the browser again, and the cookies are still valid until the set expiration time is exceeded.

Cookies stored on your hard disk can be shared between different browser processes, such as two IE windows. For cookies stored in memory, different browsers have different ways of handling them. For IE, a window that is opened by pressing CTRL-N (or from the File menu) on an open window can be shared with the original window, while the new IE process in other ways cannot share the memory cookie of the open window; for Mozilla Firefox0.8, all processes and tab pages can share the same cookie. In general, a window opened with JavaScript window.open will share the memory cookie with the original window. The browser's handling of this cookie-only recognition of session cookies is often a major problem for Web application developers adopting the sessions mechanism.

Here is an example of a Goolge setting the response header for a cookie

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

This is part of the HTTP communication record captured using Httplook this HTTP sniffer software

The browser automatically sends out cookies when it accesses Goolge resources again

Using Firefox makes it easy to see the value of an existing cookie

Using Httplook with Firefox makes it easy to understand how cookies work.

IE can also be set to ask before accepting cookies

This is a dialog box asking to accept cookies.

Iv. Understanding of the session mechanism

The session mechanism is a server-side mechanism in which the server uses a structure similar to a hash table (or perhaps a hash table) to hold the information.

When a program needs to create a session for a client's request, the server first checks to see if the client's request already contains a session ID-called the session ID. If a session is included ID indicates that the session has previously been created for this client, and the server retrieves it using the session ID (if it is not retrieved, a new one may be made), and if the client request does not contain a session ID, A session is created for this client and a value that generates a session Id,session ID associated with this session should be a string that neither repeats nor is easily found to mimic, this session The ID will be returned to the client for saving in this response.

This session ID can be saved in the form of a cookie, so that the browser can automatically play the logo to the server as per the rules during the interaction. Generally this cookie's name is similar to Seeesionid, and. For example, WebLogic for Web application-generated cookie,jsessionid=byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng!- 145788764, its name is Jsessionid.

Since cookies can be artificially banned, there must be other mechanisms to pass the session ID back to the server when the cookie is blocked. A technique that is often used is called URL rewriting, which is to attach the session ID directly behind the URL path, and there are two additional methods, one being the additional information as a URL path, and the representation 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
These two ways for users is no difference, but the server in the resolution of the different ways to deal with, the first way is also conducive to the session ID information and normal program parameters to distinguish.

In order to remain state throughout the interaction, the session ID must be included after the path that each client may request.

Another technique is called a form-hiding field. The server will automatically modify the form and add a hidden field so that the session ID can be passed back to the server when the form is submitted. Like the following form

<form name= "Testform" action= "/xxx" >
<input type= "Text" >
</form>

will be overwritten before being passed to the client

<form name= "Testform" action= "/xxx" >
<input type= "hidden" name= "Jsessionid" value= "byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng!-145788764" >
<input type= "Text" >
</form>

This technique is now less applied, and the old IPlanet6 (formerly known as the SunOne application server) that I have contacted have used this technique. In fact, this technique can be simply replaced by applying URL rewriting to the action.

When talking about the session mechanism, it is often heard that "as long as the browser is closed, the session disappears." In fact, you can imagine the membership card example, unless customers take the initiative to put a PIN card, otherwise the store will not easily delete the customer's information. For the session is also the same, unless the program notifies the server to delete a sessions, otherwise the server will remain, the program is generally in the user do log off when the instructions to delete session. However, the browser never proactively notifies the server that it is shutting down before shutting down, so the server will never have a chance to know that the browser has been turned off, and this illusion is that most of the session cookies are used to save sessions IDs. The session ID disappears when you close the browser, and you cannot find the original session when you connect to the server again. If the server-set cookie is saved to the hard disk, or if you use some means to overwrite the HTTP request header issued by the browser, and send the original session ID to the server, you can still find the original session by opening the browser again.

Precisely because the browser does not cause the session to be deleted, forcing the server to set an expiration time for seesion, the server can assume that the client has stopped the activity when it is more than the expiration time from the time when the client last used sessions. Will remove the session to save storage space.