Kushagra,

On Fri, 29 Nov 2019 at 12:29, Kushagra Bindal <bindal.kusha...@gmail.com>
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
>
> <Context allowMultipleLeadingForwardSlashInPath="true">
>
>     <!-- Default set of monitored resources. If one of these changes, the
>  -->
>     <!-- web application will be reloaded.
>   -->
>     <WatchedResource>WEB-INF/web.xml</WatchedResource>
>     <WatchedResource>WEB-INF/tomcat-web.xml</WatchedResource>
>     <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
>
>     <ResourceLink name="jdbc/edbDataSource" global="jdbc/edbDataSource"
> type="javax.sql.DataSource"/>
>
>     <CookieProcessor
> className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
>
>     <!-- Uncomment this to disable session persistence across Tomcat
> restarts -->
>     <!--
>     <Manager pathname="" />
>     -->
>
>     <!-- Uncomment this to enable Comet connection tacking (provides events
>          on session expiration as well as webapp lifecycle) -->
>     <!--
>     <Valve
> className="org.apache.catalina.valves.CometConnectionManagerValve" />
>     -->
> </Context>
>
>
>
> On Fri, Nov 29, 2019 at 5:52 PM M. Manna <manme...@gmail.com> wrote:
>
> > Hi
> >
> > On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal <bindal.kusha...@gmail.com
> >
> > 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.
> > >
> > > <Context *allowMultipleLeadingForwardSlashInPath="true"*>
> >
> >
> > Why this asterisk? *
> >
> > >
> > >
> > >     <!-- Default set of monitored resources. If one of these changes,
> the
> > >  -->
> > >     <!-- web application will be reloaded.
> > >   -->
> > >     <WatchedResource>WEB-INF/web.xml</WatchedResource>
> > >     <WatchedResource>WEB-INF/tomcat-web.xml</WatchedResource>
> > >     <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
> > >
> > >     <ResourceLink name="jdbc/edbDataSource" global="jdbc/edbDataSource"
> > > type="javax.sql.DataSource"/>
> > >
> > >     <CookieProcessor
> > > className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
> > >
> > >     <!-- Uncomment this to disable session persistence across Tomcat
> > > restarts -->
> > >     <!--
> > >     <Manager pathname="" />
> > >     -->
> > >
> > >     <!-- Uncomment this to enable Comet connection tacking (provides
> > events
> > >          on session expiration as well as webapp lifecycle) -->
> > >     <!--
> > >     <Valve
> > > className="org.apache.catalina.valves.CometConnectionManagerValve" />
> > >     -->
> > > </Context>
> > >
> > > But after restart still I am getting below errors in tomcat's
> > > *localhost_access_log.2019-11-29.txt* file.
> > >
> > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +0000] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +0000] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:46 +0000] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > >
> > > Please help me in correcting the syntax.
> > >
> > > Regards
> > > Kushagra
> > >
> > > On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal <
> > bindal.kusha...@gmail.com
> > > >
> > > wrote:
> > >
> > > > 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 Fri, Nov 29, 2019 at 2:56 PM M. Manna <manme...@gmail.com> wrote:
> > > >
> > > >> HI,
> > > >>
> > > >>
> > > >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> > > bindal.kusha...@gmail.com>
> > > >> 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 we are upgrading it to 9.0.27 we found that now the same
> > url
> > > >> which
> > > >> > was working earlier it is now throwing 404 status code.
> > > >> >
> > > >> > Now, the problem is that we can not remove these double slash (//)
> > > >> manually
> > > >> > as it is used widely.
> > > >> >
> > > >> > So, can someone please provide a possible solution of this issue?
> > > >> >
> > > >>
> > > >>  Tomcat processes HTTP query and URL using RFC 7230 standards. But
> > > >> multiple
> > > >> leading forward slash support was disabled by default for good
> > reasons.
> > > >> This was done in 8.5.31 due to issues with Http Redirects involving
> > > >> Servlets.
> > > >>
> > > >> If you must use this, you have to modify your application context to
> > add
> > > >> the override as true - the attribute is called
> > > >> "allowMultipleLeadingForwardSlashInPath".
> > > >>
> > > >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> > > >>
> > > >> But I would sincerely recommend that you work on such designs and
> > > correct
> > > >> them in your application. There is always a "way". This is one of
> the
> > > >> reasons web applications become obsolete requires huge maintenance.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> >
> > > >> > --
> > > >> > Regards,
> > > >> > Kushagra Bindal
> > > >> > +91-9013792807
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Kushagra Bindal
> > > > +91-9013792807
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Kushagra Bindal
> > > +91-9013792807
> > >
> >
>
>
I have just started a tomcat with
<Context allowMultipleLeadingForwardSlashInPath="true" >

in the context.xml file. works just fine. I am not Mark, but he did suggest
that your issue is probably handled better in filtering at Servlet request
level.

If you also provide the below (as Mark suggested earlier in his reply),
that will be great:


>
>
>
> *Can you provide more details such as:- an example request URI- the
> <url-pattern> for the servlet you expect it to match toThanks,Mark  *


Thanks,



> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Reply via email to