Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: dev@tomcat.apache.org
Subject: [Bug 61634] URLs with double consecutive slashes stopped working in
 8.0.45 in some scenarios
Date: Thu, 19 Oct 2017 10:08:27 +0000
Message-ID: <bug-61634-78-eeKV5TWbuD@https.bz.apache.org/bugzilla/>
In-Reply-To: <bug-61634-78@https.bz.apache.org/bugzilla/>
References: <bug-61634-78@https.bz.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
MIME-Version: 1.0
archived-at: Thu, 19 Oct 2017 10:08:41 -0000

https://bz.apache.org/bugzilla/show_bug.cgi?id=3D61634

Mark Thomas <markt@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Mark Thomas <markt@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 rewri=
tten
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 decod=
es)
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 w=
ith
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 norma=
lize
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 norma=
lize
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" rath=
er
than just "decode, rewrite".

Finally, it is worth mentioning the
http://localhost:8080/index/foo/../index.html fails as well. Note if you ma=
ke
that request with a browser it is likely to normalize it for you before sen=
ding
it and then it will work.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org