-----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

Reply via email to