Created attachment 26216 [details] war file demonstrating the bug When registering a Filter with a wildcarded url-patterm (ie: "/*") tomcat 7.0.4 seems to be adding "index.jsp" to the end of any url which ends in a "/" prior to invoking the Filter's doFilter method. This is a change in behavior from tomcat 6.0.29 (and certainly seems like a bug, but i'm not an expert on the servlet spec) The attached war file includes a filter (and it's source) which is mapped to the url-pattern "/*". This filter causes a 400 response for any request it sees, specifying the path information included in the HttpServletRequest as the error message. If you start up tomcat 6.0.* using port 8080, running this war, a URL like this.... http://localhost:8080/filter-bug/asdf ...will produce an error message like... FilterBugDemo@24988707 Got:/asdf + null ...likewise a URL like this... http://localhost:8080/filter-bug/asdf/ ...will produce the error message... FilterBugDemo@24988707 Got:/asdf/ + null Using Tomcat 7.0.4 however, the last URL method above produces this error... FilterBugDemo@4a8d3d62 Got:/asdf/index.jsp + null ...indicating that the Filter did not receive an HttpServletRequest containing the "correct" URL sent by the client. (Note: This behavior may exist in other versions of Tomcat 7.0.*, i only tested 7.0.4)
Note: this is (evidently) the root cause of SOLR-2022... https://issues.apache.org/jira/browse/SOLR-2022
Looks like another case of bug 49422. More discussions in http://tomcat.markmail.org/thread/xvuophujspik5liq Short version: - Tomcat is stricter in applying the spec rules for welcome files - Some EG members think the spec does not reflect what was agreed in the EG - Tomcat will be adding some new options to handle this - probably defaulting to previous behaviour
*** This bug has been marked as a duplicate of bug 49422 ***
While i appreciate that the underlying change that caused this bug is most certainly the same as that of bug#49422 i would like to point out that the actual issue is (to me at least) fairly distinct. Having read the comments in bug#49422 I (somewhat) understand the reasons why a servlet wishing to receive requests for "/foo/" should be registered with a url-mapping of "/foo/*" in order to receive the implicit request for "/foo/index.jsp" but in the case of this bug (bug#50161) We are already using a url-mapping of "/*" for the Filter in question. The issue at hand is what the return value of HttpServletRequest.getServletPath() should be when the Servlet (or in our case Filter) processes the request. Shouldn't that method (per the javadocs) "Returns the part of this request's URL that calls the servlet" ... w/o having additional (implicit) values tacked on to the end?
Don't know how legal it is but I use the following workaround in the web.xml (works with 7.0.4): <welcome-file-list> <welcome-file></welcome-file> </welcome-file-list> This turns off the default welcome file list and adds nothing to the end of the url.
(In reply to comment #4) > The issue at hand is what the return value of > HttpServletRequest.getServletPath() should be when the Servlet (or in our case > Filter) processes the request. > > Shouldn't that method (per the javadocs) "Returns the part of this request's > URL that calls the servlet" ... w/o having additional (implicit) values tacked > on to the end? There are a couple of ambiguities in the spec in this area: - It isn't clear if filter mapping occurs before or after welcome file processing. The implication is that filter mapping is after welcome file processing. - It isn't clear if the welcome file should be included in getServletPath() etc. The implication is that it should. Both of these issues - and a bunch of others - are on my list of things to nag the EG about. The option(s) that get added for the next 7.0.x release should fix this for you - or at least enable you to work around it.