DO NOT REPLY [Bug 8100] - Session Tracking and HttpURLConnection

[bu...@apache.org]

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=8100>.
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=8100

Session Tracking and HttpURLConnection





------- Additional Comments From adb@cisco.com  2003-05-08 21:12 -------
I'm seeing a similar problem with Tomcat 4.0.12.  I have a simple JSP page 
which contains the following code:

<jsp:useBean 
    id="evpSessionBean" 
    class="evp.jsp.EvpSessionBean"
    scope="session"/>
<jsp:setProperty name="evpSessionBean" property="*"/>
User ID is: <jsp:getProperty name="evpSessionBean" property="id"/>.
User PIN is: <jsp:getProperty name="evpSessionBean" property="pin"/>.

This page has a "id" and "pin" parameter passed to it in the GET request, and 
the results are as you'd expect.  On a subsequently accessed page, located in 
the same context, I have a segment of code identical to the above, but of 
course without the "setProperty" line.  This works just fine too, and produces 
the "id" and "pin" values which had been provided in the previously accessed 
page's GET request.

The problem is not manifest until a *third* page is accessed.  That is, if I as 
user then access a third page containing the same block of code above (again, 
sans setProperty), I will get *nothing* for the property values.  The original 
evpSessionBean gets lost and a new one is created.

In an attempt to work around this, I replaced this code with scriptlets that 
explicitly add and retrieve these values to and from the HttpSession as 
attributes.  The same problem occurrs:

1) First page accessed creates a new session, attaches the ID and PIN to it, 
and it's happy.

2) Second page accessed get's a handle to the session, reads the ID and PIN, 
it's happy too.

3) Third page accessed has no idea what's going on. The browser dutifully 
passes it the JSESSIONID of the HttpSession used by the first two pages (I've 
confirmed this), but the server decided to create a new session anyway.  If I 
call HttpServletRequest.getSession(false) it returns null.

Hope this is enough detail for you, if not let me know (adb@cisc.com).

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