You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Arvind Srinivasan <Ar...@Sun.COM> on 2007/03/30 16:32:38 UTC
TC4.x vs TC5/6.x - JSESSIONID Set-Cookie differences
Hi,
In Tomcat 5.x and 6.x, the JSESSIONID Set-Cookie header is added to the
response during session creation (in Request.doGetSession), whereas in
Tomcat 4.x this used to be done during Response.sendHeaders(). Not that
it causes any problems, but TC 5.x/6.x responses can contain JSESSIONID
Set-Cookie headers even when there is no session or can contain multiple
JSESSIONID Set-Cookie headers (examples at the end of this mail)
Was there a problem in TC4.x when the JSESSIONID cookie was added when
the response headers were committed and hence this logic had to be moved
to Request.doGetSession in TC5.x/6.x?
Thanks,
Arvind
% cat webapps/ROOT/session1.jsp
<%
session.invalidate();
out.print("request.getSession(false)=");
if (request.getSession(false) == null)
out.println("null");
else
out.println(session);
%>
GET /session1.jsp HTTP/1.0
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=152B8151F108C614BB90FF20F4304340; Path=/
Content-Type: text/html
Content-Length: 35
Date: Fri, 30 Mar 2007 12:21:45 GMT
Connection: close
request.getSession(false)=null
---------------------------------------------------
% cat webapps/ROOT/session2.jsp
<%
session.invalidate();
session = request.getSession(true);
session.invalidate();
session = request.getSession(true);
out.print("request.getSession(false)=");
if (request.getSession(false) == null)
out.println("null");
else
out.println(session);
%>
GET /session2.jsp HTTP/1.0
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=A37F56FC791DE3D5A25B0D31109C6D47; Path=/
Set-Cookie: JSESSIONID=6766CBEEF3D3093773D75F59A95E2E54; Path=/
Set-Cookie: JSESSIONID=133C6FFF6E09ABD71E79DE84F68479BC; Path=/
Content-Type: text/html
Content-Length: 87
Date: Fri, 30 Mar 2007 12:23:01 GMT
Connection: close
request.getSession(false)=org.apache.catalina.session.StandardSessionFacade@3a5a9c
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TC4.x vs TC5/6.x - JSESSIONID Set-Cookie differences
Posted by Arvind Srinivasan <Ar...@Sun.COM>.
Remy Maucherat wrote:
> This is not that easy to do.
I realized this when trying to come up with a patch for moving the logic
to the response :)
Arvind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TC4.x vs TC5/6.x - JSESSIONID Set-Cookie differences
Posted by Remy Maucherat <re...@apache.org>.
Arvind Srinivasan wrote:
> Hi,
>
> In Tomcat 5.x and 6.x, the JSESSIONID Set-Cookie header is added to the
> response during session creation (in Request.doGetSession), whereas in
> Tomcat 4.x this used to be done during Response.sendHeaders(). Not that
> it causes any problems, but TC 5.x/6.x responses can contain JSESSIONID
> Set-Cookie headers even when there is no session or can contain multiple
> JSESSIONID Set-Cookie headers (examples at the end of this mail)
>
> Was there a problem in TC4.x when the JSESSIONID cookie was added when
> the response headers were committed and hence this logic had to be moved
> to Request.doGetSession in TC5.x/6.x?
This is not that easy to do. While it doesn't really support your
(funny) use case, the current impl is far simpler, so I would be in
favor of keeping it.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TC4.x vs TC5/6.x - JSESSIONID Set-Cookie differences
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> 2. throw an illegal state exception if a session.create is called after
> the response headers are committed.
Good idea.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TC4.x vs TC5/6.x - JSESSIONID Set-Cookie differences
Posted by Arvind Srinivasan <Ar...@Sun.COM>.
Filip Hanik - Dev Lists wrote:
> what would seem appropriate would be to do this:
>
> 1. Prevent multiple cookies, ie, swap out the old cookie. Only one
> session id should be sent down
There doesn't seem to be an easy way to get hold of the response object
from inside of session.expire().
> 2. throw an illegal state exception if a session.create is called after
> the response headers are committed.
i think the code in doGetSession() already does this.
Arvind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TC4.x vs TC5/6.x - JSESSIONID Set-Cookie differences
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
this is somewhat of an interesting use case, however, what if this happens:
..session usage..
..headers get committed..
..session invalidate..
..new session creation..
I don't see how the old solution would work around the problem either.
no matter where you put the cookie creation, once the response is
committed, and you try to create a new session, there is no way to set
that cookie.
Although I would agree that sending down 3 session cookies doesn't seem
right.
what would seem appropriate would be to do this:
1. Prevent multiple cookies, ie, swap out the old cookie. Only one
session id should be sent down
2. throw an illegal state exception if a session.create is called after
the response headers are committed.
Filip
Arvind Srinivasan wrote:
> Hi,
>
> In Tomcat 5.x and 6.x, the JSESSIONID Set-Cookie header is added to
> the response during session creation (in Request.doGetSession),
> whereas in Tomcat 4.x this used to be done during
> Response.sendHeaders(). Not that it causes any problems, but TC
> 5.x/6.x responses can contain JSESSIONID Set-Cookie headers even when
> there is no session or can contain multiple JSESSIONID Set-Cookie
> headers (examples at the end of this mail)
>
> Was there a problem in TC4.x when the JSESSIONID cookie was added when
> the response headers were committed and hence this logic had to be
> moved to Request.doGetSession in TC5.x/6.x?
>
> Thanks,
> Arvind
>
> % cat webapps/ROOT/session1.jsp
>
> <%
> session.invalidate();
>
> out.print("request.getSession(false)=");
> if (request.getSession(false) == null)
> out.println("null");
> else
> out.println(session);
> %>
>
> GET /session1.jsp HTTP/1.0
>
> HTTP/1.1 200 OK
> Server: Apache-Coyote/1.1
> Set-Cookie: JSESSIONID=152B8151F108C614BB90FF20F4304340; Path=/
> Content-Type: text/html
> Content-Length: 35
> Date: Fri, 30 Mar 2007 12:21:45 GMT
> Connection: close
>
>
> request.getSession(false)=null
> ---------------------------------------------------
> % cat webapps/ROOT/session2.jsp
>
> <%
> session.invalidate();
> session = request.getSession(true);
> session.invalidate();
> session = request.getSession(true);
>
> out.print("request.getSession(false)=");
> if (request.getSession(false) == null)
> out.println("null");
> else
> out.println(session);
> %>
>
> GET /session2.jsp HTTP/1.0
>
> HTTP/1.1 200 OK
> Server: Apache-Coyote/1.1
> Set-Cookie: JSESSIONID=A37F56FC791DE3D5A25B0D31109C6D47; Path=/
> Set-Cookie: JSESSIONID=6766CBEEF3D3093773D75F59A95E2E54; Path=/
> Set-Cookie: JSESSIONID=133C6FFF6E09ABD71E79DE84F68479BC; Path=/
> Content-Type: text/html
> Content-Length: 87
> Date: Fri, 30 Mar 2007 12:23:01 GMT
> Connection: close
>
>
> request.getSession(false)=org.apache.catalina.session.StandardSessionFacade@3a5a9c
>
> ---------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org