www.cnblogs.com/lonelydream…
Session mechanism in detail
Ref:justsee.iteye.com/blog/157065… www.cnblogs.com/huhx/p/webS… Tomcat session processing:
Tomcat Session management (I) – Session generation
zddava.iteye.com/blog/311053
Tomcat Session management (2) – Session background processing
zddava.iteye.com/blog/311136
tomcat StandardSession
Nod0620.iteye.com/blog/104018…
Although the session mechanism has been used in Web applications for a long time, there are still many people who do not understand the nature of the session mechanism and cannot use the technology properly. This article will discuss in detail how sessions work and answer common questions when applying the session mechanism in Java Web Applications.
** the term session**
In my experience, session is probably the second most overused term after transaction, and what’s even more interesting is that transaction and session have the same meanings in some contexts.
Session, often translated as session in Chinese, originally refers to a series of actions/messages that start and end. For example, when making a phone call, the process from picking up the phone to dialing up to hanging up the phone can be called a session. Sometimes we see statements like “During a browser session…” The period between the opening and closing of a browser window. “Is the most chaotic user (client) during a session” the phrase, a series of action it may refer to the user (usually is a series of actions related to a specific purpose, such as from log on to the choose and buy goods to log out of such a process of online shopping, we settle is sometimes called a transaction). However, it can also refer to a single connection, or it can refer to meaning ①, where the difference can only be inferred from context ②.
However, when the session is a word that is associated with network protocols, it is often implied the connection-oriented and/or “maintain status” this two meanings, “a connection-oriented” refers to the communication before the two sides in the communication to establish a communication channel, such as a phone call, until someone answered the phone communication can start, in contrast to write, You don’t know if the address is correct when you send the letter. A communication channel may not be established, but for the sender, communication has already begun. “Keep-state” refers to the ability of the communicator to relate a series of messages so that they can depend on each other, such as a waiter who can recognize a repeat customer and remember that the customer owes the store a dollar. Examples of this type are “one TCP session” or “one POP3 session” ③.
However, in the era of vigorous development of Web server, the semantic of session in the context of Web development has a new extension, which means a solution used to maintain state between the client and server. Session is sometimes used to refer to the storage structure of this solution, as in “keep XXX in session” ⑤. Since various languages used for Web development support this solution to some extent, session is also used in the context of a particular language to refer to the solution for that language, Such as often provide javax.mail. In the Java servlet. HTTP. HttpSession session 6 for short.
In view of this confusion, the use of the term session in this article also has different meanings depending on the context, so please pay attention to distinguish between them. In this article, use the Chinese “browser session” to express the meaning ①, use the “session mechanism” to express the meaning ④, use the “session” to express the meaning ⑤, use the specific “HttpSession” to express the meaning ⑥
** HTTP protocol and state maintain **
HTTP protocol itself is stateless, which is consistent with the original purpose of HTTP protocol. The client only needs to simply request the server to download some files. Neither the client nor the server need to record each other’s past behavior, each request is independent. It’s like the relationship between a customer and a vending machine or a regular (non-membership) big-box store.
Yet clever (or greedy?) People at Google quickly figured out that the Web would be more useful if they could provide some dynamic information generated on demand, much like adding on-demand to cable television. On the one hand, this demand forces HTML to gradually add forms, scripts, DOM and other client-side behaviors, on the other hand, CGI specifications appear on the server side to respond to the dynamic request of the client, as a transmission carrier HTTP protocol also added file upload, cookie and other features. Cookie is an effort to solve the stateless defect of HTTP protocol. The later session mechanism is another solution to maintain state between client and server.
Let’s use a few examples to illustrate the differences and connections between cookies and session mechanisms. I used to go to a coffee shop that offered one free cup of coffee if I drank five cups of coffee. However, the chance of buying five cups of coffee at one time was very small. At this time, some way was needed to record the amount of a customer’s consumption. Imagine the following scenarios:
1. The staff in this store are very good at remembering how much each customer has spent and knowing what to do with them as soon as they walk into the coffee shop. This practice is the protocol itself support state.
2. A card is issued to the customer to record the amount spent, usually with an expiry date. Each time a customer shows the card, the purchase will be linked to a previous or future purchase. The practice is to maintain state on the client side.
3. A membership card is issued to the customer, which does not record any information except the card number. If the customer shows the card every time, the shop assistant will find the corresponding record of the card number in the store record book and add some consumption information. This is done by maintaining state on the server side.
Since the HTTP protocol is stateless and for various reasons does not want to make it stateful, the latter two options are realistic. Specifically, the cookie mechanism adopts the scheme of maintaining state on the client side, while the session mechanism adopts the scheme of maintaining state on the server side. We can also see that the session mechanism may need to resort to cookies to preserve the identity, since the state preserving scheme on the server also needs to store an identity on the client, but there are other options.
** The basic principle of the cookie mechanism is as simple as the example above, but there are still several problems to solve: how to distribute “membership card”; Contents of “Membership Card”; And how customers use the “membership card”.
Orthodox cookie distribution is realized by extending the HTTP protocol. The server adds a special instruction line in the HTTP response header to prompt the browser to generate the corresponding cookie. However, pure client-side scripts such as JavaScript or VBScript can also generate cookies.
The use of cookies is automatically sent to the server in the background by the browser according to certain principles. The browser checks all stored cookies, and if a cookie’s stated scope is greater than or equal to the location of the requested resource, it sends the cookie to the server on the HTTP request header for the requested resource. This means that the McDonald’s membership card can only be presented in McDonald’s stores. If a branch has issued its own membership card, it will be required to show the McDonald’s membership card as well as the McDonald’s membership card when entering the store.
The content of cookies mainly includes: name, value, expiration time, path and domain.
You can specify a domain, such as.google.com, which is equivalent to the head office sign, such as Procter & Gamble, or you can specify a specific machine in a domain, such as www.google.com or froogle.google.com, which can be compared with Rejoice.
A path is a URL path that follows a domain name, such as/or /foo, etc., as compared to a Rejoice counter. Together, the path and the domain form the scope of the cookie. If the expiration time is not set, it means that the cookie has a lifetime of the browser session and disappears as soon as the browser window is closed. Cookies with a lifetime of a browser session are called session cookies. Session cookies are generally not stored on hard disk but in memory, although this behavior is not regulated by the specification. If an expiration time is set, the browser saves cookies to hard disk, closes the browser and opens it again. Cookies remain valid until the expiration time is exceeded.
Cookies stored on the hard disk can be shared between different browser processes, such as two IE Windows. Different browsers treat cookies stored in memory differently. For Internet Explorer, a window opened by pressing Ctrl-N on an open window (or from a file menu) can be shared with the original window, while a new IE process opened otherwise cannot share the memory cookie of an already open window. With Mozilla Firefox0.8, all processes and tabs can share the same cookie. Typically, Windows opened with javascript window.open share memory cookies with the original window. The browser’s approach to session cookies is often confusing to developers of Web applications using the session mechanism.
Here is an example of Google setting the cookie’s response header
HTTP/1.1 302 Found Location: 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 HTTP traffic captured using HTTPLook, an HTTP Sniffer:
The browser automatically sends out cookies when it accesses a Google resource again:
Using Firefox, it is easy to observe the value of existing cookies. Using HTTPLook with Firefox, it is easy to understand how cookies work.
IE can also be set to ask before accepting cookies:
This is a dialog asking you to accept cookies.
** understand session mechanism **
The session mechanism is a server-side mechanism that uses a hash table like structure (and possibly hash tables) to store information.
When a program needs to create a session for a client request, the server first checks whether the client request contains a session id. If the request contains a session ID, it indicates that a session has been created for the client before. The server retrieves the session based on the session ID and uses it (if it cannot be retrieved, it may create a new one). If the client request does not contain the session ID, it creates a session for the client and generates a session ID associated with the session. The value of the session ID should be a string that is neither duplicated nor easily found to be faked. The session ID will be returned to the client for storage in this response.
The session ID can be saved using a cookie, so that the browser can automatically play the id to the server according to the rules during the interaction. Usually the cookie’s name is something like SEEESIONID, and. Such as weblogic for web applications to generate cookies, JSESSIONID = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng! -145788764, its name is JSESSIONID.
Since cookies can be artificially disabled, there must be some other mechanism to pass the session ID back to the server even if cookies are disabled. URL rewriting is a technique that is often used to append the session ID directly to the URL path. There are two ways to append the session ID. One is as additional information of the URL path, in the form of 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 The two methods are the same for users, but the server processes the session ID differently. Using the first method helps distinguish the session ID information from normal program parameters. To maintain state throughout the interaction, the session ID must be included after every possible path requested by the client.
Another technique is called form-hiding fields. The server automatically modifies the form to add a hidden field so that it can pass the session ID back to the server when the form is submitted. For example, the following form:
Will be overwritten before being passed to the client:
This technique is less commonly used today, and the very old iPlanet6(the predecessor of the SunONE application server) that I worked with used this technique. In fact, this technique can be replaced by simply applying URL rewriting to the action.
When talking about the session mechanism, it is a common misconception that “just close the browser and the session is gone”. In fact, you can imagine the example of membership card, unless the customer takes the initiative to put forward the store to cancel the card, otherwise the store will not easily delete the customer’s information. The same is true for sessions. Unless an application notifies the server to delete a session, the server will retain the session until the user logs off. However, the browser never actively notifies the server that it is closing before closing, so the server never has a chance to know that the browser has closed. The reason for this illusion is that most session mechanisms use session cookies to store session ids. The session ID disappears when the browser is closed, 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 in some way to send the original session ID to the server, the original session can still be found when the browser is opened again.
Closing the browser does not cause the session to be deleted, forcing the server to set an expiration time for Seesion. When the expiration time has passed since the last session used by the client, the server can consider that the client has stopped activities and delete the session to save storage space.
* * 5, understanding javax.mail. Servlet. HTTP. HttpSession * *
HttpSession is the Java platform’s implementation of the Session mechanism, because it is only an interface, specific to each Web application server provider, in addition to the specification support, there are still some minor differences not specified in the specification. Here we use BEA’s Weblogic Server8.1 as an example to demonstrate.
First, Weblogic Server provides a set of parameters to control its HttpSession implementation, including the option to use cookies, the option to use URL rewriting, session persistence, session expiration time, And various Settings for cookies, such as setting the cookie name, path, domain, cookie survival time and so on.
When the server process is stopped or restarted, the session in memory will be cleared. If persistent session is enabled, the server will save the session to hard disk. When the server process is restarted or the information can be used again. The persistence modes supported by Weblogic Server include file, database, client-side cookie saving and replication.
Replication is not strictly persisted, since sessions are actually kept in memory, but the same information is copied to server processes in each cluster so that even if one server process stops working, sessions can still be fetched from other processes.
The setting of the cookie lifetime affects whether the cookie generated by the browser is a session cookie. Session cookies are used by default. Those interested can use it to test the misconception we mentioned in section 4.
The path of cookies is a very important option for Web applications, and the default treatment of this option by Weblogic Server makes it significantly different from other servers. We’ll talk about that later.
For session Settings, see [5] e-docs.bea.com/wls/docs70/…
HttpSession (in this section the meaning of session is a mixture of ⑤ and ⑥)
* * 1, when the session is created * * a common misconception is that the session with the client to access when it was created, but the fact is that until a server application to call it. The getSession (true) statement to be created, <%@page session=”false”%> The JSP file is writing translated into Servlet will automatically add a statement like this HttpSession session. = it getSession (true); This is where the session object implicit in JSP comes from.
Because sessions consume memory resources, you should turn them off in all JSPS if you do not intend to use them.
** From the previous discussion, a session can be deleted in the following cases: a. The program calls httpsession.invalidate (); Or b. The interval since the last session ID received from the client exceeds the session timeout setting. Or c. The server process is stopped (non-persistent session)
** how to delete session** when browser is closed
Strictly speaking, you can’t do that. One way to do a bit of research is to use the javascript code Window.oncolose on all client pages to monitor the browser shutdown and then send a request to the server to remove the session. But there’s nothing you can do about browser crashes or forcing processes to die.
** ** ** ** **
You can create a listener to monitor session creation and destruction events, so that you can do something when such events occur. Note that it is the session creation and destruction actions that trigger the Listener, not the other way around. Similar listener and HttpSessionBindingListener, associated with the HttpSession HttpSessionActivationListener and HttpSessionAttributeListener.
Do objects stored in session have to be serializable
Not required. Serializable objects are required only so that sessions can be replicated or persisted in the cluster or temporarily swapped out of memory by the server if necessary. Placing a non-serializable object in a Weblogic Server session will receive a warning on the console. One version of iPlanet THAT I used, if there were non-serializable objects in a session, would get an Exception on session destruction, which is weird.
** 6. How to properly deal with the possibility that the client will prohibit cookies **
Use URL rewriting for all urls, including hyperlinks, form actions, and redirected urls. See [6] e-docs.bea.com/wls/docs70/…
** 7, open two browser Windows to access the application using the same session or different sessions **
Refer to the discussion on cookies in section 3. For sessions, only ids are recognized, so different browsers, different window opening methods and different cookie storage methods will affect the answer to this question.
** 8. How to prevent session chaos caused by user opening two browser Windows **
This problem is similar to preventing forms from being submitted multiple times, and can be solved by setting the client’s token. When submitting a form, the client must return this ID to the server. The program first compares whether the returned ID is consistent with the value saved in the session. If the value is inconsistent, it indicates that the operation has been submitted. See the presentation layer pattern section of J2EE Core Patterns. Note that for Windows opened with javascript window.open, this ID is usually not set, or a separate ID is used. In case the main window cannot operate, it is recommended not to modify the window opened by window.open, so that the setting is not needed.
SetValue ** The value of a Weblogic Server session has been changed. The value of a Weblogic Server session has been changed. The new session value needs to be copied to other server processes.
** why is session missing **
Barring normal session failure, the likelihood of the server itself should be minimal, although I have encountered it on the Solaris version of iPlanet6SP1 with several patches; Browser plugins are the next most likely, and I have also encountered problems caused by the 3721 plugin. Theoretically, the firewall or proxy server may also have problems with cookie processing. Most of the reasons for this problem are program errors, the most common being accessing another application from within one application. We’ll discuss this in the next section.
It is often the case that a large project is split into several smaller projects, each of which is required to be developed as a separate Web application in order to avoid interference, and at the end of the day, you suddenly find that some information needs to be shared between the smaller projects. Or if you want to use a session to achieve single sign-on (SSO) and store login user information in a 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, and different applications cannot access each other’s sessions. Each application server complies with this specification in practice, but the details of the implementation can vary, and so the approach to cross-application session sharing can vary.
First, let’s take a look at how Tomcat implements session isolation between Web applications. From the cookie path set by Tomcat, it sets different cookie paths for different applications, so that different applications use different session ids. Therefore, even if different applications are accessed in the same browser window, the session ID sent to the server can be different.
Based on this feature, we can assume that the memory structure of the Session in Tomcat is roughly as follows.
I used iPlanet in the past in the same way, and I don’t expect much difference between SunONE and iPlanet. For this kind of server, the solution is very simple, the actual implementation is not difficult. Either let all applications share a session ID, or let applications get session ids from other applications.
An easy way to implement a shared session ID in iPlanet is to set the cookie path for each application to/(it should actually be /NASApp, which acts as root for applications).
/NASApp
Note that sessions that operate on shared attributes should follow some programming conventions, such as adding the application prefix to the session attribute name. Change setAttribute(“name”, “neo”) to setAttribute(“app1.name”, “neo”) to prevent namespace conflicts and overwrite each other.
In Tomcat, there is no such convenient option. With Tomcat version 3, there are also ways to share sessions. For Tomcat above version 4, I have not yet found an easy solution. Only with the help of a third party, such as using files, databases, JMS or client cookies, URL parameters or hidden fields.
Let’s look again at how Weblogic Server handles sessions.
It can be seen from the screenshot that the Weblogic Server sets the cookie path to/for all applications. Does this mean that the Weblogic Server can share the session by default? However, a small experiment shows that even though different applications use the same session, each application can only access the properties it has set. This indicates that the memory structure of the Session in Weblogic Server may be as follows:
With such a structure, it should be impossible to solve the problem of session sharing in the session mechanism itself. In addition to using third-party tools such as files, databases, JMS or client cookies, URL parameters or hidden fields, it is more convenient to put an application’s session into a ServletContext. This allows another application to retrieve 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 worth noting that this usage is not portable, because according to ServletContext’s JavaDoc, the application server can be safe for context.getContext(“/appA”); Returns a null value. This is done in Weblogic Server 8.1.
So why does Weblogic Server set the cookie path of all applications to /? Originally for SSO, any application that shares this session can share authentication information. A simple experiment demonstrates this by changing the weblogic.xml descriptor of the first application logged in to change the cookie path to /appA. Accessing another application will require logging in again, even if it is reversed by accessing the application whose cookie path is/and then accessing the one whose cookie path is changed. Although you are no longer prompted to log in, the logged in user information is also lost. Note that you should use the FORM authentication method when doing this experiment, because browsers and Web servers have other ways of handling basic authentication, and the second request is not authenticated by session. See [7] SecION 14.8 Authorization for details, and you can modify the attached sample program to do these tests.
The session mechanism itself is not complex, but the flexibility of its implementation and configuration makes it complicated and changeable. It also requires us not to take a single experience or a single browser or server experience as a universal experience, but to always look at it on a case-by-case basis.
Thanks to author: Lang Yunpeng.