Re: Double Slash Support in Tomcat 9.0.27
-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. "/foobar.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
Re: Double Slash Support in Tomcat 9.0.27
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. "/foobar.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
Re: Double Slash Support in Tomcat 9.0.27
-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 < > ch...@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. "/foobar.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
Re: Double Slash Support in Tomcat 9.0.27
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. > "/foobar.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 > >
Re: Double Slash Support in Tomcat 9.0.27
-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. "/foobar.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
Re: Double Slash Support in Tomcat 9.0.27
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 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 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. DanglingSessionInvalidateFilter DanglingSessionInvalidateFilter com.SessionInvalidateFilter DanglingSessionInvalidateFilter /restcall/* 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 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.
Re: Double Slash Support in Tomcat 9.0.27
Thanks On Wed, Dec 4, 2019, 5:20 PM Mark Thomas wrote: > On 04/12/2019 11:32, Kushagra Bindal wrote: > > Hi Mark, > > > > I am not saying that this is a tomcat issue, I am just asking if there > is a > > way by which we can handle this. As maybe in later version of 8.5.24 > Tomcat > > has take 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 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. > >>> > >>> > >>> DanglingSessionInvalidateFilter > >>> DanglingSessionInvalidateFilter > >>> com.SessionInvalidateFilter > >>> > >>> DanglingSessionInvalidateFilter > >>> /restcall/* > >>> > >>> 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 > >>> 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 > > 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 > >> > >> > >>> > >>> default > >>> > >>> > >> > > >> org.apache.catalina.servlets.DefaultServlet >>> lass> > >>> > > >>> > >>> debug > >>> 0 > >>> listings > >>> false > >>> 1 > >>> jsp > >>> > >> > >> org.apache.jasper.servlet.JspServlet > >>> > >> > >>> > >>> fork > >>> false > >>> xpoweredBy >
Re: Double Slash Support in Tomcat 9.0.27
-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 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 > 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. >>> >>> >>> DanglingSessionInvalidateFilter >>> >>> DanglingSessionInvalidateFilter >>> com.SessionInvalidateFilter >>> >>> DanglingSessionInvalidateFilter >>> >>> /restcall/* >>> >>> 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 >>> 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 > 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 >> >> >>> >>> default >>> >>>
Re: Double Slash Support in Tomcat 9.0.27
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 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. >>> >>> >>> DanglingSessionInvalidateFilter >>> DanglingSessionInvalidateFilter >>> com.SessionInvalidateFilter >>> >>> DanglingSessionInvalidateFilter >>> /restcall/* >>> >>> 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 >>> 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 > 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 >> >> >>> >>> default >>> >>> >> >> org.apache.catalina.servlets.DefaultServlet>> lass> >>> >>> >>> debug >>> 0 >>> listings >>> false >>> 1 >>> jsp >>> >> >> org.apache.jasper.servlet.JspServlet >>> >> >>> >>> fork >>> false >>> xpoweredBy >>> false >>> 3 >>> default >>> / >>> jsp >>> *.jsp >>> *.jspx >>> >>> PatternTemplateLaunchServlet >>> PatternTemplateLaunchServlet >>> >>> >>> >>> >>> MyReportsLaunchServlet >>> MyReportsLaunchServlet >>> >>> PatternTemplateLaunchServlet >>>
Re: Double Slash Support in Tomcat 9.0.27
Hi Mark, I am not saying that this is a tomcat issue, I am just asking if there is a way by which we can handle this. As maybe in later version of 8.5.24 Tomcat has take some action to handle such conditions. On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas wrote: > On 04/12/2019 05:16, Kushagra 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. > > > > > > DanglingSessionInvalidateFilter > > DanglingSessionInvalidateFilter > > com.SessionInvalidateFilter > > > > DanglingSessionInvalidateFilter > > /restcall/* > > > > 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 > > 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 > >>> 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 > > > > > > default > > > > > > >> > org.apache.catalina.servlets.DefaultServlet > lass> > > > >> > > > > debug > > 0 > > listings > > false > > 1 > > jsp > > > > org.apache.jasper.servlet.JspServlet > > > > > > > fork > > false > > xpoweredBy > > false > > 3 > > default > > / > > jsp > > *.jsp > > *.jspx > > > > PatternTemplateLaunchServlet > > PatternTemplateLaunchServlet > > > > > > > > > > MyReportsLaunchServlet > > MyReportsLaunchServlet > > > > PatternTemplateLaunchServlet > > /patterntemplatelaunch > > > > MyReportsLaunchServlet > > /MyReportsLaunchServlet > > > > > > Please let me know if you need anyother details from our > > side. >
Re: Double Slash Support in Tomcat 9.0.27
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 > 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. > > > DanglingSessionInvalidateFilter > DanglingSessionInvalidateFilter > com.SessionInvalidateFilter > > DanglingSessionInvalidateFilter > /restcall/* > > 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 > 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 >>> 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 > > default > > >> org.apache.catalina.servlets.DefaultServlet lass> > >> > > debug > 0 > listings > false > 1 > jsp > org.apache.jasper.servlet.JspServlet > > > fork > false > xpoweredBy > false > 3 > default > / > jsp > *.jsp > *.jspx > > PatternTemplateLaunchServlet > PatternTemplateLaunchServlet > > > > > MyReportsLaunchServlet > MyReportsLaunchServlet > > PatternTemplateLaunchServlet > /patterntemplatelaunch > > MyReportsLaunchServlet > /MyReportsLaunchServlet > > > Please let me know if you need anyother details from our > side. > > On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas > 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
Re: Double Slash Support in Tomcat 9.0.27
Hi Mark/Manna/Chris, Do we have any way out to handle this type of behavior? On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal wrote: > Chris, > > If you will check in my early email then you will find that with // it is > throwing 404. But as soon as I removed it manually then it starts working > 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: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Kushagra, >> >> On 12/2/19 11:29, Kushagra Bindal wrote: >> > I think it should be. >> > >> > >> > DanglingSessionInvalidateFilter >> > DanglingSessionInvalidateFilter >> > com.SessionInvalidateFilter >> > >> > DanglingSessionInvalidateFilter >> > /restcall/* >> > >> > Here 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 >> > 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 >> >>> 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 >> >> >> > >> > default >> > >> > >> >> >> org.apache.catalina.servlets.DefaultServlet> lass> >> > >> >> >> >> > debug >> > 0 >> > listings >> > false >> > 1 >> > jsp >> > >> org.apache.jasper.servlet.JspServlet >> > >> >> >> > fork >> > false >> > xpoweredBy >> > false >> > 3 >> > default >> > / >> > jsp >> > *.jsp >> > *.jspx >> > >> > PatternTemplateLaunchServlet >> > PatternTemplateLaunchServlet >> > >> > >> >> > >> > MyReportsLaunchServlet >> > MyReportsLaunchServlet >> > >> > PatternTemplateLaunchServlet >> > /patterntemplatelaunch >> > >> > MyReportsLaunchServlet >> > /MyReportsLaunchServlet >> > >> > >> > Please let me know if you need anyother details from our >> > side. >> > >> > On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas >> > 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
Re: Double Slash Support in Tomcat 9.0.27
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: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Kushagra, > > On 12/2/19 11:29, Kushagra Bindal wrote: > > I think it should be. > > > > > > DanglingSessionInvalidateFilter > > DanglingSessionInvalidateFilter > > com.SessionInvalidateFilter > > > > DanglingSessionInvalidateFilter > > /restcall/* > > > > Here 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 > > 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 > >>> 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 > > > > > > default > > > > > > >> org.apache.catalina.servlets.DefaultServlet lass> > > > >> > > > debug > > 0 > > listings > > false > > 1 > > jsp > > > org.apache.jasper.servlet.JspServlet > > > > > > fork > > false > > xpoweredBy > > false > > 3 > > default > > / > > jsp > > *.jsp > > *.jspx > > > > PatternTemplateLaunchServlet > > PatternTemplateLaunchServlet > > > > > > > > > MyReportsLaunchServlet > > MyReportsLaunchServlet > > > > PatternTemplateLaunchServlet > > /patterntemplatelaunch > > > > MyReportsLaunchServlet > > /MyReportsLaunchServlet > > > > > > Please let me know if you need anyother details from our > > side. > > > > On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas > > 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 > >> for the servlet you expect it to match to > >> > >> Mark > >> > >> - > - > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail:
Re: Double Slash Support in Tomcat 9.0.27
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kushagra, On 12/2/19 11:29, Kushagra Bindal wrote: > I think it should be. > > > DanglingSessionInvalidateFilter > DanglingSessionInvalidateFilter > com.SessionInvalidateFilter > > DanglingSessionInvalidateFilter > /restcall/* > > Here 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 > 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 >>> 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 > > default > > >> org.apache.catalina.servlets.DefaultServlet > >> > debug > 0 > listings > false > 1 > jsp > org.apache.jasper.servlet.JspServlet > > fork > false > xpoweredBy > false > 3 > default > / > jsp > *.jsp > *.jspx > > PatternTemplateLaunchServlet > PatternTemplateLaunchServlet > > > > MyReportsLaunchServlet > MyReportsLaunchServlet > > PatternTemplateLaunchServlet > /patterntemplatelaunch > > MyReportsLaunchServlet > /MyReportsLaunchServlet > > > Please let me know if you need anyother details from our > side. > > On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas > 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 >> 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 >> >> > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird -
Re: Double Slash Support in Tomcat 9.0.27
I think it should be. DanglingSessionInvalidateFilter DanglingSessionInvalidateFilter com.SessionInvalidateFilter DanglingSessionInvalidateFilter /restcall/* Here in below URL: "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck; sdm will 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 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 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 > >> > >> > >>> > >>> > >>> default > >>> > >>> > >> > org.apache.catalina.servlets.DefaultServlet > >>> > >>> debug > >>> 0 > >>> > >>> > >>> listings > >>> false > >>> > >>> 1 > >>> > >>> > >>> jsp > >>> > >> org.apache.jasper.servlet.JspServlet > >>> > >>> fork > >>> false > >>> > >>> > >>> xpoweredBy > >>> false > >>> > >>> 3 > >>> > >>> > >>> > >>> default > >>> / > >>> > >>> > >>> > >>> jsp > >>> *.jsp > >>> *.jspx > >>> > >>> > >>> PatternTemplateLaunchServlet > >>> PatternTemplateLaunchServlet > >>> > >>> > >>> MyReportsLaunchServlet > >>> MyReportsLaunchServlet > >>> > >>> > >>> PatternTemplateLaunchServlet > >>> /patterntemplatelaunch > >>> > >>> > >>> MyReportsLaunchServlet > >>> /MyReportsLaunchServlet > >>> > >>> > >>> Please let me know if you need anyother details from our side. > >>> > >>> On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas 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 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 > > -- Regards, Kushagra Bindal +91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
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 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 >> >> >>> >>> >>> default >>> >>> >> org.apache.catalina.servlets.DefaultServlet >>> >>> debug >>> 0 >>> >>> >>> listings >>> false >>> >>> 1 >>> >>> >>> jsp >>> >> org.apache.jasper.servlet.JspServlet >>> >>> fork >>> false >>> >>> >>> xpoweredBy >>> false >>> >>> 3 >>> >>> >>> >>> default >>> / >>> >>> >>> >>> jsp >>> *.jsp >>> *.jspx >>> >>> >>> PatternTemplateLaunchServlet >>> PatternTemplateLaunchServlet >>> >>> >>> MyReportsLaunchServlet >>> MyReportsLaunchServlet >>> >>> >>> PatternTemplateLaunchServlet >>> /patterntemplatelaunch >>> >>> >>> MyReportsLaunchServlet >>> /MyReportsLaunchServlet >>> >>> >>> Please let me know if you need anyother details from our side. >>> >>> On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas 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 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
Re: Double Slash Support in Tomcat 9.0.27
Hi Mark/Manna Please let me know if I need to provide some additional information about the deployments so that it can be helpful in resolving the issue. Regards Kushagra On Mon, Dec 2, 2019, 4:29 PM Kushagra Bindal wrote: > Hi Mark, > > These are Rest Endpoints, and so will be processed through Filter. Do, you > think Servlet mapping will play any role here? > > On Mon, Dec 2, 2019 at 2:33 PM Mark Thomas wrote: > >> On 02/12/2019 04:53, Kushagra Bindal wrote: >> > Hi Mark, >> > >> > Please find the snippet from web.xml >> >> Which 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 >> >> >> > >> > >> > default >> > >> > >> org.apache.catalina.servlets.DefaultServlet >> > >> > debug >> > 0 >> > >> > >> > listings >> > false >> > >> > 1 >> > >> > >> > jsp >> > >> org.apache.jasper.servlet.JspServlet >> > >> > fork >> > false >> > >> > >> > xpoweredBy >> > false >> > >> > 3 >> > >> > >> > >> > default >> > / >> > >> > >> > >> > jsp >> > *.jsp >> > *.jspx >> > >> > >> > PatternTemplateLaunchServlet >> > PatternTemplateLaunchServlet >> > >> > >> > MyReportsLaunchServlet >> > MyReportsLaunchServlet >> > >> > >> > PatternTemplateLaunchServlet >> > /patterntemplatelaunch >> > >> > >> > MyReportsLaunchServlet >> > /MyReportsLaunchServlet >> > >> > >> > Please let me know if you need anyother details from our side. >> > >> > On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas 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 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 >> >> > > -- > Regards, > Kushagra Bindal > +91-9013792807 >
Re: Double Slash Support in Tomcat 9.0.27
Hi Mark, These are Rest Endpoints, and so will be processed through Filter. Do, you think Servlet mapping will play any role here? On Mon, Dec 2, 2019 at 2:33 PM Mark Thomas wrote: > On 02/12/2019 04:53, Kushagra Bindal wrote: > > Hi Mark, > > > > Please find the snippet from web.xml > > Which 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 > > > > > > > > default > > > > > org.apache.catalina.servlets.DefaultServlet > > > > debug > > 0 > > > > > > listings > > false > > > > 1 > > > > > > jsp > > > org.apache.jasper.servlet.JspServlet > > > > fork > > false > > > > > > xpoweredBy > > false > > > > 3 > > > > > > > > default > > / > > > > > > > > jsp > > *.jsp > > *.jspx > > > > > > PatternTemplateLaunchServlet > > PatternTemplateLaunchServlet > > > > > > MyReportsLaunchServlet > > MyReportsLaunchServlet > > > > > > PatternTemplateLaunchServlet > > /patterntemplatelaunch > > > > > > MyReportsLaunchServlet > > /MyReportsLaunchServlet > > > > > > Please let me know if you need anyother details from our side. > > > > On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas 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 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 > > -- Regards, Kushagra Bindal +91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
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 > > > default > > org.apache.catalina.servlets.DefaultServlet > > debug > 0 > > > listings > false > > 1 > > > jsp > org.apache.jasper.servlet.JspServlet > > fork > false > > > xpoweredBy > false > > 3 > > > > default > / > > > > jsp > *.jsp > *.jspx > > > PatternTemplateLaunchServlet > PatternTemplateLaunchServlet > > > MyReportsLaunchServlet > MyReportsLaunchServlet > > > PatternTemplateLaunchServlet > /patterntemplatelaunch > > > MyReportsLaunchServlet > /MyReportsLaunchServlet > > > Please let me know if you need anyother details from our side. > > On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas 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 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
Re: Double Slash Support in Tomcat 9.0.27
Hi Mark, Please find the snippet from web.xml default org.apache.catalina.servlets.DefaultServlet debug 0 listings false 1 jsp org.apache.jasper.servlet.JspServlet fork false xpoweredBy false 3 default / jsp *.jsp *.jspx PatternTemplateLaunchServlet PatternTemplateLaunchServlet MyReportsLaunchServlet MyReportsLaunchServlet PatternTemplateLaunchServlet /patterntemplatelaunch MyReportsLaunchServlet /MyReportsLaunchServlet Please let me know if you need anyother details from our side. On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas 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 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 > > -- Regards, Kushagra Bindal +91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
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 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
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 wrote:
> Kushagra,
>
> On Fri, 29 Nov 2019 at 12:29, Kushagra Bindal
> wrote:
>
> > Hi Mark,
> >
> > This astrik is because I highlighted it as BOLD. But I guess at your end
> it
> > is being received as plain text. Resending the content in context.xml
> >
> >
> >
> >
> >
> > WEB-INF/web.xml
> > WEB-INF/tomcat-web.xml
> > ${catalina.base}/conf/web.xml
> >
> > > type="javax.sql.DataSource"/>
> >
> > > className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Nov 29, 2019 at 5:52 PM M. Manna wrote:
> >
> > > Hi
> > >
> > > On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal <
> bindal.kusha...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi Mark,
> > > >
> > > > We tried to put the changes as suggested by you. Below are the
> changes
> > > that
> > > > we have made in context.xml file.
> > > >
> > > >
> > >
> > >
> > > Why this asterisk? *
> > >
> > > >
> > > >
> > > >
> > > >
> > > > WEB-INF/web.xml
> > > > WEB-INF/tomcat-web.xml
> > > > ${catalina.base}/conf/web.xml
> > > >
> > > > global="jdbc/edbDataSource"
> > > > type="javax.sql.DataSource"/>
> > > >
> > > > > > > className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 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 +] "GET
> > > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > > 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> > > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > >
> > > > Please help me in correcting the syntax.
> > > >
> > > > Regards
> > > > Kushagra
> > > >
> > > > On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal <
> > > bindal.kusha...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi Mark,
> > > > >
> > > > > Thanks for providing the response.
> > > > >
> > > > > Yes, you are right that we should design our application to remove
> //
> > > > from
> > > > > being used.
> > > > >
> > > > > I will plan it accordingly, for the provided solution in below. Let
> > me
> > > > try
> > > > > the same and I will revert back to you in case of any further
> queries
> > > and
> > > > > concerns.
> > > > >
> > > > > On Fri, Nov 29, 2019 at 2:56 PM M. Manna
> wrote:
> > > > >
> > > > >> HI,
> > > > >>
> > > > >>
> > > > >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> > > > bindal.kusha...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > We are working on upgrading our enterprise application from
> 8.5.24
> > > to
> > > > >> > 9.0.27 version.
> > > > >> >
> > > > >> > What we have observed that in earlier version i.e. 8.5.24 we
> were
> > > able
> > > > >> to
> > > > >> > process process a REST URI have double slash ("//") in it.
> > > > >> >
> > > > >> > But when we are upgrading it to 9.0.27 we found that now the
> same
> > > url
> > > > >> which
> > > > >> > was working earlier it is now throwing 404 status code.
> > > > >> >
> > > > >> > Now, the problem is that we can not remove these double slash
> (//)
> > > > >> manually
> > > > >> > as it is used widely.
> > > > >> >
> > > > >> > So, can someone please provide a possible solution of this
> issue?
> > > > >> >
> > > > >>
> > > > >> Tomcat processes HTTP query and URL using RFC 7230 standards. But
> > > > >> multiple
> > > > >> leading forward slash support was disabled by default for good
> > > reasons.
> > > > >> This was done in 8.5.31 due to issues with Http Redirects
> involving
> > > > >> Servlets.
> > > > >>
> > > > >> If you must use this, you have to modify your application context
> to
> > > add
> > > > >> the override as true - the attribute is called
> > > > >> "allowMultipleLeadingForwardSlashInPath".
> > > > >>
> > > > >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> > > > >>
> > > > >> But I would sincerely recommend that you work on such designs and
> > > > correct
> > > > >> them in your application. There is always a "way". This is one of
> > the
> > > > >> reasons web applications become obsolete requires huge
> maintenance.
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> >
> > > > >> > --
> > > > >> > Regards,
> > > > >> > Kushagra
Re: Double Slash Support in Tomcat 9.0.27
Kushagra,
On Fri, 29 Nov 2019 at 12:29, Kushagra Bindal
wrote:
> Hi Mark,
>
> This astrik is because I highlighted it as BOLD. But I guess at your end it
> is being received as plain text. Resending the content in context.xml
>
>
>
>
>
> WEB-INF/web.xml
> WEB-INF/tomcat-web.xml
> ${catalina.base}/conf/web.xml
>
> type="javax.sql.DataSource"/>
>
> className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
>
>
>
>
>
>
>
>
>
>
> On Fri, Nov 29, 2019 at 5:52 PM M. Manna wrote:
>
> > Hi
> >
> > On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal >
> > wrote:
> >
> > > Hi Mark,
> > >
> > > We tried to put the changes as suggested by you. Below are the changes
> > that
> > > we have made in context.xml file.
> > >
> > >
> >
> >
> > Why this asterisk? *
> >
> > >
> > >
> > >
> > >
> > > WEB-INF/web.xml
> > > WEB-INF/tomcat-web.xml
> > > ${catalina.base}/conf/web.xml
> > >
> > > > > type="javax.sql.DataSource"/>
> > >
> > > > > className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 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 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > >
> > > Please help me in correcting the syntax.
> > >
> > > Regards
> > > Kushagra
> > >
> > > On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal <
> > bindal.kusha...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi Mark,
> > > >
> > > > Thanks for providing the response.
> > > >
> > > > Yes, you are right that we should design our application to remove //
> > > from
> > > > being used.
> > > >
> > > > I will plan it accordingly, for the provided solution in below. Let
> me
> > > try
> > > > the same and I will revert back to you in case of any further queries
> > and
> > > > concerns.
> > > >
> > > > On Fri, Nov 29, 2019 at 2:56 PM M. Manna wrote:
> > > >
> > > >> HI,
> > > >>
> > > >>
> > > >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> > > bindal.kusha...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > We are working on upgrading our enterprise application from 8.5.24
> > to
> > > >> > 9.0.27 version.
> > > >> >
> > > >> > What we have observed that in earlier version i.e. 8.5.24 we were
> > able
> > > >> to
> > > >> > process process a REST URI have double slash ("//") in it.
> > > >> >
> > > >> > But when we are upgrading it to 9.0.27 we found that now the same
> > url
> > > >> which
> > > >> > was working earlier it is now throwing 404 status code.
> > > >> >
> > > >> > Now, the problem is that we can not remove these double slash (//)
> > > >> manually
> > > >> > as it is used widely.
> > > >> >
> > > >> > So, can someone please provide a possible solution of this issue?
> > > >> >
> > > >>
> > > >> Tomcat processes HTTP query and URL using RFC 7230 standards. But
> > > >> multiple
> > > >> leading forward slash support was disabled by default for good
> > reasons.
> > > >> This was done in 8.5.31 due to issues with Http Redirects involving
> > > >> Servlets.
> > > >>
> > > >> If you must use this, you have to modify your application context to
> > add
> > > >> the override as true - the attribute is called
> > > >> "allowMultipleLeadingForwardSlashInPath".
> > > >>
> > > >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> > > >>
> > > >> But I would sincerely recommend that you work on such designs and
> > > correct
> > > >> them in your application. There is always a "way". This is one of
> the
> > > >> reasons web applications become obsolete requires huge maintenance.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> >
> > > >> > --
> > > >> > Regards,
> > > >> > Kushagra Bindal
> > > >> > +91-9013792807
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Kushagra Bindal
> > > > +91-9013792807
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Kushagra Bindal
> > > +91-9013792807
> > >
> >
>
>
I have just started a tomcat with
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
> for the servlet you expect it to match toThanks,Mark *
Thanks,
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>
Re: Double Slash Support in Tomcat 9.0.27
Hi Mark,
This astrik is because I highlighted it as BOLD. But I guess at your end it
is being received as plain text. Resending the content in context.xml
WEB-INF/web.xml
WEB-INF/tomcat-web.xml
${catalina.base}/conf/web.xml
On Fri, Nov 29, 2019 at 5:52 PM M. Manna wrote:
> Hi
>
> On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal
> wrote:
>
> > Hi Mark,
> >
> > We tried to put the changes as suggested by you. Below are the changes
> that
> > we have made in context.xml file.
> >
> >
>
>
> Why this asterisk? *
>
> >
> >
> >
> >
> > WEB-INF/web.xml
> > WEB-INF/tomcat-web.xml
> > ${catalina.base}/conf/web.xml
> >
> > > type="javax.sql.DataSource"/>
> >
> > > className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
> >
> >
> >
> >
> >
> >
> >
> >
> > 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 +] "GET
> > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> >
> > Please help me in correcting the syntax.
> >
> > Regards
> > Kushagra
> >
> > On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal <
> bindal.kusha...@gmail.com
> > >
> > wrote:
> >
> > > Hi Mark,
> > >
> > > Thanks for providing the response.
> > >
> > > Yes, you are right that we should design our application to remove //
> > from
> > > being used.
> > >
> > > I will plan it accordingly, for the provided solution in below. Let me
> > try
> > > the same and I will revert back to you in case of any further queries
> and
> > > concerns.
> > >
> > > On Fri, Nov 29, 2019 at 2:56 PM M. Manna wrote:
> > >
> > >> HI,
> > >>
> > >>
> > >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> > bindal.kusha...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > We are working on upgrading our enterprise application from 8.5.24
> to
> > >> > 9.0.27 version.
> > >> >
> > >> > What we have observed that in earlier version i.e. 8.5.24 we were
> able
> > >> to
> > >> > process process a REST URI have double slash ("//") in it.
> > >> >
> > >> > But when we are upgrading it to 9.0.27 we found that now the same
> url
> > >> which
> > >> > was working earlier it is now throwing 404 status code.
> > >> >
> > >> > Now, the problem is that we can not remove these double slash (//)
> > >> manually
> > >> > as it is used widely.
> > >> >
> > >> > So, can someone please provide a possible solution of this issue?
> > >> >
> > >>
> > >> Tomcat processes HTTP query and URL using RFC 7230 standards. But
> > >> multiple
> > >> leading forward slash support was disabled by default for good
> reasons.
> > >> This was done in 8.5.31 due to issues with Http Redirects involving
> > >> Servlets.
> > >>
> > >> If you must use this, you have to modify your application context to
> add
> > >> the override as true - the attribute is called
> > >> "allowMultipleLeadingForwardSlashInPath".
> > >>
> > >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> > >>
> > >> But I would sincerely recommend that you work on such designs and
> > correct
> > >> them in your application. There is always a "way". This is one of the
> > >> reasons web applications become obsolete requires huge maintenance.
> > >>
> > >> Thanks,
> > >>
> > >> >
> > >> > --
> > >> > Regards,
> > >> > Kushagra Bindal
> > >> > +91-9013792807
> > >> >
> > >>
> > >
> > >
> > > --
> > > Regards,
> > > Kushagra Bindal
> > > +91-9013792807
> > >
> >
> >
> > --
> > Regards,
> > Kushagra Bindal
> > +91-9013792807
> >
>
--
Regards,
Kushagra Bindal
+91-9013792807
Re: Double Slash Support in Tomcat 9.0.27
Hi
On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal
wrote:
> Hi Mark,
>
> We tried to put the changes as suggested by you. Below are the changes that
> we have made in context.xml file.
>
>
Why this asterisk? *
>
>
>
>
> WEB-INF/web.xml
> WEB-INF/tomcat-web.xml
> ${catalina.base}/conf/web.xml
>
> type="javax.sql.DataSource"/>
>
> className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
>
>
>
>
>
>
>
>
> 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 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "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 >
> 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 wrote:
> >
> >> HI,
> >>
> >>
> >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> bindal.kusha...@gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > We are working on upgrading our enterprise application from 8.5.24 to
> >> > 9.0.27 version.
> >> >
> >> > What we have observed that in earlier version i.e. 8.5.24 we were able
> >> to
> >> > process process a REST URI have double slash ("//") in it.
> >> >
> >> > But when we are upgrading it to 9.0.27 we found that now the same url
> >> which
> >> > was working earlier it is now throwing 404 status code.
> >> >
> >> > Now, the problem is that we can not remove these double slash (//)
> >> manually
> >> > as it is used widely.
> >> >
> >> > So, can someone please provide a possible solution of this issue?
> >> >
> >>
> >> Tomcat processes HTTP query and URL using RFC 7230 standards. But
> >> multiple
> >> leading forward slash support was disabled by default for good reasons.
> >> This was done in 8.5.31 due to issues with Http Redirects involving
> >> Servlets.
> >>
> >> If you must use this, you have to modify your application context to add
> >> the override as true - the attribute is called
> >> "allowMultipleLeadingForwardSlashInPath".
> >>
> >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> >>
> >> But I would sincerely recommend that you work on such designs and
> correct
> >> them in your application. There is always a "way". This is one of the
> >> reasons web applications become obsolete requires huge maintenance.
> >>
> >> Thanks,
> >>
> >> >
> >> > --
> >> > Regards,
> >> > Kushagra Bindal
> >> > +91-9013792807
> >> >
> >>
> >
> >
> > --
> > Regards,
> > Kushagra Bindal
> > +91-9013792807
> >
>
>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>
Re: Double Slash Support in Tomcat 9.0.27
Hi Mark,
We tried to put the changes as suggested by you. Below are the changes that
we have made in context.xml file.
WEB-INF/web.xml
WEB-INF/tomcat-web.xml
${catalina.base}/conf/web.xml
But after restart still I am getting below errors in tomcat's
*localhost_access_log.2019-11-29.txt* file.
172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
/sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
/sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
172.18.0.3 - - [29/Nov/2019:11:27:46 +] "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
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 wrote:
>
>> HI,
>>
>>
>> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal
>> wrote:
>>
>> > Hi,
>> >
>> > We are working on upgrading our enterprise application from 8.5.24 to
>> > 9.0.27 version.
>> >
>> > What we have observed that in earlier version i.e. 8.5.24 we were able
>> to
>> > process process a REST URI have double slash ("//") in it.
>> >
>> > 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
Re: Double Slash Support in Tomcat 9.0.27
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 wrote:
> HI,
>
>
> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal
> wrote:
>
> > Hi,
> >
> > We are working on upgrading our enterprise application from 8.5.24 to
> > 9.0.27 version.
> >
> > What we have observed that in earlier version i.e. 8.5.24 we were able to
> > process process a REST URI have double slash ("//") in it.
> >
> > 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
Re: Double Slash Support in Tomcat 9.0.27
On 29/11/2019 09:00, Kushagra Bindal wrote:
> Hi,
>
> We are working on upgrading our enterprise application from 8.5.24 to
> 9.0.27 version.
>
> What we have observed that in earlier version i.e. 8.5.24 we were able to
> process process a REST URI have double slash ("//") in it.
>
> But when 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?
Can you provide more details such as:
- an example request URI
- the for the servlet you expect it to match to
Thanks,
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
HI,
On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal
wrote:
> Hi,
>
> We are working on upgrading our enterprise application from 8.5.24 to
> 9.0.27 version.
>
> What we have observed that in earlier version i.e. 8.5.24 we were able to
> process process a REST URI have double slash ("//") in it.
>
> 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
>
Double Slash Support in Tomcat 9.0.27
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?
--
Regards,
Kushagra Bindal
+91-9013792807
