You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kushagra Bindal <bi...@gmail.com> on 2019/12/01 07:11:57 UTC
Re: Double Slash Support in Tomcat 9.0.27
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.
Looking forward to hearing from you.
Regards
Kushagra
On Fri, Nov 29, 2019 at 6:23 PM M. Manna <ma...@gmail.com> wrote:
> Kushagra,
>
> On Fri, 29 Nov 2019 at 12:29, Kushagra Bindal <bi...@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 <ma...@gmail.com> wrote:
> >
> > > Hi
> > >
> > > On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal <
> bindal.kushagra@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.kushagra@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 <ma...@gmail.com>
> wrote:
> > > > >
> > > > >> HI,
> > > > >>
> > > > >>
> > > > >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> > > > bindal.kushagra@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
> >
>
--
Regards,
Kushagra Bindal
+91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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.
> // in url i.e. //HelloWorldExample.
>
> In both cases I was getting 404 error. This is a running
> application with same // pattern on 8.5.24 version tomcat with
> nginx on top of it.
>
> Please do let me know if possible option is available for this.
If your application always uses a single-slash for all url-patters,
your clients should not receive any 404s no matter how many slashes
they use.
Can you please either post everything of yours all at once, or show us
how to change the Tomcat examples application to make it return a 404
response for a URL which should actually return a non-404 response? It
should not matter how many slashes the client uses.
- -chris
> On Thu, Dec 5, 2019, 9:44 PM Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> 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 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).
>
> Actually, it's somewhat in *violation* of the specs. But it's a
> generally-accepted violation because it allows security rules to
> actually remain sane.
>
> If you want to protect "/foo/bar.html" which maps to a file on the
> disk, you'll find that the filesystem collapses slashes and will
> load that same file regardless of how many extra slashes you put in
> there. "/foo////bar.html" is going to give you the same result.
>
> The same is true for multiple levels like "/foo/bar/bar.html". If
> you want to protect all files in "/foo/bar" it's not practical to
> add protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/"
> and ... you see where I'm going with this.
>
> So the server decides that slash-collapsing will allow security
> constraints to be more practically applied.
>
> What if we get super-spec-compliant and allow those extra slashes?
> Well, you'd have to get really (and, IMHO, /overly/) strict about
> how those slashes are treated. In Java, you'd have to do something
> like this :
>
> String path = ... // file-path from request String docRoot = ... //
> docroot base, absolute File file = new File(docRoot, path);
> if(!file.exists()) // return 404
> if(!path.equals(file.getAbsolutePath().substring(docRoot.length()))
>
>
// return 404
>
> That last check will check to make sure that the path requested by
> the client *exactly equals* that of the path on the disk. That
> means that multiple-slashes are essentially forbidden when
> requesting disk-files.
>
> (It gets more fun when you are requesting a directory which has an
> "index file" like index.html and you have to decide whether or not
> it's okay to load that file automatically, even though the client
> didn't specifically request it.)
>
> So now we are spec-compliant. Yay! Except that all those sloppy
> webmasters links no longer work because they do all kinds of weird
> URL manipulations that don't always result in a perfectly-clean
> URL. So we've achieved spec-compliance and inconvenienced users.
> Did we really achieve anything? Those multi-slash URLs were never
> going to work. It is really a big deal to just ... let them work?
> So we collapse slashes and everything is fine. Nobody is really
> going to complain if /foo//bar.html and /foo/bar.html both work
> instead of one of them returning 404.
>
> What about resource that are *not* on a disk? Like servlets and
> stuff like that? Well, the servlet spec allows us to map to URL
> patterns of various types. Some are exact, others prefixes, etc. We
> can also define security constraints with the same kind of
> url-pattern basis. Generally, those things should agree. What
> happens when you introduce multiple-slashes in there?
>
> Well, nobody is ever going to map a bunch of additional slashes to
> make their servlets work properly. So we are back to the same
> problem as the on-disk-file: the multiple-slashes are essentially
> forbidden if we want to be super-spec-compliant. So we relax a
> little and take the practical approach: collapse slashes and move
> on with our lives. This has the added benefit of making security
> constraints more consistent, and fewer mistakes. And encouraging
> fewer security mistakes is a Good Thing.
>
>>>> 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).
>
> Turning it off would be a giant mess. And yes, it needs to be doe
> quite early because Tomcat has to figure out which web application
> will be responding to the request. So it's one of the first things
> that Tomcat has to do with an incoming request.
>
>>>> 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.
>
> Yep: see above. It's a deliberate violation of the spec designed
> to make the world work the way everyone expects it to work, and
> also make security configuration sensible, too.
>
> -chris
>
>>>> On 04.12.2019 15:18, Christopher Schultz wrote: 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.kushagra@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
>>>>>>>>>> < chris@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//heal
thC
>
>>>>>>>>>>>>>
hec
>>>>
>>>>>>>>>>>>>
> 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//healthChe
ck
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>>>>>>>>>
>
>>>>>>>>>
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//hea
lth
>
>>>>>>>>>>>>>>
Che
>>>>
>>>>>>>>>>>>>>
> 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//h
eal
>
>>>>>>>>>>>>>>>>
thC
>>>>
>>>>>>>>>>>>>>>>
> 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</servle
> t-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-cl
ass
>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>
>>>>>>>>
>
>>>>>>>>
<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-na
me>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>>>>
<servlet-class>PatternTemplateLaunchServlet</servlet-class>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>> </servlet>
>>>>>>>>>>>>>>>>> <servlet>
>>>>>>>>>>>>>>>>> <servlet-name>MyReportsLaunchServlet</servlet-name>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>>>>
<servlet-class>MyReportsLaunchServlet</servlet-class>
>>>>>>>>>>>>>>>>> </servlet> <servlet-mapping>
>>>>>>>>>>>>>>>>> <servlet-name>PatternTemplateLaunchServlet</servlet-na
me>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>>>>
<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_u
plo
>
>>>>>>>>>>>>>>>>>>>
ads
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>
> 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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
- ---
>
>>>>>>>>
- -
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>
>>>>>>>>
> ---------------------------------------------------------------------
>>>>>>>>>>>
>
To unsubscribe, e-mail:
>>>>>>>>>>> users-unsubscribe@tomcat.apache.org For
>>>>>>>>>>> additional commands, e-mail:
>>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
- ---
>
>>>>>>>>
- ---
>>>>>>>>
>>>>>>>>
>>>>
>>>>>>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail:
>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
- ---
>>>>>
>>>>>
>
>>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
- --
>>>>
>>>>
>
>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3pUgMACgkQHPApP6U8
pFjBPBAAiN+gtmhGkda/XjigqfJ06IY76r2wr2ICIziG9L4MM2l/eD2uWZ5IBj3D
8E6SzU0Sb/g02kN4bMjGQ/h2rDrkK4wymo+Ax60GtKwOPzdLjmSvsjLAVw3RRy8Y
N2KZ750+sk91A1LdfEhxI+/Y6HdxblW2fKVXENjIGxOxNjLEpYbmoBE8EN/clBWI
fOgeShmG5JirbYPsrRCxuXSWMYFdsuYyN0hg8PPUug1wqmYIbsQzuDzXwjA/cV+Z
GJDQKsHwkmYi2kD2FashsBbD6qAFHTbU0Q0uOaDQPJvjm/pAzp+0HvfS//rBzeUe
0PcmS6TBzb8XVzm2i75lJPpk0WCQI5NcWAabN+H29WNhevNbMy+zERKwCN/ECsAZ
Be3x57WydT5i9MkIYZaRYW/cNR+FpQKh5uSJ7uQuEiYlx1xRy49ugG/gOXX0emS5
YBBRV2KzQvoxH+GB8RpWsJZy5FzTeRi3ubh8MHVED3IT/ukF/nH8FuEasTbRkGhq
7ZNGslZF991JUdS4lLTpeAlE4LxqcbC5AcNAowHOq0KMp0qm32yLwr/c/yAseN6a
gGsK1otDiVz/CxU9PA+TUTrq35HI1NPuGsUGA+V+NI+s3q0S5egpS9mSqRYw7VKW
1OPfy4eymVX793gsvPm7YeJm4QwAAa4bkuqv6GzqYzUVcg5EX6g=
=w5Kn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 ever pops up again.
>
> It maybe even be worth a note somewhere in the main documentation,
> such as where it explains how Tomcat actually maps URLs to webapps.
> Except that I can't locate the documentation which specifically
> explains this.. Maybe this is because Tomcat normally refers to the
> Servlet Spec for this ?
>
> The closest I find is here :
> http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Naming
> Maybe inserting a note to the effect of 'Note: before any of the
> mapping below takes place, Tomcat collapses any consecutive "/"
> characters in the path portion of the URL to a single "/". The
> complete explanation is here : --> FAQ article" '
Sure. Feel free to go ahead and add that.
There may be a place in the security documentation that might be
appropriate to add a reference, too. Like under "security
considerations" or something.
- -chris
> On 05.12.2019 17:13, Christopher Schultz wrote: 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 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).
>
> Actually, it's somewhat in *violation* of the specs. But it's a
> generally-accepted violation because it allows security rules to
> actually remain sane.
>
> If you want to protect "/foo/bar.html" which maps to a file on the
> disk, you'll find that the filesystem collapses slashes and will
> load that same file regardless of how many extra slashes you put in
> there. "/foo////bar.html" is going to give you the same result.
>
> The same is true for multiple levels like "/foo/bar/bar.html". If
> you want to protect all files in "/foo/bar" it's not practical to
> add protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/"
> and ... you see where I'm going with this.
>
> So the server decides that slash-collapsing will allow security
> constraints to be more practically applied.
>
> What if we get super-spec-compliant and allow those extra slashes?
> Well, you'd have to get really (and, IMHO, /overly/) strict about
> how those slashes are treated. In Java, you'd have to do something
> like this :
>
> String path = ... // file-path from request String docRoot = ... //
> docroot base, absolute File file = new File(docRoot, path);
> if(!file.exists()) // return 404
> if(!path.equals(file.getAbsolutePath().substring(docRoot.length()))
>
>
// return 404
>
> That last check will check to make sure that the path requested by
> the client *exactly equals* that of the path on the disk. That
> means that multiple-slashes are essentially forbidden when
> requesting disk-files.
>
> (It gets more fun when you are requesting a directory which has an
> "index file" like index.html and you have to decide whether or not
> it's okay to load that file automatically, even though the client
> didn't specifically request it.)
>
> So now we are spec-compliant. Yay! Except that all those sloppy
> webmasters links no longer work because they do all kinds of weird
> URL manipulations that don't always result in a perfectly-clean
> URL. So we've achieved spec-compliance and inconvenienced users.
> Did we really achieve anything? Those multi-slash URLs were never
> going to work. It is really a big deal to just ... let them work?
> So we collapse slashes and everything is fine. Nobody is really
> going to complain if /foo//bar.html and /foo/bar.html both work
> instead of one of them returning 404.
>
> What about resource that are *not* on a disk? Like servlets and
> stuff like that? Well, the servlet spec allows us to map to URL
> patterns of various types. Some are exact, others prefixes, etc. We
> can also define security constraints with the same kind of
> url-pattern basis. Generally, those things should agree. What
> happens when you introduce multiple-slashes in there?
>
> Well, nobody is ever going to map a bunch of additional slashes to
> make their servlets work properly. So we are back to the same
> problem as the on-disk-file: the multiple-slashes are essentially
> forbidden if we want to be super-spec-compliant. So we relax a
> little and take the practical approach: collapse slashes and move
> on with our lives. This has the added benefit of making security
> constraints more consistent, and fewer mistakes. And encouraging
> fewer security mistakes is a Good Thing.
>
>>>> 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).
>
> Turning it off would be a giant mess. And yes, it needs to be doe
> quite early because Tomcat has to figure out which web application
> will be responding to the request. So it's one of the first things
> that Tomcat has to do with an incoming request.
>
>>>> 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.
>
> Yep: see above. It's a deliberate violation of the spec designed
> to make the world work the way everyone expects it to work, and
> also make security configuration sensible, too.
>
> -chris
>
>>>> On 04.12.2019 15:18, Christopher Schultz wrote: 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.kushagra@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
>>>>>>>>>> < chris@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//heal
thC
>
>>>>>>>>>>>>>
hec
>>>>
>>>>>>>>>>>>>
> 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//healthChe
ck
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>>>>>>>>>
>
>>>>>>>>>
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//hea
lth
>
>>>>>>>>>>>>>>
Che
>>>>
>>>>>>>>>>>>>>
> 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//h
eal
>
>>>>>>>>>>>>>>>>
thC
>>>>
>>>>>>>>>>>>>>>>
> 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</servle
> t-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-cl
ass
>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>
>>>>>>>>
>
>>>>>>>>
<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-na
me>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>>>>
<servlet-class>PatternTemplateLaunchServlet</servlet-class>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>> </servlet>
>>>>>>>>>>>>>>>>> <servlet>
>>>>>>>>>>>>>>>>> <servlet-name>MyReportsLaunchServlet</servlet-name>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>>>>
<servlet-class>MyReportsLaunchServlet</servlet-class>
>>>>>>>>>>>>>>>>> </servlet> <servlet-mapping>
>>>>>>>>>>>>>>>>> <servlet-name>PatternTemplateLaunchServlet</servlet-na
me>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>>>>
<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_u
plo
>
>>>>>>>>>>>>>>>>>>>
ads
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>
>>>>>>>>>>>>>>>>>>>
> 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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
- ---
>
>>>>>>>>
- -
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>
>>>>>>>>
> ---------------------------------------------------------------------
>>>>>>>>>>>
>
To unsubscribe, e-mail:
>>>>>>>>>>> users-unsubscribe@tomcat.apache.org For
>>>>>>>>>>> additional commands, e-mail:
>>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
- ---
>
>>>>>>>>
- ---
>>>>>>>>
>>>>>>>>
>>>>
>>>>>>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail:
>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
- ---
>>>>>
>>>>>
>
>>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
- --
>>>>
>>>>
>
>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3ubnYACgkQHPApP6U8
pFiajA/+IK6qQZDXDZ+keUKKWZnTFJw1OXOKILyMU8RjcvgXJfF10iC1szFLBah0
FtSJNcmKzrkp1kHdnoZguESdK/hcuJrxqOQR3S/D1vCSe3F5fwgEr5ugxwn4Ezzt
NvaEFA11BikotpQJD1t/OdQc4SKL9Y/+Vkz4IhjHHdMZY/NWF55fHsqLVHWf+sMb
AQNpu+te3xHNMD4A8VBiXwaZFejMYoP1gaFXZCfx1GYaFlW+S9O6OnXHuCyWmxr/
//K2RIHv01sIzcBg8MIAFDk9BToOul+41kgiCdSX7YDDPdk6GZUK4xKAn4ad0Bov
iWxuy2nESl6GWfYD+QO2PXuCsPpoF/J1mfzbJqXSJt+aUMpwC4F2cicgfm+Q1ZE/
u3kf5GhxPTC4gUJQFKIqY42PYpsMOD3QOI+JuP5Lklqap3Iy0AX8RUR+kiPbzUTT
tlynVQS/niSQ1pMoSyZIGNxvIW33xPISFXIrw0fgaGtjKx7pmVNky+GIKbF/dsjU
6moR3vcdYlxaSmwlZyXVElHspHFdg/KnIDShY3doYtxBpAYGErmHRyCY67A2h0pS
lvA1iPejUDY6Tp9o88ONthscmpXytcYIIhkisGpSn/X9ST3WSNwGNgVJPGqQ1Vr2
IL3h+klcmSiO6gMel2lOhQsGtPVRDuSgNw+BbWBs5v2XEgC5KYw=
=x7s7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Kushagra Bindal <bi...@gmail.com>.
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 // pattern on 8.5.24 version tomcat with nginx on top of it.
Please do let me know if possible option is available for this.
On Thu, Dec 5, 2019, 9:44 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----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 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).
>
> Actually, it's somewhat in *violation* of the specs. But it's a
> generally-accepted violation because it allows security rules to
> actually remain sane.
>
> If you want to protect "/foo/bar.html" which maps to a file on the
> disk, you'll find that the filesystem collapses slashes and will load
> that same file regardless of how many extra slashes you put in there.
> "/foo////bar.html" is going to give you the same result.
>
> The same is true for multiple levels like "/foo/bar/bar.html". If you
> want to protect all files in "/foo/bar" it's not practical to add
> protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/" and ...
> you see where I'm going with this.
>
> So the server decides that slash-collapsing will allow security
> constraints to be more practically applied.
>
> What if we get super-spec-compliant and allow those extra slashes?
> Well, you'd have to get really (and, IMHO, /overly/) strict about how
> those slashes are treated. In Java, you'd have to do something like this
> :
>
> String path = ... // file-path from request
> String docRoot = ... // docroot base, absolute
> File file = new File(docRoot, path);
> if(!file.exists())
> // return 404
> if(!path.equals(file.getAbsolutePath().substring(docRoot.length()))
> // return 404
>
> That last check will check to make sure that the path requested by the
> client *exactly equals* that of the path on the disk. That means that
> multiple-slashes are essentially forbidden when requesting disk-files.
>
> (It gets more fun when you are requesting a directory which has an
> "index file" like index.html and you have to decide whether or not
> it's okay to load that file automatically, even though the client
> didn't specifically request it.)
>
> So now we are spec-compliant. Yay! Except that all those sloppy
> webmasters links no longer work because they do all kinds of weird URL
> manipulations that don't always result in a perfectly-clean URL. So
> we've achieved spec-compliance and inconvenienced users. Did we really
> achieve anything? Those multi-slash URLs were never going to work. It
> is really a big deal to just ... let them work? So we collapse slashes
> and everything is fine. Nobody is really going to complain if
> /foo//bar.html and /foo/bar.html both work instead of one of them
> returning 404.
>
> What about resource that are *not* on a disk? Like servlets and stuff
> like that? Well, the servlet spec allows us to map to URL patterns of
> various types. Some are exact, others prefixes, etc. We can also
> define security constraints with the same kind of url-pattern basis.
> Generally, those things should agree. What happens when you introduce
> multiple-slashes in there?
>
> Well, nobody is ever going to map a bunch of additional slashes to
> make their servlets work properly. So we are back to the same problem
> as the on-disk-file: the multiple-slashes are essentially forbidden if
> we want to be super-spec-compliant. So we relax a little and take the
> practical approach: collapse slashes and move on with our lives. This
> has the added benefit of making security constraints more consistent,
> and fewer mistakes. And encouraging fewer security mistakes is a Good
> Thing.
>
> > 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).
>
> Turning it off would be a giant mess. And yes, it needs to be doe
> quite early because Tomcat has to figure out which web application
> will be responding to the request. So it's one of the first things
> that Tomcat has to do with an incoming request.
>
> > 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.
>
> Yep: see above. It's a deliberate violation of the spec designed to
> make the world work the way everyone expects it to work, and also make
> security configuration sensible, too.
>
> - -chris
>
> > On 04.12.2019 15:18, Christopher Schultz wrote: 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.kushagra@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 <
> >>>>>>> chris@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//healthC
> hec
> >
> >>>>>>>>>>
> 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//health
> Che
> >
> >>>>>>>>>>>
> 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//heal
> thC
> >
> >>>>>>>>>>>>>
> 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</servle
> t-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_uplo
> ads
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>
> >>>>>>>>>>>>>>>>
> >
> >>>>>>>>>>>>>>>>
> 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-unsubscribe@tomcat.apache.org
> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>>> users-help@tomcat.apache.org
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>> ------------------------------------------------------------------
> - -
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >
> >>>>>
> - ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail:
> >>>>>>>> users-unsubscribe@tomcat.apache.org For additional
> >>>>>>>> commands, e-mail: users-help@tomcat.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> - ---
> >>>>>
> >>>>>
> >
> >>>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail:
> >>>>> users-help@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3pLLwACgkQHPApP6U8
> pFhJBA//XZXoK7Yd01UBtUBSrji4l2lwCiT8pxh9YGvWd6FOs3SVpTyoNg1EVxqZ
> JCeBzFeYIjOouA8FyXbOZO6olSi/B6SP/yNPtchgYQnCTloGKrH3Og1t46ZdfpgZ
> 408ay/UpIZJAOZTPjtnXYLmgwNgm79xR82+sOb/LK6tSk0ujzDryEuMG/QECvulM
> NsGl/PXVo5WBlvHoj3L7WgcMAx7hnmBWBr1SLdnGi0a/ZlgzGYriH9LLaSfOjIyc
> y2lmij9uAzwiiCe46+bQJ3YHxm4m+/39jFizJj+WhE/f8ecj3vxLcBoAwaruQRXW
> b65/fzPRfpGA+mUapFTh5S2+KS8YWhbABdfLL1Du6RDIhmEFTa2SkMs/Qpo9bAlY
> fYuVeuwudIQrXingp+uRFhMMbbyzFd6U89pktf3k3wBLfazOnB5csMOwPcE1jlq2
> TGcjiLq6PwnfSeAKhCEQHzgLOyXIM0izsd0nkRvAC5YuuhVN6vqetma8wvMsvoVD
> kaPQwKdRXHjoydLF9z4GaKRO97yeC9EP+vHQhXjrQqWe1HO4q06xL8EwpxTU46T+
> qqXRLtvEJrdKfOaiVK0E+it9Rh5uSSKjzW79qVzuQ5H59Lb4fJm0BsKc0nI2bgfu
> wkTazYm8SJ0ziZs/ElCpUKgLG5WChRiSDFowUEnM35U7+1T6H4U=
> =Fh+F
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Double Slash Support in Tomcat 9.0.27
Posted by "André Warnier (tomcat/perl)" <aw...@ice-sa.com>.
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 Tomcat actually maps URLs to webapps. Except that I can't locate the
documentation which specifically explains this..
Maybe this is because Tomcat normally refers to the Servlet Spec for this ?
The closest I find is here :
http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Naming
Maybe inserting a note to the effect of 'Note: before any of the mapping below takes
place, Tomcat collapses any consecutive "/" characters in the path portion of the URL to a
single "/". The complete explanation is here : --> FAQ article" '
On 05.12.2019 17:13, Christopher Schultz wrote:
> -----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 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).
>
> Actually, it's somewhat in *violation* of the specs. But it's a
> generally-accepted violation because it allows security rules to
> actually remain sane.
>
> If you want to protect "/foo/bar.html" which maps to a file on the
> disk, you'll find that the filesystem collapses slashes and will load
> that same file regardless of how many extra slashes you put in there.
> "/foo////bar.html" is going to give you the same result.
>
> The same is true for multiple levels like "/foo/bar/bar.html". If you
> want to protect all files in "/foo/bar" it's not practical to add
> protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/" and ...
> you see where I'm going with this.
>
> So the server decides that slash-collapsing will allow security
> constraints to be more practically applied.
>
> What if we get super-spec-compliant and allow those extra slashes?
> Well, you'd have to get really (and, IMHO, /overly/) strict about how
> those slashes are treated. In Java, you'd have to do something like this
> :
>
> String path = ... // file-path from request
> String docRoot = ... // docroot base, absolute
> File file = new File(docRoot, path);
> if(!file.exists())
> // return 404
> if(!path.equals(file.getAbsolutePath().substring(docRoot.length()))
> // return 404
>
> That last check will check to make sure that the path requested by the
> client *exactly equals* that of the path on the disk. That means that
> multiple-slashes are essentially forbidden when requesting disk-files.
>
> (It gets more fun when you are requesting a directory which has an
> "index file" like index.html and you have to decide whether or not
> it's okay to load that file automatically, even though the client
> didn't specifically request it.)
>
> So now we are spec-compliant. Yay! Except that all those sloppy
> webmasters links no longer work because they do all kinds of weird URL
> manipulations that don't always result in a perfectly-clean URL. So
> we've achieved spec-compliance and inconvenienced users. Did we really
> achieve anything? Those multi-slash URLs were never going to work. It
> is really a big deal to just ... let them work? So we collapse slashes
> and everything is fine. Nobody is really going to complain if
> /foo//bar.html and /foo/bar.html both work instead of one of them
> returning 404.
>
> What about resource that are *not* on a disk? Like servlets and stuff
> like that? Well, the servlet spec allows us to map to URL patterns of
> various types. Some are exact, others prefixes, etc. We can also
> define security constraints with the same kind of url-pattern basis.
> Generally, those things should agree. What happens when you introduce
> multiple-slashes in there?
>
> Well, nobody is ever going to map a bunch of additional slashes to
> make their servlets work properly. So we are back to the same problem
> as the on-disk-file: the multiple-slashes are essentially forbidden if
> we want to be super-spec-compliant. So we relax a little and take the
> practical approach: collapse slashes and move on with our lives. This
> has the added benefit of making security constraints more consistent,
> and fewer mistakes. And encouraging fewer security mistakes is a Good
> Thing.
>
>> 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).
>
> Turning it off would be a giant mess. And yes, it needs to be doe
> quite early because Tomcat has to figure out which web application
> will be responding to the request. So it's one of the first things
> that Tomcat has to do with an incoming request.
>
>> 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.
>
> Yep: see above. It's a deliberate violation of the spec designed to
> make the world work the way everyone expects it to work, and also make
> security configuration sensible, too.
>
> - -chris
>
>> On 04.12.2019 15:18, Christopher Schultz wrote: 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.kushagra@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 <
>>>>>>>> chris@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//healthC
> hec
>>
>>>>>>>>>>>
> 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//health
> Che
>>
>>>>>>>>>>>>
> 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//heal
> thC
>>
>>>>>>>>>>>>>>
> 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</servle
> t-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_uplo
> ads
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>>
>>
>>>>>>>>>>>>>>>>>
> 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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> ------------------------------------------------------------------
> - -
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>
>>>>>>
> - ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@tomcat.apache.org For additional
>>>>>>>>> commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
> - ---
>>>>>>
>>>>>>
>>
>>>>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3pLLwACgkQHPApP6U8
> pFhJBA//XZXoK7Yd01UBtUBSrji4l2lwCiT8pxh9YGvWd6FOs3SVpTyoNg1EVxqZ
> JCeBzFeYIjOouA8FyXbOZO6olSi/B6SP/yNPtchgYQnCTloGKrH3Og1t46ZdfpgZ
> 408ay/UpIZJAOZTPjtnXYLmgwNgm79xR82+sOb/LK6tSk0ujzDryEuMG/QECvulM
> NsGl/PXVo5WBlvHoj3L7WgcMAx7hnmBWBr1SLdnGi0a/ZlgzGYriH9LLaSfOjIyc
> y2lmij9uAzwiiCe46+bQJ3YHxm4m+/39jFizJj+WhE/f8ecj3vxLcBoAwaruQRXW
> b65/fzPRfpGA+mUapFTh5S2+KS8YWhbABdfLL1Du6RDIhmEFTa2SkMs/Qpo9bAlY
> fYuVeuwudIQrXingp+uRFhMMbbyzFd6U89pktf3k3wBLfazOnB5csMOwPcE1jlq2
> TGcjiLq6PwnfSeAKhCEQHzgLOyXIM0izsd0nkRvAC5YuuhVN6vqetma8wvMsvoVD
> kaPQwKdRXHjoydLF9z4GaKRO97yeC9EP+vHQhXjrQqWe1HO4q06xL8EwpxTU46T+
> qqXRLtvEJrdKfOaiVK0E+it9Rh5uSSKjzW79qVzuQ5H59Lb4fJm0BsKc0nI2bgfu
> wkTazYm8SJ0ziZs/ElCpUKgLG5WChRiSDFowUEnM35U7+1T6H4U=
> =Fh+F
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 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).
Actually, it's somewhat in *violation* of the specs. But it's a
generally-accepted violation because it allows security rules to
actually remain sane.
If you want to protect "/foo/bar.html" which maps to a file on the
disk, you'll find that the filesystem collapses slashes and will load
that same file regardless of how many extra slashes you put in there.
"/foo////bar.html" is going to give you the same result.
The same is true for multiple levels like "/foo/bar/bar.html". If you
want to protect all files in "/foo/bar" it's not practical to add
protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/" and ...
you see where I'm going with this.
So the server decides that slash-collapsing will allow security
constraints to be more practically applied.
What if we get super-spec-compliant and allow those extra slashes?
Well, you'd have to get really (and, IMHO, /overly/) strict about how
those slashes are treated. In Java, you'd have to do something like this
:
String path = ... // file-path from request
String docRoot = ... // docroot base, absolute
File file = new File(docRoot, path);
if(!file.exists())
// return 404
if(!path.equals(file.getAbsolutePath().substring(docRoot.length()))
// return 404
That last check will check to make sure that the path requested by the
client *exactly equals* that of the path on the disk. That means that
multiple-slashes are essentially forbidden when requesting disk-files.
(It gets more fun when you are requesting a directory which has an
"index file" like index.html and you have to decide whether or not
it's okay to load that file automatically, even though the client
didn't specifically request it.)
So now we are spec-compliant. Yay! Except that all those sloppy
webmasters links no longer work because they do all kinds of weird URL
manipulations that don't always result in a perfectly-clean URL. So
we've achieved spec-compliance and inconvenienced users. Did we really
achieve anything? Those multi-slash URLs were never going to work. It
is really a big deal to just ... let them work? So we collapse slashes
and everything is fine. Nobody is really going to complain if
/foo//bar.html and /foo/bar.html both work instead of one of them
returning 404.
What about resource that are *not* on a disk? Like servlets and stuff
like that? Well, the servlet spec allows us to map to URL patterns of
various types. Some are exact, others prefixes, etc. We can also
define security constraints with the same kind of url-pattern basis.
Generally, those things should agree. What happens when you introduce
multiple-slashes in there?
Well, nobody is ever going to map a bunch of additional slashes to
make their servlets work properly. So we are back to the same problem
as the on-disk-file: the multiple-slashes are essentially forbidden if
we want to be super-spec-compliant. So we relax a little and take the
practical approach: collapse slashes and move on with our lives. This
has the added benefit of making security constraints more consistent,
and fewer mistakes. And encouraging fewer security mistakes is a Good
Thing.
> 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).
Turning it off would be a giant mess. And yes, it needs to be doe
quite early because Tomcat has to figure out which web application
will be responding to the request. So it's one of the first things
that Tomcat has to do with an incoming request.
> 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.
Yep: see above. It's a deliberate violation of the spec designed to
make the world work the way everyone expects it to work, and also make
security configuration sensible, too.
- -chris
> On 04.12.2019 15:18, Christopher Schultz wrote: 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.kushagra@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 <
>>>>>>> chris@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//healthC
hec
>
>>>>>>>>>>
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//health
Che
>
>>>>>>>>>>>
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//heal
thC
>
>>>>>>>>>>>>>
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</servle
t-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_uplo
ads
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>
>
>>>>>>>>>>>>>>>>
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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> ------------------------------------------------------------------
- -
>>>>>>>>
>>>>>>>>
>>>>>
>
>>>>>
- ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> users-unsubscribe@tomcat.apache.org For additional
>>>>>>>> commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
- ---
>>>>>
>>>>>
>
>>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3pLLwACgkQHPApP6U8
pFhJBA//XZXoK7Yd01UBtUBSrji4l2lwCiT8pxh9YGvWd6FOs3SVpTyoNg1EVxqZ
JCeBzFeYIjOouA8FyXbOZO6olSi/B6SP/yNPtchgYQnCTloGKrH3Og1t46ZdfpgZ
408ay/UpIZJAOZTPjtnXYLmgwNgm79xR82+sOb/LK6tSk0ujzDryEuMG/QECvulM
NsGl/PXVo5WBlvHoj3L7WgcMAx7hnmBWBr1SLdnGi0a/ZlgzGYriH9LLaSfOjIyc
y2lmij9uAzwiiCe46+bQJ3YHxm4m+/39jFizJj+WhE/f8ecj3vxLcBoAwaruQRXW
b65/fzPRfpGA+mUapFTh5S2+KS8YWhbABdfLL1Du6RDIhmEFTa2SkMs/Qpo9bAlY
fYuVeuwudIQrXingp+uRFhMMbbyzFd6U89pktf3k3wBLfazOnB5csMOwPcE1jlq2
TGcjiLq6PwnfSeAKhCEQHzgLOyXIM0izsd0nkRvAC5YuuhVN6vqetma8wvMsvoVD
kaPQwKdRXHjoydLF9z4GaKRO97yeC9EP+vHQhXjrQqWe1HO4q06xL8EwpxTU46T+
qqXRLtvEJrdKfOaiVK0E+it9Rh5uSSKjzW79qVzuQ5H59Lb4fJm0BsKc0nI2bgfu
wkTazYm8SJ0ziZs/ElCpUKgLG5WChRiSDFowUEnM35U7+1T6H4U=
=Fh+F
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by "André Warnier (tomcat/perl)" <aw...@ice-sa.com>.
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.kushagra@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 <
>>>>> chris@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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>> -------------------------------------------------------------------
>>>>>>
>>>>>>
>>>
> - ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> users-unsubscribe@tomcat.apache.org For additional
>>>>>> commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Kushagra Bindal <bi...@gmail.com>.
Thanks
On Wed, Dec 4, 2019, 5:20 PM Mark Thomas <ma...@apache.org> 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 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.kushagra@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 <
> >>>> chris@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-unsubscribe@tomcat.apache.org
> >>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>> users-help@tomcat.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >> -------------------------------------------------------------------
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>>
> >>>>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Double Slash Support in Tomcat 9.0.27
Posted by Mark Thomas <ma...@apache.org>.
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.kushagra@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 <
>>>> chris@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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>> -------------------------------------------------------------------
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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.kushagra@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 <
>>>> chris@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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>> -------------------------------------------------------------------
>>>>>
>>>>>
>>
- ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> users-unsubscribe@tomcat.apache.org For additional
>>>>> commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Kushagra Bindal <bi...@gmail.com>.
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 <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.kushagra@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 <
> >> chris@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-unsubscribe@tomcat.apache.org
> >>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>> users-help@tomcat.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> -------------------------------------------------------------------
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Regards,
Kushagra Bindal
+91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
Posted by Mark Thomas <ma...@apache.org>.
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 <bi...@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 <
>> chris@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-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Kushagra Bindal <bi...@gmail.com>.
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 <bi...@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 <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> 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-unsubscribe@tomcat.apache.org
>> >>>>>> For additional commands, e-mail:
>> >>>>>> users-help@tomcat.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> -------------------------------------------------------------------
>> - --
>> >>>>
>> >>>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> >>>> For additional commands, e-mail:
>> >>>> users-help@tomcat.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> >> For additional commands, e-mail: users-help@tomcat.apache.org
>> >>
>> >>
>> >
>> -----BEGIN PGP SIGNATURE-----
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3lazUACgkQHPApP6U8
>> pFj62hAAsXJM1uwsodox5AeVs6UCs1/uuUxHatmnd4LpKJzoHq8u2OEBNkUHEY/8
>> 46dJ/RtGBRcsgqA/sopbYjELtKUAwQPPKDEiD5DlpCg2ksyE75bTPb49PcO5a880
>> b2dyYAsfxpccApUXsTGasXriR0Mis/W7E1rqUy6TY7qo/PXVWR5bLFxc540+iEjf
>> Zuwi0l4cg43d2R8NABbsN7HQWu7rDBFJkeXWpVc5QXy/XdAkIgkgsBux1QaOcZgG
>> yf9saKknAwBqgMzPRvMEh6h4Lio/LRd1ido1M52X7Hqeuw7Kj9zzcnCF85LRZ73n
>> hkHUrMVvi++AELLzr+WhFSduJxrdtAfnRlXu7zYt6CfzxETu+t3g5c83/fF5QzDZ
>> nwdAKRmSPEMmVM8eczCrsYbFpITJjR71pRopFIKmJhrran6hFAn5vIUE5ay9QEv+
>> JUQqf9lrL5gQYUdaNqsAMe+JqYeiNLy8x/8y5qrUk/Jb2FtDx6yoJAUi9mFO/mCC
>> BsmnjEOE1TB9rylCzcSmHzJP6rYnd6pqoyCiq4NNAeaQBysIHKUwMWqMEEPrszED
>> P6MwKUUdzRuzX+SrLeRaIzqByRUzYtOuMP5IMPCB8tP2VE8R0J2txYyH2TMlBZgy
>> ZbcS3VB+kyz2RlX34bIN8gJZz7RQiSlATao0ux9A96KTbqMSIQs=
>> =c9w2
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
--
Regards,
Kushagra Bindal
+91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
Posted by Kushagra Bindal <bi...@gmail.com>.
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 <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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-unsubscribe@tomcat.apache.org
> >>>>>> For additional commands, e-mail:
> >>>>>> users-help@tomcat.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> - --
> >>>>
> >>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail:
> >>>> users-help@tomcat.apache.org
> >>>>
> >>>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3lazUACgkQHPApP6U8
> pFj62hAAsXJM1uwsodox5AeVs6UCs1/uuUxHatmnd4LpKJzoHq8u2OEBNkUHEY/8
> 46dJ/RtGBRcsgqA/sopbYjELtKUAwQPPKDEiD5DlpCg2ksyE75bTPb49PcO5a880
> b2dyYAsfxpccApUXsTGasXriR0Mis/W7E1rqUy6TY7qo/PXVWR5bLFxc540+iEjf
> Zuwi0l4cg43d2R8NABbsN7HQWu7rDBFJkeXWpVc5QXy/XdAkIgkgsBux1QaOcZgG
> yf9saKknAwBqgMzPRvMEh6h4Lio/LRd1ido1M52X7Hqeuw7Kj9zzcnCF85LRZ73n
> hkHUrMVvi++AELLzr+WhFSduJxrdtAfnRlXu7zYt6CfzxETu+t3g5c83/fF5QzDZ
> nwdAKRmSPEMmVM8eczCrsYbFpITJjR71pRopFIKmJhrran6hFAn5vIUE5ay9QEv+
> JUQqf9lrL5gQYUdaNqsAMe+JqYeiNLy8x/8y5qrUk/Jb2FtDx6yoJAUi9mFO/mCC
> BsmnjEOE1TB9rylCzcSmHzJP6rYnd6pqoyCiq4NNAeaQBysIHKUwMWqMEEPrszED
> P6MwKUUdzRuzX+SrLeRaIzqByRUzYtOuMP5IMPCB8tP2VE8R0J2txYyH2TMlBZgy
> ZbcS3VB+kyz2RlX34bIN8gJZz7RQiSlATao0ux9A96KTbqMSIQs=
> =c9w2
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Double Slash Support in Tomcat 9.0.27
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
- --
>>>>
>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3lazUACgkQHPApP6U8
pFj62hAAsXJM1uwsodox5AeVs6UCs1/uuUxHatmnd4LpKJzoHq8u2OEBNkUHEY/8
46dJ/RtGBRcsgqA/sopbYjELtKUAwQPPKDEiD5DlpCg2ksyE75bTPb49PcO5a880
b2dyYAsfxpccApUXsTGasXriR0Mis/W7E1rqUy6TY7qo/PXVWR5bLFxc540+iEjf
Zuwi0l4cg43d2R8NABbsN7HQWu7rDBFJkeXWpVc5QXy/XdAkIgkgsBux1QaOcZgG
yf9saKknAwBqgMzPRvMEh6h4Lio/LRd1ido1M52X7Hqeuw7Kj9zzcnCF85LRZ73n
hkHUrMVvi++AELLzr+WhFSduJxrdtAfnRlXu7zYt6CfzxETu+t3g5c83/fF5QzDZ
nwdAKRmSPEMmVM8eczCrsYbFpITJjR71pRopFIKmJhrran6hFAn5vIUE5ay9QEv+
JUQqf9lrL5gQYUdaNqsAMe+JqYeiNLy8x/8y5qrUk/Jb2FtDx6yoJAUi9mFO/mCC
BsmnjEOE1TB9rylCzcSmHzJP6rYnd6pqoyCiq4NNAeaQBysIHKUwMWqMEEPrszED
P6MwKUUdzRuzX+SrLeRaIzqByRUzYtOuMP5IMPCB8tP2VE8R0J2txYyH2TMlBZgy
ZbcS3VB+kyz2RlX34bIN8gJZz7RQiSlATao0ux9A96KTbqMSIQs=
=c9w2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Kushagra Bindal <bi...@gmail.com>.
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.
Regards
Kushagra
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-class>
> >>> <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-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>
> >>>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Regards,
Kushagra Bindal
+91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
Posted by Mark Thomas <ma...@apache.org>.
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-class>
>>> <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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Kushagra Bindal <bi...@gmail.com>.
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 <bi...@gmail.com>
wrote:
> 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 <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-class>
>> > <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-unsubscribe@tomcat.apache.org
>> >> For additional commands, e-mail: users-help@tomcat.apache.org
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>
Re: Double Slash Support in Tomcat 9.0.27
Posted by Kushagra Bindal <bi...@gmail.com>.
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 <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-class>
> > <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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Regards,
Kushagra Bindal
+91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
Posted by Mark Thomas <ma...@apache.org>.
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-class>
> <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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Posted by Kushagra Bindal <bi...@gmail.com>.
Hi Mark,
Please find the snippet from web.xml
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Regards,
Kushagra Bindal
+91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org