req.isRequestedSessionIdValid() and req.getSession()

J

Joshua

I have a servlet. Nothing in the doPost() apart from:

if (req.isRequestedSessionIdValid())
{
System.out.println("session ID is valid");
}
else
{
System.out.println("session ID is not valid");
}

So first time in from a JSP (in a fresh instance of a browser) calling
this servlet it is printing "session ID is valid" which I can't
understand. My understanding is that only if req.getSession() or
req.getSession(true) a new session is created.

Do I understand incorrectly?
 
S

Sudsy

Joshua wrote:
So first time in from a JSP (in a fresh instance of a browser) calling
this servlet it is printing "session ID is valid" which I can't
understand. My understanding is that only if req.getSession() or
req.getSession(true) a new session is created.

Do I understand incorrectly?

The answer, as is frequently the case, is: it depends. If you're
using an application framework such as Struts then the session
might have been established automagically. In point of fact, you
should not rely on the low-level sessions calls at all when
using Struts, HttpSession#invalidate in particular.
So, without knowing more details of your installation, the return
from HttpServletRequest#isSessionIdValid could well be correct.
 
J

John C. Bollinger

Sudsy said:
Joshua wrote:



The answer, as is frequently the case, is: it depends. If you're
using an application framework such as Struts then the session
might have been established automagically. In point of fact, you
should not rely on the low-level sessions calls at all when
using Struts, HttpSession#invalidate in particular.
So, without knowing more details of your installation, the return
from HttpServletRequest#isSessionIdValid could well be correct.

In fact, considering that you wrote that you are invoking the servlet
from a JSP, it is quite likely that the result is correct. JSPs assume
by default that requests they service should be part of a session, and
they create one if necessary to ensure it. This behavior can be
disabled by including this directive in your JSP (assuming vanilla JSP;
consult your documentation if you are using some framework on top):

<@page session="false">

I suppose it's possible that a compliant page implementation might delay
requesting a session until its "session" implicit variable was accessed,
but I don't see any reason why a container implementor would choose to
do it that way.

The details are discussed in the JSP spec, JSP.2.8.3 and JSP.2.10.1 (for
JSP 1.2).


John Bollinger
(e-mail address removed)
 
J

John C. Bollinger

John said:
In fact, considering that you wrote that you are invoking the servlet

The "you" in that sentence was intended to mean the OP -- sorry if there
was any confusion.


John Bollinger
(e-mail address removed)
 
J

Joshua

Sudsy said:
Joshua wrote:


The answer, as is frequently the case, is: it depends. If you're
using an application framework such as Struts then the session
might have been established automagically.

No framework being used. Just plain old vanilla Servlet and JSP.
 
J

Joshua

In fact, considering that you wrote that you are invoking the servlet
from a JSP, it is quite likely that the result is correct.

Aye a link to the servlet from a JSP e.g. <a
href="/servlet/path.bla.Servlet">link said:
JSPs assume
by default that requests they service should be part of a session, and
they create one if necessary to ensure it. This behavior can be
disabled by including this directive in your JSP (assuming vanilla JSP;
consult your documentation if you are using some framework on top):

<@page session="false">

So to make sure I understand, this directive will simply prevent JSP
creating a session, and it will not affect any session information
within a HTTP header on any future requests to that JSP after the
servlet has created a session?

No framework being used.
 
J

John C. Bollinger

Joshua said:
Aye a link to the servlet from a JSP e.g. <a
href="/servlet/path.bla.Servlet">link</a>

So you browse to the JSP and then click on the link? Yes, that would
probably cause the servlet to see a pre-existing session.
So to make sure I understand, this directive will simply prevent JSP
creating a session, and it will not affect any session information
within a HTTP header on any future requests to that JSP after the
servlet has created a session?

It instructs the JSP that it is not participating in a session. The
session implicit object and session-scoped beans will not be available
within that JSP, and sessions threaded together by means of URL
rewriting will likely be broken by traversal of the page. Sessions
threaded together by cookies or some other means should tolerate such a
JSP without a hiccup. The page implementation should not attempt to
create or access a session object.


John Bollinger
(e-mail address removed)
 
S

Sudsy

John said:
Joshua wrote:
... The page implementation should not attempt to
create or access a session object.

Aye, there's the rub! You can work around the limitations but I've
always found it easier to let the container do the grunt work. So
my recommendation would be to utilize the facilities already provided
and augment them with a "superstructure" for your login management.
I use a combination of cookies and the HttpSession. YMMV.
 
J

Joshua

Sudsy said:
Aye, there's the rub! You can work around the limitations but I've
always found it easier to let the container do the grunt work. So
my recommendation would be to utilize the facilities already provided
and augment them with a "superstructure" for your login management.
I use a combination of cookies and the HttpSession. YMMV.


Thanks for both your posts guys.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top