Hello Jan,
Thank you again for your reply.
Jan Luehe wrote:
I see what you are getting at, and I agree that the servlet spec
could be much clearer about this. Unfortunately, this ambiguous
wording as been around for the longest time.
That is why I was surprised to find the change in Tomcat 5, and no
mention in the commit log, Bugzilla or this mailing list that it was
misinterpreted and therefore fixed.
If the mere presence of a JSESSIONID in the request were
considered session access, how would you treat the case
where a request did not carry any JSESSIONID, and a servlet
created a new session by a call to HttpServletRequest.getSession()?
According to your interpretation of SRV.7.6, the session
would not be considered accessed until a subsequent request
that carried its JSESSIONID was received by the container.
Yes, that would also be my interpretation of what the API says:
Returns:
a long representing the last time the client sent a request
associated with this session
I would expect it having said something like the following in your
interpretation:
Returns the last time this session object was accessed, as the number of
milliseconds since midnight January 1, 1970 GMT, and marked by the time
the container received the request.
or
Returns:
a long representing the last time the session object was accessed
I don't believe this was the original spec authors' intention.
I will double-check with the Servlet EG to make sure we're all
in agreement on this.
I suppose they changed their minds a few times on what this method
should do and that led to the ambiguity. Thank you for double-checking,
I'm looking forward to hearing their reply.
Regards,
Dies Koper
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
