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 < ch...@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.kusha...@gmail.com> > >>>>>> wrote: > >>>>>> > >>>>>>> Chris, > >>>>>>> > >>>>>>> If you will check in my early email then you will find > >>>>>>> that with // it > >>>>> is > >>>>>>> throwing 404. But as soon as I removed it manually then > >>>>>>> it starts > >>>>> working > >>>>>>> properly and all these url were working fine in 8.5.24 > >>>>>>> version. > >>>>>>> > >>>>>>> On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz < > >>>>>>> ch...@christopherschultz.net> wrote: > >>>>>>> > >>>>>> Kushagra, > >>>>>> > >>>>>> On 12/2/19 11:29, Kushagra Bindal wrote: > >>>>>>>>>> I think it should be. > >>>>>>>>>> > >>>>>>>>>> <filter> > >>>>>>>>>> <description>DanglingSessionInvalidateFilter</description> > >>>>>>>>>> > >>>>>>>>>> > > > >>>>>>>>>> > <filter-name>DanglingSessionInvalidateFilter</filter-name> > >>>>>>>>>> <filter-class>com.SessionInvalidateFilter</filter-class> > >>>>>>>>>> > >>>>>>>>>> > </filter> <filter-mapping> > >>>>>>>>>> <filter-name>DanglingSessionInvalidateFilter</filter-name> > >>>>>>>>>> > >>>>>>>>>> > > > >>>>>>>>>> > <url-pattern>/restcall/*</url-pattern> </filter-mapping> > >>>>>>>>>> > >>>>>>>>>> Here in below URL: > >>>>>>>>>> > >>>>>>>>>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//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-unsubscr...@tomcat.apache.org > >>>>>>>>>>>>>>> For additional commands, e-mail: > >>>>>>>>>>>>>>> users-h...@tomcat.apache.org > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>> ------------------------------------------------------------------ > - - > >>>>>>>> > >>>>>>>> > >>>>> > > > >>>>> > - --------------------------------------------------------------------- > >>>>>>>> To unsubscribe, e-mail: > >>>>>>>> users-unsubscr...@tomcat.apache.org For additional > >>>>>>>> commands, e-mail: users-h...@tomcat.apache.org > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------ > - --- > >>>>> > >>>>> > > > >>>>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>>> For additional commands, e-mail: > >>>>> users-h...@tomcat.apache.org > >>>>> > >>>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
