What is HttpSession?

Web Servers have a short term memory. As soon as they send the response to the clients they forget who the clients were. In other words, web servers do not remember what the clients had requested in past. Sometimes that is fine but in many scenarios you need to maintain the conversational state between client and the server. One common example could be of a shopping cart. Mostly users select multiple things to buy before proceeding to checkout. In such scenarios the web server should be smart enough to remember what all products the user selected. Surprisingly, the Servlet API provides a very simple solution to handle such scenarios – The HttpSession API.

An HttpSession object can hold conversational state across multiple requests from the same client. In other words, it persists for an entire session with a specific client.
We can use it to store everything we get back from the client in all the requests the client makes during a session.

But be careful…..you should not be making your session object too heavy for performance reasons. There should be valid reasons for persisting data inside a Session object otherwise it can destroy the performance of the application. HttpSession is a powerful API, but with great powers comes greater responsibilities.

How do the client and container exchange session ID info?

There are two major techniques that the container follows behind the scenes to exchange this info, we say behind the scenes because a developer does not need to care about it. All the developer would care is whether there is a Session object associated with the request, if yes, what information does it have.

These techniques are Cookies and URL rewriting.

Cookies reside on the client’s machine. The Container does virtually all the cookie work. You do have to tell the container that you want to create or use a session, but the container takes care of generating the session ID, creating a new Cookie object, stuffing the Session ID into the cookie, and setting the cookie as part of the response. And on subsequent requests, the Container gets the Session ID from a cookie in the request, matches the session ID with the existing session, and associates that session with the current request.

Sending a session cookie in the RESPONSE:
HttpSession session = request.getSession();

You don’t make the Session object yourself.
You don’t generate the unique session ID.
You don’t make the new Cookie object.
You don’t associate the session ID with the cookie.
You don’t set the Cookie into the response.

But there could be a scenario that the client does not accept cookies….
Yes, cookies are components of your browser. One can also disable it hence the session management may not work in case cookies are disabled.

URL rewriting: comes to rescue….
If the client won’t take cookies you can use URL rewriting as the back up. Assuming the developer takes care of his or her part the URL rewriting will always work – the client won’t care that it’s happening and won’t do anything to prevent it.
URL rewriting takes the session ID that’s in the cookie and sticks it right onto the end of every URL that comes in to this app.

URL rewriting only kicks in ONLY if cookies fail, and only if you tell the response to encode the URL.
If cookies don’t work, the Container falls back to URL rewriting, but only if you’ve done the extra work of encoding all the URLs you send in the response. If you want the Container to always default to using cookies first, with URL rewriting as a last resort, you can relax. That’s exactly how it works. But if you don’t explicitly encode your URLs, and the client won’t accept cookies, you don’t get to use the sessions. If you do encode your URLs, the Container will first attempt to use cookies for session management, and fall back to URL rewriting only if the cookie approach fails.

URL rewriting is automatic but only if you encode all your URLs. You have to run all your URLs through a method of the response object – encode URL() – and the container does everything else.

response.encodeURL(“/search.do”);

encodeURL() method is something you call on your HttpServletResponse object. URL encoding is all about response.