On 14/10/2021 10:25, Konstantin Kolinko wrote:
чт, 14 окт. 2021 г. в 11:25, Mark Thomas <ma...@apache.org>:
On 14/10/2021 09:22, ma...@apache.org wrote:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 70d4e9b Do not add a trailing / to a request URI during
canonicalization.
70d4e9b is described below
commit 70d4e9ba0a81a1d782fa50695a18d23f2f1f179c
Author: Mark Thomas <ma...@apache.org>
AuthorDate: Wed Oct 13 18:28:45 2021 +0100
Do not add a trailing / to a request URI during canonicalization.
This is part of the clarification in Servet 6.0 of the expected
canonicalization Servlet containers are expected to apply to request
URIs.
All,
This is the first of several clarifications. The question is do we want
to back-port this change to earlier versions?
My current thinking is that we should as the current behaviour looks
wrong. We add a trailing "/" to simplify the normalization algorithm but
then don't remove it after we have completed normalization.
Hi!
I have not thought about this in detail.
Just several quick observations / quick thoughts.
a. Generally, I like doing things correctly.
b. Looking at test example:
doTestNormalize("/foo/.", "/foo");
It can be seen that "foo" is a directory,
and thus I think it actually behaves as follows:
Old behaviour:
1. Serve content of "/foo/"
New behaviour:
1. As "/foo" is a directory, Tomcat will likely won't serve it, but
will respond with a 302-redirect to "/foo/"
2. Serve content of "/foo/".
It is one more round-trip, but at least the browser will display a
correct normalized URL.
The extra round-trip annoys me a little. But then I think if that is an
issue for the user agent, submit a sensible URI in the first place.
c. I think that browsers usually normalize URLs before making a
request, though I am not 100% sure. If so, the non-normalized URLs
will come from elsewhere, not from a browser. (And so there will be no
difference for browsers).
I can think a few possible sources:
- reverse proxies with possibly inefficient/wrong configuration
- attackers trying to exploit a reverse proxy / servlet container
combination
- application generate URIs where the URiu has been generated by
concatenating various strings
d. If backporting, it would better be configurable.
Yeah, I know. I'd like to avoid lots of new configuration options. Maybe
a single new option "servlet6Canonicalization" for all the changes I am
proposing (there are a few more commits to come)?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
