Bug 55266 - Trailing slash redirect loses jsessionid attribute
Summary: Trailing slash redirect loses jsessionid attribute
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.33
Hardware: Macintosh All
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-15 07:30 UTC by Frank
Modified: 2013-12-20 09:42 UTC (History)
0 users



Attachments
contains a maven project including tomcat6-plugin to package the webapp and run tomcat using maven. This archive also includes a deployable war beneath /dist. (3.93 KB, application/x-gzip)
2013-07-15 07:30 UTC, Frank
Details
Proposed patch for this issue (1.21 KB, patch)
2013-07-21 17:47 UTC, Mark Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frank 2013-07-15 07:30:05 UTC
Created attachment 30594 [details]
contains a maven project including tomcat6-plugin to package the webapp and run tomcat using maven. This archive also includes a deployable war beneath /dist.

I'm using URL rewriting and recently upgraded my tomcat version from 6.0.32 to 6.0.33. I figured out that since 6.0.33 the jsessionid attribute is omitted in the Location header when Tomcat forces a trailing slash redirect e.g. from /mypath to /mypath/. The effect is that the session information is lost after the redirect.

This pretty looks like the same as an old bug 'Bug 34749' (https://issues.apache.org/bugzilla/show_bug.cgi?id=34749) in Tomcat 5.


Steps to reproduce:

1. Deploy the attached war to a Tomcat >= 6.0.33 or use 'mvn package tomcat6:run' if you whish to use maven tomcat6 plugin.

2. Create a session by requesting a page 'createsession.jsp'. The response shows a sessionid that is required for step three and four.
curl -v "http://localhost:8080/jsessionid-issue/createsession.jsp"


3. Append the jsessionid attribute to the uri "http://localhost:8080/jsessionid-issue/". Please note the slash at the end of the path.
curl -Lv "http://localhost:8080/jsessionid-issue/;jsessionid=_id_"

The jsessionid is taken into account. The response shows that the session of the requested sessionid has been used.

4. Now, request the same uri without the trailing slash: 'http://localhost:8080/jsessionid-issue;jsessionid=_id_'
curl -Lv "http://localhost:8080/jsessionid-issue;jsessionid=_id_"

First, the output shows a 302 redirect that is forced by tomcat. The location header shows the uri 'http://localhost:8080/jsessionid-issue/' with a trailing slash now but the jsessionid attribute is missing.
Accordingly, the response of the second request shows that no session has been used.



Sample:

1. 'mvn package tomcat6:run'
15.07.2013 07:46:46 org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
15.07.2013 07:46:46 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.37
15.07.2013 07:46:47 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
15.07.2013 07:46:47 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080


2. curl -v "http://localhost:8080/jsessionid-issue/createsession.jsp"
* About to connect() to localhost port 8080 (#0)
*   Trying ::1...
* connected
* Connected to localhost (::1) port 8080 (#0)
> GET /jsessionid-issue/createsession.jsp HTTP/1.1
> User-Agent: curl/7.28.0
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: text/html;charset=utf-8
< Content-Length: 92
< Date: Mon, 15 Jul 2013 06:22:11 GMT
< 

########################################
created session: 968F6BEC133C69A20EAFF0D2093F7A56
########################################


3. curl -Lv "http://localhost:8080/jsessionid-issue/;jsessionid=968F6BEC133C69A20EAFF0D2093F7A56"
* About to connect() to localhost port 8080 (#0)
*   Trying ::1...
* connected
* Connected to localhost (::1) port 8080 (#0)
> GET /jsessionid-issue/;jsessionid=968F6BEC133C69A20EAFF0D2093F7A56 HTTP/1.1
> User-Agent: curl/7.28.0
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: text/html;charset=utf-8
< Content-Length: 285
< Date: Mon, 15 Jul 2013 06:22:49 GMT
< 

########################################
http session: 968F6BEC133C69A20EAFF0D2093F7A56
getRequestURI: /jsessionid-issue/;jsessionid=968F6BEC133C69A20EAFF0D2093F7A56
getRequestedSessionId: 968F6BEC133C69A20EAFF0D2093F7A56
isRequestedSessionIdFromURL: true
isRequestedSessionIdValid: true
########################################


4. curl -Lv "http://localhost:8080/jsessionid-issue;jsessionid=968F6BEC133C69A20EAFF0D2093F7A56"
* About to connect() to localhost port 8080 (#0)
*   Trying ::1...
* connected
* Connected to localhost (::1) port 8080 (#0)
> GET /jsessionid-issue;jsessionid=968F6BEC133C69A20EAFF0D2093F7A56 HTTP/1.1
> User-Agent: curl/7.28.0
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 302 Found
< Server: Apache-Coyote/1.1
< Location: http://localhost:8080/jsessionid-issue/
< Transfer-Encoding: chunked
< Date: Mon, 15 Jul 2013 06:24:12 GMT
< 
* Ignoring the response-body
* Connection #0 to host localhost left intact
* Issue another request to this URL: 'http://localhost:8080/jsessionid-issue/'
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (::1) port 8080 (#0)
> GET /jsessionid-issue/ HTTP/1.1
> User-Agent: curl/7.28.0
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: text/html;charset=utf-8
< Content-Length: 189
< Date: Mon, 15 Jul 2013 06:24:12 GMT
< 

########################################
http session is null
getRequestURI: /jsessionid-issue/
getRequestedSessionId: null
isRequestedSessionIdFromURL: false
isRequestedSessionIdValid: false
########################################
Comment 1 Mark Thomas 2013-07-21 17:33:30 UTC
Confirmed. This happens with 6.0.x but not 7.0.x or trunk.
Comment 2 Mark Thomas 2013-07-21 17:47:41 UTC
Created attachment 30608 [details]
Proposed patch for this issue

This patch fixes this issue for me in local testing. I'll propose it for 6.0.x.
Comment 3 Mark Thomas 2013-12-20 09:42:14 UTC
This has been fixed in 6.0.x and will be included in 6.0.38 onwards.