HTTP Cookies and Session/User Management
When the Web first came into use, it was governed by earlier versions of the HTTP protocol that provided no way to track user sessions between requests. Then Netscape published a “preliminary specification” defining how to track a “Persistent Client State” using what it called “a cookie, for no compelling reason.”
The Internet being what it is, this preliminary specification was immediately adopted as a standard and it is still in wide use today. (A version of the original proposal was still viewable at the time of this writing at http://wp.netscape.com/newsref/std/cookie_spec.html.) When the IETF later published its cookie specification (RFC 2109) (http://www.ietf.org/rfc/rfc2109.txt), there were very few changes to Netscape’s original proposal.
JSP/servlet containers, such as Tomcat, use cookies to track user sessions. The user session is associated with the HTTP request (as opposed to the response); this is because the servlet container uses the cookie provided by the request to track the session.
Because Struts is a framework built on JSP, it uses JSP/servlet session management to track session-scoped information, such as a user’s shopping cart.
As an example, consider the simple JSP program in Listing 4.8.
Listing 4.8. A Simple JSP Program Demonstrating User Session Management Driven by the HTTP Request and Cookies (session.jsp)
<html>
<head>
<title>Testing Session Management</title>
</head>
<body>
<% out.print("Session ID = " + request.getSession().getId() ); %>
</body>
</html>
|
Notice that the session is associated with the request object as opposed to the response object.
In Listing 4.9, requesting the session.jsp file shows how cookies are used to manage session information. (For illustration, this JSP file has been put into the JSP Web application named chapter04. The reason for this will be apparent in a moment.)
Listing 4.9. A Sample HTTP Communication Demonstrating Session Management
bash-2.05$ ./telnet -E localhost 8080 Trying 127.0.0.1... Connected to localhost. Escape character is 'off'. GET /chapter04/session.jsp HTTP/1.0 HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Date: Wed, 12 Jun 2002 00:39:49 GMT Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) Connection: close Set-Cookie: JSESSIONID=AC75B22FD1D283D1CEF0136928110679;Path=/chapter04 <html> <head> <title>Testing Session Management</title> </head> <body> Session ID = AC75B22FD1D283D1CEF0136928110679 </body> </html> Connection closed by foreign host. bash-2.05$ |
Notice that the scope of the JSESSIONID cookie in this example is limited to the /chapter04 Web application. (You can tell because the Set-Cookie HTTP response header specifies PATH=/chapter04, which means that the cookie will be sent back to the Web server only if more requests are made for files in the /chapter04 Webapp.)
So, even if you have many Web applications (or Struts applications) deployed in a servlet container, session tracking is isolated between them. That is, even if a user has a valid session in one Struts application, his session is not valid in any other Struts applications deployed in the same server.
In Listing 4.10, you can see how submitting the request with a session ID allows the servlet container to match this request to an existing session. (Notice the session ID submitted is the same one that was received previously.) To demonstrate this, all that’s needed is to request the same file again—this time sending the JSESSIONID cookie back with it.
Listing 4.10. Associating a Request to an Existing User Session
bash-2.05$ ./telnet -E localhost 8080 Trying 127.0.0.1... Connected to localhost. Escape character is 'off'. GET /chapter04/session.jsp HTTP/1.0 pragma: no-cache Cookie: JSESSIONID=AC75B22FD1D283D1CEF0136928110679 HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Date: Wed, 12 Jun 2002 01:43:21 GMT Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) Connection: close <html> <head> <title>Testing Session Management</title> </head> <body> Session ID = AC75B22FD1D283D1CEF0136928110679 </body> </html> Connection closed by foreign host. bash-2.05$ |
Notice that this time the session ID was submitted to the server using the Cookie HTTP request header. By submitting the session ID with the request, this request was able to be associated with its existing session. The server also didn’t send another Set-Cookie HTTP response header in its response; it didn’t need to because the Cookie HTTP request header submitted with the request indicates that there is already a session associated with the incoming request. (The Pragma: no-cache header tells the Web server that it should send the file even if the results from it haven’t changed since last time it was requested.)