чт, 14 окт. 2021 г. в 11:25, Mark Thomas <[email protected]>:
>
> On 14/10/2021 09:22, [email protected] 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 <[email protected]>
> > 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.
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).
d. If backporting, it would better be configurable.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
