Client does not join HttpSession - then what?

[Steve Claflin]

Almost any book on servlets has the obligatory note about
HttpSession.isNew() and the client choosing not to join the session.
But I haven't seen one that presents a strategy for dealing with it.
And it seems that any well written code would need to take that
possibility into account.

That implies that the first page the user gets to can't do any real work
other than to try and initiate the session, so that the second, real,
page can find out if the session was joined. And I wouldn't want my
main page to try to set cookies, so the navigation should go main page
--> session initiating page --> real page.

It also implies that I would need a fallback strategy if the session
can't be maintained, like a form with a hidden field (but then I have to
use a submit button instead of an ordinary link) or rewrite links (in
which case I have to do GET instead of POST and end up with extra
garbage in the URL) *. Of course, if I'm going to go to all the work of
coding that fallback strategy, why not use it all the time and dispense
with the session?

* Or use javascript in the page, in which case I need a fallback
strategy for that being disabled.

Is there a "standard" strategy for dealing with this?

 

[Chris Smith]

Almost any book on servlets has the obligatory note about
HttpSession.isNew() and the client choosing not to join the session.
But I haven't seen one that presents a strategy for dealing with it.
And it seems that any well written code would need to take that
possibility into account.

I wouldn't go that far. It depends on your environment. A lot of
applications can expect the user to have cookies enabled in their
browser and simply refuse to work if they don't.

It also implies that I would need a fallback strategy if the session
can't be maintained, like a form with a hidden field (but then I have to
use a submit button instead of an ordinary link) or rewrite links (in
which case I have to do GET instead of POST and end up with extra
garbage in the URL) *. Of course, if I'm going to go to all the work of
coding that fallback strategy, why not use it all the time and dispense
with the session?

You can still use the session API, but in conjunction with URL
rewriting. I'd go that route.

Is there a "standard" strategy for dealing with this?

That would be URL rewriting.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Steve Claflin]

I wouldn't go that far. It depends on your environment. A lot of
applications can expect the user to have cookies enabled in their
browser and simply refuse to work if they don't.


You can still use the session API, but in conjunction with URL
rewriting. I'd go that route.


That would be URL rewriting.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Thanks for the note. Your implication that it ought to "just be there"
made me take another look through all the methods in the API docs, where
I found encodeURL(String url), which does indeed do the trick. But,
it's a shame that the docs don't mention at least the possibility that
the method might require a relative URL on the same site, rather than a
hardcoded http://fullpath string for the URL even if it is the same
servlet.