Servlet old play new sing the session again

Servlet|session

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.

But smart (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 the URL path, the representation beinghttp://...../xxx;jsessionid=byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng!-145788764
The other is appended to the URL as a query string, in the formhttp://...../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


will be overwritten before being passed to the client
Value= "byok3vjfd75apnrf7c2hmdnv6qzcebzwowibyenlerjq99zwpbng!-145788764" >


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, browsers never actively notify the server that it will shut 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 cookie is used to save the sessions ID, and when the browser closes the The session ID disappears 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.

v. Understanding of Javax.servlet.http.HttpSession
HttpSession is the Java platform for the implementation of the session mechanism specification, because it is only an interface, specific to each Web application Server provider, in addition to the specification support, there will still be some specifications do not specify the subtle differences. Here we demonstrate it as an example of Bea's WebLogic Server8.1.

First, Weblogic server provides a series of parameters to control its HttpSession implementation, including the option to use cookies, switch options with URL overrides, session persistence settings, session Expiration time settings, and various settings for cookies, such as setting the name of the cookie, the path, the domain, the lifetime of the cookie, and so on.

In general, the session is stored in memory, when the server process is stopped or restarted, memory session will be emptied, if set the persistence of the session feature, the server will be saved to the hard disk, When the server process restarts or the information will be used again, the Weblogic server supports persistence in the form of files, databases, client cookie saving, and replication.

Replication is strictly not a persistent save because the session is actually kept in memory, but the same information is replicated to the server process within each cluster, so that even if a server process stops working, it can still get a session from another process.

The cookie lifetime setting affects whether the browser-generated cookie is a session cookie. The default is to use session cookies. Interested can use it to test the misunderstanding we mentioned in the fourth quarter.

The path to the cookie is a very important option for Web applications, and Weblogic server's default handling of this option makes it significantly different from other servers. We'll have a discussion later.

About setting the session reference [5]http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html

Vi. httpsession FAQ
(The meaning of the session in this section is the blending of ⑤ and ⑥)

1, when the session was created
A common misconception is that the session is created when there is client access, but the fact is that it is not created until a server-side program invokes a statement such as Httpservletrequest.getsession (true), noting that if the JSP does not display the use <% @page session= "false"%> closes the session, the JSP file is automatically translated into a servlet with such a statement HttpSession Httpservletrequest.getsession (true); This is also the origin of the session object implied in the JSP.

Because session consumes memory resources, you should close it in all JSPs if you do not intend to use it.

2, when the session was deleted
In combination with the previous discussion, the session is deleted in the following cases a. Program calls Httpsession.invalidate (); The distance from the last time the client sent the sessions ID interval is more than the timeout setting; or C. Server process is stopped (non persistent session)

3, how to do when the browser is closed to delete session
Strictly speaking, this is not to be done. One way to do this is to use JavaScript code window.oncolose on all client pages to monitor the browser's shutdown action, and then send a request to the server to delete the session. But there is still nothing to do about the browser crashing or the forced killing of the process by unconventional means.

4, what's going on with a httpsessionlistener?
You can create such listener to monitor session creation and destruction events so that you can do some work when such events occur. Note that the creation and destruction actions of the session trigger the listener, not the other way around. Similar to httpsession-related listener and Httpsessionbindinglistener,httpsessionactivationlistener and Httpsessionattributelistener.

5, the object stored in the session must be serializable?
are not required. Object serialization is required only for the session to be replicated in the cluster or to be persisted or, if necessary, for the server to swap session memory temporarily. Placing an Weblogic object in the session of the server receives a warning on the console. One of the iplanet versions that I used. If there is an object in the session that is not serializable, there will be a exception when it is destroyed, very strange.

6, how to correctly deal with the possibility of the client to prohibit cookies
URL overrides are used for all URLs, including hyperlinks, form actions, and redirected URLs, as specified in [6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html

7, open two browser window to access the application will use the same session or different sessions
See the third section of the discussion of cookies, for the session is only ID not identify, so different browsers, different windows open way and different ways of storing cookies will affect the answer to this question.

8, how to prevent users to open two browser window operation caused by session confusion
This problem is similar to preventing the form from being submitted multiple times, and can be resolved by setting the client's token. is when the server generates a different ID to return to the client each time, also stored in the session, the client must return the form when the ID also returned to the server, the program first compares the returned ID and saved in the session of the value is consistent, if inconsistent then that this operation has been submitted. You can see the section on the presentation layer pattern in the Java EE core model. Note that for Windows that are open with JavaScript window.open, this ID is not normally set, or a separate ID is used to prevent the main window from being unable to operate, and it is recommended that you do not modify the window.open open window so that you do not need to set it.

9, why change the value of the session in WebLogic server to call again Session.setvalue
This action is done primarily to prompt in the cluster environment that the value in the WebLogic server session has changed, and the new sessions value needs to be replicated to other server processes.

10, why the session disappeared
Excluding the normal failure of the session, the possibility of the server itself should be minimal, although the author in Iplanet6sp1 plus a number of patches on the Solaris version has also been encountered; the possibility of browser Plug-ins, the author also encountered 3721 Plug-ins caused by the problem Theoretically, the firewall or proxy server may also have problems with cookie processing.
Most of the reasons for this problem are program errors, and the most common is to access another application in one application. We'll discuss the issue in the next section.

Seven, cross-application session sharing

It is often the case that a large project is split into small projects that require each small project to be developed as a separate Web application to be able to interfere with each other, but at the end of the day there is a sudden discovery that a few small projects need to share some information or want to use the session to implement SSO ( Single sign on), saving login's user information in session, the most natural requirement is that applications can access each other's sessions.

However, according to the servlet specification, the scope of the session should be limited to the current application, where different applications cannot access each other's sessions. Each application server complies with this specification in real terms, but the details of the implementation may vary, so there are different ways to resolve sharing across application sessions.

First, let's look at how Tomcat implements session isolation between Web applications, and from the cookie path set by Tomcat, it is different for the cookie path for different application settings, so the session IDs used by different applications are different. So even if you are accessing a different application in the same browser window, the session ID sent to the server can be different.

Based on this feature, we can speculate that the memory structure of the session in Tomcat is roughly as follows.

The author used before the iplanet is also used in the same way, estimated SunOne and iplanet will not be too big difference. For this kind of server, the solution of the idea is very simple, the actual implementation is not difficult. Either have all the applications share a session ID, or have the application get the session ID of the other application.

In iplanet, there is an easy way to share a session ID, which is to set the cookie path for each application to/(in fact, it should be/nasapp, which acts as the root for the application).
/nasapp


It should be noted that the session of the operation share should follow some programming conventions, such as adding the prefix of the application to the name of the session attribute, so that setattribute ("name", "Neo") becomes setattribute (" App1.name "," Neo ") to prevent namespace collisions, resulting in overwriting each other.


In Tomcat, there is no such a convenient choice. On Tomcat version 3, we can also have some means to share the session. For Tomcat above version 4, the author has not yet found a simple solution. Can only use the power of a third party, such as using a file, database, JMS or client cookie,url parameters or hidden fields and other means.

Let's take a look at how WebLogic server handles sessions.

From the screen screen, you can see that the WebLogic server has a path to all the cookies that are set by the application, does this mean that the session can be shared by default in WebLogic server? However, a small experiment proves that even if different applications use the same session, each application can still access only those properties that it has set. This indicates that the memory structure of the session in WebLogic server may be as follows

For such a structure, it should be impossible to solve the problem of session sharing in the session mechanism itself. In addition to the power of third parties, such as the use of files, databases, JMS or client cookie,url parameters or hidden fields, and other means, there is a more convenient way to put an application session into the ServletContext, This allows another application to obtain a reference to the previous application from the ServletContext. The sample code is as follows,

Application A
Context.setattribute ("Appa", session);

Application B
Contexta = Context.getcontext ("/appa");
HttpSession Sessiona = (HttpSession) contexta.getattribute ("Appa");

It is noteworthy that this usage is not portable, because depending on servletcontext Javadoc, the application server can be in a safe cause for context.getcontext ("/appa"); 8.1 In the passage.

So why would WebLogic server set all the cookie paths for all applications to/? Originally for SSO, all applications sharing this session can share authenticated information. A simple experiment can prove this by modifying the descriptor Weblogic.xml of the application that first logged in, modifying the cookie path to/appa access to another application will request login again, even if in turn, access the cookie path/application First, Access to this modified path, although no longer prompt for login, but logged in user information will also be lost. Note that the authentication method should use form when doing this experiment, because the browser and Web server have other way to the Basic authentication method, the second request authentication is not through the session to realize. Please refer to [7] secion 14.8 Authorization, you can modify the attached sample program to do these experiments.

Viii. Summary
The session mechanism itself is not complex, but its implementation and configuration flexibility makes the specific situation complex and changeable. This also requires that we do not use a single experience or a browser, server experience as a universally applicable experience, but always need specific circumstances specific analysis.
Absrtact: Although the session mechanism has been used in Web applications for a long time, there are still a lot of 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.