Bug 56501 - problems with urlencoding in webapp name
Summary: problems with urlencoding in webapp name
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2014-05-08 08:43 UTC by Kay
Modified: 2014-05-12 16:57 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Kay 2014-05-08 08:43:29 UTC
we have a webapp with a filter, that generates an index.html file if the app is called on its root directory or with index.html as path.

there is one edge case where this filter is ignored and tomcat trys to open an actual index.html (which does not exist).

this happens when the webapp contains a underscore (_) in its name and the app is opened with %5F encoding instead of the underscore and a leading /.

we found this issue while migrating our apps from tomcat 6 to tomcat 7(.0.52). the manager app links the webapps with "/test%5Fapp/" (tomcat 6 used "/test%5Fapp" without the leading /) on tomcat 6 clicking the link the webapp opened as expected. on tomcat 7 we get 404 or if we place a real index.html it is shown.

on tomcat 8 the real index.html is accessed too, haven't checked how the manager links to the app.

WepApp name: test_app

http://tomcat/test_app - Filter
http://tomcat/test_app/ - Filter
http://tomcat/test%5Fapp - Filter
http://tomcat/test%5Fapp/ - index.html (404)
http://tomcat/test_app/index.html - Filter
http://tomcat/test%5Fapp/index.html - Filter

with name: testapp
http://tomcat/testapp - Filter
http://tomcat/testapp/ - Filter
http://tomcat/testapp/index.html - Filter
Comment 1 Mark Thomas 2014-05-08 13:11:27 UTC
What filter mapping are you using?
Comment 2 Kay 2014-05-08 13:42:19 UTC

this is my mapping
Comment 3 Mark Thomas 2014-05-08 15:37:44 UTC
This works for me with the latest code for 7.0.x.

The one thing that looks odd with this report is that http://tomcat/test%5Fapp works but http://tomcat/test%5Fapp/ doesn't since the response to the first URL should be a redirect to the latter url so I can;t see how the first works but the second fails.

I suspect something a little more complex is going on, probably with welcome files.

You need to follow this up on the users mailing list (when ASF e-mail is restored). Until then, I'd suggest trying to put together the simplest test case the demonstrates this issue - I suspect that process will be illuminating.
Comment 4 Kay 2014-05-09 06:05:04 UTC
What Browser did you use to test?

I tested with some and found that Chrome and IE (tested with 8, so 8+ should work too i think) work, but on Firefox this issue occurs.

I'l try to build a little sample app for you to test.
Comment 5 Kay 2014-05-09 06:56:10 UTC
I just uploaded a sample project.

- git clone https://github.com/dodgex/tomcat-issue-56501
- mvn package
- deploy on a tomcat server as test_app
- open http://tomcat/test_app/test.html (in firefox)

click the links.
SUCCESS => IndexFilter
FAILURE => real index.html

as mentioned in the comment before, for Chrome and IE every link yields "SUCCESS" but for Firefox it is failure in two cases.

a look on the network tab of FireBug and Chrome dev tools i can see that chrome decodes the %5F to _ for the requests while firefox actually sends the request with %5F to the server.

i think there should be some kind on URL decode on tomcat side.

Kind regards,
Comment 6 Mark Thomas 2014-05-09 16:24:45 UTC
(In reply to Kay from comment #5)

> i think there should be some kind on URL decode on tomcat side.

The problem is the exact opposite. Neither getRequestURI() not getContextPath() should return decoded values but currently getContextPath() does.

I'll look into fixing this.
Comment 7 Mark Thomas 2014-05-09 21:03:00 UTC
This has been fixed in 8.0.x for 8.0.6 onwards.
Comment 8 Konstantin Kolinko 2014-05-10 00:02:40 UTC
For reference:

[quote]The container does not decode this string.[/quote]

The same in JavaEE 6 and 5 javadocs for getContextPath() method.

Thus I agree with this change. ( r1593621 )

This change also means that any path parameters present in that part of request URI are now returned by getContextPath().
Comment 9 Mark Thomas 2014-05-12 16:57:10 UTC
Fixed in 7.0.x for 7.0.54 onwards.