session management (Mock Exam Question)

[aanal jethalia]

I found this on Jiris

The four methods for session management in the context of web-based application are: Cookie, HttpSession object, URL rewriting and Hidden value.

Is the above statement true? Should it not be SSL instead of HttpSession object?

[Deepak Bala]

Why not HttpSession objects ? Surely you use request.getSession() to create new sessions or return the reference to existing sessions.
[ November 25, 2006: Message edited by: John Meyers ]

[Paul Anilprem]

I think what Aanal is saying is correct in the context of this question. It should be HTTPS (HTTP over SSL) instead of HttpSession. The reason is that HttpSession is just a wrapper over the underlying mechanism that is actually used to implement session behavior. Thus, HttpSession will work same irrespective the underlying mechanism - cookies, URL rewriting, hidden form fields, or HTTPS.

Unless, the question is considering the usage of raw mechanisms to implement its own session management in the web application. In this case, a developer might want to handle cookies/hidden form fields himself instead of working with HttpSession object. But I doubt it.

[Ulf Dittmer]

Although SSL/HTTPS does create a session, it is one on a lower level than HttpSession provides - you can't derive an HttpSession from an HTTPS connection, because the session details are invisible to the servlet. So, if the point of the question is to work within the framework of servlets/JSPs, then HTTPS is not a way to create a session.

[Paul Anilprem]

Originally posted by Ulf Dittmer:
Although SSL/HTTPS does create a session, it is one on a lower level than HttpSession provides - you can't derive an HttpSession from an HTTPS connection, because the session details are invisible to the servlet. So, if the point of the question is to work within the framework of servlets/JSPs, then HTTPS is not a way to create a session.

With due respect, I do not think that is entirely correct. SSL provides "SSL Session", and an ID to identify that SSL Session, which in turn can be used by the servlet container to locate and associate an HttpSession with the request. In this mode, there is not need for cookie, URL Rewriting, or any other mechanism for locating HttpSession.

Some webservers, such as IIS do not make the SSL Session ID available to servlet container plugins (or has it changed now?), in which case it is not possible to use this mechanism.

[Ulf Dittmer]

I stand corrected - the servlet spec 2.4 mentions this in #7.1.2.

But is any servlet container actually doing this? It would depend on the SSL ID being available to the servlet container, which is often not the case because the SSL session is terminated (e.g. by the web server or a hardware device) before the servlet container ever sees the request. I suppose the ID could be passed along as an additional HTTP header in order to make this possible.
[ November 27, 2006: Message edited by: Ulf Dittmer ]