Two implementation mechanisms of session

Some basic things are almost forgotten ...

1, based on the cookie implementation session

The principle of the session object is that the server can create and maintain a so-called session object for the client to store the data. While the session object is created, the server will produce a unique number for the sessions object, which is called SessionID, and the server stores the SessionID on the client in the form of cookies. When the browser accesses the server again, the SessionID is brought to the server as a cookie, and the server can retrieve and access the previous session object through the SessionID. It should be noted that at this time the cookie only saved a SessionID, while the relatively large number of session data stored in the server-side corresponding sessions, by the server for unified maintenance, so that a certain degree of security of the session data, but increased the server-side memory overhead.
Cookies stored on the client side for saving SessionID are purged when the browser is closed. We open a user to a browser to access an application to start, the interaction process is called a "session" until the browser is closed. During a "session" process, multiple requests may be made to the same application, which will share a sessions object because the requests carry the same SessionID information.
1. Session working principle
The following servlet is used to demonstrate how the session works:

public void doget (HttpServletRequest request, httpservletresponse response) throws Servletexception, IOException { 
    Response.setcontenttype ("text/html"); 
    PrintWriter out = Response.getwriter (); 
    String option = request.getparameter ("option"); 
        if ("Create". Equals (option)) {//Get HttpSession object HttpSession session = Request.getsession (); 
        Sets the maximum inactive interval of the Session object Session.setmaxinactiveinterval (30); 
        Gets the data list List = (list) session.getattribute ("list") in session; 
            if (list = = null) {list = new ArrayList (); 
            List.add ("Hey"); 
        Add data to the session Session.setattribute ("list", list); 
    else {list.add ("hey"); 
   } out.println (list); 
       }elseif ("Invalidate". Equals (option)) {HttpSession session = Request.getsession (false); 
   if (session!= NULL) {//Invalidates Session object Session.invalidate (); } 
}

The Url-pattern of the servlet is/testsession.
When the browser requests the address ".../tst/testsession?option=create", the servlet invokes the request's GetSession method to get the session object. If the server side has a session object that corresponds to the SessionID in the request information (as a cookie message), the session object is returned. Otherwise, a new session object will be created and the resulting sessionid will be sent back in the form of a cookie in response to the message. Note that the Setmaxinactiveinterval method of the Session object is used to set the maximum inactivity interval, in seconds, and if the session object is not accessed during this time period, the session object will be invalidated. Typically, this value is set appropriately for server performance and security reasons (Tomcat will have default settings for session Maxinactiveinterval). If the setmaxinactiveinterval is set to a negative value, the session never expires. In addition, the session object accesses data through SetAttribute and GetAttribute methods, and the data is stored in the form of "name-object" pairs. The HTTP information for the request and response for the request is:

Request: 
get/tst/testsession?option=create http/1.1 
accept:image/gif, Image/x-xbitmap, Image/jpeg, Image/pjpeg, Application/x-shockwave-flash, Application/x-silverlight, * * 
ACCEPT-LANGUAGE:ZH-CN 
ua-cpu:x86 
Accept-encoding:gzip, deflate 
user-agent:mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) 
host:192.168.5.100:8080 
connection:keep-alive 
cookie:jsessionid= C69B3053C575ECC8C7FCAF7D189A4FD1 

response 
http/1.1 OK 
server:apache-coyote/1.1 
content-type: Text/html;charset=iso-8859-1 
content-length:12 
Date:sun, June 2008 07:20:41 GMT

[Hey, hey!] 

Note: The SessionID value carried in the request information is consistent with the previous corresponding SessionID. In addition, there are two "hey" in the HTML text of the response output, because this time the request servlet placed a string object in the list object that is stored in the session.

When the browser requests ".../tst/testsession?option=invalidate", the servlet invokes the Invalidate method of the session object to invalidate the session object. Note that the method that gets the session object at this point is the overloaded getsession (Boolean B) where a Boolean parameter indicates that the current request is not associated with a session object on the server side when a new session is created (when the argument is true) or return null (when the argument is false).

2, based on URL rewrite

As you can see from the above introduction, the normal use of Session objects depends on cookies. If you consider that the client browser may have disabled cookies for security reasons, you should use URL rewriting to make the session continue to take effect if the cookie is disabled by the client.
There are two JSP pages below: A string object named "Hi" is stored in the session object in 1.jsp. Hyperlinks can be linked to 2.jsp, and in 2.jsp you will get an object named "HI" in the session and appear on the page. Note that the address of the hyperlink in 1.jsp is not directly written "2.jsp" but through the Resopnse Encodeurl method to deal with this address.
1.jsp

<%
session.setattribute ("Hi", "do your work or are you a student?");
%>

2.jsp

<%=session.getattribute ("Hi")%>

First disable the browser's cookie (note to restart IE), and then request 1.jsp, the response after the click Link to 2.jsp, the interactive process involves two requests and corresponding, HTTP information is as follows:

Request 1.jsp 
get/tst/session/1.jsp http/1.1 
accept:image/gif, Image/x-xbitmap, Image/jpeg, Image/pjpeg, Application/x-shockwave-flash, Application/x-silverlight, * * 
referer:http://192.168.5.100:8080/tst/session/ 1.jsp 
accept-language:zh-cn 
ua-cpu:x86 
accept-encoding:gzip, deflate 
user-agent:mozilla/4.0 ( compatible; MSIE 7.0; Windows NT 5.1) 
host:192.168.5.100:8080 
connection:keep-alive 
response: 
http/1.1 OK 
Server: apache-coyote/1.1 
content-type:text/html;charset=iso-8859-1 
content-length:33 
Date:sun, June 2008 07:31:36 GMT 
do your work or are you a student?

Note: Because of the disabling of cookies, the request protocol header does not carry SessionID information, but the SessionID information is uploaded to the server side as part of the request address, which is what URL rewriting means.
The response Encodeurl method determines whether to write SessionID information to the linked address based on whether the browser does not support cookies.