views:

58

answers:

1

Hi all,

I've always taken for granted the JSESSIONID cookie created for every fresh request for a given client when developing applications using the servlet specification. But after giving it a bit of thought, isn't is more logical for the servlet container to create a cookie header only after the session has been requested and created in code? For clients who have their cookies disabled, won't it end up creating a new HttpSession for each request made?

Please let me know if the question is still unclear so I can edit it. TIA.

+1  A: 

A new Session will not be created by the Servlet container by default unless the Servlet actually creates it explicitly. Just because in the Header a JSEESIONID is being populated does not mean that there has to be a seesion on the server. An exception to this is in JSPs that by default create a Session if one is not there unless <%@ page session="false" %>

As far as not having cookies turned on:

A web container can use several methods to associate a session with a user, all of which involve passing an identifier between the client and the server. The identifier can be maintained on the client as a cookie, or the web component can include the identifier in every URL that is returned to the client.

If your application uses session objects, you must ensure that session tracking is enabled by having the application rewrite URLs whenever the client turns off cookies. You do this by calling the response's encodeURL(URL) method on all URLs returned by a servlet. This method includes the session ID in the URL only if cookies are disabled; otherwise, it returns the URL unchanged.

Romain Hippeau
That begs the question, what exactly is the purpose of generating the JSESSIONID in advance if the container is anyways not going to create a new session?
sasuke
Oh well, I guess I'll just ask a new question for this query of mine. Thanks for the help.
sasuke