Bugrat #356 not reproducible
Regarding the following bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=356 While testing for bug #484, I also tested #356 (the same JSP pages calling sendRedirect()). All my tests showed no bugs. Oddly the Bugzilla report says Tomcat 3.2 Final, but the Bugrat report says Tomcat 3.2.1 Final. I tested using 3.2.1 Final. HttpServletResponse.sendRedirect() sends a brief HTTP Response header (HttpServletResponse.SC_MOVED_TEMPORARILY) that tells the client's browser to load the new URL. This header might not be properly interpreted by older browsers. However, the anonymous reporter(s) of this bug did not mention what type of browser they were using. sendRedirect() works for me using Netscape 4.76 on Linux. Again, I'd like it if someone double-checks this for me, or if anyone can report it with browser specifics. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat ready for primetime (was RE: some benchmarks)
Benchmarks don't mean a whole lot to me as they're all a bit on the subjective and software has gotten a little too complex to say "this is faster/better or more stable than this" because different situations highlight different things/needs. I mean Microsoft does benchmarks where they beat Oracle and have 99% uptime...haven't witnessed it myself though. I converted (mostly by removing all the "getRealPath") a legacy jserv application to tomcat, it did not use JSPs mind you. The site got ~150,000 hits a day. Tomcat kept up fine and was not noticably slower or faster, as far as the eye could see it was near-instantanious. (keep in mind I had no real bandwidth constraints when measuring this..those of you on old 56k modems probably don't know what that means) Later when rewriting in JSPs/beans/EJBs. Tomcat and Jboss were actually slower than the original application on initial startup but after about half an hour it was equal the speed if not faster. (but using perception its hard to say). I'd guess it was faster due to the number of apache connections open at once (dropped to ~35 from about 100). Some of this is due to the improvements in the application. I did have a number of performance problems with both editions of the application, but I traced them all back to the database (which had stack overflows and memory leaks) or the legacy application (which had synchronization problems). What other problems I had were usually either a configuration issue (documentation on both tomcat/jboss projects leaves much to be desired, I'd be happy to contribute to this effort at some point, however you have to know what the heck you're talking about well enough to explain it before you can document something or have greater than usual support for doing an un-sexy project like documentation from volunteers,in my humble opinion this is where the Suns and IBMs need to donate most...donate experienced tech writers and people who full time just analyze the stuff and document..that will win greater commercial support). So the bottom line is in my opinion Tomcat 3.21 has reached prime-time capability. If you're (somewhat off topic but related since they often get bundled) willing to load a "pre" then JBoss 2.1pre can be used, 2.0 isn't so ready due to various intermittant problems and the documentation which is confused between about 3 versions of it leaves so much to be desired...some effort is being made in changing this but they need to go through it with a fine tooth comb and say "still true/not true". Lastly although mod_jk is a royal pain to switch to, its worth doing. I had little luck getting the mod_jserv-tomcat-apache combination to work. (work means live more than an hour) Note that if you do uploads with Multi-part requests you'll need a direct-to-tomcat method of doing them as mod_jk breaks them. FYI: first edition was primarily servlet driven/interperated in-house tag language with jserv and apache. Second edition was the same except adapted for tomcat and mod_jk/apache Third edition was written in JSPs with some regular beans which front ended some EJBs. No servlets were used as this was a "view only" project and I'd intended to have a forth edition once I could redo the database schema. Equipment was a couple of load balanced Sparcs with another dual-processor sparc back end running Solaris 7. So anyhow thats my subjective evidence that tomcat 3.21 is ready for primetime while so many state otherwise. -Andy -Original Message- From: GOMEZ Henri To: [EMAIL PROTECTED] Sent: 3/3/01 6:54 PM Subject: RE: Some benchmarks I need to choose for my company the "next generation" servlet-engine. For now we are using JRUN. I am doing benchmark to choose the next one. choices for me are : JRUN, RESIN... not Tomcat as it is considered not stable and slow compare to the two others... When you say that Tomcat is slow could you give numbers. ie : tomcat served 1000 req/s and Resin 3000 req/s - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Volunteer: Connectors?
Could you send it to me too, please. I am next to finishing the jsp compacter I promised but I will really need help to integrate it. Gracias, Carlos Gaston Alvarez - Original Message - From: Alex Fernndez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 21, 2001 9:12 AM Subject: Re: Volunteer: Connectors? At the risk of getting everyone fed up with my messages today: I have generated the javadoc documentation for Tomcat 3.3m1, complete with class diagrams. It was done with Together Control Center -- it includes an Applet to view UML diagrams. You click on a diagram, it shows you the javadoc for that class. The full package is about 12 MB, 3.3 MB zipped. Shall I send it somewhere? Un saludo, Alex. Remy Maucherat wrote: Hi-- I work w/ Rational Software. We have been working with Tomcat for some time for our web product, RequisiteWeb. I'd like to volunteer to help out in the Tomcat Connectors department. I am a 1.5-year Java veteran w/ a CS bachelor's degree, wanting to help produce free software. Let me know where/if I can be of help. Your UML products are cool :) The online browsing feature is great (as an example of it, you can browse online the UML representation of the Slide project core API here : http://jakarta.apache.org/slide/uml/index.html). I think it would be great to have something similar for Tomcat 4, but unfortunately I don't have Rose 2001 (the model was contributed to the project by a Slide user). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH][tc3.3]Re: Proposed ApacheConfig.java change
The attached PATCH modifies org.apache.tomcat.modules.config.ApacheConfig to add some needed flexibility. I need someone who is running apache and tomcat3.3 using mod_jserv to test it in that configuration and give their feedback. I've tested it with mod_jk on winNT and linux 6.2 and it seems to work fine. I would of course welcome any tests that would uncover things I may have overlooked. As soon as I have a reasonable amount of feedback to resolve any such oversights, I will commit the changes. The nature of the changes is as follows. First off, if you haven't been using the latest tomcat3.3, you need to tell it to auto-generate the Apache config files for jserv and jk. To do this, the only thing you need to do is insert an ApacheConfig/ config intercepter element inside the ContextManager tag like so: ContextManager ... ... ApacheConfig / ... /ContextManager That will make sure that ApacheConfig is invoked. In the absence of any attributes in the ApacheConfig/ tag the only difference in behavior should be that the LoadModule statements will be wrapped in IfModule !mod_name.c ... /IfModule tags to make the loads conditional. In addition to making the LoadModule statements conditional, I've also added some attributes to the ApacheConfig / tag that should greatly help setting up Apache and Tomcat deployments: confighome - default parent directory for the following paths. If not set, this defaults to TOMCAT_HOME. Ignored whenever any of the following paths is absolute. jservconfig - path to write apache jserv conf file to. If not set, defaults to "conf/jserv/tomcat-apache.conf". jkconfig - path to write apacke mod_jk conf file to. If not set, defaults to "conf/jk/mod_jk.conf". workersconfig - path to workers.properties file used by mod_jk. If not set, defaults to "conf/jk/workers.properties". modjserv - path to Apache JServ plugin module file. If not set, defaults to "modules/ApacheModuleJServ.dll" on windows, "modules/Jserv.nlm" on netware, and "libexec/mod_jserv.so" everywhere else. modjk - path to Apache mod_jk plugin file. If not set, defaults to "modules/mod_jk.dll" on windows, "modules/mod_jk.nlm" on netware, and "libexec/mod_jk.so" everywhere else. jklog - path to log file to be used by mod_jk. All of these attributes are optional. Please try the patch out and let me know if you have any problems. Send me a +1 if you think it should be committed. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH][tc3.3]Re: Proposed ApacheConfig.java change
{sorry about the resend - I hit the send button early
last time}
The attached PATCH modifies
org.apache.tomcat.modules.config.ApacheConfig to add
some needed flexibility. I need someone who is
running apache and tomcat3.3 using mod_jserv to test
it in that
configuration and give their feedback.
I've tested it with mod_jk on winNT and linux 6.2 and
it seems to work fine. I would of course welcome any
tests that would uncover things I may have overlooked.
As soon as I have a reasonable amount of feedback to
resolve any such oversights, I will commit the
changes.
The nature of the changes is as follows. First off,
if you haven't been using the latest tomcat3.3, you
need to tell it to auto-generate the Apache config
files for jserv and jk. To do this, the only thing you
need to do is insert an ApacheConfig/ config
intercepter element inside the ContextManager tag like
so:
ContextManager ...
...
ApacheConfig /
...
/ContextManager
That will make sure that ApacheConfig is invoked.
In the absence of any attributes in the
ApacheConfig/
tag the only difference in behavior should be that the
LoadModule statements will be wrapped in
IfModule !mod_name.c
...
/IfModule
tags to make the loads conditional.
In addition to making the LoadModule
statements conditional, I've also added some
attributes to the ApacheConfig / tag that should
greatly
help setting up Apache and Tomcat deployments:
confighome - default parent directory for the
following
paths. If not set, this defaults to TOMCAT_HOME.
Ignored whenever any of the following paths is
absolute.
jservconfig - path to write apache jserv conf file to.
If not set, defaults to
"conf/jserv/tomcat-apache.conf".
jkconfig - path to write apacke mod_jk conf file to.
If not set, defaults to "conf/jk/mod_jk.conf".
workersconfig - path to workers.properties file used
by mod_jk. If not set, defaults to
"conf/jk/workers.properties".
modjserv - path to Apache JServ plugin module file.
If not set, defaults to
"modules/ApacheModuleJServ.dll" on windows,
"modules/Jserv.nlm" on netware, and
"libexec/mod_jserv.so" everywhere else.
modjk - path to Apache mod_jk plugin file. If not
set, defaults to "modules/mod_jk.dll" on windows,
"modules/mod_jk.nlm" on netware, and
"libexec/mod_jk.so" everywhere else.
jklog - path to log file to be used by mod_jk.
All of these attributes are optional.
Please try the patch out and let me know if you have
any problems.
Send me a +1 if you think it should be committed.
Cheers,
Mel
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Index: ApacheConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
retrieving revision 1.6
diff -u -r1.6 ApacheConfig.java
--- ApacheConfig.java 2001/03/02 04:49:11 1.6
+++ ApacheConfig.java 2001/03/04 22:39:14
@@ -1,4 +1,4 @@
-/*
+/* $Id$
*
*
* The Apache Software License, Version 1.1
@@ -70,22 +70,97 @@
import org.apache.tomcat.modules.server.Ajp13Interceptor;
/**
- * Used by ContextManager to generate automatic apache configurations
- *
- * @author Costin Manolache
+Generates automatic apache configurations based on
+the Tomcat server.xml settings and the war contexts
+initialized during startup.
+p
+This config interceptor is enabled by inserting an ApacheConfig
+element in the b\ContextManager/b tag body inside
+the server.xml file like so:
+pre
+* ContextManager ...
+* ...
+* bApacheConfig/b ioptions/i /
+* ...
+* /ContextManager
+/pre
+where ioptions/i can include any of the following attributes:
+ul
+ libconfighome/b - default parent directory for the following paths.
+If not set, this defaults to TOMCAT_HOME. Ignored
+whenever any of the following paths is absolute.
+ /li
+ libjservconfig/b - path to write apache jserv conf file to. If
+ not set, defaults to
+ "conf/jserv/tomcat-apache.conf"./li
+ libjkconfig/b - path to write apacke mod_jk conf file to. If
+not set, defaults to
+"conf/jk/mod_jk.conf"./li
+ libworkersconfig/b - path to workers.properties file used by
+mod_jk. If not set, defaults to
+"conf/jk/workers.properties"./li
+ libmodjserv/b - path to Apache JServ plugin module file. If not
+ set, defaults to "modules/ApacheModuleJServ.dll"
+ on windows, "modules/Jserv.nlm" on netware, and
+
TC3.3 build not generating javadocs?
I notice that as of a day or two ago (my last major 'update' from CVS) that now when I build tomcat 3.3, even after a 'clean', that only a few of the javadocs get generated. Specifically, just those in org.apache.tomcat.modules. I realize that for some folks, they don't want to wait to rebuild all the javadocs everytime they build. So maybe it makes sense to have the script not build them by default. However, I'd like for someone to tell me how to modify the build.xml script to re-enable complete generation of the javadocs for all the packages. I am an Ant newbie and the build.xml looks strange and frightening to me! :-) Thanks, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH][tc3.3]Re: Proposed ApacheConfig.java change
We can -1 later :) go for it , it looks nice.
I dont understand your question fully .., you are asking about to
generate the complete javadocs for all packages ?
8
javadoc packagenames="org.apache.tomcat.*"
sourcepath="src/share;src/facade22"
destdir="${tomcat.build}/webapps/ROOT/javadoc"
author="true"
version="true"
use="true"
windowtitle="Tomcat internal API"
doctitle="Tomcat internal"
bottom="Copyright 2000 Apache Software Foundation. All
Rights Reserved."/
8
should work..
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: Mel Martinez [mailto:[EMAIL PROTECTED]]
Enviado el: lunes 5 de marzo de 2001 0:04
Para: [EMAIL PROTECTED]
Asunto: [PATCH][tc3.3]Re: Proposed ApacheConfig.java change
{sorry about the resend - I hit the send button early
last time}
The attached PATCH modifies
org.apache.tomcat.modules.config.ApacheConfig to add
some needed flexibility. I need someone who is
running apache and tomcat3.3 using mod_jserv to test
it in that
configuration and give their feedback.
I've tested it with mod_jk on winNT and linux 6.2 and
it seems to work fine. I would of course welcome any
tests that would uncover things I may have overlooked.
As soon as I have a reasonable amount of feedback to
resolve any such oversights, I will commit the
changes.
The nature of the changes is as follows. First off,
if you haven't been using the latest tomcat3.3, you
need to tell it to auto-generate the Apache config
files for jserv and jk. To do this, the only thing you
need to do is insert an ApacheConfig/ config
intercepter element inside the ContextManager tag like
so:
ContextManager ...
...
ApacheConfig /
...
/ContextManager
That will make sure that ApacheConfig is invoked.
In the absence of any attributes in the
ApacheConfig/
tag the only difference in behavior should be that the
LoadModule statements will be wrapped in
IfModule !mod_name.c
...
/IfModule
tags to make the loads conditional.
In addition to making the LoadModule
statements conditional, I've also added some
attributes to the ApacheConfig / tag that should
greatly
help setting up Apache and Tomcat deployments:
confighome - default parent directory for the
following
paths. If not set, this defaults to TOMCAT_HOME.
Ignored whenever any of the following paths is
absolute.
jservconfig - path to write apache jserv conf file to.
If not set, defaults to
"conf/jserv/tomcat-apache.conf".
jkconfig - path to write apacke mod_jk conf file to.
If not set, defaults to "conf/jk/mod_jk.conf".
workersconfig - path to workers.properties file used
by mod_jk. If not set, defaults to
"conf/jk/workers.properties".
modjserv - path to Apache JServ plugin module file.
If not set, defaults to
"modules/ApacheModuleJServ.dll" on windows,
"modules/Jserv.nlm" on netware, and
"libexec/mod_jserv.so" everywhere else.
modjk - path to Apache mod_jk plugin file. If not
set, defaults to "modules/mod_jk.dll" on windows,
"modules/mod_jk.nlm" on netware, and
"libexec/mod_jk.so" everywhere else.
jklog - path to log file to be used by mod_jk.
All of these attributes are optional.
Please try the patch out and let me know if you have
any problems.
Send me a +1 if you think it should be committed.
Cheers,
Mel
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup Main.java
melaquias01/03/04 14:38:16
Modified:src/share/org/apache/tomcat/startup Main.java
Log:
Changed name of configuration property "org.apache.tomcat.shared.classpath" to
"org.apache.tomcat.apps.classpath" to be consistent with the new TOMCAT_HOME/lib/
directory structure.
Updated javadoc comments to match.
Revision ChangesPath
1.28 +36 -31jakarta-tomcat/src/share/org/apache/tomcat/startup/Main.java
Index: Main.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/Main.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- Main.java 2001/03/04 03:36:52 1.27
+++ Main.java 2001/03/04 22:38:14 1.28
@@ -1,4 +1,4 @@
-/* $Id: Main.java,v 1.27 2001/03/04 03:36:52 costin Exp $
+/* $Id: Main.java,v 1.28 2001/03/04 22:38:14 melaquias Exp $
*
*
* The Apache Software License, Version 1.1
@@ -81,30 +81,35 @@
ol
lia 'common' loader to be the parent of both the server
container and also webapp loaders./li
- lia 'shared' loader to load classes used by all webapps, but
+ lian 'applications' loader to load classes used by all webapps, but
not the servlet engine./i
- lia 'server' loader exclusively for the tomcat servlet engine./li
+ lia 'container' loader exclusively for the tomcat servlet engine./li
/ol
- Both the 'shared' loader and 'server' loader have the common loader as
+ Both the 'apps' loader and 'container' loader have the common loader as
the parent class loader. The class path for each is assembled like so:
ul
- licommon - all elements of the
codeorg.apache.tomcat.common.classpath/code
- property plus all *.jar files found in ${TOMCAT_HOME}/lib/common/./li
- lishared - all elements of the
codeorg.apache.tomcat.shared.classpath/code
- property plus all *.jar files found in ${TOMCAT_HOME}/lib/shared/./i
- liserver - all jar files found in ${TOMCAT_HOME}/lib, plus the class
- folder ${TOMCAT_HOME}/classes and finally also the utility jar
- file ${JAVA_HOME}/lib/tools.jar./li
- /ol
+ licommon - all elements of the
+ codeorg.apache.tomcat.common.classpath/code
+ property plus all *.jar files found in ${TOMCAT_HOME}/lib/common/.
+ /li
+ liapps - all elements of the
+ codeorg.apache.tomcat.apps.classpath/code
+ property plus all *.jar files found in ${TOMCAT_HOME}/lib/apps/.
+ In addition, all classes loaded via the 'common' loader./i
+ licontainer - all jar files found in ${TOMCAT_HOME}/lib/container/ plus
+ the class folder ${TOMCAT_HOME}/classes and finally also the utility
+ jar file ${JAVA_HOME}/lib/tools.jar. In addition, all classes loaded
+ via the common loader./li
+ /ul
After creating the above class loaders, this class instantiates, initializes
and starts an instance of the class
codeorg.apache.tomcat.startup.Tomcat/code.
p
@author Costin Manolache
@author Ignacio J. Ortega
@author Mel Martinez [EMAIL PROTECTED]
- @version $Revision: 1.27 $ $Date: 2001/03/04 03:36:52 $
+ @version $Revision: 1.28 $ $Date: 2001/03/04 22:38:14 $
*/
-public class Main {
+public class Main{
/**
name of configuration property to set (using the -D option at
@@ -114,18 +119,18 @@
normal file paths separated by the path.seperator delimiter for
the host platform. Example (unix):
precode
-* org.apache.tomcat.shared.classpath = /home/mypath/lib/mylib.jar: \
+* org.apache.tomcat.apps.classpath = /home/mypath/lib/mylib.jar: \
* /home/mypath/classes/
/code/pre
*/
-public static final String TOMCAT_SHARED_CLASSPATH_PROPERTY =
-"org.apache.tomcat.shared.classpath";
+public static final String TOMCAT_APPS_CLASSPATH_PROPERTY =
+"org.apache.tomcat.apps.classpath";
/**
the classpath shared among all web apps (in addition to any
-jar files placed directly in $TOMCAT_HOME/lib/shared/).
+jar files placed directly in $TOMCAT_HOME/lib/apps/).
*/
-public static final String TOMCAT_SHARED_CLASSPATH;
+public static final String TOMCAT_APPS_CLASSPATH;
/**
name of configuration property to set (using the -D option at
@@ -151,11 +156,11 @@
static{
String s=null;
-s = System.getProperty(TOMCAT_SHARED_CLASSPATH_PROPERTY);
+s =
Restricting Access to Tomcat 3.x and Tomcat 4.0 Connectors
I have a general question about restricting access from remote hosts to common connectors used by Tomcat 3.x and Tomcat 4.0. Tomcat 3.x will use port 8007 for its Apache ajp12 connector, is there anyway to configure Tomcat 3.x so it will only accept connections on that port from localhost or a single remote host? What about shutdown, does the port only accept requests from localhost? Tomcat 4.0 will use port 8005 as its shutdown port, will this only accept connections from localhost? Is this configurable? Tomcat 4.0 will use port 8008 for its Warp Connector. Can this be filtered using the Request Filter Valve? The docs for the Request Filter refer to denying HTTP requests. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Restricting Access to Tomcat 3.x and Tomcat 4.0 Connectors
Glenn Nielsen wrote: I have a general question about restricting access from remote hosts to common connectors used by Tomcat 3.x and Tomcat 4.0. Tomcat 3.x will use port 8007 for its Apache ajp12 connector, is there anyway to configure Tomcat 3.x so it will only accept connections on that port from localhost or a single remote host? What about shutdown, does the port only accept requests from localhost? Tomcat 4.0 will use port 8005 as its shutdown port, will this only accept connections from localhost? Yes, in effect. The connection is accepted no matter where it comes from, but attempts to shut down Tomcat are refused unless they are from localhost. AFAIK, there is no way through standard Java I/O to restrict where the connection comes from at the socket accept level. Is this configurable? Not currently, although this would be relatively easily to add. Tomcat 4.0 will use port 8008 for its Warp Connector. Can this be filtered using the Request Filter Valve? The docs for the Request Filter refer to denying HTTP requests. As long as the Warp connector properly identifies where the request originated (which I am pretty sure it does), you can indeed use request filters to accept only requests from matching clients. However, this cannot be used to control where the connection from Apache comes from -- that would require code in the connector itself. Regards, Glenn Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/io FileUtil.java
In article cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/io FileUtil.java, [EMAIL PROTECTED] writes: |larryi 01/03/01 10:05:07 | | Modified:src/share/org/apache/tomcat/util/io FileUtil.java | Log: | Removed the "trim" in patch() method to avoid security hole. A file ending | in ".jsp%20" would not be considered a JSP page, but could still be served, | probably statically, if the trailing space is removed. The sanity and watchdog | tests still pass. | | Submitted by: Kazuhiro Kazama | | This fixes direct access to Tomcat. The impact on access through mod_jserv | and mod_jk still need to be checked. | | Revision ChangesPath | 1.2 +4 -4 |jakarta-tomcat/src/share/org/apache/tomcat/util/io/FileUtil.java This patch should apply to tomcat_32 branch too. Tomcat 3.2.X has same security problem. --- Yoshiyuki Karezaki [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Restricting Access to Tomcat 3.x and Tomcat 4.0 Connectors
Ok, so if you want to restrict network access from remote Apache servers using the mod_jserv, mod_jk, or mod_webapp connectors to Tomcat; you can't do it with either Tomcat 3.2 or Tomcat 4.0, correct? Sure would be nice if network access allow/deny for Connectors could be configured for those who don't put Tomcat behind a firewall. Regards, Glenn "Pier P. Fumagalli" wrote: Craig R. McClanahan [EMAIL PROTECTED] wrote: Tomcat 4.0 will use port 8005 as its shutdown port, will this only accept connections from localhost? Yes, in effect. The connection is accepted no matter where it comes from, but attempts to shut down Tomcat are refused unless they are from localhost. AFAIK, there is no way through standard Java I/O to restrict where the connection comes from at the socket accept level. BARF, Craig :) :) :) Bind your serversocket to the 127.0.0.1 address only, and the trick is done... (if it doesn't work, it's a JVM/OS problem) Is this configurable? Not currently, although this would be relatively easily to add. I wouldn't bother, but rather wait for the outcomes of JSR-096 (Java Daemons)... Even if maybe it will not make it for our final release, we can always incorporate their code (should come out with a BSD license), change the packages from javax.daemon to org.apache and keep the two in sync. When it finally comes out, we can simply incorporate it and change back to javax.daemon. Tomcat 4.0 will use port 8008 for its Warp Connector. Can this be filtered using the Request Filter Valve? The docs for the Request Filter refer to denying HTTP requests. As long as the Warp connector properly identifies where the request originated (which I am pretty sure it does), you can indeed use request filters to accept only requests from matching clients. However, this cannot be used to control where the connection from Apache comes from -- that would require code in the connector itself. Actually, that's all the way around... GetRemoteHost() and addr() return the Apache client, not the WARP client... Filtering at WARP level is a feature that can be integrated in the connector... Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Restricting Access to Tomcat 3.x and Tomcat 4.0 Connectors
Glenn Nielsen [EMAIL PROTECTED] wrote: Ok, so if you want to restrict network access from remote Apache servers using the mod_jserv, mod_jk, or mod_webapp connectors to Tomcat; you can't do it with either Tomcat 3.2 or Tomcat 4.0, correct? Sure would be nice if network access allow/deny for Connectors could be configured for those who don't put Tomcat behind a firewall. I don't know about mod_jserv/mod_jk (in mod_jserv it was possible with Jserv, but I don't know about the Tomcat implementation of AJP). With mod_webapp, or better, the WARP connector for Tomcat 4.0 (we're not dealing with the Apache side of things, but with it's counterpart in the Java Virtual Machine) is not implemented, but it's feasible. Maybe in the next release? Who knows... :) :) :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Restricting Access to Tomcat 3.x and Tomcat 4.0 Connectors
In 3.x, the Ajp12 and Ajp13 Connectors currently accept connections from anywhere. People have proposed adding the ability to have an accept/deny list in the configs, but it hasn't been done (the Java code for this would be pretty easy, actually), and it would be backward compatible with the mod_jk C code (which wouldn't need to know about it at all, actually). As a minimal form of security, both connectors will only accept a shutdown if it issued from the same host as TC is running on (e.g. if socket.getLocalAddress and socket.getInetAddress are the same). Costin recently added an optional 'secret' -- either user-set or randomly generated by TC. If user-set, it can be added to worker.properties (I think), or if randomly generated, it can be read from a specific file in the config dir (the same way that httpd.pid can be read by apachectl). If useSecret is set, then the shutdown request is only acted on if it is followed by the secret. I don't know if Costin has documented this or not -- I haven't looked. With ajp13, the server is basically proxying requests, so some security issues don't arise. The biggest gotcha I'm aware of is that TC trusts the web server to establish the remote_user property (which the user might need to authenticate to prove). So someone could manufacture an ajp13 connection which would allow them to access servlets that they should be denied. I haven't actually created this exploit, but I believe the vulnerability is there. The spec for the Ajp2.1 (which was not, AFAIK, ever implemented) has an excellent section discussing "Security Hazards". Anyone interested can check that out at: http://java.apache.org/jserv/protocol/AJPv21.html -Dan Glenn Nielsen wrote: I have a general question about restricting access from remote hosts to common connectors used by Tomcat 3.x and Tomcat 4.0. Tomcat 3.x will use port 8007 for its Apache ajp12 connector, is there anyway to configure Tomcat 3.x so it will only accept connections on that port from localhost or a single remote host? What about shutdown, does the port only accept requests from localhost? Tomcat 4.0 will use port 8005 as its shutdown port, will this only accept connections from localhost? Is this configurable? Tomcat 4.0 will use port 8008 for its Warp Connector. Can this be filtered using the Request Filter Valve? The docs for the Request Filter refer to denying HTTP requests. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Patch for JspInterceptor.java
I've been trying to get jikes to work under tomcat - and finally tracked
down the problem I was facing to this:
in TC 3.3.1 M1
src/facade22/org/apache/tomcat/facade/JspInterceptor.java
In the case where there is no context classpath, jikes will not work
because of invalid
class path. I've included my changes below... I'm not sure what form
you folks accept diffs in...
so here is my first shot.../tmp/JspInterceptor.java was my
original
-Tom
--patch below here
---
--- JspInterceptor.java Sun Mar 4 22:34:09 2001
+++ /tmp/JspInterceptor.javaSun Mar 4 22:33:46 2001
@@ -655,12 +655,8 @@
{
javac.setEncoding(javaEncoding);
-
- String cp=System.getProperty("java.class.path");
- String contextCp = ctxt.getClassPath();
- if (contextCp != null)
- cp += sep + contextCp;
- cp += sep + ctxt.getOutputDir();
+ String cp=System.getProperty("java.class.path")+ sep +
+ ctxt.getClassPath() + sep + ctxt.getOutputDir();
//System.out.println("classpath:"+cp);
javac.setClasspath( cp );
if( debug5) log.log( "ClassPath " + cp);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util FileUtil.java
marcsaeg01/03/04 20:02:50
Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
FileUtil.java
Log:
Removed trim() from patch() method to avoide security hole. This patch was applied
to Tomcat 3.3 a couple months ago, but never got ported to the tomcat_32 branch.
Submitted by Kazuhiro Kazama.
Revision ChangesPath
No revision
No revision
1.9.2.6 +4 -4
jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/FileUtil.java
Index: FileUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/FileUtil.java,v
retrieving revision 1.9.2.5
retrieving revision 1.9.2.6
diff -u -r1.9.2.5 -r1.9.2.6
--- FileUtil.java 2000/11/05 05:28:53 1.9.2.5
+++ FileUtil.java 2001/03/05 04:02:49 1.9.2.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/FileUtil.java,v
1.9.2.5 2000/11/05 05:28:53 craigmcc Exp $
- * $Revision: 1.9.2.5 $
- * $Date: 2000/11/05 05:28:53 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/FileUtil.java,v
1.9.2.6 2001/03/05 04:02:49 marcsaeg Exp $
+ * $Revision: 1.9.2.6 $
+ * $Date: 2001/03/05 04:02:49 $
*
*
*
@@ -228,7 +228,7 @@
}
public static String patch(String path) {
- String patchPath = path.trim();
+ String patchPath = path;
// Move drive spec to the front of the path
if (patchPath.length() = 3
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Restricting Access to Tomcat 3.x and Tomcat 4.0 Connectors
"Pier P. Fumagalli" wrote: Craig R. McClanahan [EMAIL PROTECTED] wrote: Tomcat 4.0 will use port 8005 as its shutdown port, will this only accept connections from localhost? Yes, in effect. The connection is accepted no matter where it comes from, but attempts to shut down Tomcat are refused unless they are from localhost. AFAIK, there is no way through standard Java I/O to restrict where the connection comes from at the socket accept level. BARF, Craig :) :) :) Bind your serversocket to the 127.0.0.1 address only, and the trick is done... (if it doesn't work, it's a JVM/OS problem) That controls where the *destination* of the client connection can go, but not the *origin*. Look again and find me the appropriate JDK methods to call to say "only accept connections from IP address a.b.c.d", which was the original question. Is this configurable? Not currently, although this would be relatively easily to add. I wouldn't bother, but rather wait for the outcomes of JSR-096 (Java Daemons)... Even if maybe it will not make it for our final release, we can always incorporate their code (should come out with a BSD license), change the packages from javax.daemon to org.apache and keep the two in sync. When it finally comes out, we can simply incorporate it and change back to javax.daemon. Tomcat 4.0 will use port 8008 for its Warp Connector. Can this be filtered using the Request Filter Valve? The docs for the Request Filter refer to denying HTTP requests. As long as the Warp connector properly identifies where the request originated (which I am pretty sure it does), you can indeed use request filters to accept only requests from matching clients. However, this cannot be used to control where the connection from Apache comes from -- that would require code in the connector itself. Actually, that's all the way around... GetRemoteHost() and addr() return the Apache client, not the WARP client... Filtering at WARP level is a feature that can be integrated in the connector... Pier Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Restricting Access to Tomcat 3.x and Tomcat 4.0 Connectors
Craig R. McClanahan [EMAIL PROTECTED] wrote: BARF, Craig :) :) :) Bind your serversocket to the 127.0.0.1 address only, and the trick is done... (if it doesn't work, it's a JVM/OS problem) That controls where the *destination* of the client connection can go, but not the *origin*. Look again and find me the appropriate JDK methods to call to say "only accept connections from IP address a.b.c.d", which was the original question. But if your concern is to have connections coming ONLY from the localhost interface (127.0.0.1), that by definition of any TCP-IP stack I've seen so far can accept connections only from itself... I know, if you want to accept or reject connections from Ips different from 127.0.0.1, you always have to open the socket, but if you bind only to 127.0.0.1 you're guaranteed that all connections can only come from the same interface... (AFAIK!) :) :) :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Restricting Access to Tomcat 3.x and Tomcat 4.0 Connectors
Dan Milstein [EMAIL PROTECTED] wrote: The spec for the Ajp2.1 (which was not, AFAIK, ever implemented) has an excellent section discussing "Security Hazards". Anyone interested can check that out at: http://java.apache.org/jserv/protocol/AJPv21.html Hehehe :) I was one of the co-authors of that spec :) (Nice to see when someone pulls out a work from the past and says it contains "excellent" pointers) To deny DOS attacks, I suggest using kernel-level IP filtering packages (such as the IPF package for Solaris/*BSD or IPCHAINS for Linux - or whatever it's name is today). They work pretty well, try to connect to port 8080 on kali.betaversion.org :) :) :) (Tomcat is running with the default HTTP connector, but its access is restricted to only 127.0.0.1 and 192.168.1.* if it comes from the right Ethernet interface :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
