Hi Dies,
Dies Koper wrote On 08/16/06 21:27,:
Hello Jan,
Thank you for your reply.
Yes, I noticed the "associated with this session". It seemed clear. But
then I read the following in the specification:
[Servlet 2.4 spec - SRV.7.6 Last Accessed Times]
The session is considered to be accessed when a request that is part of
the session is first handled by the servlet container.
I noticed "request that is part of the session".
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.
I don't see how the mere presence of a JSESSIONID could
be considered and treated the same as accessing a session
(but I also see how SRV.7.6 might be interpreted that way).
Session access to me implies that a session is being acquired
via a call to HttpServletRequest.getSession().
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.
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.
Thanks,
Jan
Is a request with a jsessionid that gets accepted by the container part
of a session? I'd say yes. But you say it is not, until the servlet
calls a method that needs to access the session context (getSession,
encodeURL, etc.), only then you can say it actually was part of the session?
I suppose that does sounds reasonable.
I think this change was made to bring the impl in compliance with the
servlet spec.
The servlet 2.3 spec contains the same. So Tomcat 4.1 does not but
Tomcat 5.0/5.5 now does comply with the spec regarding this method?
#I had opened a bug about this last month, I'd like to add this info to
it for reference before it is closed.
Just to make sure, you /think/ this change was done because you have
some recollection of it or guessing from what I wrote and what the spec
writes?
I tried searching the mailing lists about it but could not find any
discussion about it.
Thank again for the reply,
Dies
Jan Luehe wrote:
Hi Dies,
Dies Koper wrote On 08/16/06 05:28,:
Hello,
I'm looking into an issue we ran into when upgrading from Tomcat 4.1 to
Tomcat 5.5.
The time returned by the HttpSession.getLastAccessTime method seems to
have changed.
We believe it should return the time of the previous request from the
same client. It did in Tomcat 4.1. It did so no matter whether that
client accessed a Servlet or an html file.
However, in Tomcat 5.5 it only returns this time if the previous request
went to a servlet, and that servlet called the getSession or
request.encodeURL method. Otherwise it returns the time of the last
request from that client that did call either of those methods.
I think this change was made to bring the impl in compliance with the
servlet
spec.
The javadocs of HttpSession.getLastAccessedTime() have this:
* Returns the last time the client sent a request associated with
* this session, as the number of milliseconds since midnight
* January 1, 1970 GMT, and marked by the time the container received the
* request.
Notice the "associated with this session".
Only if a request creates or resumes a session should the session's
lastAccessedTime
be updated.
Jan
I am a bit confused why. Did the Tomcat developers disagree with the
Servlet spec or the interpretation of it at the time Tomcat 4.1 was
released and is this now fixed? Or is it an accidental side-effect of
another change?
The reason I ask is because I need to solve this problem. Should I look
for a work-around or try to write a patch?
So far, I found that the change happened in Tomcat 5.0, with the
following commit.
Revision: 302627
Author: remm
Date: 3:21:36, 2004-01-23
Message:
- Improvements to session activity tracking, handling the case where the
session is new, as well as cross context.
- If this doesn't work, I give up ;)
----
Modified :
/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Modified :
/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
Modified :
/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
Modified :
/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/session/StandardSession.java
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
