user lockout realm, logging ip addresses
Is it possible to configure the user lockout realm to log what ip address the failed login attempt came from? I know the information needed will also be in the access log but added it to the "attempt to login from a locked account" message would be super helpful. Would it be more advisable to extend the existing lockout realm and modify the log statements myself?
Re: [tomcat:8.0-jre8] CONFIDENTIAL adds Cache-Control: private?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/17/18 11:49 AM, Mark Thomas wrote: > On 17/08/18 14:57, Christopher Schultz wrote: >> Mark, >> >> On 8/17/18 4:09 AM, Mark Thomas wrote: >>> On 16/08/18 13:40, Martynas Jusevičius wrote: Hi, my initial observations suggest, and SO post [1] seems to confirm, that when CONFIDENTIAL is specified on a security-constraint in web.xml, Tomcat does two things: 1. automatically redirects to HTTPS 2. appends Cache-Control: private and Expires: Thu, 01 Jan 1970 01:00:00 CET response headers Is that correct? >> >>> It is broader than that. Tomcat adds those headers to any >>> resource that is protected by any security constraint. >> I had added the CONFIDENTIAL because I want the redirect to HTTPS. What I don't want is Tomcat overriding my caching headers and effectively disabling browser caching. >> >>> Those headers shouldn't disable browser caching. >> >> Expires: 1970 certainly effectively disables browsed caching. > > My understanding was that the browser caches the resource but marks > it as stale which means it needs validation on the next request. That's essentially the same thing. The server can still return a 304 response if the browser thinks it has an up-to-date copy, but it's still a round-trip to the server that might be avoided. >>> They will mean the client has to revalidate the request. How >>> relatively expensive that is will depend on the resources. >> Why in the world would those two things be conflated? >> >>> Security. Any resource protected by a security constraint >>> should not be stored in a shared cache else information >>> disclosure could occur. >> >> I'm curious, too: I can understand the "Cache-Control" header, >> but why the "Expires" one? What about some CSS file that can >> surely be cached by the browser? > > Looks like an HTTP/1.0 solution from a very short amount of > research. Revalidation for a static file shouldn't be too > expensive. > >> Is it possible for a servlet to override a single header -- say, >> the "Expires" header? It might be nice to have a facility to >> allow applications to override maybe just this one header (or, >> optionally, just one *other* header). I glossed-over the servlet >> spec and I don't see much in the way of proscriptions for >> precisely how to handle security-constraints e.g. when it comes >> to setting headers. > > It depends when the header is added. In this case the Authenticator > adds them before the filter chain is invoked so it should be > possible for an application to remove them. That's very good to know. There are very few headers that Tomcat automatically adds (at any stage). Could those be described somewhere including when/where they are added and whether they can be overridden? For example, I tried (and failed) to override the "Date" response header at some point while testing my "replay response" sample code. It might be nice to know that Tomcat adds (overwrites) that header fairly late in the process. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt3EskACgkQHPApP6U8 pFg9TQ/9E2lLXq8ZjBBU1bMvd66jHJ4RgruQYG3sViaTA6xkk0zF1YWmAH0fquZV Xnid0102FteOZ7uqsMvzIRNywvnuL6S1nq9ItIvBMIQofZZnTnu275Xetq6smOHR j+o51S1sq5WwFP1ypijnYwT1KHmc1eQ9XwubsxmWgxVw33nJNhfsLr2BWMs9xWsT lG+iHA1ArIxRjx/oTtjuZAXgyH2PsB5T91huOmrzeR9uXbXfUGj+/qCoS33KcMyq +qQT/iDFH/z6i0g50a95fl6dLb3Tizmpwk7xikhd4eZ+D05qJEQAH0Vnyff8a/NA leHjeouGgo0ZaSBGWByYDZno1q34QkwOUfv6UGaHD0fw21yGsxWt1mfo6jedHNQ3 ZhXbEQMhM8uYIHYuKAaMcXSEbOvMkd7SsoqZGRzK6t1HptgtGN6NyRQA9U6hLT8I 5eGad3Bdx2nbnR7KDqcizJZ/Ulx5Be6XIQE4pncf2OLgfB6H3EkJ8FUkeU74i6W5 se0z9vECh7zBxEAaCm0u7bVH1NK5zZKcOgPxzFvtHrkj7bnpBXcN9Qm6G1OkEfjG d7rxnQtzG/d38YL0LQy3VsMp+q0Va9sRSztKpmmSU+se2904R/mj4ITz3M7e6VTE 1+LhS4WSf4yriC7qmShd5d/CzDW3Pvz0S0uyoV5MduQWtBbnDbQ= =8Svp -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [tomcat:8.0-jre8] CONFIDENTIAL adds Cache-Control: private?
On 17/08/18 14:57, Christopher Schultz wrote: > Mark, > > On 8/17/18 4:09 AM, Mark Thomas wrote: >> On 16/08/18 13:40, Martynas Jusevičius wrote: >>> Hi, >>> >>> my initial observations suggest, and SO post [1] seems to >>> confirm, that when >>> >>> >>> CONFIDENTIAL >>> >>> >>> is specified on a security-constraint in web.xml, Tomcat does two >>> things: 1. automatically redirects to HTTPS 2. appends >>> Cache-Control: private and Expires: Thu, 01 Jan 1970 01:00:00 CET >>> response headers >>> >>> Is that correct? > >> It is broader than that. Tomcat adds those headers to any resource >> that is protected by any security constraint. > >>> I had added the CONFIDENTIAL because I want the redirect to >>> HTTPS. What I don't want is Tomcat overriding my caching headers >>> and effectively disabling browser caching. > >> Those headers shouldn't disable browser caching. > > Expires: 1970 certainly effectively disables browsed caching. My understanding was that the browser caches the resource but marks it as stale which means it needs validation on the next request. >> They will mean the client has to revalidate the request. How >> relatively expensive that is will depend on the resources. > >>> Why in the world would those two things be conflated? > >> Security. Any resource protected by a security constraint should >> not be stored in a shared cache else information disclosure could >> occur. > > I'm curious, too: I can understand the "Cache-Control" header, but why > the "Expires" one? What about some CSS file that can surely be cached > by the browser? Looks like an HTTP/1.0 solution from a very short amount of research. Revalidation for a static file shouldn't be too expensive. > Is it possible for a servlet to override a single header -- say, the > "Expires" header? It might be nice to have a facility to allow > applications to override maybe just this one header (or, optionally, > just one *other* header). I glossed-over the servlet spec and I don't > see much in the way of proscriptions for precisely how to handle > security-constraints e.g. when it comes to setting headers. It depends when the header is added. In this case the Authenticator adds them before the filter chain is invoked so it should be possible for an application to remove them. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [tomcat:8.0-jre8] CONFIDENTIAL adds Cache-Control: private?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/17/18 4:09 AM, Mark Thomas wrote: > On 16/08/18 13:40, Martynas Jusevičius wrote: >> Hi, >> >> my initial observations suggest, and SO post [1] seems to >> confirm, that when >> >> >> CONFIDENTIAL >> >> >> is specified on a security-constraint in web.xml, Tomcat does two >> things: 1. automatically redirects to HTTPS 2. appends >> Cache-Control: private and Expires: Thu, 01 Jan 1970 01:00:00 CET >> response headers >> >> Is that correct? > > It is broader than that. Tomcat adds those headers to any resource > that is protected by any security constraint. > >> I had added the CONFIDENTIAL because I want the redirect to >> HTTPS. What I don't want is Tomcat overriding my caching headers >> and effectively disabling browser caching. > > Those headers shouldn't disable browser caching. Expires: 1970 certainly effectively disables browsed caching. > They will mean the client has to revalidate the request. How > relatively expensive that is will depend on the resources. > >> Why in the world would those two things be conflated? > > Security. Any resource protected by a security constraint should > not be stored in a shared cache else information disclosure could > occur. I'm curious, too: I can understand the "Cache-Control" header, but why the "Expires" one? What about some CSS file that can surely be cached by the browser? >> And how do I disable this header override behavior? >> >> Does disableProxyCaching attribute need to be set to false to in >> order to do that? [2] > > That would work. The consequence is that the application has to > take responsibility for setting all of the caching headers - > including those served by container servlets such as static > resources and JSPs. Is it possible for a servlet to override a single header -- say, the "Expires" header? It might be nice to have a facility to allow applications to override maybe just this one header (or, optionally, just one *other* header). I glossed-over the servlet spec and I don't see much in the way of proscriptions for precisely how to handle security-constraints e.g. when it comes to setting headers. This is an academic question for me... all of our static resources are served by httpd and not Tomcat, so those headers that are advantageous for caching are handled there and not in Tomcat. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt21EkACgkQHPApP6U8 pFiJBRAAx/e2eagrr6OFv8yrX0C3ckxTC3aahSqGISieunlBb1TypdygqAtt0/Ro P+40LplhT17U+bvFU1HYacq2m4lswYUosaPKRcQEh5lqcP0DXCMPX3kBk0C8Wlw1 g5aJMha/21YDZysITzJzppGiBtqSIsdKH8yIhgOf1yR5U/oMR4UMFMDqZI1cLf4X vPDROT3f+SNLfmPglXMlGbYvXI2fauel1sHbdjttUNdbneAVJwDS5Szc36uj2Cpq 7SophzD37FbroBfa/Ylxs5yI+p88gQjOHS96ebqNElNtosiidrwK6ysn8qVtgbGb v4oZeWqahrwkDRBibWAIGJjiNiO0/pB2hLSuxuuBG1JapTOeawZ8WwJLTZ9iiX71 ThI7L7t7iBEIB1I1dpq8KrIUP/dJc6H0ekFlW6Q87cZcvWTyRB45gibNC2tRNxwz 7x2Pm7MU0eB7fihKNJuMmYUY0N+QUlqetMEkwEFbmMrIL4Wn6MGTAYgRu3Y5OqE1 Ctlil/SCEgZHpXEXU86xTTEQVB0gei0k4KbXlld0vuF9dzAxGA/AuwnjygihAigL PNlbNHhfFmYn+UGMoP2+J3CKYJc9Eu/xZfhrQebEJ80GWK3NPZTEoEu/iz70B/Pf LqSeENgMi6hQZYDn8xpLSzKm1S4XzmwNb2pW3pfUaeqMclAZylk= =HIre -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to prevent user access to JSP pages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/17/18 3:54 AM, Mark Thomas wrote: > On 16/08/18 18:19, Berneburg, Cris J. - US wrote: >> Due to security concerns and general fussiness on my part, I'd >> like to prevent users from requesting JSP pages directly, except >> for the login page. I want all requests to be handled by >> servlets. That way I can legitimately claim that all requests >> are being validated, input scrubbed, JSP's cannot be taken >> advantage of w/o their servlet chaperones being present, etc. > > I'm struggling to understand what risks exists with JSPs that don't > with Servlets. After all, a JSP is just an alternative way to write > a Servlet. Tomcat translates the .jsp file to the .java source for > a servlet, compiles it and runs it. > > Can you elaborate? JSP support for input validation, etc. is basically non-existent. I'm sure someone has a crappy library that can do it, and yes, you can implement everything in JSP using miles of tag libraries and stuff like that, but in the application world, that's a serious no-no. MVC (or some version of it, under various names) is the "proper" way to build software, and JSPs are relegated to the "V" portion of that paradigm. Once you have decided that JSPs are squarely in the "V" category, it's no longer appropriate for them to be treated as "C" components and therefore they should not be accessed directly. Protecting them from direct-access is a reasonable decision for a number of reasons, including security if you have pages that cough-up sensitive information under the assumption that authentication and authorization requirements have previously been satisfied. Sure, the container's authentication and authorization should be able to protect those JSPs just fine, but the application may have other controls in place that also need to sanity-check things before the JSP takes over. So, while there isn't anything particularly "dangerous" about direct-access to JSPs, there are a number of "best practices" that suggest that hiding them is a good idea. I hope that helps explain Cris's (likely) reasoning a little more. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt20yEACgkQHPApP6U8 pFj6uxAAxyAHmZgiPBNFXRQvbfmr7Su7WKfXeIuu2/VNdWluUBjmxqnNCbO7dgyh F/emljDwMhU+PG/5Q8CDyi7+owPcRL0ix5l0ywQ+cm+nJk1YsohN52INUJ9uod4F Uo+/Lty1/sro2coJYtDCeXTJzocgagSdef5Uw3jYnL64Zeaa1D/FwOffcGNbAG9g mHY07JN3AsDDM3+ehNCK/MKSe+CYK+MSWPhb+ALYKXkRfhltWJu1ojNo5O4jy4SS G1w2ZZaSZ1ISb52VXbN0+MOsHquNNFrm1UH7fDrrSazwSNMq998qeuUPzdljtEVa aM8H4Zf3ERLUbEXIL4pbhd1wU7hkjdSzTzxvQlqyI1F1dtmHV9t3F0YITdCaFmfU lepJhrHq6NHwt9peHs1DCSsb72kOv3bAR7F/rHVZNi3I0PL+MsxkoGgMQt74Xi1a du9gHdsWMLIs0ZouLjAFVRLihbqKKXvZ7ATzgrFmFPNR3yIoIZn+iLT8LqiNqMBq NsTQnktWTYKCs7uE7HUOyYwoqLOnEmjMqG9wjhTAETPQzp2PP3v2RJKfjI5WHMN8 H8PohSj7SxYxN5KWFR/JmO7eksetVVLw0q+NvuDj6L8grhBatVskIWV3FpFPzyI1 Qd2QxabNjNBgH+CXP57q7iYtYAdxkIOlH2q2JnkFbP1S1aWKWXY= =DEMc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 2018.03.07-2 Bundle issue with tomcat 8 - Post
On 17.08.2018 15:40, Mandal, Jayanta wrote: Tomcat Version : We upgraded our tomcat environment from bundle 2016.10.31-2 to 2018.03.07-2 & suddenly we are seeing all Post method stopped working with new bundle. Previous Value Changed Value Bundle 2016.10.31-2 2018.03.07-2 Tomcat Server: : 8.0.18-62_patch_01.ep7.el6.-patch-01 8.0.36-17.ep7.el6.0 As the downloads on tomcat.apache.org have only 3 digits for the version numbers: You're asking about /some/ version that /someone/ has packaged according to unknown standards and with unknown patches. Plus, it's a version that is already past its end of life, check https://tomcat.apache.org/tomcat-80-eol.html Your best bet is to upgrade to 8.5 or 9.0. Use a stock version from tomcat.apache.org if you expect help on this list. If you expect support from your OS vendor (or whoever packaged this version for you), they'd be the ones to contact. They might provide support beyond this version's end-of-life. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: 2018.03.07-2 Bundle issue with tomcat 8 - Post
Tomcat Version : We upgraded our tomcat environment from bundle 2016.10.31-2 to 2018.03.07-2 & suddenly we are seeing all Post method stopped working with new bundle. Previous Value Changed Value Bundle 2016.10.31-2 2018.03.07-2 Tomcat Server: : 8.0.18-62_patch_01.ep7.el6.-patch-01 8.0.36-17.ep7.el6.0 Operating System LINUX : linux 2.6.32-696.28.1.el6.x86_64 System Model vm_vulcan_vsi Processor Model virtual virtual MHz Logical Processors 2 Physical Memory(GB) 16 NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent required and/or permitted under applicable law, to monitor electronic communications, including telephone calls with Morgan Stanley personnel. This message is subject to the Morgan Stanley General Disclaimers available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access the links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you acknowledge that you have read, understand and consent, (where applicable), to the foregoing and the Morgan Stanley General Disclaimers.
2018.03.07-2 Bundle issue with tomcat 8 - Post
Tomcat Version : We upgraded our tomcat environment from bundle 2016.10.31-2 to 2018.03.07-2 & suddenly we are seeing all Post method stopped working with new bundle. Previous Value Changed Value Bundle 2016.10.31-2 2018.03.07-2 Tomcat Server: : 8.0.18-62_patch_01.ep7.el6.-patch-01 8.0.36-17.ep7.el6.0 Operating System LINUX : linux 2.6.32-696.28.1.el6.x86_64 System Model vm_vulcan_vsi Processor Model virtual virtual MHz Logical Processors 2 Physical Memory(GB) 16 NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent required and/or permitted under applicable law, to monitor electronic communications, including telephone calls with Morgan Stanley personnel. This message is subject to the Morgan Stanley General Disclaimers available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access the links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you acknowledge that you have read, understand and consent, (where applicable), to the foregoing and the Morgan Stanley General Disclaimers.
Re: Apache 2.4.33 with mod_jk 1.2.43 keeps shutting down when no Tomcat worker is available
Hi, please ignore. There was another component (corosync) that I did not consider. When all tomcats are down, that ends up in a 503 which confused the HA software ... Happy Weekend Martin On Fri, Aug 17, 2018 at 12:15 PM Martin Knoblauch wrote: > Hi, > > we have Apache-2.4.33 as a frontend to a bunch of Tomcats using > mod_jk-1.2.43 as load balancer. Since we upgraded to this combination, we > observe Apache shutdowns as soon as the last Tomcat worker is down. This > has not happened before up until apache-2.4.33+mod_jk-1.2.42. > > error-log is pretty non-informative: > > [Fri Aug 17 11:39:24.172531 2018] [ldap:info] [pid 2312:tid > 139990203332352] AH01318: APR LDAP: Built with OpenLDAP LDAP SDK > [Fri Aug 17 11:39:24.172712 2018] [ldap:info] [pid 2312:tid > 139990203332352] AH01319: LDAP: SSL support available > [Fri Aug 17 11:39:24.191526 2018] [mpm_worker:notice] [pid 2312:tid > 139990203332352] AH00292: Apache/2.4.33 (Unix) OpenSSL/1.0.2p mod_jk/1.2.43 > configured -- resuming normal operations > [Fri Aug 17 11:39:24.191566 2018] [core:notice] [pid 2312:tid > 139990203332352] AH00094: Command line: '/opt/cb2/apache2/bin/httpd -D > STATUS -f /opt/cb2/apache2/conf/httpd.conf' > [Fri Aug 17 11:39:27.106795 2018] [mpm_worker:notice] [pid 2312:tid > 139990203332352] AH00295: caught SIGTERM, shutting down > > Is there anything known along this lines? > > Thanks > Martin > -- > -- > Martin Knoblauch > email: k n o b i AT knobisoft DOT de > www: http://www.knobisoft.de > -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
Apache 2.4.33 with mod_jk 1.2.43 keeps shutting down when no Tomcat worker is available
Hi, we have Apache-2.4.33 as a frontend to a bunch of Tomcats using mod_jk-1.2.43 as load balancer. Since we upgraded to this combination, we observe Apache shutdowns as soon as the last Tomcat worker is down. This has not happened before up until apache-2.4.33+mod_jk-1.2.42. error-log is pretty non-informative: [Fri Aug 17 11:39:24.172531 2018] [ldap:info] [pid 2312:tid 139990203332352] AH01318: APR LDAP: Built with OpenLDAP LDAP SDK [Fri Aug 17 11:39:24.172712 2018] [ldap:info] [pid 2312:tid 139990203332352] AH01319: LDAP: SSL support available [Fri Aug 17 11:39:24.191526 2018] [mpm_worker:notice] [pid 2312:tid 139990203332352] AH00292: Apache/2.4.33 (Unix) OpenSSL/1.0.2p mod_jk/1.2.43 configured -- resuming normal operations [Fri Aug 17 11:39:24.191566 2018] [core:notice] [pid 2312:tid 139990203332352] AH00094: Command line: '/opt/cb2/apache2/bin/httpd -D STATUS -f /opt/cb2/apache2/conf/httpd.conf' [Fri Aug 17 11:39:27.106795 2018] [mpm_worker:notice] [pid 2312:tid 139990203332352] AH00295: caught SIGTERM, shutting down Is there anything known along this lines? Thanks Martin -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
Re: [tomcat:8.0-jre8] CONFIDENTIAL adds Cache-Control: private?
On 16/08/18 13:40, Martynas Jusevičius wrote: > Hi, > > my initial observations suggest, and SO post [1] seems to confirm, that when > > > CONFIDENTIAL > > > is specified on a security-constraint in web.xml, Tomcat does two things: > 1. automatically redirects to HTTPS > 2. appends Cache-Control: private and Expires: Thu, 01 Jan 1970 > 01:00:00 CET response headers > > Is that correct? It is broader than that. Tomcat adds those headers to any resource that is protected by any security constraint. > I had added the CONFIDENTIAL because I want the redirect to HTTPS. > What I don't want is Tomcat overriding my caching headers and > effectively disabling browser caching. Those headers shouldn't disable browser caching. They will mean the client has to revalidate the request. How relatively expensive that is will depend on the resources. > Why in the world would those two things be conflated? Security. Any resource protected by a security constraint should not be stored in a shared cache else information disclosure could occur. > And how do I > disable this header override behavior? > > Does disableProxyCaching attribute need to be set to false to in order > to do that? [2] That would work. The consequence is that the application has to take responsibility for setting all of the caching headers - including those served by container servlets such as static resources and JSPs. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to prevent user access to JSP pages?
On 16/08/18 18:19, Berneburg, Cris J. - US wrote: > Due to security concerns and general fussiness on my part, I'd like to > prevent users from requesting JSP pages directly, except for the login page. > I want all requests to be handled by servlets. That way I can legitimately > claim that all requests are being validated, input scrubbed, JSP's cannot be > taken advantage of w/o their servlet chaperones being present, etc. I'm struggling to understand what risks exists with JSPs that don't with Servlets. After all, a JSP is just an alternative way to write a Servlet. Tomcat translates the .jsp file to the .java source for a servlet, compiles it and runs it. Can you elaborate? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
