Re: Disabling Naggle's algorithm / Setting tcpNoDelay programatically for web sockets
On 25/06/2015 06:59, Ganesh Bms wrote: Hi, As per tomcat's performance tuning doc, 'tcpNoDelay' can be enabled/disabled at connector level. Is there a programmatic way to set 'tcpNoDelay' to true for web socket connections ? I am using tomcat's proprietary web socket APIs in my application. Sorry, no. I have gone though the API documentation of tomcat's proprietary web socket implementation, I didn't see any API which allows application to override the 'tcpNoDelay' value. As per doc for writeTextMessage(CharBuffer msgCb) of 'WsOutbound', for each write, tomcat flushes the socket buffer and sends the new frame with the buffer passed. Does that mean, flushing of socket buffer gives the same effect of disabling naggle's algorithm ? I don't know. The Javadoc only guarantees that the bytes will be passed to the OS when flush() is called. What happens after that is up to the OS. You'll need to do some testing on your system (possibly with Wireshark) to see exactly what is going on. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can i use Tomcat 7 catalina-ws.jar in Tomcat 8???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Agharta, On 6/25/15 2:39 AM, agharta wrote: On 06/24/2015 06:04 PM, Christopher Schultz wrote: Agharta, On 6/24/15 11:17 AM, agharta wrote: Hi all, A rapid question: colud i place the tomcat 7 catalina-ws.jar inside a new tomcat 8 installation ? Why would you want to do something like that? Because i have many customers, with many different versions of tomcat 7/8 and i'm trying to keep libs update method most simple as possible. Having no per-tomcat-version-libs solves me that problem. Why not just use the libraries that Tomcat already provides? Are you using a Tomcat-specific API for something? If so, what is that API you are using? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjAd/AAoJEBzwKT+lPKRYs1MQAJI0RGajVD/uSi36KIh3GySb Yn2Sz7+zpZ+p0IjYpcayd/2SxIBLVjgl6GtIK2IreHO+8lON7P4tGAMPXnEFYMYl zVsNYQqsJVhp6Bl7THU7Qemypden22A7YgdfN1+X6t79oT587XNLKy/146m/Yaqm V4aJIsjKBFU29hVpmFiKDOdLMNn/+sWpZ0R2kDa1L7rDEVWlekYolqza5XO987fm H/KW55IYuWGjpISLPueXpsotkKcS/VDXOTMWiBVxH4wu+BXYqJNoj2Zieh4fPNkF kwUhxgk7oU6c633e5HZ11RGEitp8nSYZs7mw4icAl74K/YuFGDu2WQfkQggCUk/G u3o+hvANZyBuqL8kDlUHl1/sFNTbXkXOa0GwlXgIxUEND3VPwPqcRoOhorAPFynD pgDUlBqVVTS9wUAdSj42sJcqeJPKm6p3ZPgDdYOAKmSqqYHDeP7TS3+wn54ihWer YOrKeC5njOVyYcZEpnVHjEgDzN68JW49Vzwvl9HQV+ZYWcxi60LyI6yhuoHuboxv cXLVNLm87D7y32N36VQBQiPCyci/VZGcK+sQpyfYVgRvP2FpnnUWZwcQ3fzzTpwO TWWbOFW1Kk1x4qHCUQLlRV9e9ifzvSkODyQTsCbrCKitzUHMRACc/6EkmYYGcEQG 18zpzmV9wrmyZFzvNlaW =d+Fy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is Tomcat 7.0.62 vulnerable to these issues: CVE-2007-6750/CVE-2009-5111
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/25/15 3:49 AM, Mark Thomas wrote: On 25/06/2015 07:07, Nikitha Benny wrote: Hi, I am confused regarding the 2 security issues CVE-2007-6750 and CVE-2009-5111. Can they be tracked to CVE-2012-5568? All of those CVEs are essentially the same issue (slowloris) in different products. According to CVE-2012-5568, I understand that this is not a vulnerability in Tomcat. Please confirm. That depends on your point of view. When Tomcat 7.0.62 was scanned using McAfee Vulnerability Manager Tool, it reported the below results: * HTTP Server Prone To Slow Denial Of Service Attack [FID 12824]* 5.0 Medium 10.53.137.57:80 (http) ,10.53.137.57:8081 (http) * HTTP Server Prone To Slow Denial Of Service Attack [FID 12824]* 5.0 Medium 10.53.137.56:80 (http) ,10.53.137.56:8081 (http) Please help me understand if this can be resolved or if this is a valid vulnerability. Read this and the referenced links. https://bz.apache.org/bugzilla/show_bug.cgi?id=54263 ... and of course the mitigation for Slowloris is: 1. Use a non-blocking I/O connector (NIO, NIO2) 2. Set appropriate values for the following Connector settings: - connectionTimeout - connectionUploadTimeout - keepAliveTimeout - maxPostSize - maxSwallowSize At some point, it may be necessary to write a Valve (or similar component) that keeps track of throughput, and aborts a connection whose throughput fails to meet some threshold. Do to that, you'd want to take into account the size of the upload and the total time taken by the request. Some clients are just slow and that's okay. But if you have client that has been tying-up a connection for 30 seconds and only sent a few bytes, kill 'em. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjAkfAAoJEBzwKT+lPKRYNLoP+wUksaD0SZD9+s8hxHreG99v lVk9EqlVtndwxRVg/pUd2+La07+IOgyp8IWbcN8K/hgMu8wC56lCxCRHaLdQwif9 31fCosN9X+eAIQcCzT2nV3fE5VNB4W6/IXAGn5i5bgCNPcVXSuWAsn3uefNE1iFo Fir31NhWLdp7rH1F9WxN0uYxTCwYzrkJ/hxbntyonpxirPTVmlFxe/mOFbApGpdz AvHbwoToTg5Cjz2rRGUxq55PvXpb0iowi+jnf0g+DCuLekqkK72pJzFg1Wh1l8mF VIic3nV9xh7pgbtzlqwH4Jwfc0ua8Cqbbnjn9BCjmOp8oHPdoPNIvpb2Cqbh5aAt gjv7DKDbQmzeITJ8zweAqM+Q6CqbSsCuRH8SjkA/qplO3E6+k+bQdFznrhqii50w NH0V2TmPjLYLECAwpA9+djdhRSOiycS81xIvqCeE8o7skfe9NN/86kpQ9RaZbJwH SvmfKUCE9+XgMdBaHOAmd1uym+LRW/MX/MtKJfw0py3+GEhvO4zuBX2nQHe012IU iSjsx4xkTxPJbBYXzc1jJiOYPkHh1PDryebKwwYohZpGbJHwwGvH7sD7TdvzAJxs KJYCka5rSwpv6gtcIVEdkg2c3Url3e9WMieLDktk6NX8RuiUTQKR6O7lcqyqJwMB I5pWRPDaLVZGFHOnhEw/ =mOIy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CVE-2014-7810 Mitigation
Lynch, Charles [USA] wrote: Seeking guidance on mitigation of CVE-2014-7810http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7810 on Apache Tomcat 6.0.37. Upgrading to 6.0.43 is not an option for my team at the moment, and we need to secure our install via other means until the patch can be applied. If there are any workaround that can be provided it would be much appreciated. Thank you. Hi. Maybe the first thing to ask yourself, is if you are in a situation where you are really vulnerable to this vulnerability. I am not an expert, but from the description, it sounds like this vulnerability could only be exploited by someone who has the possibility to load a malicious web application into the Tomcat system, and have it be run. Is that your case ? See http://mail-archives.apache.org/mod_mbox/www-announce/201505.mbox/%3c5554ab1c.7050...@apache.org%3E - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [External] Re: CVE-2014-7810 Mitigation
Lynch, Charles [USA] wrote: Thank you. I am fairly unfamiliar with Apache as a whole. Simply trying to address our possible attack surfaces. I appreciate your assistance. Welcome. By the way, I found the reference to the article below by entering this on Google : CVE-2014-7810 and Tomcat So if you have any more similar issues.. The references at the bottom of that article may also be of help : [1] http://tomcat.apache.org/security-8.html [2] http://tomcat.apache.org/security-7.html [3] http://tomcat.apache.org/security-6.html (or not, as the case may be. But it is always better to be informed, isn't it ?) From: André Warnier [a...@ice-sa.com] Sent: Thursday, June 25, 2015 8:32 AM To: Tomcat Users List Subject: Re: [External] Re: CVE-2014-7810 Mitigation Lynch, Charles [USA] wrote: You are saying a malicious actor would need to be on the server itself to load an application? Basically yes, or be allowed to load and deploy applications via the Manager application (which is either not installed, or anyway secured by default) It is fairly clear in the mail archive article I quoted below, which is signed by one of the core Tomcat developers. From: André Warnier [a...@ice-sa.com] Sent: Thursday, June 25, 2015 7:55 AM To: Tomcat Users List Subject: [External] Re: CVE-2014-7810 Mitigation Lynch, Charles [USA] wrote: Seeking guidance on mitigation of CVE-2014-7810http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7810 on Apache Tomcat 6.0.37. Upgrading to 6.0.43 is not an option for my team at the moment, and we need to secure our install via other means until the patch can be applied. If there are any workaround that can be provided it would be much appreciated. Thank you. Hi. Maybe the first thing to ask yourself, is if you are in a situation where you are really vulnerable to this vulnerability. I am not an expert, but from the description, it sounds like this vulnerability could only be exploited by someone who has the possibility to load a malicious web application into the Tomcat system, and have it be run. Is that your case ? See http://mail-archives.apache.org/mod_mbox/www-announce/201505.mbox/%3c5554ab1c.7050...@apache.org%3E - 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: [External] Re: CVE-2014-7810 Mitigation
You are saying a malicious actor would need to be on the server itself to load an application? From: André Warnier [a...@ice-sa.com] Sent: Thursday, June 25, 2015 7:55 AM To: Tomcat Users List Subject: [External] Re: CVE-2014-7810 Mitigation Lynch, Charles [USA] wrote: Seeking guidance on mitigation of CVE-2014-7810http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7810 on Apache Tomcat 6.0.37. Upgrading to 6.0.43 is not an option for my team at the moment, and we need to secure our install via other means until the patch can be applied. If there are any workaround that can be provided it would be much appreciated. Thank you. Hi. Maybe the first thing to ask yourself, is if you are in a situation where you are really vulnerable to this vulnerability. I am not an expert, but from the description, it sounds like this vulnerability could only be exploited by someone who has the possibility to load a malicious web application into the Tomcat system, and have it be run. Is that your case ? See http://mail-archives.apache.org/mod_mbox/www-announce/201505.mbox/%3c5554ab1c.7050...@apache.org%3E - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [External] Re: CVE-2014-7810 Mitigation
Thank you. I am fairly unfamiliar with Apache as a whole. Simply trying to address our possible attack surfaces. I appreciate your assistance. From: André Warnier [a...@ice-sa.com] Sent: Thursday, June 25, 2015 8:32 AM To: Tomcat Users List Subject: Re: [External] Re: CVE-2014-7810 Mitigation Lynch, Charles [USA] wrote: You are saying a malicious actor would need to be on the server itself to load an application? Basically yes, or be allowed to load and deploy applications via the Manager application (which is either not installed, or anyway secured by default) It is fairly clear in the mail archive article I quoted below, which is signed by one of the core Tomcat developers. From: André Warnier [a...@ice-sa.com] Sent: Thursday, June 25, 2015 7:55 AM To: Tomcat Users List Subject: [External] Re: CVE-2014-7810 Mitigation Lynch, Charles [USA] wrote: Seeking guidance on mitigation of CVE-2014-7810http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7810 on Apache Tomcat 6.0.37. Upgrading to 6.0.43 is not an option for my team at the moment, and we need to secure our install via other means until the patch can be applied. If there are any workaround that can be provided it would be much appreciated. Thank you. Hi. Maybe the first thing to ask yourself, is if you are in a situation where you are really vulnerable to this vulnerability. I am not an expert, but from the description, it sounds like this vulnerability could only be exploited by someone who has the possibility to load a malicious web application into the Tomcat system, and have it be run. Is that your case ? See http://mail-archives.apache.org/mod_mbox/www-announce/201505.mbox/%3c5554ab1c.7050...@apache.org%3E - 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: [External] Re: CVE-2014-7810 Mitigation
Lynch, Charles [USA] wrote: You are saying a malicious actor would need to be on the server itself to load an application? Basically yes, or be allowed to load and deploy applications via the Manager application (which is either not installed, or anyway secured by default) It is fairly clear in the mail archive article I quoted below, which is signed by one of the core Tomcat developers. From: André Warnier [a...@ice-sa.com] Sent: Thursday, June 25, 2015 7:55 AM To: Tomcat Users List Subject: [External] Re: CVE-2014-7810 Mitigation Lynch, Charles [USA] wrote: Seeking guidance on mitigation of CVE-2014-7810http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7810 on Apache Tomcat 6.0.37. Upgrading to 6.0.43 is not an option for my team at the moment, and we need to secure our install via other means until the patch can be applied. If there are any workaround that can be provided it would be much appreciated. Thank you. Hi. Maybe the first thing to ask yourself, is if you are in a situation where you are really vulnerable to this vulnerability. I am not an expert, but from the description, it sounds like this vulnerability could only be exploited by someone who has the possibility to load a malicious web application into the Tomcat system, and have it be run. Is that your case ? See http://mail-archives.apache.org/mod_mbox/www-announce/201505.mbox/%3c5554ab1c.7050...@apache.org%3E - 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
CVE-2014-7810 Mitigation
Seeking guidance on mitigation of CVE-2014-7810http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7810 on Apache Tomcat 6.0.37. Upgrading to 6.0.43 is not an option for my team at the moment, and we need to secure our install via other means until the patch can be applied. If there are any workaround that can be provided it would be much appreciated. Thank you. Chuck Lynch
Re: Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
Le 25 juin 2015 à 10:40, André Warnier a...@ice-sa.com a écrit : Pascal Abaziou wrote: Le 25 juin 2015 à 00:23, Mark Eggers its_toas...@yahoo.com.INVALID a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2015 2:40 PM, André Warnier wrote: Pascal Abaziou wrote: Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. You know, I don't want to discourage you, but.. Assuming even that this was a bug that was fixed on its own, and not some side-effect of some other change.. As you know, Tomcat is an open-source and free software, developed and supported by volunteers, who apart from their Tomcat involvement, all have a paying job which they do on the side.. This user's list is the same. Tomcat 6.0.24 is at least 5 years old. The current Tomcat version is 8.0.23. Between these two, there are 5 years and probably close to 100 versions. Some of these versions correct real bugs or security issues which could leave any lower version vulnerable to hacking. The Tomcat developers, having a limited amount of time to dedicate to it, rather understandably prefer to spend this time working on and supporting the latest version, rather than very old ones. All of this to say that unless there is a very strong incentive for someone to go and dig through the documentation and the code, your chances of getting real help on this apparently minor and peripheral issue, affecting an old version of Tomcat but not more recent ones, are really slim. If your sysadmin does not understand the benefits of upgrading to a more recent version, rather than this very old one, then the problem is with him, not with you and not with the Tomcat developers. Maybe you should just take the change logs, starting with 6.0.44 and working back to 6.0.24, append them to one another, and send this to him as a token of what he is missing in terms of bug corrections and security fixes, by /not/ upgrading. And if he still does not understand the issue, or cannot give you a better reason to want to stay with 6.0.24, send the list to his boss. There's another issue when comparing vendor-packaged versus Apache-distributed Tomcat versions. Vendors often backport various fixes from later Apache-distributed versions to vendor-packaged versions. For example, you may see the following in RedHat (I'm running Fedora 22 or CentOS 6) distributions: CentOS 6 Name: tomcat6 Arch: x86_64 Version : 6.0.24 Release : 83.el6_6 Size: 92 k Repo: updates First of all, you have to select Tomcat 6 as opposed to Tomcat on CentOS 6.6. I understand that the Tomcat 7 version is only available in the EPEL repository. Here's the information for tomcat.noarch from the EPEL repository. Name: tomcat Arch: noarch Version : 7.0.33 Release : 4.el6 Size: 86 k Repo: epel The key thing to look at in both of these listings is the Release tag. RedHat (and I suppose other vendors) release updates to their packages that include backports for certain issues. In general, RedHat addresses security issues, but avoids backporting API changes between releases of their Linux platform. It is very difficult to compare RedHat's version of 6.0.24 or 7.0.33 with the Apache release. You would have to compare both sets of change logs to find out how RedHat's release compared to Apache's release. Then, since it doesn't appear that this particular problem was uniquely identified in the Apache Tomcat changelogs, you would have to determine what change (and when) fixed the issue. Finally, you would then have to lobby RedHat to include the appropriate change into their repackaging of Tomcat. Lots of work . . . This is one of the reasons why most people on the list advocate using Apache-distributed packages. In the end, it's easier for everyone (mailing list members, Apache Tomcat users, and system administrators). As André pointed out above, this is a system administrator issue, not a Tomcat issue. If there are policies in place that preclude third party packaged applications running in production, then there are also corporate policy issues. In short, there are few reasons to stay with a vendor-distributed packaging of Tomcat, and quite a few good
Re: Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
Le 25 juin 2015 à 21:45, Pascal Abaziou pascal.abaz...@gmail.com a écrit : Le 25 juin 2015 à 10:40, André Warnier a...@ice-sa.com mailto:a...@ice-sa.com a écrit : Pascal Abaziou wrote: Le 25 juin 2015 à 00:23, Mark Eggers its_toas...@yahoo.com.INVALID mailto:its_toas...@yahoo.com.INVALID a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2015 2:40 PM, André Warnier wrote: Pascal Abaziou wrote: Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. You know, I don't want to discourage you, but.. Assuming even that this was a bug that was fixed on its own, and not some side-effect of some other change.. As you know, Tomcat is an open-source and free software, developed and supported by volunteers, who apart from their Tomcat involvement, all have a paying job which they do on the side.. This user's list is the same. Tomcat 6.0.24 is at least 5 years old. The current Tomcat version is 8.0.23. Between these two, there are 5 years and probably close to 100 versions. Some of these versions correct real bugs or security issues which could leave any lower version vulnerable to hacking. The Tomcat developers, having a limited amount of time to dedicate to it, rather understandably prefer to spend this time working on and supporting the latest version, rather than very old ones. All of this to say that unless there is a very strong incentive for someone to go and dig through the documentation and the code, your chances of getting real help on this apparently minor and peripheral issue, affecting an old version of Tomcat but not more recent ones, are really slim. If your sysadmin does not understand the benefits of upgrading to a more recent version, rather than this very old one, then the problem is with him, not with you and not with the Tomcat developers. Maybe you should just take the change logs, starting with 6.0.44 and working back to 6.0.24, append them to one another, and send this to him as a token of what he is missing in terms of bug corrections and security fixes, by /not/ upgrading. And if he still does not understand the issue, or cannot give you a better reason to want to stay with 6.0.24, send the list to his boss. There's another issue when comparing vendor-packaged versus Apache-distributed Tomcat versions. Vendors often backport various fixes from later Apache-distributed versions to vendor-packaged versions. For example, you may see the following in RedHat (I'm running Fedora 22 or CentOS 6) distributions: CentOS 6 Name: tomcat6 Arch: x86_64 Version : 6.0.24 Release : 83.el6_6 Size: 92 k Repo: updates First of all, you have to select Tomcat 6 as opposed to Tomcat on CentOS 6.6. I understand that the Tomcat 7 version is only available in the EPEL repository. Here's the information for tomcat.noarch from the EPEL repository. Name: tomcat Arch: noarch Version : 7.0.33 Release : 4.el6 Size: 86 k Repo: epel The key thing to look at in both of these listings is the Release tag. RedHat (and I suppose other vendors) release updates to their packages that include backports for certain issues. In general, RedHat addresses security issues, but avoids backporting API changes between releases of their Linux platform. It is very difficult to compare RedHat's version of 6.0.24 or 7.0.33 with the Apache release. You would have to compare both sets of change logs to find out how RedHat's release compared to Apache's release. Then, since it doesn't appear that this particular problem was uniquely identified in the Apache Tomcat changelogs, you would have to determine what change (and when) fixed the issue. Finally, you would then have to lobby RedHat to include the appropriate change into their repackaging of Tomcat. Lots of work . . . This is one of the reasons why most people on the list advocate using Apache-distributed packages. In the end, it's easier for everyone (mailing list members, Apache Tomcat users, and system administrators). As André pointed out above, this is a system administrator issue, not a Tomcat issue. If there are policies in place that preclude third party packaged applications running in production, then there are
Filter behaviour
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException
Assuming you have only a single Filter configured in web.xml
Assuming you have logic in a doFilter that checks the value of a boolean.
If the boolean is true, then assume you send a http status code back and
use a return in the if condition.
example:
if (someConditionIsTrue)
{
HttpServletResponse httpResponse = (HttpServletResponse)
response;
httpResponse.sendError(HttpServletResponse.WHATEVER_YOU_CHOOSE);
return;
}
chain.doFilter(request, response);
My question is:
If the chain is placed inside an else, which would not run if the condition
is true, does that violate the Filter in any way? In other words, if one
does not call chain.doFilter within a doFilter method, should one expect
something bad?
What I'm really saying without saying it is, whether I call chain.doFilter
in or out of an else, on Tomcat I get the sendError status that I expect,
but not from other containers. I realize that statement is moot on this
list, but I thought I would share it.
Are there any conditions in which Tomcat will decide what to do on its own,
related to sendError, when it can't figure it out from code?
Leo
Using CATALINA_BASE: C:\apache-tomcat\apache-tomcat-7.0.62
Using CATALINA_HOME: C:\apache-tomcat\apache-tomcat-7.0.62
Using CATALINA_TMPDIR: C:\apache-tomcat\apache-tomcat-7.0.62\temp
Using JRE_HOME:C:\Program Files (x86)\Java\jdk1.7.0_67
Using CLASSPATH:
C:\apache-tomcat\apache-tomcat-7.0.62\bin\bootstrap.jar;C:\apache-tomcat\apache-tomcat-7.0.62\bin\tomcat-juli.jar
Server version: Apache Tomcat/7.0.62
Server built: May 7 2015 17:14:55 UTC
Server number: 7.0.62.0
OS Name:Windows 7
OS Version: 6.1
Architecture: x86
JVM Version:1.7.0_67-b01
JVM Vendor: Oracle Corporation
Re: Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
Le 25 juin 2015 à 16:16, Christopher Schultz ch...@christopherschultz.net a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pascal, On 6/25/15 10:01 AM, Christopher Schultz wrote: Pascal, On 6/24/15 4:23 PM, Pascal Abaziou wrote: Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. This is more compelling reading: http://tomcat.apache.org/security-6.html Here are some issues you may want to specifically be aware of (search for them in the text of the above document): CVE-2012-0022 CVE-2012-4534 CVE-2012-2733 CVE-2012-3544/CVE-2013-4322 CVE-2005-2090/CVE-2013-4286 CVE-2014-0099 CVE-2014-0075 CVE-2014-0227 - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjA07AAoJEBzwKT+lPKRY3/wP/0AryA0WY6uek7TLhNg/G+dT hSFoVPNohDsKde2BP+kdCabBRVUnqe2b5rRID0CuGQe4Ve5RCzdmwQtXoJEvySNW WEiQVIKO4sg3D3ihrAAyDtWKKSwlHr8PY9R+J80yPATfKKdGjvAJkRMe1CxCGbZ9 hcU3F7g86h7dnqh2nL3EcfscCT/4E+0QXmrEaNWluMD2acCYFcfJRVzLpo+vTP7B exrOdlgPp4TWPt/StzoDIrJ00daI6y0rYtgQSNrKIXFGVgCB7PsEpDQoQ2fcLHkD QVUl5EfAIP4/oWSnLjh7Ncj2x/gp15yc3oR/EkBNgeqxVPzB+y0UHTrn7p6CzlED bVxFzOCdBCFHGqIuZi1hR26TIbHOu3XJlBBafpVD2kxJnKgyo5mjpxj/mMNVwX2A Wj/NHtmieKMRIqTKlqXyIFEYBBrzYVNNjRPmIR/ghPwGRntw45x2eEuzZLL49f1O NXIwiuf80H5pjrmMt/dWztRlq5QlyqFtxf/xMSNtWu1tnfG6OJI2Nsmtc1MCCXmu apZx3Em+lohCEh9/ElX8ZlKGJ2AsjhI6WNXvcS3uE7/8zInCU/P04y+QI9Zw/w/F jQAJ4gSarQAyk+hDKtSHcC2LfeExhbRR9upONF/P3wPOZukWN/T6ZJsMelhpzx/m /aJbYhiVNM9fmo6bfLww =ywXV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Christopher, Many thanks for the link. It will be very helpful. Regards, Pascal - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pascal, On 6/24/15 4:23 PM, Pascal Abaziou wrote: Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. This is more compelling reading: http://tomcat.apache.org/security-6.html - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjAm1AAoJEBzwKT+lPKRYt44P/i1/LNARWLb338irCjQIoVlE wQM6/q+w7vRtlfMLKcv4KfrV4k5NWxXIKey+dInAZ8Bk882BUJ4PSM7cOagnRrkT JrEUhsqEwk5vHhb4t7AM39CwvfYyaUmKQYA0zQcAqq4E/ZKwRNhByUr7JTub+jM7 kLun0Gu7lF8UL18Z+UHc3qNB/CNUc9aWm1d/pykerAGDqYxIdKYEPXjNwCryGy89 QL03qJ3Kqpus/kQUN1/5ni6HebNkAiF3ykZyMuMD8weDJyRqlZN74hlfkHu+HLCk JWmG92NwrZjkoHkcWqqi03ZypGRgIxjDmxlnXfV+aiK7t61vicIVkFUK1+x4CXB3 9J5PsOo0F+lvfozVVpv28Gp0Bsd0UQ2ADF1rydNhvgiBIqzHirpbzfJqUJHKdcOY tHYX1T7iVyKieRtDhnszrNsarSg3ZqOJTTcFrCjpFw50N+031kwl5ffNZvuolUT/ kIczNsQeH3yPsRGrTHXUxT/uxy+FvqcKwI7dOIxyQC5ekVIy5q4aIRZZzWCwzLH5 GQ3B4vsDfrLB9iGdeP8+JhReGBQDuh4mAsslg+V3KIFJYQJ+tpGs2d9qhpF93rbe VO0nHU4pCAQ+Q7sNWL4sNIt5ehcjhGyvctSJXBZgRfwsBlAHWBB9FU3enPaRRruW atE5j2bmMXxQANogZAvs =QBKG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can i use Tomcat 7 catalina-ws.jar in Tomcat 8???
On 06/25/2015 04:45 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Agharta, On 6/25/15 10:30 AM, agharta wrote: On 06/25/2015 03:51 PM, Christopher Schultz wrote: Agharta, On 6/25/15 2:39 AM, agharta wrote: On 06/24/2015 06:04 PM, Christopher Schultz wrote: Agharta, On 6/24/15 11:17 AM, agharta wrote: Hi all, A rapid question: colud i place the tomcat 7 catalina-ws.jar inside a new tomcat 8 installation ? Why would you want to do something like that? Because i have many customers, with many different versions of tomcat 7/8 and i'm trying to keep libs update method most simple as possible. Having no per-tomcat-version-libs solves me that problem. Why not just use the libraries that Tomcat already provides? Are you using a Tomcat-specific API for something? If so, what is that API you are using? I'm not using any particular tomcat-specific api (except catalina-ws, needed by jax-ws web services). Simple, catalina-ws.jar is not provided with default tomcat installation, but should be placed manually. To do that, i should: 1) Detect tomcat version (7.x, 8.x) 2) Get the right catalina-ws.jar 3) Place (replace in case of upgrade) the catalina-ws.jar 4) Keep tomcat-catalina-ws track version for future upgrades. Do you have an installer process of any kind, or are all upgrades done by hand? Detecting the version of Tomcat should be easy, and then you just have to make sure the various catalina-ws.jar files are available. Since you can always pull-down the distro from the ASF, they should always be available (unless you are on a server that does not allow outgoing HTTP connections to the outside world). You could also package all of the catalina-ws.jar versions necessary in your installer... No installer, all upgrades are by hand :( Some customers have a public internet access, others are in a restricted lan :((( I have about 80 customers with about 20 different versions of tomcat (7.x 8.x.too much, i known.) and i'm searching a quick update method. Something like stop copy/replace jars and wars cleanup start. If you are willing to package one version of catalina-ws.jar, you could package other versions as well. Are you managing the Tomcat installation for your customers? If so, why not upgrade them to a common version? If not, why not just tell your customer that a prerequisite of your product is that catalina-ws.jar is installed and up-to-date? I'm the maintainer, but the company upgrade policy is upgrade only if it necessary. So, the facts are: 1) Some old customers, upgraded years ago with old tomcat version and old war version... 2) A bit of new customers with new tomcat version and wars 3) A lot of keep updated customers, with quite recent tomcat and fresh wars The keep tomcat/webapps upgraded policy can not be applied because: 1) Company policy (too much spent time to upgrade, customer is already satisfied, etci known, it's not a good policy, but i'm in italysorry ..) 2) Customers are in the National Health System category, so they have 24*7 uptime, cluster, etc, so a stop restart should be done with care/speed and should be scheduled I hope I have been clear, sorry if not. An offtopic question: do you known why catalina-ws.jar is an optional lib?? Because it's not a part of the main supported APIs: Servlet, JSP, EL, and Websocket. I'm not entirely sure if catalina-ws.jar contains anything Tomcat-version-specific. You could test your own web application against that kind of thing if you wanted to be sure. I'm sorry, but I don't know the answer. You could always use another JSR109 implementation -- one that wasn't sensitive to the Tomcat version. Or use something like Apache Axis2 which, while not being JSR-109-compliant (I think), still supports web services. It's a bit old, though. There is also Apache CXF, which is under active development and probably supports all of the new-fangled things web-services types expect from a support library. Thanks so much for your suggestions, Best regards, Agharta - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjBQmAAoJEBzwKT+lPKRYB1YQAMKv85SrgjnIpl9ScB0GRpW1 1oE8EjIVXSzrQFDKlex7ewyc4qTreVAELBcCUAM/uGTYllekXN94mMdmYUwvLi4b /yOovNnsbMnY7qPqrkzEgOJnSJKv77VSadWa9UIoomviZTA9k2dS5D5+GkkBATxf WqmfMesFsfBVqGAkgKAT4iq4nhQloDUmDwfIs6a8IozjPq2UG2tJDidqTpJWBaQw g8WdPByb1a6vj+S/OUKv0cXMn95fi7f3RpJVFGgnxKQ4OfsldrZH72K6w9u3BeFd 36qPUP4OwFcX4xh+4oBZABE03e6sGitPouKn0xTaprqsWOPydcz4Ly4Ap81PdKa5 lcqY/fPSOOQB+p/+/x4E1FDj3kvMxXEMXuN9tedcPbIxjWjhpzEcwrl4SSljOHQl 5AUha8Tqd14l/1lK2QOwDwLrr7cxDQXNcJEgRdUK0y47td8nDz/I2uYWHTuRbcaa XY6Db3ZK4PZUeWkR9MvYhHphVtX6sPthUD4UNsIywJq1DTpq3ZrMF3ccSnRVwSuC icphIAg0TyYgTBz6SUJ6xjT7NjajyQirMazHvJ/xmfVVkUfAYqUOveLaO/BZSJbT e9M9nAzz8gO69KYwWB21dhz8xbX+WCtkV/fMfG8PYReVS2lJH9IgXjefYSijRmqs SQU4q8OlusduFfMc9eEy =fnY7 -END PGP SIGNATURE-
Re: Can i use Tomcat 7 catalina-ws.jar in Tomcat 8???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Agharta, On 6/25/15 10:30 AM, agharta wrote: On 06/25/2015 03:51 PM, Christopher Schultz wrote: Agharta, On 6/25/15 2:39 AM, agharta wrote: On 06/24/2015 06:04 PM, Christopher Schultz wrote: Agharta, On 6/24/15 11:17 AM, agharta wrote: Hi all, A rapid question: colud i place the tomcat 7 catalina-ws.jar inside a new tomcat 8 installation ? Why would you want to do something like that? Because i have many customers, with many different versions of tomcat 7/8 and i'm trying to keep libs update method most simple as possible. Having no per-tomcat-version-libs solves me that problem. Why not just use the libraries that Tomcat already provides? Are you using a Tomcat-specific API for something? If so, what is that API you are using? I'm not using any particular tomcat-specific api (except catalina-ws, needed by jax-ws web services). Simple, catalina-ws.jar is not provided with default tomcat installation, but should be placed manually. To do that, i should: 1) Detect tomcat version (7.x, 8.x) 2) Get the right catalina-ws.jar 3) Place (replace in case of upgrade) the catalina-ws.jar 4) Keep tomcat-catalina-ws track version for future upgrades. Do you have an installer process of any kind, or are all upgrades done by hand? Detecting the version of Tomcat should be easy, and then you just have to make sure the various catalina-ws.jar files are available. Since you can always pull-down the distro from the ASF, they should always be available (unless you are on a server that does not allow outgoing HTTP connections to the outside world). You could also package all of the catalina-ws.jar versions necessary in your installer... I have about 80 customers with about 20 different versions of tomcat (7.x 8.x.too much, i known.) and i'm searching a quick update method. Something like stop copy/replace jars and wars cleanup start. If you are willing to package one version of catalina-ws.jar, you could package other versions as well. Are you managing the Tomcat installation for your customers? If so, why not upgrade them to a common version? If not, why not just tell your customer that a prerequisite of your product is that catalina-ws.jar is installed and up-to-date? I hope I have been clear, sorry if not. An offtopic question: do you known why catalina-ws.jar is an optional lib?? Because it's not a part of the main supported APIs: Servlet, JSP, EL, and Websocket. I'm not entirely sure if catalina-ws.jar contains anything Tomcat-version-specific. You could test your own web application against that kind of thing if you wanted to be sure. I'm sorry, but I don't know the answer. You could always use another JSR109 implementation -- one that wasn't sensitive to the Tomcat version. Or use something like Apache Axis2 which, while not being JSR-109-compliant (I think), still supports web services. It's a bit old, though. There is also Apache CXF, which is under active development and probably supports all of the new-fangled things web-services types expect from a support library. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjBQmAAoJEBzwKT+lPKRYB1YQAMKv85SrgjnIpl9ScB0GRpW1 1oE8EjIVXSzrQFDKlex7ewyc4qTreVAELBcCUAM/uGTYllekXN94mMdmYUwvLi4b /yOovNnsbMnY7qPqrkzEgOJnSJKv77VSadWa9UIoomviZTA9k2dS5D5+GkkBATxf WqmfMesFsfBVqGAkgKAT4iq4nhQloDUmDwfIs6a8IozjPq2UG2tJDidqTpJWBaQw g8WdPByb1a6vj+S/OUKv0cXMn95fi7f3RpJVFGgnxKQ4OfsldrZH72K6w9u3BeFd 36qPUP4OwFcX4xh+4oBZABE03e6sGitPouKn0xTaprqsWOPydcz4Ly4Ap81PdKa5 lcqY/fPSOOQB+p/+/x4E1FDj3kvMxXEMXuN9tedcPbIxjWjhpzEcwrl4SSljOHQl 5AUha8Tqd14l/1lK2QOwDwLrr7cxDQXNcJEgRdUK0y47td8nDz/I2uYWHTuRbcaa XY6Db3ZK4PZUeWkR9MvYhHphVtX6sPthUD4UNsIywJq1DTpq3ZrMF3ccSnRVwSuC icphIAg0TyYgTBz6SUJ6xjT7NjajyQirMazHvJ/xmfVVkUfAYqUOveLaO/BZSJbT e9M9nAzz8gO69KYwWB21dhz8xbX+WCtkV/fMfG8PYReVS2lJH9IgXjefYSijRmqs SQU4q8OlusduFfMc9eEy =fnY7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pascal, On 6/25/15 10:01 AM, Christopher Schultz wrote: Pascal, On 6/24/15 4:23 PM, Pascal Abaziou wrote: Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. This is more compelling reading: http://tomcat.apache.org/security-6.html Here are some issues you may want to specifically be aware of (search for them in the text of the above document): CVE-2012-0022 CVE-2012-4534 CVE-2012-2733 CVE-2012-3544/CVE-2013-4322 CVE-2005-2090/CVE-2013-4286 CVE-2014-0099 CVE-2014-0075 CVE-2014-0227 - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjA07AAoJEBzwKT+lPKRY3/wP/0AryA0WY6uek7TLhNg/G+dT hSFoVPNohDsKde2BP+kdCabBRVUnqe2b5rRID0CuGQe4Ve5RCzdmwQtXoJEvySNW WEiQVIKO4sg3D3ihrAAyDtWKKSwlHr8PY9R+J80yPATfKKdGjvAJkRMe1CxCGbZ9 hcU3F7g86h7dnqh2nL3EcfscCT/4E+0QXmrEaNWluMD2acCYFcfJRVzLpo+vTP7B exrOdlgPp4TWPt/StzoDIrJ00daI6y0rYtgQSNrKIXFGVgCB7PsEpDQoQ2fcLHkD QVUl5EfAIP4/oWSnLjh7Ncj2x/gp15yc3oR/EkBNgeqxVPzB+y0UHTrn7p6CzlED bVxFzOCdBCFHGqIuZi1hR26TIbHOu3XJlBBafpVD2kxJnKgyo5mjpxj/mMNVwX2A Wj/NHtmieKMRIqTKlqXyIFEYBBrzYVNNjRPmIR/ghPwGRntw45x2eEuzZLL49f1O NXIwiuf80H5pjrmMt/dWztRlq5QlyqFtxf/xMSNtWu1tnfG6OJI2Nsmtc1MCCXmu apZx3Em+lohCEh9/ElX8ZlKGJ2AsjhI6WNXvcS3uE7/8zInCU/P04y+QI9Zw/w/F jQAJ4gSarQAyk+hDKtSHcC2LfeExhbRR9upONF/P3wPOZukWN/T6ZJsMelhpzx/m /aJbYhiVNM9fmo6bfLww =ywXV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [External] Re: CVE-2014-7810 Mitigation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 6/25/15 8:32 AM, André Warnier wrote: Lynch, Charles [USA] wrote: You are saying a malicious actor would need to be on the server itself to load an application? Basically yes, or be allowed to load and deploy applications via the Manager application (which is either not installed, or anyway secured by default). Correct: this CVE indicates that Tomcat is vulnerable to a malicious web application, not to a remote user. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjA4hAAoJEBzwKT+lPKRYyAMP/2IxiSl7O29dCh7kxmTxlGCc rPBxz+gOFhjunR9DgZsxX+KKL1NeTl/L08lZ4qAXj4+lqZJ49Mmmr55A+QSeIJYa L/fGOKC7W5kFsqxLJ+wXWLMEUsA7eLgWDPxysrqQGDkyw6z9C08s7qoIDtakp53e jpeAFPElemuylrtAS4tzzlpuYPUX+OmaMO5yT9KIFoQJFuiEn3y/sDR2FjX8BEdr k2SwtJ97Zs/Tq889QuLxzHrSZCZMwpeFu3NYYJjCZWAyc6hvX5PKBrTfdKIIe4Ox l7VNJun14aZ5soIob7XreIJKm9RJR5GhHvzY6g+lGXbT/6pWEBZAf3uRxsZaF186 K1Ybtx4BMVZEZB9ZtpY01pfKUaTW3CrmunUWcZ1QuW8OgXfewzdDBmdlEf+VmwLW JdwXQfHike+TT4PL+VKcOKQ9tjwkhylQ/OH0hztOVFxDdhjjDZ3dsWkbClrTVw/k ajhzyrimEbweAFAvmByb2Q08Xlp7AR7hiAruRFAKUmi5/zaCjVRB44Gke4CxjD5g tx0NANroy3fpqGxAJedJ9tWHq7GyuudHJtrqFtufB6h/JNAt1kdFC+ZkPf7TDy/b VgsXAj/7wYCRpcG+56whKE+VZSplBzTwTMwHfuAtlhTqGKHSw46I8wgWFlcoS3QB Ho0Eg/eDBqW9R6dD8AN5 =vEEP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can i use Tomcat 7 catalina-ws.jar in Tomcat 8???
On 06/25/2015 03:51 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Agharta, On 6/25/15 2:39 AM, agharta wrote: On 06/24/2015 06:04 PM, Christopher Schultz wrote: Agharta, On 6/24/15 11:17 AM, agharta wrote: Hi all, A rapid question: colud i place the tomcat 7 catalina-ws.jar inside a new tomcat 8 installation ? Why would you want to do something like that? Because i have many customers, with many different versions of tomcat 7/8 and i'm trying to keep libs update method most simple as possible. Having no per-tomcat-version-libs solves me that problem. Why not just use the libraries that Tomcat already provides? Are you using a Tomcat-specific API for something? If so, what is that API you are using? I'm not using any particular tomcat-specific api (except catalina-ws, needed by jax-ws web services). Simple, catalina-ws.jar is not provided with default tomcat installation, but should be placed manually. To do that, i should: 1) Detect tomcat version (7.x, 8.x) 2) Get the right catalina-ws.jar 3) Place (replace in case of upgrade) the catalina-ws.jar 4) Keep tomcat-catalina-ws track version for future upgrades. I have about 80 customers with about 20 different versions of tomcat (7.x 8.x.too much, i known.) and i'm searching a quick update method. Something like stop copy/replace jars and wars cleanup start. I hope I have been clear, sorry if not. An offtopic question: do you known why catalina-ws.jar is an optional lib?? Thanks a lot, Best regards, Agharta - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjAd/AAoJEBzwKT+lPKRYs1MQAJI0RGajVD/uSi36KIh3GySb Yn2Sz7+zpZ+p0IjYpcayd/2SxIBLVjgl6GtIK2IreHO+8lON7P4tGAMPXnEFYMYl zVsNYQqsJVhp6Bl7THU7Qemypden22A7YgdfN1+X6t79oT587XNLKy/146m/Yaqm V4aJIsjKBFU29hVpmFiKDOdLMNn/+sWpZ0R2kDa1L7rDEVWlekYolqza5XO987fm H/KW55IYuWGjpISLPueXpsotkKcS/VDXOTMWiBVxH4wu+BXYqJNoj2Zieh4fPNkF kwUhxgk7oU6c633e5HZ11RGEitp8nSYZs7mw4icAl74K/YuFGDu2WQfkQggCUk/G u3o+hvANZyBuqL8kDlUHl1/sFNTbXkXOa0GwlXgIxUEND3VPwPqcRoOhorAPFynD pgDUlBqVVTS9wUAdSj42sJcqeJPKm6p3ZPgDdYOAKmSqqYHDeP7TS3+wn54ihWer YOrKeC5njOVyYcZEpnVHjEgDzN68JW49Vzwvl9HQV+ZYWcxi60LyI6yhuoHuboxv cXLVNLm87D7y32N36VQBQiPCyci/VZGcK+sQpyfYVgRvP2FpnnUWZwcQ3fzzTpwO TWWbOFW1Kk1x4qHCUQLlRV9e9ifzvSkODyQTsCbrCKitzUHMRACc/6EkmYYGcEQG 18zpzmV9wrmyZFzvNlaW =d+Fy -END PGP SIGNATURE- - 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
Tomcat - OOM Perm gen
Hi All, I have 2 web apps sitting on single tomcat instance, App A( Classic JSP/Servlet/jstl/velocity App) and App B (Struts2 based app). Now I have added S2 to App A and trying to fix some bad code in it with it.But after making this change I keep getting out of OOM issues once user count reaches to 75 + and App A seems to be bringing App B down with it. Below is trace I get in catalina out log. I think I can increase memory but it will not solve this and I have hard limit of memory with hosting provider. Is their anything in tomcat that I need to enable which can give me some mileage ? How do I fix this ? Jun 24, 2015 6:49:19 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.lang.OutOfMemoryError: PermGen space at com.sun.beans.infos.ComponentBeanInfo.clinit(ComponentBeanInfo.java:35) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:525) at java.lang.Class.newInstance0(Class.java:374) at java.lang.Class.newInstance(Class.java:327) at com.sun.beans.finder.InstanceFinder.instantiate(InstanceFinder.java:96) at com.sun.beans.finder.InstanceFinder.instantiate(InstanceFinder.java:107) at com.sun.beans.finder.BeanInfoFinder.instantiate(BeanInfoFinder.java:63) at com.sun.beans.finder.BeanInfoFinder.instantiate(BeanInfoFinder.java:41) at com.sun.beans.finder.InstanceFinder.find(InstanceFinder.java:81) at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:436) at java.beans.Introspector.init(Introspector.java:386) at java.beans.Introspector.getBeanInfo(Introspector.java:161) at java.beans.Introspector.getBeanInfo(Introspector.java:248) at java.beans.Introspector.init(Introspector.java:395) at java.beans.Introspector.getBeanInfo(Introspector.java:161) at java.beans.Introspector.getBeanInfo(Introspector.java:248) at java.beans.Introspector.init(Introspector.java:395) at java.beans.Introspector.getBeanInfo(Introspector.java:161) at java.beans.Introspector.getBeanInfo(Introspector.java:248) at java.beans.Introspector.init(Introspector.java:395) at java.beans.Introspector.getBeanInfo(Introspector.java:161) at freemarker.ext.beans.BeansWrapper.populateClassMapWithBeanInfo(BeansWrapper.java:1147) at freemarker.ext.beans.BeansWrapper.populateClassMap(BeansWrapper.java:1072) at freemarker.ext.beans.BeansWrapper.introspectClassInternal(BeansWrapper.java:1010) at freemarker.ext.beans.BeansWrapper.introspectClass(BeansWrapper.java:969) at freemarker.ext.beans.BeanModel.init(BeanModel.java:140) at freemarker.ext.beans.StringModel.init(StringModel.java:90) at freemarker.ext.beans.StringModel$1.create(StringModel.java:75) at freemarker.ext.beans.BeansModelCache.create(BeansModelCache.java:45) Jun 24, 2015 6:49:19 PM org.apache.struts2.dispatcher.Dispatcher error SEVERE: Exception occurred during processing request: javax.servlet.ServletException: java.lang.OutOfMemoryError: PermGen space org.apache.jasper.JasperException: javax.servlet.ServletException: java.lang.OutOfMemoryError: PermGen space at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:549) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:455) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:60) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339) at org.apache.struts2.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:164) at org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:186) at
Re: Can i use Tomcat 7 catalina-ws.jar in Tomcat 8???
On 06/24/2015 06:04 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Agharta, On 6/24/15 11:17 AM, agharta wrote: Hi all, A rapid question: colud i place the tomcat 7 catalina-ws.jar inside a new tomcat 8 installation ? Why would you want to do something like that? Because i have many customers, with many different versions of tomcat 7/8 and i'm trying to keep libs update method most simple as possible. Having no per-tomcat-version-libs solves me that problem. Is it compatibile? Probably not. I supposed thatdoh! I've not found any topic about it. Probably nobody ever thought about doing it. you're right again If this qestion was already made, give me the link and sorry for my bad search. - -chris Thank you again, Best regards, Agharta -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVitT9AAoJEBzwKT+lPKRYHrIP/ROx8an/64gWsexbfZk4nIVV e/7GFcLFNJYy1Lty0WujxkdPvRBie6a6PKRZN/trCPjK5GU7IVaORzh12jK6T+Mx GmFT+WRsLKI6y2DcApgb1SRyk6whQdxeuaUdVTgOW2vgZKUgj2tlKvGJWpffHFa9 sALVSTCfYexEpSY8Q6f9ZjeHP6ZIhZpoLz7Q0mNRi9POJlLobYe8l3Co7KRr0xqJ ky1aWZCtBxbehooHh6aFgv9lA53pp/o6sXm62jprpA299uSiEeVXrKhZmckRtaFs 0U+Yr9J4zCqwGlW0rfueQmh7hn4ws9U/s8v9Vn4zsF1+5HGAl+rEBzRx96dx4cvQ oHQXjEeBRukLvmoYAEUfY5/3DvLbdoerhLV/xBDaYis3+QrAGHwJxk3E8CMIDt2q 8szro10Z6hxAiNgJ98H1gen2oZxy+q00lIouMzlghMNcjSc0ryTmCDOQgxbjyUXv O96IiTilJ3ZcBsaexcXFQLjyjuv9VyCy7jcHHizazEnsJ2wvtqpbpNOVX5vTIVzY aQGl5fo4pANcc7axjShO+JAZPfqR73XJ9VOrt34XlcsCGq4GTh8f4a2lEPyxifIW RuZtqDrVERBv+k2opo3FQ+CDWqpcWoba/aD/FPrYL0NqZ7xbztNVFaMsQA6pN6ps 6wIB2+Ai+dum17X3CuRl =jFu1 -END PGP SIGNATURE- - 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: Is Tomcat 7.0.62 vulnerable to these issues: CVE-2007-6750/CVE-2009-5111
On 25/06/2015 07:07, Nikitha Benny wrote: Hi, I am confused regarding the 2 security issues CVE-2007-6750 and CVE-2009-5111. Can they be tracked to CVE-2012-5568? All of those CVEs are essentially the same issue (slowloris) in different products. According to CVE-2012-5568, I understand that this is not a vulnerability in Tomcat. Please confirm. That depends on your point of view. When Tomcat 7.0.62 was scanned using McAfee Vulnerability Manager Tool, it reported the below results: * HTTP Server Prone To Slow Denial Of Service Attack [FID 12824]* 5.0 Medium 10.53.137.57:80 (http) ,10.53.137.57:8081 (http) * HTTP Server Prone To Slow Denial Of Service Attack [FID 12824]* 5.0 Medium 10.53.137.56:80 (http) ,10.53.137.56:8081 (http) Please help me understand if this can be resolved or if this is a valid vulnerability. Read this and the referenced links. https://bz.apache.org/bugzilla/show_bug.cgi?id=54263 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Is Tomcat 7.0.62 vulnerable to these issues: CVE-2007-6750/CVE-2009-5111
Hi, I am confused regarding the 2 security issues CVE-2007-6750 and CVE-2009-5111. Can they be tracked to CVE-2012-5568? According to CVE-2012-5568, I understand that this is not a vulnerability in Tomcat. Please confirm. When Tomcat 7.0.62 was scanned using McAfee Vulnerability Manager Tool, it reported the below results: * HTTP Server Prone To Slow Denial Of Service Attack [FID 12824]* 5.0 Medium 10.53.137.57:80 (http) ,10.53.137.57:8081 (http) * HTTP Server Prone To Slow Denial Of Service Attack [FID 12824]* 5.0 Medium 10.53.137.56:80 (http) ,10.53.137.56:8081 (http) Please help me understand if this can be resolved or if this is a valid vulnerability. Thanks Regards, Nikitha
Re: Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
Pascal Abaziou wrote: Le 25 juin 2015 à 00:23, Mark Eggers its_toas...@yahoo.com.INVALID a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2015 2:40 PM, André Warnier wrote: Pascal Abaziou wrote: Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. You know, I don't want to discourage you, but.. Assuming even that this was a bug that was fixed on its own, and not some side-effect of some other change.. As you know, Tomcat is an open-source and free software, developed and supported by volunteers, who apart from their Tomcat involvement, all have a paying job which they do on the side.. This user's list is the same. Tomcat 6.0.24 is at least 5 years old. The current Tomcat version is 8.0.23. Between these two, there are 5 years and probably close to 100 versions. Some of these versions correct real bugs or security issues which could leave any lower version vulnerable to hacking. The Tomcat developers, having a limited amount of time to dedicate to it, rather understandably prefer to spend this time working on and supporting the latest version, rather than very old ones. All of this to say that unless there is a very strong incentive for someone to go and dig through the documentation and the code, your chances of getting real help on this apparently minor and peripheral issue, affecting an old version of Tomcat but not more recent ones, are really slim. If your sysadmin does not understand the benefits of upgrading to a more recent version, rather than this very old one, then the problem is with him, not with you and not with the Tomcat developers. Maybe you should just take the change logs, starting with 6.0.44 and working back to 6.0.24, append them to one another, and send this to him as a token of what he is missing in terms of bug corrections and security fixes, by /not/ upgrading. And if he still does not understand the issue, or cannot give you a better reason to want to stay with 6.0.24, send the list to his boss. There's another issue when comparing vendor-packaged versus Apache-distributed Tomcat versions. Vendors often backport various fixes from later Apache-distributed versions to vendor-packaged versions. For example, you may see the following in RedHat (I'm running Fedora 22 or CentOS 6) distributions: CentOS 6 Name: tomcat6 Arch: x86_64 Version : 6.0.24 Release : 83.el6_6 Size: 92 k Repo: updates First of all, you have to select Tomcat 6 as opposed to Tomcat on CentOS 6.6. I understand that the Tomcat 7 version is only available in the EPEL repository. Here's the information for tomcat.noarch from the EPEL repository. Name: tomcat Arch: noarch Version : 7.0.33 Release : 4.el6 Size: 86 k Repo: epel The key thing to look at in both of these listings is the Release tag. RedHat (and I suppose other vendors) release updates to their packages that include backports for certain issues. In general, RedHat addresses security issues, but avoids backporting API changes between releases of their Linux platform. It is very difficult to compare RedHat's version of 6.0.24 or 7.0.33 with the Apache release. You would have to compare both sets of change logs to find out how RedHat's release compared to Apache's release. Then, since it doesn't appear that this particular problem was uniquely identified in the Apache Tomcat changelogs, you would have to determine what change (and when) fixed the issue. Finally, you would then have to lobby RedHat to include the appropriate change into their repackaging of Tomcat. Lots of work . . . This is one of the reasons why most people on the list advocate using Apache-distributed packages. In the end, it's easier for everyone (mailing list members, Apache Tomcat users, and system administrators). As André pointed out above, this is a system administrator issue, not a Tomcat issue. If there are policies in place that preclude third party packaged applications running in production, then there are also corporate policy issues. In short, there are few reasons to stay with a vendor-distributed packaging of Tomcat, and quite a few good reasons to move to the Apache-distributed packages. . . . happily running Apache-distributed packages everywhere /mde/ Thanks for your answers. I’ll go in this direction. We
