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).
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).
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.
On 04.12.2019 15:18, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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//healthChec
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//healthChe
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//healthC
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</servlet-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_uploads
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
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3nwE8ACgkQHPApP6U8
pFg7FBAAy23SNDu9rnTmAT+HZnKlw4CPhmMvbjfikQ5+boogd/6z+3K2UINKW5Cl
yjQhrMWP2jvPNer6nzOXoQ48BgFHBc05okpNZ8Y/QW3olj5o3Cp1V5tPQ3zjTHL4
P+V0bY9Owi4lHbx3A0aFXN78Umg/nDjj8ayllC9XvlnYSXe4Ud575seGpXn1txgX
Bk4Ghq4wwMJ8m+BMY0RWq9Rq0yo+TTcUS/6DMVVk8MfTMEEbztS4td1W0LSxAmXo
xqO4e46rBJJzAtDHFM4X0IOZ9bBy4y5OKEMEm4cnfVM80wr2AHHLb6hKw7SA+g7F
hNoNa35i2qy2g6e6yNLkEGsbW7zk4pVC9n2TSPwZ0FmB8Gq3AiYioRPR+nCjo5A2
f/nwxdFVSy6BqpMc54AaEC1SGYNTLMFvHAh+zzE/PpsRcno9y+eHSRsCIg9bi1/S
8CqeM0+egzLul1BAbHXwMQGdIOjClct9LohGed1Knvjexo+ByxK9gYWmZkr2+k0w
IAl47kUYeaC9/3aaxEJ/VI4KCoq7/G6E8zhVRz7mv8rheqP0DJQC1hQ4gcdMlOxw
pGxyPQTa6Vk9TUavieICPA+XAfm/On4PeCfS1Y1vOX97T8tvIjUVGA0CgO2DyfOT
O7wwUx/BMv+8knpKUCGa8iCkBwaRaemdTjqhC1xr2eZfW6vtMWY=
=eyNx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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
