DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5368>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5368

StandardContextValve changes session state from new to old too late for other Valves

           Summary: StandardContextValve changes session state from new to
                    old too late for other Valves
           Product: Tomcat 4
           Version: Nightly Build
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


In the situation where both client and server are passing session tracking
tokens around (via jsessionid in the URL or JSESSIONID cookie), Valves attached
to the Catalina pipeline should have access to a non-new session on the second
request to the servlet container.

As of CVS HEAD today, session state does not change from new to old until the
StandardContextValve (SCV) is called at the end of the pipeline (immediately
before it
invokes the Servlet wrapper).  If Valves attached to the pipeline before SCV are
called, to them the session will appear to be new.  According to version 2.3 of
the servlet spec, a session is new if:

* The client does not yet know about the session.
* The client chooses not to join a session. This implies that the servlet
container has no mechanism by which to associate a request with a previous request.

Neither of the above are true during the second request to Catalina in the
scenario I'm describing, and the current implementation of SCV does the Right
Thing as per the spec.  However, SCV takes action too late.  The block which
calls StandardSession.access() in SCV should be moved to the beginning of the
pipeline, giving Valves attached in the middle access to a session whose state
has been set appropriately.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to