https://bz.apache.org/bugzilla/show_bug.cgi?id=61634
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
Thanks for the test case. It is much easier to figure out what is going on with
a working example in front of you.
The short version is that I do not believe there is a Tomcat bug here.
The difference between 8.0.44 and 8.0.45 that causes this is indeed the fix for
bug 61185. It wasn't obvious that fix and this issue were related until the use
of the Tuckey rewrite filter was mentioned.
The rewrite filter uses RequestDispatchers to forward requests to the rewritten
URL. The filter correctly uses HttpServletRequest.getRequestURI() to obtain the
URL provided by the user to perform the rewrite.
The fix corrected an edge case behaviour in Tomcat's RequestDispatcher
implementation that was not compliant with the Servlet specification. From
section 9.4 of the Servlet specifcation:
<quote>
The path elements of the request object exposed to the target servlet must
reflect the path used to obtain the RequestDispatcher.
</quote>
In this case the rewrite in the ROOT context obtains a RequestDispatcher for
/context2 using the path "/index//index.html". Tomcat normalises (and decodes)
this path to enable the request to be mapped to the correct Servlet. Prior to
8.0.45 Tomcat incorrectly then used the normalized path to construct the
RequestDispatcher. This meant that the target servlet saw a path of
"/index/index.html" for HttpServletRequest.getRequestURI() which was NOT the
path used to obtain the RequestDispatcher and was therefore NOT compliant with
section 9.4 of the Servlet Specification.
As of 8.0.45 Tomcat correctly uses the originally provided path
"/index//index.html" to construct the RequestDispatcher.
The rewrite filter decodes URLs before processing but does not appear normalize
them. That is surprising. In matching incoming URIs to rewrite rules, the
filter is doing something very similar to what Tomcat (or any Servlet
container) does to map a request to a Servlet. The process Tomcat uses for this
is (in short form) normalize, decode, check normalization, map. I'd expect the
filter to do something similar.
I tried Googling for information on configuring the rewrite filter to normalize
but all I could find was this:
https://jira.atlassian.com/browse/CONFSERVER-26888
I also searched the rewrite filter source at GitHub but could find no
references to normalization.
At this point I recommend opening an issue with the rewrite filter. My own view
is that it should always "normalize, decode, check normalize, rewrite" rather
than just "decode, rewrite".
Finally, it is worth mentioning the
http://localhost:8080/index/foo/../index.html fails as well. Note if you make
that request with a browser it is likely to normalize it for you before sending
it and then it will work.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
