Rashmi, Thanks for your initial response. I guess I wasn't clear on a few things. The behavior I'm seeing is the same in both Tomcat 5.0 and 5.5, and they are both configured the same -- using default behavior for cookies.
I should elaborate further and mention that the urlEncode method causes url rewriting to occur. So a cookie does not appear in my client browser (verified with a cookie viewer for IE). Despite this apparent lack of client side cookie, when doGet is invoked in step 3) Tomcat exposes a cookie object with the session id of Session1 off of the HttpServletRequest object and has stripped off the Session 2 session id on the encoded URL from step 2). David On 4/28/07, Rashmi Rubdi <[EMAIL PROTECTED]> wrote:
On 4/28/07, David <[EMAIL PROTECTED]> wrote: > I'm hoping someone can shed light on some session anomalies I'm seeing with > Tomcat 5.0.2.8 and Tomcat 5.5.23. > > I have a web application containing FacesServlet ( > javax.faces.webapp.FacesServlet) as well as some additional servlets that > also make use of the Faces Context. > > The normal flow is: > > > > 1) call into the FacesServlet for some work, > > 2) invoke another servlet, ServletA, via doPost. Within doPost images > are generated dynamically and the bytes are stored within a session. > > 3) The response returns 1 or more URLs each of which will call back > ServletA via doGet to have the image data retrieved from the session and > streamed back to the client. These URLs are created using the encodeURL > method on the response to attach the session id. > > > > In one case step 1) does not require any session information to be created. > So when step 2) occurs a new session is created, and in step 3) within doGet > this session is correctly retrieved and things work beautifully. > > > > However in another use case step 1) requires some information to be stored > in the session, so Session 1 is created. When step 2) occurs, another > session, Session 2 is created. The fact that Session 1 is not reused is the > first surprise. When encodeURL is used in step 2), Session2's id is encoded > into the response URLs. However in step 3), when the servlet's doGet is > called back, the session that is returned is Session 1 which of course does > not have the image bytes. Of note, in step 3) the HttpServletRequest object > reports that the session is coming from a cookie, not the URL. It could be possible that you configured Tomcat 5.0.2.8 and Tomcat 5.5.23 instances differently. If you set the cookies attribute for your web application's Context to true then the JSESIONID is stored in the browser as a cookie. If cookies is set to false then jsessionid appears in the rewritten URL. Reference: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html > > Any thoughts on what might be going on here? My first thought is that this > is a bug in Tomcat. Guidance on how to further debug this issue, or come up > with a work-around is greatly appreciated. > > David > -Regards Rashmi --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
