Hi!
I was reviewing the spec and the code with regards to the following issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51812
Ch.7.6 of the Servlet specification (both 2.5 and 3.0 versions) says:
"The session is considered to be accessed when a request that is part
of the session is first
handled by the servlet container."
My understanding of the phrase is that
a) Regardless of whether request.getSession(..) was called or not, if
the request is part of a session the session access time must be
updated.
(Thus the use case reported in Bug 51812 cannot be implemented, unless
you move your servlet into an independent webapp): regardless of how
you try to avoid accessing the session in a servlet, the last accessed
time should be "ticket" by any request that appears to belong to this
session.
b) The access time should be when request processing started, i.e.
org.apache.coyote.Request#getStartTime()
My findings in the current trunk:
1. Access time ticking is effectively done by Request.doGetSession(...).
On first call if "(requestedSessionId != null)" it finds existing
session and calls session.access().
There are several other places where access time is updated, but I
think this is the main use case.
As code fragment in issue 51812 shows, this method is always called
when an Authenticator is
configured in the webapp and does not have its cache disabled.
(AccessLogValve can also access the session and thus tick its last
access time -- from AccessLogValve$SessionIdElement or
AccessLogValve$SessionAttributeElement, if it is configured to use
those elements in its pattern).
The first question that I have is that I do not see how last access is
ticked if there is no explicit request for a session. I think it
should be ticked regardless of whether getSession(..) has been called.
2. Access time in StandardSession is updated using System.currentTimeMillis();
The second question that I have is that it contradicts my "b)" point
from above. I think it is against the spec.
The third question is that there are a lot of places that call
access(), and every such call updates thisAccessedTime in
StandardSession.
It looks like not all such calls are associated with an actual
request, and strictly speaking they should not update the time.
The second question can be demonstrated. Steps to reproduce:
1. Add the following line to catalina.properties:
org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
2. Add the following JSP page to the ROOT webapp and start Tomcat:
sessionTest.jsp:
[[[
<%@page session="false" import="java.util.*"
contentType="text/plain;charset=UTF-8"%>
<%
out.println("Time 1: " + new Date());
Thread.sleep(2000);
out.println("Time 2: " + new Date());
HttpSession session = request.getSession(true);
Thread.sleep(2000);
out.println("Time 3: " + new Date());
out.println("Last accessed: " + new Date(session.getLastAccessedTime()));
%>]]]
Open a new web browser and access the page three times.
First access:
Time 1: Wed Sep 21 21:36:25 MSD 2011
Time 2: Wed Sep 21 21:36:27 MSD 2011
Time 3: Wed Sep 21 21:36:29 MSD 2011
Last accessed: Wed Sep 21 21:36:27 MSD 2011 <- expected 21:36:25
Second access:
Time 1: Wed Sep 21 21:36:32 MSD 2011
Time 2: Wed Sep 21 21:36:34 MSD 2011
Time 3: Wed Sep 21 21:36:36 MSD 2011
Last accessed: Wed Sep 21 21:36:27 MSD 2011
Third access:
Time 1: Wed Sep 21 21:36:42 MSD 2011
Time 2: Wed Sep 21 21:36:44 MSD 2011
Time 3: Wed Sep 21 21:36:46 MSD 2011
Last accessed: Wed Sep 21 21:36:34 MSD 2011 <- expected 21:36:32
If I add the same jsp page into examples webapp, the behaviour becomes
different:
On first access: The same problem, System.currentTimeMillis() is used
for a new session
On third access: No problem: I see Time 1 from previous request, as expected.
I think that is because examples webapp has protected pages and thus
uses Authenticator. So if some webapp is used to test the difference
in lastAccessedTime, it wouldn't see any problems if it uses
Authenticator.
Regarding the bug 51812, I think that it makes sense, but because of
"a)" it cannot be implemented if Tomcat were strictly following the
spec.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
