-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 12/5/19 04:55, André Warnier (tomcat/perl) wrote:
> Christopher,
>
> I believe that the problem of the OP is that either this filter or
> the application, *relies* on the fact that Tomcat would NOT
> collapse multiple consecutive slashes in the URL, to a single
> slash. That (the non-collapsing) seems to have been the case in
> some previous versions of Tomcat, and has apparently been changed
> in more recent versions of Tomcat (and probably rightly so, to
> adhere more strictly to the specs).
Actually, it's somewhat in *violation* of the specs. But it's a
generally-accepted violation because it allows security rules to
actually remain sane.
If you want to protect "/foo/bar.html" which maps to a file on the
disk, you'll find that the filesystem collapses slashes and will load
that same file regardless of how many extra slashes you put in there.
"/foo////bar.html" is going to give you the same result.
The same is true for multiple levels like "/foo/bar/bar.html". If you
want to protect all files in "/foo/bar" it's not practical to add
protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/" and ...
you see where I'm going with this.
So the server decides that slash-collapsing will allow security
constraints to be more practically applied.
What if we get super-spec-compliant and allow those extra slashes?
Well, you'd have to get really (and, IMHO, /overly/) strict about how
those slashes are treated. In Java, you'd have to do something like this
:
String path = ... // file-path from request
String docRoot = ... // docroot base, absolute
File file = new File(docRoot, path);
if(!file.exists())
// return 404
if(!path.equals(file.getAbsolutePath().substring(docRoot.length()))
// return 404
That last check will check to make sure that the path requested by the
client *exactly equals* that of the path on the disk. That means that
multiple-slashes are essentially forbidden when requesting disk-files.
(It gets more fun when you are requesting a directory which has an
"index file" like index.html and you have to decide whether or not
it's okay to load that file automatically, even though the client
didn't specifically request it.)
So now we are spec-compliant. Yay! Except that all those sloppy
webmasters links no longer work because they do all kinds of weird URL
manipulations that don't always result in a perfectly-clean URL. So
we've achieved spec-compliance and inconvenienced users. Did we really
achieve anything? Those multi-slash URLs were never going to work. It
is really a big deal to just ... let them work? So we collapse slashes
and everything is fine. Nobody is really going to complain if
/foo//bar.html and /foo/bar.html both work instead of one of them
returning 404.
What about resource that are *not* on a disk? Like servlets and stuff
like that? Well, the servlet spec allows us to map to URL patterns of
various types. Some are exact, others prefixes, etc. We can also
define security constraints with the same kind of url-pattern basis.
Generally, those things should agree. What happens when you introduce
multiple-slashes in there?
Well, nobody is ever going to map a bunch of additional slashes to
make their servlets work properly. So we are back to the same problem
as the on-disk-file: the multiple-slashes are essentially forbidden if
we want to be super-spec-compliant. So we relax a little and take the
practical approach: collapse slashes and move on with our lives. This
has the added benefit of making security constraints more consistent,
and fewer mistakes. And encouraging fewer security mistakes is a Good
Thing.
> And the collapsing of multiple consecutive slashes in the URL, is
> probably done at such an early stage in the request processing,
> that it is not easy to do something to turn it off (which may or
> may not be spec-compliant anyway).
Turning it off would be a giant mess. And yes, it needs to be doe
quite early because Tomcat has to figure out which web application
will be responding to the request. So it's one of the first things
that Tomcat has to do with an incoming request.
> I did not look up the HTTP specs to find where this collapsing of
> slashes is specified, but I found this in the Apache httpd
> documentation, which would seem to suggest that consecutive slashes
> are not necessarily invalid, and may even *mean* something :
> http://httpd.apache.org/docs/2.4/mod/core.html#location (see : Note
> about "/")
>
> Ok, then I got curious and did have a quick look at RFCs 7230 and
> 7231, and they are mute about consecutive slashes. RFC2396 on the
> other hand does not seem to forbid consecutive slashes, and as I
> understand it, they are even "significant", as they seem to delimit
> a path element (which just happens to be empty).
> https://tools.ietf.org/html/rfc3986#section-3.3 does not seem to
> forbid consecutive slashes either.
>
> But I would suppose that if the Tomcat developers decided to
> collapse multiple consecutive slashes, they must have had a
> reason.
Yep: see above. It's a deliberate violation of the spec designed to
make the world work the way everyone expects it to work, and also make
security configuration sensible, too.
- -chris
> On 04.12.2019 15:18, Christopher Schultz wrote: Kushagra,
>
> On 12/4/19 06:32, Kushagra Bindal wrote:
>>>> I am not saying that this is a tomcat issue, I am just asking
>>>> if there is a way by which we can handle this. As maybe in
>>>> later version of 8.5.24 Tomcat has take some action to handle
>>>> such conditions.
>
> I still don't really see the problem. Your responses have included
> tiny bits of information separately and not everything all at once.
> If you have a <filter> defined and mapped to a URL pattern, it
> should work and not give you a 404.
>
> Try this with the examples application:
>
> http://localhost:8080/examples/servlets/servlet/HelloWorldExample
>
> It will respond no matter how any slashes you put in various
> places:
>
> http://localhost:8080/examples/servlets/servlet//HelloWorldExample
> http://localhost:8080/examples/servlets//servlet//HelloWorldExample
>
>
http://localhost:8080/examples/servlets/servlet//////HelloWorldExample
>
> There are no 404 errors.
>
> Are you sure your application has deployed correctly?
>
> -chris
>
>>>> On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas
>>>> <ma...@apache.org> wrote:
>>>>
>>>>> On 04/12/2019 05:16, Kushagra Bindal wrote:
>>>>>> Hi Mark/Manna/Chris,
>>>>>>
>>>>>> Do we have any way out to handle this type of behavior?
>>>>>
>>>>> All the evidence so far points to an application issue, not
>>>>> a Tomcat issue.
>>>>>
>>>>> If you are able to create a simple test case that
>>>>> demonstrates a Tomcat issue we can take a look.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>>>
>>>>>> On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal <
>>>>> bindal.kusha...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Chris,
>>>>>>>
>>>>>>> If you will check in my early email then you will find
>>>>>>> that with // it
>>>>> is
>>>>>>> throwing 404. But as soon as I removed it manually then
>>>>>>> it starts
>>>>> working
>>>>>>> properly and all these url were working fine in 8.5.24
>>>>>>> version.
>>>>>>>
>>>>>>> On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz <
>>>>>>> ch...@christopherschultz.net> wrote:
>>>>>>>
>>>>>> Kushagra,
>>>>>>
>>>>>> On 12/2/19 11:29, Kushagra Bindal wrote:
>>>>>>>>>> I think it should be.
>>>>>>>>>>
>>>>>>>>>> <filter>
>>>>>>>>>> <description>DanglingSessionInvalidateFilter</description>
>>>>>>>>>>
>>>>>>>>>>
>
>>>>>>>>>>
<filter-name>DanglingSessionInvalidateFilter</filter-name>
>>>>>>>>>> <filter-class>com.SessionInvalidateFilter</filter-class>
>>>>>>>>>>
>>>>>>>>>>
</filter> <filter-mapping>
>>>>>>>>>> <filter-name>DanglingSessionInvalidateFilter</filter-name>
>>>>>>>>>>
>>>>>>>>>>
>
>>>>>>>>>>
<url-pattern>/restcall/*</url-pattern> </filter-mapping>
>>>>>>>>>>
>>>>>>>>>> Here in below URL:
>>>>>>>>>>
>>>>>>>>>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthC
hec
>
>>>>>>>>>>
k"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
> sdm will be the context path.
>>>>>>>>>>
>>>>>>>>>> But in another example that I shared in my last
>>>>>>>>>> email, one use case
>>>>>>>>>> http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads
>>>>>>>>>>
>>>>>>>>>>
my context path itself contains //.
>>>>>>>>>>
>>>>>>>>>> So, please suggest a viable solution which we can
>>>>>>>>>> try to solve this problem. :)
>>>>>>>>>>
>>>>>>>>>> Thanks in advance for your help & support in
>>>>>>>>>> resolving this issue.
>>>>>>
>>>>>> All of these slashes really should be collapsed into a
>>>>>> single slash before processing. I don't see an issue. If
>>>>>> the client requests:
>>>>>>
>>>>>> http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
>>>>>>
>>>>>>
>>>>>>
>
>>>>>>
then the filter/servlet at /sdm/restcall/* will respond.
>>>>>>
>>>>>> If the client requests:
>>>>>>
>>>>>> http://backend_tomcat:8080//sdm/restcall/foo/file_uploads
>>>>>>
>>>>>>
>>>>>>
Then the filter/servlet at /sdm/restcall/* will respond.
>>>>>>
>>>>>> It doesn't really matter how many extra slashes the
>>>>>> client adds... they should all be collapsed by the server
>>>>>> and your application should not have to make arrangements
>>>>>> to handle them, add them back, or worry about whether
>>>>>> they are there or not.
>>>>>>
>>>>>> -chris
>>>>>>
>>>>>>>>>> On Mon, Dec 2, 2019 at 9:00 PM Mark Thomas
>>>>>>>>>> <ma...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 02/12/2019 10:59, Kushagra Bindal wrote:
>>>>>>>>>>>> Hi Mark,
>>>>>>>>>>>>
>>>>>>>>>>>> These are Rest Endpoints, and so will be
>>>>>>>>>>>> processed through Filter.
>>>>>>>>>>>
>>>>>>>>>>> That is unusual.
>>>>>>>>>>>
>>>>>>>>>>>> Do, you think Servlet mapping will play any
>>>>>>>>>>>> role here?
>>>>>>>>>>>
>>>>>>>>>>> If the filter is handling them, no.
>>>>>>>>>>>
>>>>>>>>>>> So I'll change the question. Which URL pattern
>>>>>>>>>>> from the filter mapping do you expect:
>>>>>>>>>>>
>>>>>>>>>>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//health
Che
>
>>>>>>>>>>>
ck"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>>>>>>>>
> to match?
>>>>>>>>>>>
>>>>>>>>>>> The Context Path question still needs an
>>>>>>>>>>> answer.
>>>>>>>>>>>
>>>>>>>>>>> Mark
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Dec 2, 2019 at 2:33 PM Mark Thomas
>>>>>>>>>>>> <ma...@apache.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 02/12/2019 04:53, Kushagra Bindal
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Hi Mark,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please find the snippet from web.xml
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which URL pattern do you expect:
>>>>>>>>>>>>>
>>>>>>>>>>>>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//heal
thC
>
>>>>>>>>>>>>>
heck
>>>>>
>>>>>>>>>>>>>
> "
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> to match?
>>>>>>>>>>>>>
>>>>>>>>>>>>> And what is the Context Path at which the
>>>>>>>>>>>>> application is deployed?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <servlet>
>>>>>>>>>>>>>> <servlet-name>default</servlet-name>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servle
t-c
>>>>>>
>>>>>
>
>>>>>
lass>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> <init-param>
>>>>>>>>>>>>>> <param-name>debug</param-name>
>>>>>>>>>>>>>> <param-value>0</param-value>
>>>>>>>>>>>>>> </init-param> <init-param>
>>>>>>>>>>>>>> <param-name>listings</param-name>
>>>>>>>>>>>>>> <param-value>false</param-value>
>>>>>>>>>>>>>> </init-param>
>>>>>>>>>>>>>> <load-on-startup>1</load-on-startup>
>>>>>>>>>>>>>> </servlet> <servlet>
>>>>>>>>>>>>>> <servlet-name>jsp</servlet-name>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class
>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>
>>>>>
>
>>>>>
<init-param>
>>>>>>>>>>>>>> <param-name>fork</param-name>
>>>>>>>>>>>>>> <param-value>false</param-value>
>>>>>>>>>>>>>> </init-param> <init-param>
>>>>>>>>>>>>>> <param-name>xpoweredBy</param-name>
>>>>>>>>>>>>>> <param-value>false</param-value>
>>>>>>>>>>>>>> </init-param>
>>>>>>>>>>>>>> <load-on-startup>3</load-on-startup>
>>>>>>>>>>>>>> </servlet> <!-- The mapping for the
>>>>>>>>>>>>>> default servlet --> <servlet-mapping>
>>>>>>>>>>>>>> <servlet-name>default</servlet-name>
>>>>>>>>>>>>>> <url-pattern>/</url-pattern>
>>>>>>>>>>>>>> </servlet-mapping> <!-- The mappings for
>>>>>>>>>>>>>> the JSP servlet --> <servlet-mapping>
>>>>>>>>>>>>>> <servlet-name>jsp</servlet-name>
>>>>>>>>>>>>>> <url-pattern>*.jsp</url-pattern>
>>>>>>>>>>>>>> <url-pattern>*.jspx</url-pattern>
>>>>>>>>>>>>>> </servlet-mapping> <servlet>
>>>>>>>>>>>>>> <servlet-name>PatternTemplateLaunchServlet</servlet-name>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>
<servlet-class>PatternTemplateLaunchServlet</servlet-class>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> </servlet>
>>>>>>>>>>>>>> <servlet>
>>>>>>>>>>>>>> <servlet-name>MyReportsLaunchServlet</servlet-name>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>
<servlet-class>MyReportsLaunchServlet</servlet-class>
>>>>>>>>>>>>>> </servlet> <servlet-mapping>
>>>>>>>>>>>>>> <servlet-name>PatternTemplateLaunchServlet</servlet-name>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>
<url-pattern>/patterntemplatelaunch</url-pattern>
>>>>>>>>>>>>>> </servlet-mapping> <servlet-mapping>
>>>>>>>>>>>>>> <servlet-name>MyReportsLaunchServlet</servlet-name>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>
<url-pattern>/MyReportsLaunchServlet</url-pattern>
>>>>>>>>>>>>>> </servlet-mapping>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please let me know if you need anyother
>>>>>>>>>>>>>> details from our side.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Dec 2, 2019 at 3:07 AM Mark
>>>>>>>>>>>>>> Thomas <ma...@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 01/12/2019 07:11, Kushagra Bindal
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Hi Manna/Mark,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Below are the sample URL which we
>>>>>>>>>>>>>>>> are passing to Tomcat.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://backend_tomcat:8080//sdm/restcall)(.*)/file_uplo
ads
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>>>
http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As from the above example you can see
>>>>>>>>>>>>>>>> that // location may vary case
>>>>>>>>>>> by
>>>>>>>>>>>>>>>> case.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, you guys have a probable solution
>>>>>>>>>>>>>>>> to handle such situation, then
>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>> do let me know.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomcat is simply going to normalize
>>>>>>>>>>>>>>> those to single '/'. The
>>>>>>>>>>> application
>>>>>>>>>>>>>>> should be fine with that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To repeat my previous request: Can you
>>>>>>>>>>>>>>> provide more details such as: - an
>>>>>>>>>>>>>>> example request URI *and* - the
>>>>>>>>>>>>>>> <url-pattern> for the servlet you
>>>>>>>>>>>>>>> expect it to match to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> -----------------------------------------------------------------
>>>>>>
>>>>>
>
>>>>>
- ----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>> To unsubscribe, e-mail:
>>>>>> users-unsubscr...@tomcat.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>> users-h...@tomcat.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> ------------------------------------------------------------------
- -
>>>>>>>>
>>>>>>>>
>>>>>
>
>>>>>
- ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> users-unsubscr...@tomcat.apache.org For additional
>>>>>>>> commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
- ---
>>>>>
>>>>>
>
>>>>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-h...@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3pLLwACgkQHPApP6U8
pFhJBA//XZXoK7Yd01UBtUBSrji4l2lwCiT8pxh9YGvWd6FOs3SVpTyoNg1EVxqZ
JCeBzFeYIjOouA8FyXbOZO6olSi/B6SP/yNPtchgYQnCTloGKrH3Og1t46ZdfpgZ
408ay/UpIZJAOZTPjtnXYLmgwNgm79xR82+sOb/LK6tSk0ujzDryEuMG/QECvulM
NsGl/PXVo5WBlvHoj3L7WgcMAx7hnmBWBr1SLdnGi0a/ZlgzGYriH9LLaSfOjIyc
y2lmij9uAzwiiCe46+bQJ3YHxm4m+/39jFizJj+WhE/f8ecj3vxLcBoAwaruQRXW
b65/fzPRfpGA+mUapFTh5S2+KS8YWhbABdfLL1Du6RDIhmEFTa2SkMs/Qpo9bAlY
fYuVeuwudIQrXingp+uRFhMMbbyzFd6U89pktf3k3wBLfazOnB5csMOwPcE1jlq2
TGcjiLq6PwnfSeAKhCEQHzgLOyXIM0izsd0nkRvAC5YuuhVN6vqetma8wvMsvoVD
kaPQwKdRXHjoydLF9z4GaKRO97yeC9EP+vHQhXjrQqWe1HO4q06xL8EwpxTU46T+
qqXRLtvEJrdKfOaiVK0E+it9Rh5uSSKjzW79qVzuQ5H59Lb4fJm0BsKc0nI2bgfu
wkTazYm8SJ0ziZs/ElCpUKgLG5WChRiSDFowUEnM35U7+1T6H4U=
=Fh+F
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
