Cookies are the easiest way to maintain session state.
BUT, if you depend on cookies, you run the risk of the
client browser either not being capable of accepting
cookies or the browser user deliberately turning cookies
off.
When this happens, you probably end up creating new session
each time that user accesses a page in your application -
this could add up to a lot of useless object clutter in your
VM (as the new sessions cannot ever be used).
Does anyone have a comment on the advisability of the
following solution?...
Create a new session when a cookie-less request arrives.
Set a response header which the client will receive as
"Refresh: 0;URL=http://myserver/cookiechecker?session=xxx"
(ie specifying the session id with "home brew" url encoding)
or else accomplish the same with <META HTTP-EQUIV.....>.
When (if) the cookiechecker servlet receives a request
(which should be in 1 or 2 seconds), it tries to
getSession(false) - if null (ie no cookies) then extract
the sessionId from the "home brew" url encoding and
invalidate that session and generate a new response page
with a warning not to use this application without a browser
configured to accept cookies, but in the normal case (ie
session available via cookie) send back a 204 return code
(SC_NO_CONTENT).
This should be completely transparent to the user when cookies
are supported by their browser (except for a blip on the status
line in the browser window) but gives them a special warning
page when cookies are not supported.
My questions are:
1. how widely browser supported is "client pull"
(ie the refresh header)?
2. how widely supported are cookies anyway?
3. I assume that "home brew" encoding is needed on most
servlet encodings because the official encoding method
presumably has the side effect of telling the engine
not to use cookies - is this true?
4. any better alternatives (I don't think anything using
the "Host" header is reliably workable due to proxies and
possible ip address reuse)?
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
