On 04/12/2019 11:32, Kushagra Bindal wrote:
> Hi Mark,
> 
> 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.

If you mean, is there a Tomcat setting that will not cause Tomcat to
collapse multiple "//" to a single "/", the answer is 'No'.

Mark


> 
> 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//healthCheck";
>>>>>>>
>>>>>>> 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//healthCheck";
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> 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//healthCheck
>> "
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>> 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
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to