-----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. "/foo////bar.html" is going to give you the same result. > > The same is true for multiple levels like "/foo/bar/bar.html". If > you want to protect all files in "/foo/bar" it's not practical to > add protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/" > and ... you see where I'm going with this. > > So the server decides that slash-collapsing will allow security > constraints to be more practically applied. > > What if we get super-spec-compliant and allow those extra slashes? > Well, you'd have to get really (and, IMHO, /overly/) strict about > how those slashes are treated. In Java, you'd have to do something > like this : > > String path = ... // file-path from request String docRoot = ... // > docroot base, absolute File file = new File(docRoot, path); > if(!file.exists()) // return 404 > if(!path.equals(file.getAbsolutePath().substring(docRoot.length())) > > // return 404 > > That last check will check to make sure that the path requested by > the client *exactly equals* that of the path on the disk. That > means that multiple-slashes are essentially forbidden when > requesting disk-files. > > (It gets more fun when you are requesting a directory which has an > "index file" like index.html and you have to decide whether or not > it's okay to load that file automatically, even though the client > didn't specifically request it.) > > So now we are spec-compliant. Yay! Except that all those sloppy > webmasters links no longer work because they do all kinds of weird > URL manipulations that don't always result in a perfectly-clean > URL. So we've achieved spec-compliance and inconvenienced users. > Did we really achieve anything? Those multi-slash URLs were never > going to work. It is really a big deal to just ... let them work? > So we collapse slashes and everything is fine. Nobody is really > going to complain if /foo//bar.html and /foo/bar.html both work > instead of one of them returning 404. > > What about resource that are *not* on a disk? Like servlets and > stuff like that? Well, the servlet spec allows us to map to URL > patterns of various types. Some are exact, others prefixes, etc. We > can also define security constraints with the same kind of > url-pattern basis. Generally, those things should agree. What > happens when you introduce multiple-slashes in there? > > Well, nobody is ever going to map a bunch of additional slashes to > make their servlets work properly. So we are back to the same > problem as the on-disk-file: the multiple-slashes are essentially > forbidden if we want to be super-spec-compliant. So we relax a > little and take the practical approach: collapse slashes and move > on with our lives. This has the added benefit of making security > constraints more consistent, and fewer mistakes. And encouraging > fewer security mistakes is a Good Thing. > >>>> And the collapsing of multiple consecutive slashes in the >>>> URL, is probably done at such an early stage in the request >>>> processing, that it is not easy to do something to turn it >>>> off (which may or may not be spec-compliant anyway). > > Turning it off would be a giant mess. And yes, it needs to be doe > quite early because Tomcat has to figure out which web application > will be responding to the request. So it's one of the first things > that Tomcat has to do with an incoming request. > >>>> I did not look up the HTTP specs to find where this >>>> collapsing of slashes is specified, but I found this in the >>>> Apache httpd documentation, which would seem to suggest that >>>> consecutive slashes are not necessarily invalid, and may even >>>> *mean* something : >>>> http://httpd.apache.org/docs/2.4/mod/core.html#location (see >>>> : Note about "/") >>>> >>>> Ok, then I got curious and did have a quick look at RFCs 7230 >>>> and 7231, and they are mute about consecutive slashes. >>>> RFC2396 on the other hand does not seem to forbid consecutive >>>> slashes, and as I understand it, they are even "significant", >>>> as they seem to delimit a path element (which just happens to >>>> be empty). https://tools.ietf.org/html/rfc3986#section-3.3 >>>> does not seem to forbid consecutive slashes either. >>>> >>>> But I would suppose that if the Tomcat developers decided to >>>> collapse multiple consecutive slashes, they must have had a >>>> reason. > > Yep: see above. It's a deliberate violation of the spec designed > to make the world work the way everyone expects it to work, and > also make security configuration sensible, too. > > -chris > >>>> On 04.12.2019 15:18, Christopher Schultz wrote: Kushagra, >>>> >>>> On 12/4/19 06:32, Kushagra Bindal wrote: >>>>>>> I am not saying that this is a tomcat issue, I am just >>>>>>> asking if there is a way by which we can handle this. >>>>>>> As maybe in later version of 8.5.24 Tomcat has take >>>>>>> some action to handle such conditions. >>>> >>>> I still don't really see the problem. Your responses have >>>> included tiny bits of information separately and not >>>> everything all at once. If you have a <filter> defined and >>>> mapped to a URL pattern, it should work and not give you a >>>> 404. >>>> >>>> Try this with the examples application: >>>> >>>> http://localhost:8080/examples/servlets/servlet/HelloWorldExample >>>> >>>> >>>> It will respond no matter how any slashes you put in various >>>> places: >>>> >>>> http://localhost:8080/examples/servlets/servlet//HelloWorldExample >>>> >>>> http://localhost:8080/examples/servlets//servlet//HelloWorldExample >>>> >>>> > http://localhost:8080/examples/servlets/servlet//////HelloWorldExample >>>> >>>> > There are no 404 errors. >>>> >>>> Are you sure your application has deployed correctly? >>>> >>>> -chris >>>> >>>>>>> On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas >>>>>>> <ma...@apache.org> wrote: >>>>>>> >>>>>>>> On 04/12/2019 05:16, Kushagra Bindal wrote: >>>>>>>>> Hi Mark/Manna/Chris, >>>>>>>>> >>>>>>>>> Do we have any way out to handle this type of >>>>>>>>> behavior? >>>>>>>> >>>>>>>> All the evidence so far points to an application >>>>>>>> issue, not a Tomcat issue. >>>>>>>> >>>>>>>> If you are able to create a simple test case that >>>>>>>> demonstrates a Tomcat issue we can take a look. >>>>>>>> >>>>>>>> Mark >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal < >>>>>>>> bindal.kusha...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Chris, >>>>>>>>>> >>>>>>>>>> If you will check in my early email then you will >>>>>>>>>> find that with // it >>>>>>>> is >>>>>>>>>> throwing 404. But as soon as I removed it >>>>>>>>>> manually then it starts >>>>>>>> working >>>>>>>>>> properly and all these url were working fine in >>>>>>>>>> 8.5.24 version. >>>>>>>>>> >>>>>>>>>> On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz >>>>>>>>>> < ch...@christopherschultz.net> wrote: >>>>>>>>>> >>>>>>>>> Kushagra, >>>>>>>>> >>>>>>>>> On 12/2/19 11:29, Kushagra Bindal wrote: >>>>>>>>>>>>> I think it should be. >>>>>>>>>>>>> >>>>>>>>>>>>> <filter> >>>>>>>>>>>>> <description>DanglingSessionInvalidateFilter</description> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> <filter-name>DanglingSessionInvalidateFilter</filter-name> >>>>>>>>>>>>> <filter-class>com.SessionInvalidateFilter</filter-class> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> </filter> <filter-mapping> >>>>>>>>>>>>> <filter-name>DanglingSessionInvalidateFilter</filter-name> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> <url-pattern>/restcall/*</url-pattern> </filter-mapping> >>>>>>>>>>>>> >>>>>>>>>>>>> Here in below URL: >>>>>>>>>>>>> >>>>>>>>>>>>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//heal thC > >>>>>>>>>>>>> hec >>>> >>>>>>>>>>>>> > k" >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> sdm will be the context path. >>>>>>>>>>>>> >>>>>>>>>>>>> But in another example that I shared in my >>>>>>>>>>>>> last email, one use case >>>>>>>>>>>>> http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> my context path itself contains //. >>>>>>>>>>>>> >>>>>>>>>>>>> So, please suggest a viable solution which >>>>>>>>>>>>> we can try to solve this problem. :) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks in advance for your help & support >>>>>>>>>>>>> in resolving this issue. >>>>>>>>> >>>>>>>>> All of these slashes really should be collapsed >>>>>>>>> into a single slash before processing. I don't see >>>>>>>>> an issue. If the client requests: >>>>>>>>> >>>>>>>>> http://backend_tomcat:8080/sdm/restcall/v1/platform//healthChe ck >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> >>>>>>>>> > >>>>>>>>> then the filter/servlet at /sdm/restcall/* will respond. >>>>>>>>> >>>>>>>>> If the client requests: >>>>>>>>> >>>>>>>>> http://backend_tomcat:8080//sdm/restcall/foo/file_uploads >>>>>>>>> >>>>>>>>> >>>>>>>>> > >>>>>>>>> Then the filter/servlet at /sdm/restcall/* will respond. >>>>>>>>> >>>>>>>>> It doesn't really matter how many extra slashes >>>>>>>>> the client adds... they should all be collapsed by >>>>>>>>> the server and your application should not have to >>>>>>>>> make arrangements to handle them, add them back, or >>>>>>>>> worry about whether they are there or not. >>>>>>>>> >>>>>>>>> -chris >>>>>>>>> >>>>>>>>>>>>> On Mon, Dec 2, 2019 at 9:00 PM Mark Thomas >>>>>>>>>>>>> <ma...@apache.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 02/12/2019 10:59, Kushagra Bindal >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> Hi Mark, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> These are Rest Endpoints, and so will >>>>>>>>>>>>>>> be processed through Filter. >>>>>>>>>>>>>> >>>>>>>>>>>>>> That is unusual. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do, you think Servlet mapping will play >>>>>>>>>>>>>>> any role here? >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the filter is handling them, no. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So I'll change the question. Which URL >>>>>>>>>>>>>> pattern from the filter mapping do you >>>>>>>>>>>>>> expect: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//hea lth > >>>>>>>>>>>>>> Che >>>> >>>>>>>>>>>>>> > ck" >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> >>>> to match? >>>>>>>>>>>>>> >>>>>>>>>>>>>> The Context Path question still needs an >>>>>>>>>>>>>> answer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mark >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Dec 2, 2019 at 2:33 PM Mark >>>>>>>>>>>>>>> Thomas <ma...@apache.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 02/12/2019 04:53, Kushagra Bindal >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Hi Mark, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please find the snippet from >>>>>>>>>>>>>>>>> web.xml >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Which URL pattern do you expect: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//h eal > >>>>>>>>>>>>>>>> thC >>>> >>>>>>>>>>>>>>>> > heck >>>>>>>> >>>>>>>>>>>>>>>> >>>> " >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> to match? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And what is the Context Path at which >>>>>>>>>>>>>>>> the application is deployed? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Mark >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <servlet> >>>>>>>>>>>>>>>>> <servlet-name>default</servlet-name> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servle > t-c >>>>>>>>> >>>>>>>> >>>> >>>>>>>> > lass> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> <init-param> >>>>>>>>>>>>>>>>> <param-name>debug</param-name> >>>>>>>>>>>>>>>>> <param-value>0</param-value> >>>>>>>>>>>>>>>>> </init-param> <init-param> >>>>>>>>>>>>>>>>> <param-name>listings</param-name> >>>>>>>>>>>>>>>>> <param-value>false</param-value> >>>>>>>>>>>>>>>>> </init-param> >>>>>>>>>>>>>>>>> <load-on-startup>1</load-on-startup> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> </servlet> <servlet> >>>>>>>>>>>>>>>>> <servlet-name>jsp</servlet-name> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-cl ass >>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>> >>>>>>>> > >>>>>>>> <init-param> >>>>>>>>>>>>>>>>> <param-name>fork</param-name> >>>>>>>>>>>>>>>>> <param-value>false</param-value> >>>>>>>>>>>>>>>>> </init-param> <init-param> >>>>>>>>>>>>>>>>> <param-name>xpoweredBy</param-name> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <param-value>false</param-value> >>>>>>>>>>>>>>>>> </init-param> >>>>>>>>>>>>>>>>> <load-on-startup>3</load-on-startup> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> </servlet> <!-- The mapping for the >>>>>>>>>>>>>>>>> default servlet --> >>>>>>>>>>>>>>>>> <servlet-mapping> >>>>>>>>>>>>>>>>> <servlet-name>default</servlet-name> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <url-pattern>/</url-pattern> >>>>>>>>>>>>>>>>> </servlet-mapping> <!-- The >>>>>>>>>>>>>>>>> mappings for the JSP servlet --> >>>>>>>>>>>>>>>>> <servlet-mapping> >>>>>>>>>>>>>>>>> <servlet-name>jsp</servlet-name> >>>>>>>>>>>>>>>>> <url-pattern>*.jsp</url-pattern> >>>>>>>>>>>>>>>>> <url-pattern>*.jspx</url-pattern> >>>>>>>>>>>>>>>>> </servlet-mapping> <servlet> >>>>>>>>>>>>>>>>> <servlet-name>PatternTemplateLaunchServlet</servlet-na me> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> <servlet-class>PatternTemplateLaunchServlet</servlet-class> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>> </servlet> >>>>>>>>>>>>>>>>> <servlet> >>>>>>>>>>>>>>>>> <servlet-name>MyReportsLaunchServlet</servlet-name> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> <servlet-class>MyReportsLaunchServlet</servlet-class> >>>>>>>>>>>>>>>>> </servlet> <servlet-mapping> >>>>>>>>>>>>>>>>> <servlet-name>PatternTemplateLaunchServlet</servlet-na me> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> <url-pattern>/patterntemplatelaunch</url-pattern> >>>>>>>>>>>>>>>>> </servlet-mapping> >>>>>>>>>>>>>>>>> <servlet-mapping> >>>>>>>>>>>>>>>>> <servlet-name>MyReportsLaunchServlet</servlet-name> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> <url-pattern>/MyReportsLaunchServlet</url-pattern> >>>>>>>>>>>>>>>>> </servlet-mapping> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please let me know if you need >>>>>>>>>>>>>>>>> anyother details from our side. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Dec 2, 2019 at 3:07 AM >>>>>>>>>>>>>>>>> Mark Thomas <ma...@apache.org> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 01/12/2019 07:11, Kushagra >>>>>>>>>>>>>>>>>> Bindal wrote: >>>>>>>>>>>>>>>>>>> Hi Manna/Mark, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Below are the sample URL which >>>>>>>>>>>>>>>>>>> we are passing to Tomcat. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://backend_tomcat:8080//sdm/restcall)(.*)/file_u plo > >>>>>>>>>>>>>>>>>>> ads >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> > http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As from the above example you >>>>>>>>>>>>>>>>>>> can see that // location may >>>>>>>>>>>>>>>>>>> vary case >>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>>>> case. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So, you guys have a probable >>>>>>>>>>>>>>>>>>> solution to handle such >>>>>>>>>>>>>>>>>>> situation, then >>>>>>>>>>>>>>>>>> please >>>>>>>>>>>>>>>>>>> do let me know. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Tomcat is simply going to >>>>>>>>>>>>>>>>>> normalize those to single '/'. >>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>> application >>>>>>>>>>>>>>>>>> should be fine with that. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> To repeat my previous request: >>>>>>>>>>>>>>>>>> Can you provide more details such >>>>>>>>>>>>>>>>>> as: - an example request URI >>>>>>>>>>>>>>>>>> *and* - the <url-pattern> for the >>>>>>>>>>>>>>>>>> servlet you expect it to match >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Mark >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> --------------------------------------------------------------- - -- >>>>>>>>> >>>>>>>> >>>> >>>>>>>> > >>>>>>>> - ---- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: >>>>>>>>> users-unsubscr...@tomcat.apache.org >>>>>>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>>>>>>> users-h...@tomcat.apache.org >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> --------------------------------------------------------------- - --- > >>>>>>>> - - >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>> >>>>>>>> > --------------------------------------------------------------------- >>>>>>>>>>> > To unsubscribe, e-mail: >>>>>>>>>>> users-unsubscr...@tomcat.apache.org For >>>>>>>>>>> additional commands, e-mail: >>>>>>>>>>> users-h...@tomcat.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------- - --- > >>>>>>>> - --- >>>>>>>> >>>>>>>> >>>> >>>>>>>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>>>> For additional commands, e-mail: >>>>>>>> users-h...@tomcat.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> ------------------------------------------------------------------ - --- >>>>> >>>>> > >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: >>>>> users-h...@tomcat.apache.org >>>>> >>>> >>>> >>>> ------------------------------------------------------------------- - -- >>>> >>>> > >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: >>>> users-h...@tomcat.apache.org >>>> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3pUgMACgkQHPApP6U8 pFjBPBAAiN+gtmhGkda/XjigqfJ06IY76r2wr2ICIziG9L4MM2l/eD2uWZ5IBj3D 8E6SzU0Sb/g02kN4bMjGQ/h2rDrkK4wymo+Ax60GtKwOPzdLjmSvsjLAVw3RRy8Y N2KZ750+sk91A1LdfEhxI+/Y6HdxblW2fKVXENjIGxOxNjLEpYbmoBE8EN/clBWI fOgeShmG5JirbYPsrRCxuXSWMYFdsuYyN0hg8PPUug1wqmYIbsQzuDzXwjA/cV+Z GJDQKsHwkmYi2kD2FashsBbD6qAFHTbU0Q0uOaDQPJvjm/pAzp+0HvfS//rBzeUe 0PcmS6TBzb8XVzm2i75lJPpk0WCQI5NcWAabN+H29WNhevNbMy+zERKwCN/ECsAZ Be3x57WydT5i9MkIYZaRYW/cNR+FpQKh5uSJ7uQuEiYlx1xRy49ugG/gOXX0emS5 YBBRV2KzQvoxH+GB8RpWsJZy5FzTeRi3ubh8MHVED3IT/ukF/nH8FuEasTbRkGhq 7ZNGslZF991JUdS4lLTpeAlE4LxqcbC5AcNAowHOq0KMp0qm32yLwr/c/yAseN6a gGsK1otDiVz/CxU9PA+TUTrq35HI1NPuGsUGA+V+NI+s3q0S5egpS9mSqRYw7VKW 1OPfy4eymVX793gsvPm7YeJm4QwAAa4bkuqv6GzqYzUVcg5EX6g= =w5Kn -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
