1. Servlet Sessions and Cookies
SE-2840 Dr. Mark L. Hornick

2. By default, Servlets have no memory of who makes a request
The HTTP protocol is stateless, meaning it does not keep track of ongoing request/response messages.
Each HTTP request/response is independent of any other request/response ?
SE-2840 Dr. Mark L. Hornick

3. Stateless Pro/Con
Good for browsing and hyperlinking pages in any order without regard to past history
No HTTP overhead in maintaining state
Bad for applications that require complex user interaction between web pages
The web application may want/need to know
what page you’ve visited previous to the current page
What you’ve done on previous visits
SE Dr. Mark L. Hornick

4. A web server can ask a browser to set/read/send Cookies as part of the HTTP header
HTTP request: “give me a page”
Web Browser
Web Server
HTTP response: “OK, and BTW, store this Cookie”
SE Dr. Mark L. Hornick

5. A Cookie is a small amount of information that can be used to implement state
As a web site developer, you can store information you gather from a user on the file system of the user’s PC as a Cookie
Previous date of web site access
Login status
. . .
Cookie information
Web Browser
SE Dr. Mark L. Hornick

6. A Cookie has various properties
name – the cookie name
value – the value of the cookie
expires – the date the cookie expires
path – path in domain in which cookie is visible
domain – domain the cookie is visible to
secure – cookie is only available over secure connections
httponly – cookie is only available via HTTP
SE Dr. Mark L. Hornick

7. On subsequent visits, the web server can retrieve the Cookies via the HTTP header
HTTP request: “give me that page again; BTW, here’s the cookie you asked me to store last time”
Web Browser
Web Server
HTTP response: “OK, I’ll use that
Cookie I gave you last time so I can
customize the response”
SE Dr. Mark L. Hornick

8. Session Protocol User's browser is given a session ID by the server
Tomcat does this automatically
Cookie expiration is usually fairly short; some are very long
ID is included in subsequent HTTP exchanges with the server
“subsequent” can be even weeks later (usually not)
Server uses received session ID to locate/ retrieve corresponding session data/variables
Session variables kept on server for efficiency and security
Persist somewhere on the server filesystem or server db
SE Dr. Mark L. Hornick

9. Application Session lifetime can be adjusted
<?xml version="1.0" encoding="UTF-8"?> ... <servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>test.HelloWorldServlet</servlet-class> </servlet> ... Some other servlet’s defn goes here <!– Session life in minutes; 0 means end w/ browser session --> <session-config> <session-timeout>30</session-timeout> </session-config> </web-app>
SE-2840 Dr. Mark L. Hornick

10. Tomcat handles session management for Servlets
A reference to an HTTPServletRequest is created by the Container and passed to the doGet() and doPost() methods of an HTTPServlet. Session references are retrieved from the Request object.
Note: You can look at Cookie objects via request.getCookies(), and set your own Cookie objects via response.addCookie()
SE-2840 Dr. Mark L. Hornick

11. We usually initialize a ServletConfig attribute before any Servlets are initialized
Solution: Use a class that implements the ServletContextListener interface
This is one of 8 different Listeners
The event class
SE-2840 Dr. Mark L. Hornick

12. The contextInitialized() event handler is called by Tomcat at startup
In the contextInitialized() method, we can create a ServletContext attribute that is a complex datatype:
public void contextInitialized(ServletContextEvent e) {
ServletContext context = e.getServletContext();
context.setAttribute(“foo”, new MyComplexType() ); }
// later, any Servlet will be able to access MyComplexType via a call to getServletContext().getAttribute(“foo”);
SE-2840 Dr. Mark L. Hornick

13. We need to register ServletContextListeners
In Tomcat 7, just use annotation!
In Tomcat 6, you must edit the DD (web.xml):
<?xml version="1.0" encoding="UTF-8"?>
...
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>test.HelloWorldServlet</servlet-class>
</servlet>
... Some other servlet’s defn goes here
<!– Here’s how a ServletContextListener is registered -->
<listener>
<listener-class>myPackage.MyContextListener</listener-class>
</listener
</web-app>
SE-2840 Dr. Mark L. Hornick

14. This is what we really want
User 1 hits Submit on a form page.
service(request, response)
Data store
service(request, response)
Thread 19
User 1
User1 session
Thread 20
Data store
User2 session
Each user gets a separate session object which can be used to manage separate data stores.
User 2 hits Submit on the same form page at about the same time.
User 2
SE-2840 Dr. Mark L. Hornick