You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ken Bowen <kb...@als.com> on 2010/01/04 21:52:37 UTC
jsessionid on EXACTLY the 2nd request?
I'm seeing what I think is odd behavior regarding jsessionid's.
[My setup(s): Tomcat 6.0.20 on a MacBook Pro using Java 1.6.0_17,
Tomcat 6.0.18 on CentOS 5 using Java 1.6.0_12 ]
I'm seeing the same behavior on both systems, and the same
behavior happens with Safari and FF. Both browsers have cookies
turned on.
I have cookies="true" in context.xml in the app's META_INF.
The Behavior:
I Clear Recent History in FF, which includes clearing cookies,
and request http://myapp.com/ I connect and the address bar shows:
http://myapp.com/
Moreover, a JESSIONID cookie shows in FF's list of cookies.
I make a request for another page in the app and the address bar shows:
http://myapp.com/anotherPage;jsessionid=9612C2CAA30DE590AA7A5FDB046DA4F9
And after that, no more jsessionid's are added no matter where in
the app I go, or how many requests I make.
My understanding was that Tomcat could be expected to add a jsessionid
to a
request it was returning on the FIRST request, but if the browser had
cookies on,
then AFTER the first request there would be no more jsessionid's.
Getting the jsessionid added on exactly the 2nd request confuses me.
Has anyone here run into something like this, or is my understanding
of what
Tomcat is supposed to do erroneous?
{Separately, I'm having a problem with a Tuckey outbound filter to
strip jsessionid's,
but that's a problem for the Tuckey list.}
Thanks in advance,
Ken
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jsessionid on EXACTLY the 2nd request?
Posted by Ken Bowen <kb...@als.com>.
Thanks Mark. That cleared it up for me:
Re: a) look at the html source of the responses and/or look at the
URLs for
>
> the links you are clicking on before you click on them.
That's the trick. The source for that (in a JSP) looks like:
<a href= <%=response.encodeURL ( "anotherPage.jsp" )%>
class="top_parent">Another Page</a>
And when I hover over that link, the Browser footer shows that the
request includes the attached jsessionid.
Cheers,
Ken
On Jan 4, 2010, at 5:15 PM, Mark Thomas wrote:
> On 04/01/2010 21:43, Ken Bowen wrote:
>> I'm not sure about that.
>
> Run through your test again, but this time:
> a) look at the html source of the responses and/or look at the URLs
> for
> the links you are clicking on before you click on them.
>
>> Here's what seems to me to be the sequence of
>> events:
>>
>> Browser sends initial request http://myapp.com
>> Tomcat creates session and generates page for this request.
>> Tomcat doesn't know that Browser supports cookies, so it
>> should
>> append jsessionid (but doesn't ??)
>
> Nope. The URL displayed in the address bar is the one you requested.
> You
> should also take a look at the links in the html source at this point.
>
>> Browser get's Tomcat response & display's page with address:
>> http://myapp.com
>
> Correct.
>
>> Browser creates JSESSIONID cookie (using info supplied by Tomcat in
>> response):
>> Cookie has contents: 4E4F86E5B779F43BCA7895B8A554FDCD
>> -----
>> Browser makes 2nd request, for http://myapp/anotherPage. Browser
>> must
>> definitely by now be stating that it supports cookies.
>
> Correct. But look at the URL for the link you click on at this point.
>
>> Tomcat prepares response, adding jsessionid (why?),
>
> Nope. Again, the URL in the address bar is the URL you requested. It
> is
> not part of the response.
>
>> the SAME
>> jsessionid as in the cookie: 4E4F86E5B779F43BCA7895B8A554FDCD
>> Browser displays response with jsessionid showing in address bar.
>
> Correct.
>
>> ----
>> More interactions, but no more jsessionid's.....
>
> Correct.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jsessionid on EXACTLY the 2nd request?
Posted by Mark Thomas <ma...@apache.org>.
On 04/01/2010 21:43, Ken Bowen wrote:
> I'm not sure about that.
Run through your test again, but this time:
a) look at the html source of the responses and/or look at the URLs for
the links you are clicking on before you click on them.
> Here's what seems to me to be the sequence of
> events:
>
> Browser sends initial request http://myapp.com
> Tomcat creates session and generates page for this request.
> Tomcat doesn't know that Browser supports cookies, so it should
> append jsessionid (but doesn't ??)
Nope. The URL displayed in the address bar is the one you requested. You
should also take a look at the links in the html source at this point.
> Browser get's Tomcat response & display's page with address:
> http://myapp.com
Correct.
> Browser creates JSESSIONID cookie (using info supplied by Tomcat in
> response):
> Cookie has contents: 4E4F86E5B779F43BCA7895B8A554FDCD
> -----
> Browser makes 2nd request, for http://myapp/anotherPage. Browser must
> definitely by now be stating that it supports cookies.
Correct. But look at the URL for the link you click on at this point.
> Tomcat prepares response, adding jsessionid (why?),
Nope. Again, the URL in the address bar is the URL you requested. It is
not part of the response.
> the SAME
> jsessionid as in the cookie: 4E4F86E5B779F43BCA7895B8A554FDCD
> Browser displays response with jsessionid showing in address bar.
Correct.
> ----
> More interactions, but no more jsessionid's.....
Correct.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jsessionid on EXACTLY the 2nd request?
Posted by Ken Bowen <kb...@als.com>.
I'm not sure about that. Here's what seems to me to be the sequence
of events:
Browser sends initial request http://myapp.com
Tomcat creates session and generates page for this request.
Tomcat doesn't know that Browser supports cookies, so it
should append jsessionid (but doesn't ??)
Browser get's Tomcat response & display's page with address: http://myapp.com
Browser creates JSESSIONID cookie (using info supplied by Tomcat in
response):
Cookie has contents: 4E4F86E5B779F43BCA7895B8A554FDCD
-----
Browser makes 2nd request, for http://myapp/anotherPage. Browser
must definitely by now be stating that it supports cookies.
Tomcat prepares response, adding jsessionid (why?), the SAME
jsessionid as in the cookie: 4E4F86E5B779F43BCA7895B8A554FDCD
Browser displays response with jsessionid showing in address bar.
----
More interactions, but no more jsessionid's.....
On Jan 4, 2010, at 4:11 PM, Mark Thomas wrote:
> On 04/01/2010 20:52, Ken Bowen wrote:
>> I'm seeing what I think is odd behavior regarding jsessionid's.
>> [My setup(s): Tomcat 6.0.20 on a MacBook Pro using Java 1.6.0_17,
>> Tomcat 6.0.18 on CentOS 5 using Java 1.6.0_12 ]
>> I'm seeing the same behavior on both systems, and the same
>> behavior happens with Safari and FF. Both browsers have cookies
>> turned on.
>>
>> I have cookies="true" in context.xml in the app's META_INF.
>>
>> The Behavior:
>> I Clear Recent History in FF, which includes clearing cookies,
>> and request http://myapp.com/ I connect and the address bar
>> shows:
>>
>> http://myapp.com/
>>
>> Moreover, a JESSIONID cookie shows in FF's list of cookies.
>>
>> I make a request for another page in the app and the address bar
>> shows:
>>
>>
>> http://myapp.com/anotherPage;jsessionid=9612C2CAA30DE590AA7A5FDB046DA4F9
>
> Just a guess - I haven't looked at the source code to be sure.
>
> At the point where the page was generated, Tomcat doesn't know that
> the
> client supports cookies since at that point the client hasn't sent a
> request with a JSESSIONID cookie so any urls generated will have the
> session ID appended.
>
> Once a cookie is received, Tomcat knows there is no need to include
> the
> session ID in the URL.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jsessionid on EXACTLY the 2nd request?
Posted by Mark Thomas <ma...@apache.org>.
On 04/01/2010 20:52, Ken Bowen wrote:
> I'm seeing what I think is odd behavior regarding jsessionid's.
> [My setup(s): Tomcat 6.0.20 on a MacBook Pro using Java 1.6.0_17,
> Tomcat 6.0.18 on CentOS 5 using Java 1.6.0_12 ]
> I'm seeing the same behavior on both systems, and the same
> behavior happens with Safari and FF. Both browsers have cookies turned on.
>
> I have cookies="true" in context.xml in the app's META_INF.
>
> The Behavior:
> I Clear Recent History in FF, which includes clearing cookies,
> and request http://myapp.com/ I connect and the address bar shows:
>
> http://myapp.com/
>
> Moreover, a JESSIONID cookie shows in FF's list of cookies.
>
> I make a request for another page in the app and the address bar shows:
>
>
> http://myapp.com/anotherPage;jsessionid=9612C2CAA30DE590AA7A5FDB046DA4F9
Just a guess - I haven't looked at the source code to be sure.
At the point where the page was generated, Tomcat doesn't know that the
client supports cookies since at that point the client hasn't sent a
request with a JSESSIONID cookie so any urls generated will have the
session ID appended.
Once a cookie is received, Tomcat knows there is no need to include the
session ID in the URL.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org