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. eg 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
What filter mapping are you using?
<filter> <filter-name>IndexFilter</filter-name> <filter-class>my.package.index.IndexFilter</filter-class> </filter> <filter-mapping> <filter-name>IndexFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> this is my mapping
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.
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.
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, Kay
(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.
This has been fixed in 8.0.x for 8.0.6 onwards.
For reference: http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getContextPath%28%29 [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().
Fixed in 7.0.x for 7.0.54 onwards.