tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Luehe <Jan.Lu...@Sun.COM>
Subject Re: change in session activity tracking between Tomcat 4.1/5.0 and Tomcat 5.5
Date Fri, 18 Aug 2006 03:54:24 GMT
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: dev-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message