-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 12/9/19 04:50, André Warnier (tomcat/perl) wrote:
> Hi Christopher.
>
> I believe that yours is a really good explanation of why Tomcat
> collapses consecutive slashes in URLs. It's certainly worth a FAQ
> article, in case the question
Hi Christopher.
I believe that yours is a really good explanation of why Tomcat collapses consecutive
slashes in URLs.
It's certainly worth a FAQ article, in case the question ever pops up again.
It maybe even be worth a note somewhere in the main documentation, such as where it
explains how
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Kushagra,
On 12/5/19 11:44, Kushagra Bindal wrote:
> Hi Chris
>
> Thanks for your detailed explanation.
>
> As I mentioned in my earlier email as well, I encountered this in
> two case 1. // prior to contextpath i.e. in ur case //examples. 2.
>
Hi Chris
Thanks for your detailed explanation.
As I mentioned in my earlier email as well, I encountered this in two case
1. // prior to contextpath i.e. in ur case //examples.
2. // in url i.e. //HelloWorldExample.
In both cases I was getting 404 error. This is a running application with
same
-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
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
Thanks
On Wed, Dec 4, 2019, 5:20 PM Mark Thomas wrote:
> 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
-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
>
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
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.
On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas wrote:
> On 04/12/2019 05:16, Kushagra
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
Hi Mark/Manna/Chris,
Do we have any way out to handle this type of behavior?
On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal
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
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 <
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Kushagra,
On 12/2/19 11:29, Kushagra Bindal wrote:
> I think it should be.
>
>
> DanglingSessionInvalidateFilter
> DanglingSessionInvalidateFilter
> com.SessionInvalidateFilter
>
> DanglingSessionInvalidateFilter
> /restcall/*
>
> Here
I think it should be.
DanglingSessionInvalidateFilter
DanglingSessionInvalidateFilter
com.SessionInvalidateFilter
DanglingSessionInvalidateFilter
/restcall/*
Here in below URL:
"http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck;
sdm will
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
Hi Mark/Manna
Please let me know if I need to provide some additional information about
the deployments so that it can be helpful in resolving the issue.
Regards
Kushagra
On Mon, Dec 2, 2019, 4:29 PM Kushagra Bindal
wrote:
> Hi Mark,
>
> These are Rest Endpoints, and so will be processed
Hi Mark,
These are Rest Endpoints, and so will be processed through Filter. Do, you
think Servlet mapping will play any role here?
On Mon, Dec 2, 2019 at 2:33 PM Mark Thomas wrote:
> On 02/12/2019 04:53, Kushagra Bindal wrote:
> > Hi Mark,
> >
> > Please find the snippet from web.xml
>
> Which
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
>
>
>
Hi Mark,
Please find the snippet from web.xml
default
org.apache.catalina.servlets.DefaultServlet
debug
0
listings
false
1
jsp
org.apache.jasper.servlet.JspServlet
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
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
Kushagra,
On Fri, 29 Nov 2019 at 12:29, Kushagra Bindal
wrote:
> Hi Mark,
>
> This astrik is because I highlighted it as BOLD. But I guess at your end it
> is being received as plain text. Resending the content in context.xml
>
>
>
>
>
> WEB-INF/web.xml
>
Hi Mark,
This astrik is because I highlighted it as BOLD. But I guess at your end it
is being received as plain text. Resending the content in context.xml
WEB-INF/web.xml
WEB-INF/tomcat-web.xml
${catalina.base}/conf/web.xml
On Fri,
Hi
On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal
wrote:
> Hi Mark,
>
> We tried to put the changes as suggested by you. Below are the changes that
> we have made in context.xml file.
>
>
Why this asterisk? *
>
>
>
>
> WEB-INF/web.xml
> WEB-INF/tomcat-web.xml
>
Hi Mark,
We tried to put the changes as suggested by you. Below are the changes that
we have made in context.xml file.
WEB-INF/web.xml
WEB-INF/tomcat-web.xml
${catalina.base}/conf/web.xml
But after restart still I am getting below
Hi Mark,
Thanks for providing the response.
Yes, you are right that we should design our application to remove // from
being used.
I will plan it accordingly, for the provided solution in below. Let me try
the same and I will revert back to you in case of any further queries and
concerns.
On
On 29/11/2019 09:00, Kushagra Bindal wrote:
> Hi,
>
> We are working on upgrading our enterprise application from 8.5.24 to
> 9.0.27 version.
>
> What we have observed that in earlier version i.e. 8.5.24 we were able to
> process process a REST URI have double slash ("//") in it.
>
> But when
HI,
On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal
wrote:
> Hi,
>
> We are working on upgrading our enterprise application from 8.5.24 to
> 9.0.27 version.
>
> What we have observed that in earlier version i.e. 8.5.24 we were able to
> process process a REST URI have double slash ("//") in it.
Hi,
We are working on upgrading our enterprise application from 8.5.24 to
9.0.27 version.
What we have observed that in earlier version i.e. 8.5.24 we were able to
process process a REST URI have double slash ("//") in it.
But when we are upgrading it to 9.0.27 we found that now the same url
30 matches
Mail list logo
