RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java
Hi Keith, What about adding the REPORT method to ajp13, found in jakarta-tomcat-connector ? Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: mod_webapp with Apache 2.0
Good news Pier Happy to see a second connector web-connector for Apache 2.0 ;) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 6:22 PM To: tomcat dev jakarta.apache.org Subject: FW: mod_webapp with Apache 2.0 Directly from the authors of Apache 2.0, I'm very happy to announce that the WebApp module has now support for the new HTTPD. Thank you to the Covalent dream team... Pier -- Forwarded Message From: Ryan Bloom [EMAIL PROTECTED] Organization: Covalent Technologies Reply-To: [EMAIL PROTECTED] Date: Tue, 21 Aug 2001 09:17:25 -0700 To: Pier P. Fumagalli [EMAIL PROTECTED], Ian Kallen [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Dirk-Willem van Gulik [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: mod_webapp with Apache 2.0 Pier, Here is the C code for mod_webapp for Apache 2.0. I have it building on my machine, but APXS is horribly broken, and I haven't had time to fix it yet. That is on my VERY short list of things to do. Regardless, I have a hacked up build system, and this does build for me. I don't have Tomcat 4.0 setup though, so I haven't been able to test it yet. Again, on my VERY short list of projects. I'm hoping to have a Makefile that actually works very soon as well. :-) Ryan __ Ryan Bloom[EMAIL PROTECTED] Covalent Technologies[EMAIL PROTECTED] -- -- End of Forwarded Message
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade ServletInputStreamFacade.java
keith 01/08/23 04:22:25
Modified:src/facade22/org/apache/tomcat/facade
ServletInputStreamFacade.java
Log:
Read should report -1 if the stream is in an eof state.
Revision ChangesPath
1.4 +1 -1
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletInputStreamFacade.java
Index: ServletInputStreamFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletInputStreamFacade.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ServletInputStreamFacade.java 2001/02/09 07:46:58 1.3
+++ ServletInputStreamFacade.java 2001/08/23 11:22:25 1.4
@@ -148,7 +148,7 @@
}
return numRead;
} else {
- return 0;
+ return -1;
//return doRead(b, off, len);
}
}
RE: ajp13, tc 3.3
| -Original Message- | I suppose you're talking about chunked encoding on the input ? Yep. | The current mechanism is not the best - we shouldn't use Content-Length, | but let the connector signal the end of the stream. Yes, exactly. Both request and the facade input stream take an unknown content length to be an eof state. So, even if the data is there, a servlet can't read it. | Now the big question is when and where to make the changes. I don't feel | very good about doing anything big for 3.3, at least not on Ajp13. I think | we can do few fixes in the facade, with a lot of care. I think ajp is handling the missing content length case OK, except we might need to send an initial body chunk even if contentlength is not specified. I was hoping to get it in tc 3.3 since tc is not quite doing what one would expect from reading the spec. How about I post a diff for review and we go from there? |It should. We need to fix this one for sure. Done. Thanks for your input! Keith
Re: Security issues with Tomcat 3.2.x
On Wed, 22 Aug 2001 09:41:04 -0500, you wrote: JkMount /*.jsp ajp13 Yes, this solves my problem. But I think this issue should be documented. I remember having read about this command for telling Apache to forward *all* .jsp pages to Tomcat, but I haven't seen any advice for preventing the // source view problem described. Normally people will think that if he/she has his/her jsp's on foo directory it is sufficient with something like JkMount /foo/*.jsp ajp13. The // is tricky... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** [EMAIL PROTECTED] http://pagina.de/romansoft ~~~
RE: ajp13, tc 3.3
On Thu, 23 Aug 2001, Keith Wannamaker wrote: I think ajp is handling the missing content length case OK, except we might need to send an initial body chunk even if contentlength is not specified. I was hoping to get it in tc 3.3 since tc is not quite doing what one would expect from reading the spec. How about I post a diff for review and we go from there? What about this: we do the change in facade ( if Larry is +1 on this !), since they are clearly breaking the spec: -1 means unknown length, not no content. It should be a simple change, we just must make sure we check all places where ContentLength is used and fix it everywhere. I think Ajp13 connector can also be easily fixed. For C side - I would sugest you do it in j-t-c. The code there has few other enhancements, including the very nice configure, and can be used instead of the native in the main branch. Also, if something bigger is needed in the java side of the connector - I would use ajp14. Costin
RE: ajp13, tc 3.3
I think ajp is handling the missing content length case OK, except we might need to send an initial body chunk even if contentlength is not specified. I was hoping to get it in tc 3.3 since tc is not quite doing what one would expect from reading the spec. How about I post a diff for review and we go from there? What about this: we do the change in facade ( if Larry is +1 on this !), since they are clearly breaking the spec: -1 means unknown length, not no content. It should be a simple change, we just must make sure we check all places where ContentLength is used and fix it everywhere. I think Ajp13 connector can also be easily fixed. For C side - I would sugest you do it in j-t-c. The code there has few other enhancements, including the very nice configure, and can be used instead of the native in the main branch. Also, if something bigger is needed in the java side of the connector - I would use ajp14. Warning, people to not change anything in ajp13 protocol. We must maintain compatibility with TC 3.2.x !!! If you need to upgrade the protocol, please consider playing with ajp14 in j-t-c :)
RE: ajp13, tc 3.3
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 10:21 AM To: [EMAIL PROTECTED] Subject: RE: ajp13, tc 3.3 On Thu, 23 Aug 2001, Keith Wannamaker wrote: I think ajp is handling the missing content length case OK, except we might need to send an initial body chunk even if contentlength is not specified. I was hoping to get it in tc 3.3 since tc is not quite doing what one would expect from reading the spec. How about I post a diff for review and we go from there? What about this: we do the change in facade ( if Larry is +1 on this !), since they are clearly breaking the spec: -1 means unknown length, not no content. It should be a simple change, we just must make sure we check all places where ContentLength is used and fix it everywhere. To make sure I am in sync, exactly which spec are you refering to. Thanks. Larry I think Ajp13 connector can also be easily fixed. For C side - I would sugest you do it in j-t-c. The code there has few other enhancements, including the very nice configure, and can be used instead of the native in the main branch. Also, if something bigger is needed in the java side of the connector - I would use ajp14. Costin
cvs commit: jakarta-tomcat/src/etc/jk workers.properties jni_workers.properties
costin 01/08/23 07:57:33 Modified:src/etc/jk workers.properties Removed: src/etc/jk jni_workers.properties Log: First change - re-fixing jni worker. The 'main' workers.properties is used, and the 'main' server.xml is used ( now server.xml includes JNI by default, since the module can detect the startup mode and enable or disable itself ). Workers.properties should be the only config file you need to change to set up the workers ( and apache communication with tomcat ). Revision ChangesPath 1.4 +24 -34jakarta-tomcat/src/etc/jk/workers.properties Index: workers.properties === RCS file: /home/cvs/jakarta-tomcat/src/etc/jk/workers.properties,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- workers.properties2001/03/16 20:50:19 1.3 +++ workers.properties2001/08/23 14:57:33 1.4 @@ -1,9 +1,3 @@ -# -# $Header: /home/cvs/jakarta-tomcat/src/etc/jk/workers.properties,v 1.3 2001/03/16 20:50:19 larryi Exp $ -# $Revision: 1.3 $ -# $Date: 2001/03/16 20:50:19 $ -# -# # workers.properties - # # This file provides jk derived plugins with the needed information to @@ -37,6 +31,8 @@ # # +# OPTIONS ( very important for jni mode ) + # # workers.tomcat_home should point to the location where you # installed tomcat. This is where you have your conf, webapps and lib @@ -71,7 +67,10 @@ # # The workers that your plugins should create and work with # +# Add 'inprocess' if you want JNI connector worker.list=ajp12, ajp13 +# , inprocess + # #-- DEFAULT ajp12 WORKER DEFINITION -- @@ -152,58 +151,49 @@ # # Additional class path components. # -worker.inprocess.class_path=$(workers.tomcat_home)$(ps)classes +worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)tomcat.jar +worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)container$(ps)tomcat-modules.jar -# -# The XML parser provided with Tomcat -# -worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)jaxp.jar -worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)parser.jar - -# -# Tomcat's implementation # -worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)jasper.jar -worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)servlet.jar -worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)webserver.jar - -# -# Javac as available from Java2SE -# -worker.inprocess.class_path=$(workers.java_home)$(ps)lib$(ps)tools.jar - -# -# Setting the command line for tomcat +# Setting the command line for tomcat. # Note: The cmd_line string may not contain spaces. # -worker.inprocess.cmd_line=-config -worker.inprocess.cmd_line=$(workers.tomcat_home)$(ps)conf$(ps)jni_server.xml -worker.inprocess.cmd_line=-home -worker.inprocess.cmd_line=$(workers.tomcat_home) +worker.inprocess.cmd_line=start + +# Not needed, but can be customized. +#worker.inprocess.cmd_line=-config +#worker.inprocess.cmd_line=$(workers.tomcat_home)$(ps)conf$(ps)server.xml +#worker.inprocess.cmd_line=-home +#worker.inprocess.cmd_line=$(workers.tomcat_home) # # The JVM that we are about to use # # This is for Java2 # +# Windows worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)bin$(ps)classic$(ps)jvm.dll +# IBM JDK1.3 +#worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)bin$(ps)classic$(ps)libjvm.so +# Unix - Sun VM or blackdown +#worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)lib$(ps)i386$(ps)classic$(ps)libjvm.so # # And this is for jdk1.1.X # #worker.inprocess.jvm_lib=$(workers.java_home)$(ps)bin$(ps)javai.dll -# + # # Setting the place for the stdout and stderr of tomcat # -worker.inprocess.stdout=$(workers.tomcat_home)$(ps)inprocess.stdout -worker.inprocess.stderr=$(workers.tomcat_home)$(ps)inprocess.stderr +worker.inprocess.stdout=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stdout +worker.inprocess.stderr=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stderr # # Setting the tomcat.home Java property # -worker.inprocess.sysprops=tomcat.home=$(workers.tomcat_home) +#worker.inprocess.sysprops=tomcat.home=$(workers.tomcat_home) # # Java system properties
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa AccessInterceptor.java
costin 01/08/23 07:59:14
Modified:src/share/org/apache/tomcat/modules/aaa
AccessInterceptor.java
Log:
Fix for # 2148.
Thanks [EMAIL PROTECTED] (Mahmoud)
Submitted by: [EMAIL PROTECTED] (Mahmoud)
Revision ChangesPath
1.13 +6 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/AccessInterceptor.java
Index: AccessInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/AccessInterceptor.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- AccessInterceptor.java2001/07/15 23:58:32 1.12
+++ AccessInterceptor.java2001/08/23 14:59:14 1.13
@@ -421,6 +421,12 @@
// It's called in a single thread anyway
public synchronized void addContainer(Container ct) {
+ //bug 2148
+ if(patterns=securityPatterns.length) {
+ Container [] newsecurityPatterns = new
Container[MAX_CONSTRAINTS+securityPatterns.length];
+
System.arraycopy(securityPatterns,0,newsecurityPatterns,0,securityPatterns.length);
+ securityPatterns = newsecurityPatterns;
+ }
securityPatterns[ patterns ]= ct;
patterns++;
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config BaseJkConfig.java
costin 01/08/23 08:01:57
Modified:src/share/org/apache/tomcat/modules/config BaseJkConfig.java
Log:
Added 'regenerate' property to config generator modules.
If the attribute is set, config will be generated at startup. We can now inlcude
the modules by default, since they'll do nothing ( the current behavior ).
If -jkconf option is present on the command line ( or ContextManager properties ),
the config modules will generate the config file ( -jkconf only generates config,
it does not start tomcat !).
Revision ChangesPath
1.4 +25 -5
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/BaseJkConfig.java
Index: BaseJkConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/BaseJkConfig.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BaseJkConfig.java 2001/08/11 03:37:28 1.3
+++ BaseJkConfig.java 2001/08/23 15:01:57 1.4
@@ -1,4 +1,4 @@
-/* $Id: BaseJkConfig.java,v 1.3 2001/08/11 03:37:28 larryi Exp $
+/* $Id: BaseJkConfig.java,v 1.4 2001/08/23 15:01:57 costin Exp $
*
*
* The Apache Software License, Version 1.1
@@ -118,7 +118,7 @@
p
@author Costin Manolache
@author Larry Isaacs
- @version $Revision: 1.3 $
+ @version $Revision: 1.4 $
*/
public class BaseJkConfig extends BaseInterceptor {
protected File configHome = null;
@@ -132,8 +132,22 @@
protected boolean forwardAll=true;
protected String tomcatHome;
-
+protected boolean regenerate=false;
+
// Tomcat callbacks
+
+public void addInterceptor( ContextManager cm,
+ Context ctx,
+ BaseInterceptor bi )
+ throws TomcatException
+{
+ if( cm.getProperty( jkconf ) != null ) {
+ // we are in config generation mode - prevent tomcat
+ // from starting.
+ //??? cm.setNote(nostart, this );
+ }
+}
+
// Auto-config should be able to react to dynamic config changes,
// and regenerate the config.
@@ -145,7 +159,13 @@
{
if( state != ContextManager.STATE_INIT )
return;
-execute( cm );
+ // Generate the config only if regenerate property is
+ // set on the module or if an explicit jkconf option has
+ // been set on context manager.
+ if( regenerate ||
+ cm.getProperty(jkconf) !=null) {
+ execute( cm );
+ }
}
public void contextInit(Context ctx)
@@ -331,4 +351,4 @@
return docBase;
}
-}
\ No newline at end of file
+}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server JNIEndpoint.java
costin 01/08/23 08:02:42
Modified:src/share/org/apache/tomcat/modules/server JNIEndpoint.java
Log:
Use Main to start tomcat. Tomcat.java is deprecated, either EmbededTomcat or
Main should be used.
Revision ChangesPath
1.3 +4 -4
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java
Index: JNIEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JNIEndpoint.java 2001/08/15 02:32:02 1.2
+++ JNIEndpoint.java 2001/08/23 15:02:42 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java,v
1.2 2001/08/15 02:32:02 mmanders Exp $
- * $Revision: 1.2 $
- * $Date: 2001/08/15 02:32:02 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java,v
1.3 2001/08/23 15:02:42 costin Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/08/23 15:02:42 $
*
*
*
@@ -205,7 +205,7 @@
boolean failed = true;
try {
System.out.println(Calling main );
-org.apache.tomcat.startup.Tomcat.main(cmdLine);
+org.apache.tomcat.startup.Main.main(cmdLine);
System.out.println(Main returned );
failed = false;
} catch(Throwable t) {
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup EmbededTomcat.java
costin 01/08/23 08:13:47
Modified:src/share/org/apache/tomcat/startup EmbededTomcat.java
Log:
Added the -jkconf option.
Revision ChangesPath
1.50 +13 -0
jakarta-tomcat/src/share/org/apache/tomcat/startup/EmbededTomcat.java
Index: EmbededTomcat.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/EmbededTomcat.java,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- EmbededTomcat.java2001/08/22 04:55:33 1.49
+++ EmbededTomcat.java2001/08/23 15:13:47 1.50
@@ -106,6 +106,9 @@
boolean autoDeploy=true;
boolean serverXml=true;
+
+// prevent tomcat from starting.
+boolean nostart=false;
public EmbededTomcat() {
// setDebug( 10 );
@@ -147,6 +150,11 @@
attributes.put(sandbox, true);
}
+public void setJkconf(boolean b ) {
+ attributes.put(jkconf, true);
+ nostart=true;
+}
+
// First param
public void setStart(boolean b) {
// nothing, default mode
@@ -422,6 +430,11 @@
}
public void start() throws TomcatException {
+ if( nostart ) {
+ debug(Tomcat will not start - configuration only mode );
+ contextM.shutdown();
+ return;
+ }
long time3=System.currentTimeMillis();
contextM.start();
long time4=System.currentTimeMillis();
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_ajp13_worker.c
hgomez 01/08/23 08:41:20
Modified:src/native/mod_jk/common jk_ajp13_worker.c
Log:
Handle client Browser Stop button
Submitted by: William Barker [EMAIL PROTECTED]
Revision ChangesPath
1.10 +13 -3 jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c
Index: jk_ajp13_worker.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- jk_ajp13_worker.c 2001/07/18 21:36:35 1.9
+++ jk_ajp13_worker.c 2001/08/23 15:41:20 1.10
@@ -58,7 +58,7 @@
* Author: Henri Gomez [EMAIL PROTECTED] *
* Author: Costin [EMAIL PROTECTED] *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.9 $ *
+ * Version: $Revision: 1.10 $ *
***/
#include jk_pool.h
@@ -75,6 +75,7 @@
#define DEF_CACHE_SZ(1)
#define JK_INTERNAL_ERROR (-2)
#define JK_FATAL_ERROR (-3)
+#define JK_CLIENT_ERROR (-4)
#define MAX_SEND_BODY_SZ(DEF_BUFFER_SZ - 6)
#define AJP13_HEADER_LEN (4)
#define AJP13_HEADER_SZ_LEN (2)
@@ -338,7 +339,7 @@
res.num_headers)) {
jk_log(l, JK_LOG_ERROR,
Error ajp13_process_callback - start_response
failed\n);
-return JK_FATAL_ERROR;
+return JK_CLIENT_ERROR;
}
}
break;
@@ -349,7 +350,7 @@
if(!r-write(r, jk_b_get_buff(msg) + jk_b_get_pos(msg), len)) {
jk_log(l, JK_LOG_ERROR,
Error ajp13_process_callback - write failed\n);
-return JK_FATAL_ERROR;
+return JK_CLIENT_ERROR;
}
}
break;
@@ -711,6 +712,15 @@
*/
op-recoverable = JK_FALSE;
return JK_FALSE;
+} else if(JK_CLIENT_ERROR == rc) {
+ /*
+ * Client has stop talking to us, so get out.
+ * We assume this isn't our fault, so just a normal exit.
+ * In most (all?) cases, the ajp13_endpoint::reuse will still be
+ * false here, so this will be functionally the same as an
+ * un-recoverable error. We just won't log it as such.
+ */
+ return JK_TRUE;
} else if(rc 0) {
return (JK_FALSE); /* XXX error */
}
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp13.h jk_ajp_common.c
hgomez 01/08/23 08:51:08
Modified:jk/native/common jk_ajp13.h jk_ajp_common.c
Log:
Handle client Browser Stop Button
Submitted by: William Barker [EMAIL PROTECTED]
Revision ChangesPath
1.6 +2 -1 jakarta-tomcat-connectors/jk/native/common/jk_ajp13.h
Index: jk_ajp13.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp13.h,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_ajp13.h2001/07/23 21:02:43 1.5
+++ jk_ajp13.h2001/08/23 15:51:08 1.6
@@ -58,7 +58,7 @@
/***
* Description: Experimental bi-directionl protocol handler. *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.5 $ *
+ * Version: $Revision: 1.6 $ *
***/
#ifndef JK_AJP13_H
#define JK_AJP13_H
@@ -79,6 +79,7 @@
#define AJP13_DEF_CACHE_SZ (1)
#define JK_INTERNAL_ERROR(-2)
#define JK_FATAL_ERROR (-3)
+#define JK_CLIENT_ERROR (-4)
#define AJP13_MAX_SEND_BODY_SZ (DEF_BUFFER_SZ - 6)
/*
1.7 +12 -3 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- jk_ajp_common.c 2001/07/23 21:02:43 1.6
+++ jk_ajp_common.c 2001/08/23 15:51:08 1.7
@@ -59,7 +59,7 @@
* Description: common stuff for bi-directional protocols ajp13/ajp14. *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Author: Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.6 $ *
+ * Version: $Revision: 1.7 $ *
***/
@@ -861,7 +861,7 @@
(const char * const *)res.header_values,
res.num_headers)) {
jk_log(l, JK_LOG_ERROR, Error ajp_process_callback -
start_response failed\n);
-return JK_FATAL_ERROR;
+return JK_CLIENT_ERROR;
}
}
break;
@@ -871,7 +871,7 @@
unsigned len = (unsigned)jk_b_get_int(msg);
if(!r-write(r, jk_b_get_buff(msg) + jk_b_get_pos(msg), len)) {
jk_log(l, JK_LOG_ERROR, Error ajp_process_callback - write
failed\n);
-return JK_FATAL_ERROR;
+return JK_CLIENT_ERROR;
}
}
break;
@@ -980,6 +980,15 @@
*/
op-recoverable = JK_FALSE;
return JK_FALSE;
+} else if(JK_CLIENT_ERROR == rc) {
+ /*
+ * Client has stop talking to us, so get out.
+ * We assume this isn't our fault, so just a normal exit.
+ * In most (all?) cases, the ajp13_endpoint::reuse will still be
+ * false here, so this will be functionally the same as an
+ * un-recoverable error. We just won't log it as such.
+ */
+return JK_TRUE;
} else if(rc 0) {
return (JK_FALSE); /* XXX error */
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets InvokerServlet.java
craigmcc01/08/23 09:42:27
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
catalina/src/share/org/apache/catalina/servlets
InvokerServlet.java
Log:
Fix the race condition on the invoker servlet for real this time. It
helps if you include *all* of the critical section code inside the
synchronized block.
PR: Bugzilla #3188
Submitted by: Eddie Ruvinsky
Revision ChangesPath
1.29 +8 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- StandardWrapper.java 2001/08/16 02:46:52 1.28
+++ StandardWrapper.java 2001/08/23 16:42:26 1.29
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
1.28 2001/08/16 02:46:52 craigmcc Exp $
- * $Revision: 1.28 $
- * $Date: 2001/08/16 02:46:52 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
1.29 2001/08/23 16:42:26 craigmcc Exp $
+ * $Revision: 1.29 $
+ * $Date: 2001/08/23 16:42:26 $
*
*
*
@@ -105,7 +105,7 @@
* make them efficient are counter-productive.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.28 $ $Date: 2001/08/16 02:46:52 $
+ * @version $Revision: 1.29 $ $Date: 2001/08/23 16:42:26 $
*/
public final class StandardWrapper
@@ -1133,7 +1133,10 @@
protected String logName() {
StringBuffer sb = new StringBuffer(StandardWrapper[);
-sb.append(getParent().getName());
+if (getParent() != null)
+sb.append(getParent().getName());
+else
+sb.append(null);
sb.append(':');
sb.append(getName());
sb.append(']');
1.12 +22 -21
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java
Index: InvokerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- InvokerServlet.java 2001/08/20 22:43:52 1.11
+++ InvokerServlet.java 2001/08/23 16:42:26 1.12
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
1.11 2001/08/20 22:43:52 craigmcc Exp $
- * $Revision: 1.11 $
- * $Date: 2001/08/20 22:43:52 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
1.12 2001/08/23 16:42:26 craigmcc Exp $
+ * $Revision: 1.12 $
+ * $Date: 2001/08/23 16:42:26 $
*
*
*
@@ -87,7 +87,7 @@
* in the web application deployment descriptor.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.11 $ $Date: 2001/08/20 22:43:52 $
+ * @version $Revision: 1.12 $ $Date: 2001/08/23 16:42:26 $
*/
public final class InvokerServlet
@@ -326,26 +326,27 @@
String pattern = inServletPath + / + servletClass + /*;
Wrapper wrapper = null;
-// Are we referencing an existing servlet name?
-wrapper = (Wrapper) context.findChild(servletClass);
-if (wrapper != null) {
-if (debug = 1)
-log(Using wrapper for servlet ' +
-wrapper.getName() + ' with mapping ' + pattern + ');
-context.addServletMapping(pattern, wrapper.getName());
-}
+// Synchronize to avoid race conditions when multiple requests
+// try to initialize the same servlet at the same time
+synchronized (this) {
+
+// Are we referencing an existing servlet name?
+wrapper = (Wrapper) context.findChild(servletClass);
+if (wrapper != null) {
+if (debug = 1)
+log(Using wrapper for servlet ' +
+wrapper.getName() + ' with mapping ' +
+pattern + ');
+context.addServletMapping(pattern, wrapper.getName());
+}
-// No, create a new wrapper for the specified servlet class
-else {
+// No, create a new wrapper for the specified servlet class
+else {
-if (debug = 1)
-
jakarta-tools/javac.jar
does anybody know if it is legal to redistribute this jar file? if it is legal to redistribute this jar, but not tools.jar, why? thanks for any info, -kevin.
RE: ajp13, tc 3.3
On Thu, 23 Aug 2001, Larry Isaacs wrote: length, not no content. It should be a simple change, we just must make sure we check all places where ContentLength is used and fix it everywhere. To make sure I am in sync, exactly which spec are you refering to. Thanks. ServletRequest.getContentLength(), in javadoc it says returns -1 if the content length is unknown. ServletInputStream treats -1 as no content. It's not a big deal, as most 'common' requests with a body will have a content length header, but it is legal to have a request with body but without content-lenght. That becomes interesting for SOAP with attachments, where the body starts to be 'interesting'. In many cases, if you have (many) large attachments, you'll not be able to buffer all of them to get the total count - or guess how big the result will be ( since MimeMultipart relys on separators that are random and hard to predict the size, etC). The fix in ServletInputStreamFacade is reasonably simple - if Content-Length is -1, rely on the adapter to signal the end of the request ( by returning -1 on doRead ). Every case that works today will still work ( since now it doesn't work without Content-Length anyway, we'll just make this other case to work too ). Costin
RE: ajp13, tc 3.3
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 12:59 PM To: '[EMAIL PROTECTED]' Subject: RE: ajp13, tc 3.3 On Thu, 23 Aug 2001, Larry Isaacs wrote: length, not no content. It should be a simple change, we just must make sure we check all places where ContentLength is used and fix it everywhere. To make sure I am in sync, exactly which spec are you refering to. Thanks. ServletRequest.getContentLength(), in javadoc it says returns -1 if the content length is unknown. ServletInputStream treats -1 as no content. It's not a big deal, as most 'common' requests with a body will have a content length header, but it is legal to have a request with body but without content-lenght. That becomes interesting for SOAP with attachments, where the body starts to be 'interesting'. In many cases, if you have (many) large attachments, you'll not be able to buffer all of them to get the total count - or guess how big the result will be ( since MimeMultipart relys on separators that are random and hard to predict the size, etC). The fix in ServletInputStreamFacade is reasonably simple - if Content-Length is -1, rely on the adapter to signal the end of the request ( by returning -1 on doRead ). Every case that works today will still work ( since now it doesn't work without Content-Length anyway, we'll just make this other case to work too ). I think this makes sense to do. I'll try to review and help test the changes. Larry
tomcat 4 and CLIENT-CERT auth (maybe) not working properly
when i attempt to use CLIENT-CERT auth with the tomcat 4 manager webapp, tomcat appears to still be looking for basic auth credentials. for example, if i change web.xml in the manager webapp to look like this: --- snip --- security-constraint web-resource-collection web-resource-nameEntire Application/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint !-- NOTE: This role is not present in the default users file -- role-name*/role-name /auth-constraint /security-constraint login-config auth-methodCLIENT-CERT/auth-method /login-config --- end snip --- and configure an ssl connector along with my keystore, then try to access the manager app from a client, i get a 401: HTTP/1.1 401 Cannot authenticate with the provided credentials Content-Type: text/html Date: Thu, 23 Aug 2001 20:46:21 GMT Server: Apache Tomcat/4.0-b8-dev (HTTP/1.1 Connector) Connection: close Connection: close html head titleTomcat Error Report/title brbr h1HTTP Status 401 - Cannot authenticate with the provided credentials/h1 /body /html two message appear to show up in the log when i send the request: 2001-08-23 16:09:14 CertificatesValve[/manager]: verify: SSLPeerUnverifiedException 2001-08-23 16:09:15 CertificatesValve[/manager]: expose: Exposing converted certificates which, from looking through CertificatesValve.java, seems to indicate that the client cert chain was properly verified. from reading the servlet spec, it seems that using CLIENT-CERT should not require me to do basic auth as well. did i read the spec wrong, or is this a tomcat 4 bug? thanks, -kevin.
[PATCH] javadoc patch for minor build error (3.3)
An empty @return directive was throwing a minor build message. While I was there, I did a few other trivial touch-ups. Typos, as well as a new @return for a method that was missing one. :) - Christopher RealmBase.patch
TomcatAuthentication
Hola Joe: Almost sure my fault, please post a bug with the explanation to http://nagoya.apache.org/bugzilla i will look at it ASAP.. Thanks for the feedback and sorry for the slow response ( Just coming back from beach :) TIA Saludos , Ignacio J. Ortega
Tomcat 3.2.3 and getPathInfo
It seems that Tomcat 3.2.3 has a bug (a regression) that hits my book's Example 5-5. See: http://www.servlets.com/jservlet2/examples/ch05/index.html#ex05_05 The bug is that for the following URL: http://www.servlets.com/jservlet2/examples/ch05/goto/http://www.servlets.com the goto servlet should have extra path info of http://www.servlets.com; and in fact does with Tomcat 3.2.1 but with 3.2.3 it now returns /www.servlets.com. My guess is the server may be trying to do a windows to unix filename conversion? It could also be a side effect of decoding, although there are no special chars there to be decoded. Is this a known issue? I didn't find anything with a quick list scan. -jh-
Re: [BUG] Jasper parsing of XML documents
On the off chance anyone needs to know (and I appear to be the only one who cares about XML syntax issues :) it looks from the code like what Jasper is doing is that, while parsing a tag, it outputs any uninterpreted child tags it encounters, but accumulates all child sections of character data until the end tag of the parent and then writes it all out at once in a single CDATA. This gives the effect I described in a previous mail where a mixture of markup and data comes out of Jasper in a different order, with the CDATA at the end. I guess this means a solution is to wrap all such data in jsp:text tags. Perhaps this is even a requirement; the spec is not entirely clear on the distinction between template data and XML fragments. Most of the time, character data seems to be handled ok by Jasper without the jsp:text tags, but maybe that is misleading and wrong. Does anyone clearly understand the intent of the spec here? Mark
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java
craigmcc01/08/23 15:15:43
Modified:catalina/src/share/org/apache/catalina Server.java
catalina/src/share/org/apache/catalina/core
StandardServer.java
Added: catalina/src/share/org/apache/catalina ServerFactory.java
Log:
Add a singleton that will return the Server at the top of the component
tree, without requiring a reference to any component in the tree.
Revision ChangesPath
1.7 +8 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Server.java
Index: Server.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Server.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Server.java 2001/07/22 21:02:45 1.6
+++ Server.java 2001/08/23 22:15:43 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Server.java,v 1.6
2001/07/22 21:02:45 pier Exp $
- * $Revision: 1.6 $
- * $Date: 2001/07/22 21:02:45 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Server.java,v 1.7
2001/08/23 22:15:43 craigmcc Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/08/23 22:15:43 $
*
*
*
@@ -85,9 +85,13 @@
* specified by the codeport/code property. When a connection is accepted,
* the first line is read and compared with the specified shutdown command.
* If the command matches, shutdown of the server is initiated.
+ * p
+ * strongNOTE/strong - The concrete implementation of this class should
+ * register the (singleton) instance with the codeServerFactory/code
+ * class in its constructor(s).
*
* @author Craig R. McClanahan
- * @version $Revision: 1.6 $ $Date: 2001/07/22 21:02:45 $
+ * @version $Revision: 1.7 $ $Date: 2001/08/23 22:15:43 $
*/
public interface Server {
1.1
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ServerFactory.java
Index: ServerFactory.java
===
/*
* $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ServerFactory.java,v
1.1 2001/08/23 22:15:43 craigmcc Exp $
* $Revision: 1.1 $
* $Date: 2001/08/23 22:15:43 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software
Request: binary mod_webapp.so for Solaris built with -DEAPI
I was using the mod_webapp.so connector for Solaris which I downloaded from apache.org All was going well until I rebuilt my Apache (1.3.20) with SSL support. Now I get: [warn] Loaded DSO libexec/mod_webapp.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI) Well, I didn't compile it, so I can't recompile it. I expect that a number of other users will be in the same boat. Is there any compelling reason not to build with -DEAPI? What will really happen if this mod_webapp.so is used? -- Eryq
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardEngine.java StandardService.java
craigmcc01/08/23 15:32:10
Modified:catalina/src/share/org/apache/catalina Connector.java
Engine.java
catalina/src/share/org/apache/catalina/connector/http
HttpConnector.java
catalina/src/share/org/apache/catalina/connector/http10
HttpConnector.java
catalina/src/share/org/apache/catalina/connector/warp
WarpConnector.java
catalina/src/share/org/apache/catalina/core
StandardEngine.java StandardService.java
Log:
Add navigation link properties so that the entire Catalina component
hierarchy can be navigated. Previously, you could go down from a
Service to its associated Connector and Container children, but you
could not go up.
Note that the existence of Server and Service components is optional -
they are used when Catalina is configured from conf/server.xml, but are
not typically used in embedded environments.
Revision ChangesPath
1.10 +18 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java
Index: Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Connector.java2001/07/22 21:02:45 1.9
+++ Connector.java2001/08/23 22:32:10 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java,v
1.9 2001/07/22 21:02:45 pier Exp $
- * $Revision: 1.9 $
- * $Date: 2001/07/22 21:02:45 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Connector.java,v
1.10 2001/08/23 22:32:10 craigmcc Exp $
+ * $Revision: 1.10 $
+ * $Date: 2001/08/23 22:32:10 $
*
*
*
@@ -117,7 +117,7 @@
* normative.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.9 $ $Date: 2001/07/22 21:02:45 $
+ * @version $Revision: 1.10 $ $Date: 2001/08/23 22:32:10 $
*/
public interface Connector {
@@ -222,6 +222,20 @@
* @param secure The new secure connection flag
*/
public void setSecure(boolean secure);
+
+
+/**
+ * Return the codeService/code with which we are associated (if any).
+ */
+public Service getService();
+
+
+/**
+ * Set the codeService/code with which we are associated (if any).
+ *
+ * @param service The service that owns this Engine
+ */
+public void setService(Service service);
// - Public Methods
1.6 +18 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Engine.java
Index: Engine.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Engine.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Engine.java 2001/07/22 20:13:30 1.5
+++ Engine.java 2001/08/23 22:32:10 1.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Engine.java,v 1.5
2001/07/22 20:13:30 pier Exp $
- * $Revision: 1.5 $
- * $Date: 2001/07/22 20:13:30 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Engine.java,v 1.6
2001/08/23 22:32:10 craigmcc Exp $
+ * $Revision: 1.6 $
+ * $Date: 2001/08/23 22:32:10 $
*
*
*
@@ -90,7 +90,7 @@
* should throw codeIllegalArgumentException/code.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.5 $ $Date: 2001/07/22 20:13:30 $
+ * @version $Revision: 1.6 $ $Date: 2001/08/23 22:32:10 $
*/
public interface Engine extends Container {
@@ -111,6 +111,20 @@
* @param defaultHost The new default host
*/
public void setDefaultHost(String defaultHost);
+
+
+/**
+ * Return the codeService/code with which we are associated (if any).
+ */
+public Service getService();
+
+
+/**
+ * Set the codeService/code with which we are associated (if any).
+ *
+ * @param service The service that owns this Engine
+ */
+public void setService(Service service);
/**
1.22 +33 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java
Index: HttpConnector.java
===
RCS file:
Re: [BUG] Jasper parsing of XML documents
On Thu, 23 Aug 2001, Mark Abbott wrote: Date: Thu, 23 Aug 2001 15:04:49 -0700 From: Mark Abbott [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [BUG] Jasper parsing of XML documents On the off chance anyone needs to know (and I appear to be the only one who cares about XML syntax issues :) it looks from the code like what Jasper is doing is that, while parsing a tag, it outputs any uninterpreted child tags it encounters, but accumulates all child sections of character data until the end tag of the parent and then writes it all out at once in a single CDATA. This gives the effect I described in a previous mail where a mixture of markup and data comes out of Jasper in a different order, with the CDATA at the end. Do you have uninterpreted text that is *not* inside a jsp:text block? I don't think that is actually allowed. I will check with the spec lead. I guess this means a solution is to wrap all such data in jsp:text tags. Perhaps this is even a requirement; the spec is not entirely clear on the distinction between template data and XML fragments. Most of the time, character data seems to be handled ok by Jasper without the jsp:text tags, but maybe that is misleading and wrong. Does anyone clearly understand the intent of the spec here? The way I read things, the goal of the spec is that a page in the original syntax, and the same page in its corresponding XML syntax, should generate identical output. The rules for transforming JSP syntax to XML syntax say to embed *all* template text in jsp:text elements, which would imply that (in the XML syntax view of the page) there would be no uninterpreted template text anywhere *except* inside jsp:text tags (suitably escaped with CDATA as needed). Mark Craig
Re: New SSL HOWTOs
Sorry, I am posting to tomcat-dev although not subscribed...
Two suggestions:
- Perhaps it is a good idea to also describe in the SSL HOWTO ways to
configure SSL without stuffing libs into jre/lib/ext. Some sites run
multiple versions/vendors of jdks, TC, JSSE, et al from (secure) read-only
shared file systems. In such an environment products and versions are
delibarately kept separate from each other in order to avoid having to
maintain countless permutations. Startup scripts link everything together
via env vars. This is also convenient to test different permutations. The
jre/lib/ext mechanism is not an option, due too the read-only nature.
- The other point: I recall a discussion some time ago about the sluggish
performance of session id generation and the idea of using /dev/random to
speed this up. The cryptix JCE CryptixRandom provider can be useful here
(see below a conversation with a sun security engineer).
Wolfgang.
Brad, thanks for the *fast* reponse.
The point is that developing an application has to make sense in the first
place.
10 secs SecureRandom start up time for client side command line apps means
that such an app will never be used.
If an application is never used it is irrelevant how secure it is, except
for academic discourse.
0.5 secs is the pain limit for client side command line apps.
Plus, /dev/random is more than secure enough for many apps.
Just for the record, with the help of the cryptix JCE CryptixRandom
provider (www.cryptix.org) I finally figured out how to do this
effectively. Perhaps others may find the solution helpful as well:
java.security.Security.insertProviderAt(
(java.security.Provider)
Class.forName(cryptix.jce.provider.CryptixRandom).newInstance(), 1);
java.security.Security.addProvider(
((java.security.Provider)
Class.forName(com.sun.net.ssl.internal.ssl.Provider).newInstance()));
com.sun.net.ssl.SSLContext ctx =
com.sun.net.ssl.SSLContext.getInstance(SSL); // JSSE 1.0.2
//javax.net.ssl.SSLContext ctx =
javax.net.ssl.SSLContext.getInstance(SSL); // JDK 1.4
ctx.init(null, null, java.security.SecureRandom.getInstance(DevRandom));
factory = ctx.getSocketFactory();
sock = factory.getSocket(...)
Now on a 2x600 Mhz PentiumIII, Linux
ctx.init() takes 0.2 secs using the /dev/random algo (compared to 10 secs
using the default SecureRandom algo).
Cheers,
Wolfgang.
com.sun.net.ssl.SSLContext.getInstance(SSL).init(null, null, new
java.security.SecureRandom(new byte [] {25,13,32,5}));
to no effect. Perhaps I need to store the SSLContext somewhere. If so,
where?
Again, doing anything like you describe with Random or preseeding with
a fixed byte array is a *VERY BAD* idea in a production system. It's
ok for testing, but you'll seriously limit your security
effectiveness. I can't stress this enough.
As to your immediate question, please have a look at the JSSE API's,
especially those that deal with getting SocketFactories from the
initialized SSLContexts. You use the new socketfactories created by
the SSLContext to create sockets, and you can set these socket
factories in HttpsURLConnection.
Brad
Sorry I'm a newbie and am also seeing the same unacceptable startup delay
(13 secs) - in a command line tool.
I realize I don't understand much about JCA. The only thing I want to
achieve is that a third party library (or even better, the entire JDK) uses
an algorithm that meets performance needs. /dev/random or even
java.util.Random would in many cases be preferable to secure but
unfortunately unusable algos.
Now I can't see any difference by trying the suggestions below.
For example, the line
sr = new SecureRandom(new byte [] {25,13,32,5});
does not make anything faster. Perhaps sr needs to passed to some method?
com.sun.net.ssl.SSLContext.init(null, null, sr)
can only be called if one already has a context in hand. Where and how do I
get a context?
I tried
com.sun.net.ssl.SSLContext.getInstance(SSL).init(null, null, new
java.security.SecureRandom(new byte [] {25,13,32,5}));
to no effect. Perhaps I need to store the SSLContext somewhere. If so,
where?
Obviously I am missing out on something here.
Help, anyone?
(I see that in JDK1.4 the java.security file can be configured to use
/dev/random. But we are still 1 year away from using 1.4 in a production
environment)
Wolfgang.
Will be there a faster version of JSSE ?
I am using JSSE 1.0.1 and it is very slow (especially the handshake,
which lasts round 30 seconds).
Thanks in advance for your answer.
Hello Pierre and Jonathan (and other viewers of the java-security
archives):
Pierre and Jonathan have both noticed that JSSE/SSL connections can
take a long time to negotiate initially.
As Jonathan guessed, the reason is that the default SSLContext
implementation needs to have a source of random numbers. As you may
know, generating true randomness is a hard problem. There are some
algorithms which do a good
Re: New SSL HOWTOs
Wolfgang Hoschek wrote: Sorry, I am posting to tomcat-dev although not subscribed... Two suggestions: - Perhaps it is a good idea to also describe in the SSL HOWTO ways to configure SSL without stuffing libs into jre/lib/ext. Some sites run multiple versions/vendors of jdks, TC, JSSE, et al from (secure) read-only shared file systems. In such an environment products and versions are delibarately kept separate from each other in order to avoid having to maintain countless permutations. Startup scripts link everything together via env vars. This is also convenient to test different permutations. The jre/lib/ext mechanism is not an option, due too the read-only nature. Hmmm ... that's interesting. It's true that the JSSE libs don't necessarily have to be an installed extension, and it's easy enough to include a quick phrase about the classpath instead. I'm reluctant to encourage users to put them into the internal Tomcat classloader directories, since that is a rather sketchy configuration (someone will eventually add JSSE to the classpath as well, which will cause Tomcat to fail on startup unless the internal versions are removed). So in your environment, it sounds like you would be simply specifying the JSSE jars in classpath passed to TC, yes? - The other point: I recall a discussion some time ago about the sluggish performance of session id generation and the idea of using /dev/random to speed this up. The cryptix JCE CryptixRandom provider can be useful here (see below a conversation with a sun security engineer). LOL! I'm a developer on the Cryptix project ... nice to see people recommending us ;-) You've actually forced me into tipping my hand a little early, but I was going to try and persuade the dev list to let me create a dependency on Cryptix for a few other security proposals that I have not yet completed. Assuming that I can sell it, I would of _course_ be more than happy to examine the feasibility of the CryptixRandom class within Tomcat. It would certainly have the added benefit of also being an OS-independent solution. Cryptix JCE ... you made my week with that one =) - Christopher
[PATCH] ssl-howto update - virtual hosts (4.0)
This is a quick note about the trouble with virtual hosts in SSL. It's one of those non-obvious little gotchas, so I figured it deserves a quick note as well. - Christopher ssl-howto.patch
Re: [BUG] Jasper parsing of XML documents
At 04:02 PM 8/23/2001, Craig R. McClanahan wrote: Do you have uninterpreted text that is *not* inside a jsp:text block? I don't think that is actually allowed. I will check with the spec lead. What I actually see is that the following JSP fragment: tagAtagBtext/tagBtagA appears just like that in the output, without wrapping the text in a jsp:text tag. I assumed this was because the text was being considered part of an XML fragment, but the precise definition of that is unclear. However, this JSP fragment: tagAtagB/tagBtexttagB/tagB/tagA appears as tagAtagB/tagBtagB/tagB/tagAtext unless the text is wrapped in a jsp:text, in which case it appears as written in the JSP. I can clearly see where in the Jasper code it does this reshuffling. I tend to agree with you that the first example ought NOT to to work without the jsp:text (unfortunately, since it is convenient), so the fact that it does is a bug. Clarification would be great if you can get it. And the second example should not silently reshuffle the text either; in both cases the parser should flag the lack of a jsp:text as an error, I guess. I'll file a bug on this, since it seems something must be wrong in any case... Thanks! Mark
RE: Tomcat 3.2.3 and getPathInfo
I just tried this using the SnoopServlet that ships with Tomcat using a URL like http://localhost:8080/servlet/SnoopServlet/http://fubar and got /http:/fubar as the path info. Your description makes it look like your losing http: in addition to the one of the /s. Is this what your seeing? This problem is almost certainly caused the URL normalization code that got put into 3.2.3 to fix a serious security hole. This is going to be difficult to resolve. We have to normalize the URL before the servlet container uses it (I think this is even going to be added to the latest servlet specification) or some really bad things can happen with prefix mapping. However, until we've done the prefix mapping we can't know what part of the URL refers to a servlet and what part is path info. Getting back the original non-normalized path info is going to be tricky. This is even worse because we also won't allow the URL to be encoded like http://localhost:8080/servlet/SnoopServlet/http:%2F%2Ffubar because we make some rather draconian precautions to ensure that nastily encoded URLs can't obtain access to protected resources (or even resources outside the webapp). I'll have to give this one some thought. If URL normalization is being added to the specification then there should also some guidance on how it relates to path info. I'll CC this to servletapi-feedback. Marc Saegesser -Original Message- From: Jason Hunter [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 5:00 PM To: [EMAIL PROTECTED] Subject: Tomcat 3.2.3 and getPathInfo It seems that Tomcat 3.2.3 has a bug (a regression) that hits my book's Example 5-5. See: http://www.servlets.com/jservlet2/examples/ch05/index.html#ex05_05 The bug is that for the following URL: http://www.servlets.com/jservlet2/examples/ch05/goto/http://www.se rvlets.com the goto servlet should have extra path info of http://www.servlets.com; and in fact does with Tomcat 3.2.1 but with 3.2.3 it now returns /www.servlets.com. My guess is the server may be trying to do a windows to unix filename conversion? It could also be a side effect of decoding, although there are no special chars there to be decoded. Is this a known issue? I didn't find anything with a quick list scan. -jh-
cvs commit: jakarta-tomcat build.xml
costin 01/08/23 18:09:31
Modified:.build.xml
Log:
JNIEndpoint is a startup program. It should be moved to tomcat.startup, but
to avoid changes in the native code we can leave it where it is.
But it must be included in tomcat.jar, since the startup classpath must be 'clean',
having modules.jar in the parent class loader is trouble.
Revision ChangesPath
1.150 +4 -2 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.149
retrieving revision 1.150
diff -u -r1.149 -r1.150
--- build.xml 2001/08/22 03:01:54 1.149
+++ build.xml 2001/08/24 01:09:31 1.150
@@ -288,7 +288,7 @@
!-- Tomcat.jar ( starter ) --
- target name=tomcat.jar depends=init
+ target name=tomcat.jar depends=init,tomcat_modules
javac destdir=${tomcat.build}/classes
debug=${debug}
optimize=${optimize}
@@ -305,6 +305,8 @@
basedir=${tomcat.build}/classes
manifest=src/build/manifests/manifest
include name=org/apache/tomcat/startup/Main.class/
+ include name=org/apache/tomcat/modules/server/JNIEndpoint**/
+ include name=org/apache/tomcat/modules/server/StartupThread**/
include name=org/apache/tomcat/startup/Main$*.class/
include name=org/apache/tomcat/util/depend/**/
include name=org/apache/tomcat/util/compat/**/
@@ -527,7 +529,7 @@
/jar
/target
- target name=tomcat-jars
depends=prepare,tomcat_util,tomcat.jar,stop-tomcat.jar,tomcat_core,jasper,tomcat_modules,facade22,tomcat-startup
+ target name=tomcat-jars
depends=prepare,tomcat_util,stop-tomcat.jar,tomcat_core,jasper,tomcat_modules,tomcat.jar,facade22,tomcat-startup
/target
target name=tomcat-jars-new depends=tomcat-jars
cvs commit: jakarta-tomcat/src/etc/jk workers.properties
costin 01/08/23 18:10:38 Modified:src/etc/jk workers.properties Log: Remove tomcat-modules from the initial classpath. Leave the defaults as in the jni-workers.properties ( i.e. for windows ). Revision ChangesPath 1.5 +4 -5 jakarta-tomcat/src/etc/jk/workers.properties Index: workers.properties === RCS file: /home/cvs/jakarta-tomcat/src/etc/jk/workers.properties,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- workers.properties2001/08/23 14:57:33 1.4 +++ workers.properties2001/08/24 01:10:38 1.5 @@ -31,28 +31,28 @@ # # -# OPTIONS ( very important for jni mode ) +# OPTIONS ( very important for jni mode ) # # workers.tomcat_home should point to the location where you # installed tomcat. This is where you have your conf, webapps and lib # directories. # -# workers.tomcat_home=c:\tomcat +workers.tomcat_home=c:\tomcat # workers.tomcat_home=/usr/local/tomcat # # workers.java_home should point to your Java installation. Normally # you should have a bin and lib directories beneath it. # -# workers.java_home=c:\jdk1.3 +workers.java_home=c:\jdk1.3 # workers.java_home=/usr/java # # You should configure your environment slash... ps=\ on NT and / on UNIX # and maybe something different elsewhere. # -# ps=\ +ps=\ # ps=/ # @@ -152,7 +152,6 @@ # Additional class path components. # worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)tomcat.jar -worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)container$(ps)tomcat-modules.jar # # Setting the command line for tomcat.
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server JNIConnectionHandler.java JNIEndpoint.java
costin 01/08/23 18:15:18
Modified:src/share/org/apache/tomcat/modules/server
JNIConnectionHandler.java JNIEndpoint.java
Log:
- remove the dependency between JNIEndpoint and JNIConnectionHandler.
The reverse is ok ( JNIConnection handler depends on JNIEndpoint ), since
JNIEndpoint is in the main classloader.
- added an option to exit if the library can't be loaded. This is a serious
configuration problem, similar with apache not beeing able to find a module, the
behavior should be the same.
- fix the name of the .so/.dll/.nlm file ( had an extra s ). Fix File.separator,
use the constructed path.
- fix the 'multiple start' problem.
Revision ChangesPath
1.12 +19 -23
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIConnectionHandler.java
Index: JNIConnectionHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIConnectionHandler.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JNIConnectionHandler.java 2001/08/16 00:26:14 1.11
+++ JNIConnectionHandler.java 2001/08/24 01:15:18 1.12
@@ -1,8 +1,4 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIConnectionHandler.java,v
1.11 2001/08/16 00:26:14 costin Exp $
- * $Revision: 1.11 $
- * $Date: 2001/08/16 00:26:14 $
- *
*
*
* The Apache Software License, Version 1.1
@@ -83,25 +79,15 @@
*
* @author Gal Shachor [EMAIL PROTECTED]
*/
-public class JNIConnectionHandler extends BaseInterceptor {
+public class JNIConnectionHandler extends BaseInterceptor implements
JNIEndpoint.JniHandler {
public JNIConnectionHandler() {
}
-// JNIEndpoint was called to start tomcat
-// Hack used to set the handler in JNIEndpoint.
-// This works - if we have problems we may take the time
-// and implement a better mechanism
-static JNIEndpoint ep;
-
-public static void setEndpoint(JNIEndpoint jniep)
-{
-ep = jniep;
-}
-
// Config
boolean nativeLibLoaded=false;
String lib;
+boolean exitOnError=true;
/** Location of the jni library
*/
@@ -109,14 +95,24 @@
this.lib=lib;
}
+public void setExitIfNoLib(boolean b) {
+ exitOnError=b;
+}
+
+JNIEndpoint ep=null;
+
/** Called when the ContextManger is started
*/
public void engineInit(ContextManager cm) throws TomcatException {
- if( ep==null ) return;
+ ep= JNIEndpoint.getEndpoint();
+ if(ep==null ) return;
super.engineInit( cm );
if(! nativeLibLoaded ) {
initLibrary();
+ if( ! nativeLibLoaded exitOnError) {
+ System.exit(2);
+ }
}
try {
// notify the jni side that jni is set up corectly
@@ -201,7 +197,7 @@
}
if( lib==null ) {
- lib=jni_connector.;
+ lib=jni_connect.;
String os = System.getProperty(os.name).toLowerCase();
if(os.indexOf(windows)=0){
lib+=dll;
@@ -232,23 +228,23 @@
if( ! libF.isAbsolute() ) {
File f1=new File(cm.getInstallDir());
// XXX should it be libexec ???
- File f2=new File( f1, bin + File.pathSeparator + native );
+ File f2=new File( f1, bin + File.separator + native );
libF=new File( f2, lib );
}
if( ! libF.exists() ) {
throw new TomcatException( Native library doesn't exist + libF );
}
-
+
// Loading from the library path failed
// Try to load assuming lib is a complete pathname.
try {
- System.load(lib);
+ System.load(libF.getAbsolutePath());
nativeLibLoaded=true;
- System.out.println(Library + lib + loaded);
+ System.out.println(Library + libF.getAbsolutePath() + loaded);
return;
} catch(UnsatisfiedLinkError usl) {
-System.err.println(Failed to load() + lib);
+System.err.println(Failed to load() + libF.getAbsolutePath());
if( debug 0 )
usl.printStackTrace();
}
1.4 +38 -21
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java
Index: JNIEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/JNIEndpoint.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JNIEndpoint.java
Re: Tomcat 3.2.3 and getPathInfo
Marc Saegesser wrote: I just tried this using the SnoopServlet that ships with Tomcat using a URL like http://localhost:8080/servlet/SnoopServlet/http://fubar and got /http:/fubar as the path info. Your description makes it look like your losing http: in addition to the one of the /s. Is this what your seeing? Using SnoopServlet I see /http:/fubar just like you. My seeing the http: being eaten was due to how the GoTo servlet responded to the illegal URL being used. So that's good, it's only the double-slash to single-slash issue. It's a hard issue, but a straightforward issue. This problem is almost certainly caused the URL normalization code that got put into 3.2.3 to fix a serious security hole. This is going to be difficult to resolve. We have to normalize the URL before the servlet container uses it (I think this is even going to be added to the latest servlet specification) or some really bad things can happen with prefix mapping. However, until we've done the prefix mapping we can't know what part of the URL refers to a servlet and what part is path info. Getting back the original non-normalized path info is going to be tricky. I don't recall any EG discussion about normalizing the URL before the container sees it. Generally the spec makes contracts on the container as it interfaces with the servlet and doesn't make any statements about a web server might support a plug-in. This is even worse because we also won't allow the URL to be encoded like http://localhost:8080/servlet/SnoopServlet/http:%2F%2Ffubar because we make some rather draconian precautions to ensure that nastily encoded URLs can't obtain access to protected resources (or even resources outside the webapp). Hmm... I wonder if Tomcat has the right to make illegal what HTTP would allow? I'll have to give this one some thought. If URL normalization is being added to the specification then there should also some guidance on how it relates to path info. As I understand it, extra path info has to be returned in its simple decoded form. -jh-
Fwd: Correction to JDC Tech Tip for August 21, 2001
LOL! That poor cat. Although I'm surprised that the JDC crew didn't forward it
to Edwardo Company and/or us for review ... you know, before sending it out
to a couple hundred thousand developers, give or take.
I assume that:
Some versions of Tomcat delay the calling of getWriter(), so that the tip
might work for those versions.
... is marketing-speak for, Well, we tested it on Tomcat 3.1, and it worked
for us. =)
So, what I want to know is this: When all of the e-mails start flooding the
user list ... I tried out this one Tech Tip, but I got an error. Tomcat
bug!!! ... how are you Sun peeps (Craig, Costin, Pier, Amy, et. al.) going to
decide who gets to take the elevator up to the JDC floor and start busting
heads? You gonna draw straws or something?
;-)
- Forwarded message from JDC Tech Tips body_-
[EMAIL PROTECTED] -
Date: Thu, 23 Aug 2001 19:03:23 PDT
From: JDC Tech Tips [EMAIL PROTECTED]
Reply-To: JDC Tech Tips [EMAIL PROTECTED]
Subject: Correction to JDC Tech Tip for August 21, 2001
To: [EMAIL PROTECTED]
J D CT E C HT I P S
TIPS, TECHNIQUES, AND SAMPLE CODE
This is an update to the the Java Developer Connection(sm) (JDC)
Tech Tip for August 21, 2001 on Delivering Dynamic Images from
JavaServer Pages(tm) (JSP(tm)) Technology. You can view that
issue of the Tech Tips on the Web at
http://java.sun.com/jdc/JDCTechTips/2001/tt0821.html
That tip mistakenly generated binary content from a JSP page. The
Servlet specification requires that servlets not call both
ServletResponse.getOutputStream() and ServletResponse.getWriter().
Because JSP pages already call getWriter(), they must not also
call getOutputStream(). Some versions of Tomcat delay the calling
of getWriter(), so that the tip might work for those versions.
However the operations demonstrated in the tip should be
considered illegal. JSP pages are only meant to deliver textual
output.
In order for this tip to work properly, the dynamic image
generation must be moved into a servlet. Place the following
class definition in an appropriate servlet directory for your
web server (such as webapps\ROOT\WEB-INF\classes for Tomcat).
Then you should be able to call it with a URL of
http://localhost:8080/servlet/MakeImage. The core code is
identical to that used previously in the tip, except that it's
now part of a servlet.
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.awt.*;
import java.awt.image.*;
import com.sun.image.codec.jpeg.*;
import java.util.*;
public class MakeImage extends HttpServlet {
public void doGet(
HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType(image/jpeg);
// Create image
int width=200, height=200;
BufferedImage image = new BufferedImage(
width, height, BufferedImage.TYPE_INT_RGB);
// Get drawing context
Graphics g = image.getGraphics();
// Fill background
g.setColor(Color.white);
g.fillRect(0, 0, width, height);
// Create random polygon
Polygon poly = new Polygon();
Random random = new Random();
for (int i=0; i 20; i++) {
poly.addPoint(random.nextInt(width),
random.nextInt(height));
}
// Fill polygon
g.setColor(Color.cyan);
g.fillPolygon(poly);
// Dispose context
g.dispose();
// Send back image
ServletOutputStream sos =
response.getOutputStream();
JPEGImageEncoder encoder =
JPEGCodec.createJPEGEncoder(sos);
encoder.encode(image);
}
}
In addition, if you are a Unix user running a web server on a
headless box, you might need Xvfb, which is a virtual frame buffer
X server, to emulate a display environment. See
http://java.sun.com/products/java-media/2D/forDevelopers/java2dfaq.html#xvfb
for more information about server-side support for working with
images.
. . . . . . . . . . . . . . . . . . . . . . .
- NOTE
Sun respects your online time and privacy. The Java Developer
Connection mailing lists are used for internal Sun Microsystems(tm)
purposes only. You have received this email because you elected
to subscribe. To unsubscribe, go to the Subscriptions page
http://developer.java.sun.com/subscription/
uncheck the appropriate checkbox, and click the Update button.
- SUBSCRIBE
To subscribe to a JDC newsletter mailing list, go to the
Subscriptions page
http://developer.java.sun.com/subscription/
choose the newsletters you want to subscribe to, and click
Update.
- FEEDBACK
Comments? Send your feedback on the JDC Tech Tips to:
[EMAIL PROTECTED]
- ARCHIVES
You'll find the JDC Tech Tips archives at:
http://java.sun.com/jdc/TechTips/index.html
- COPYRIGHT
Copyright 2001 Sun Microsystems, Inc. All rights reserved.
901 San Antonio Road, Palo Alto, California 94303 USA.
This document is protected by copyright. For more
cvs commit: jakarta-tomcat/src/shell tomcat.bat
larryi 01/08/23 20:16:54 Modified:src/shell tomcat.bat Log: Add enableAdmin and estart commands with legacy enableAdmin. Added _MAIN environment variable to specify startup class like what is done in tomcat.sh. Some miscellaneous cleanup. Revision ChangesPath 1.38 +35 -8 jakarta-tomcat/src/shell/tomcat.bat Index: tomcat.bat === RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.bat,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- tomcat.bat2001/08/21 05:52:12 1.37 +++ tomcat.bat2001/08/24 03:16:53 1.38 @@ -29,7 +29,7 @@ rem Tomcat, refer to the Tomcat Users Guide (tomcat_ug.html found rem in the doc directory. rem -rem $Id: tomcat.bat,v 1.37 2001/08/21 05:52:12 costin Exp $ +rem $Id: tomcat.bat,v 1.38 2001/08/24 03:16:53 larryi Exp $ rem - @@ -47,6 +47,8 @@ set _NULL= set _CONTAINER=container :cont +rem main startup class +set _MAIN=org.apache.tomcat.startup.Main rem - Verify and Set Required Environment Variables - @@ -101,11 +103,17 @@ if %1 == run goto runServer if %1 == env goto doEnv if %1 == jspc goto runJspc +if %1 == enableAdmin goto enableAdmin +if %1 == estart goto estart :doUsage echo Usage: tomcat ( env ^| jspc ^| run ^| start ^| stop ) echo Commands: +echo enableAdmin - Trust the admin web application, +echo i.e. rewrites conf/apps-admin.xml with trusted=true echo env - Set up environment variables that Tomcat would use +echo estart - Start Tomcat using the/your EmbeddedTomcat class which +echouses a hardcoded set of modules echo jspc - Run JSPC in Tomcat's environment echo run - Start Tomcat in the current window echo start - Start Tomcat in a separate window @@ -115,33 +123,50 @@ :startServer echo Starting Tomcat in new window if %2 == -security goto startSecure -%_STARTJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main start %2 %3 %4 %5 %6 %7 %8 %9 +%_STARTJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% %_MAIN% start %2 %3 %4 %5 %6 %7 %8 %9 goto cleanup :startSecure echo Starting Tomcat with a SecurityManager -%_SECSTARTJAVA% %TOMCAT_OPTS% -Djava.security.policy==%TOMCAT_HOME%/conf/tomcat.policy -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main start -sandbox %3 %4 %5 %6 %7 %8 %9 +%_SECSTARTJAVA% %TOMCAT_OPTS% -Djava.security.policy==%TOMCAT_HOME%/conf/tomcat.policy -Dtomcat.home=%TOMCAT_HOME% %_MAIN% start -sandbox %3 %4 %5 %6 %7 %8 %9 goto cleanup :runServer +rem Backwards compatibility for enableAdmin +if %2 == enableAdmin goto oldEnbAdmin +if %2 == -enableAdmin goto oldEnbAdmin rem Running Tomcat in this window if %2 == -security goto runSecure -%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main start %2 %3 %4 %5 %6 %7 %8 %9 +%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% %_MAIN% start %2 %3 %4 %5 %6 %7 %8 %9 goto cleanup :runSecure rem Running Tomcat with a SecurityManager -%_RUNJAVA% %TOMCAT_OPTS% -Djava.security.policy==%TOMCAT_HOME%/conf/tomcat.policy -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main start -sandbox %3 %4 %5 %6 %7 %8 %9 +%_RUNJAVA% %TOMCAT_OPTS% -Djava.security.policy==%TOMCAT_HOME%/conf/tomcat.policy -Dtomcat.home=%TOMCAT_HOME% %_MAIN% start -sandbox %3 %4 %5 %6 %7 %8 %9 goto cleanup +:enableAdmin +rem Run enableAdmin +%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% %_MAIN% enableAdmin %2 %3 %4 %5 %6 %7 %8 %9 +goto cleanup + +:oldEnbAdmin +rem Run enableAdmin +%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% %_MAIN% enableAdmin %3 %4 %5 %6 %7 %8 %9 +goto cleanup + +:estart +%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% %_MAIN% estart %2 %3 %4 %5 %6 %7 %8 %9 +goto cleanup + :stopServer rem Stopping the Tomcat Server -%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main stop %2 %3 %4 %5 %6 %7 %8 %9 +%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% %_MAIN% stop %2 %3 %4 %5 %6 %7 %8 %9 goto cleanup :runJspc rem Run JSPC in Tomcat's Environment -%_RUNJAVA% %JSPC_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main jspc %2 %3 %4 %5 %6 %7 %8 %9 +%_RUNJAVA% %JSPC_OPTS% -Dtomcat.home=%TOMCAT_HOME% %_MAIN% jspc %2 %3 %4 %5 %6 %7 %8 %9 goto cleanup rem - Set CLASSPATH to Tomcat's Runtime Environment --- @@ -198,11 +223,13 @@ rem - Restore Environment Variables --- :cleanup -set TEST_JAR= set _LIBJARS= set _SECSTARTJAVA= set _STARTJAVA= set _RUNJAVA=
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade ServletInputStreamFacade.java
costin 01/08/23 21:38:50
Modified:src/share/org/apache/tomcat/modules/server
Ajp13Interceptor.java
src/facade22/org/apache/tomcat/facade
ServletInputStreamFacade.java
Log:
Part of the changes to support chunked input stream. Keith - sorry I didn't wait
for your patch, but I wanted to test it - and I'm going to run watchdogs and
tests anyway, better to have those in too.
Revision ChangesPath
1.11 +9 -3
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java
Index: Ajp13Interceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Ajp13Interceptor.java 2001/08/12 03:57:52 1.10
+++ Ajp13Interceptor.java 2001/08/24 04:38:50 1.11
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
1.10 2001/08/12 03:57:52 costin Exp $
- * $Revision: 1.10 $
- * $Date: 2001/08/12 03:57:52 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
1.11 2001/08/24 04:38:50 costin Exp $
+ * $Revision: 1.11 $
+ * $Date: 2001/08/24 04:38:50 $
*
*
*
@@ -220,6 +220,9 @@
public int doRead() throws IOException
{
+ if( contentLength == -1 ) {
+ return ajp13.doRead();
+ }
if( available = 0 )
return -1;
available--;
@@ -228,6 +231,9 @@
public int doRead(byte[] b, int off, int len) throws IOException
{
+ if( contentLength == -1 ) {
+ return ajp13.doRead(b,off,len);
+ }
if( available = 0 )
return -1;
int rd=ajp13.doRead( b,off, len );
1.5 +46 -31
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletInputStreamFacade.java
Index: ServletInputStreamFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletInputStreamFacade.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ServletInputStreamFacade.java 2001/08/23 11:22:25 1.4
+++ ServletInputStreamFacade.java 2001/08/24 04:38:50 1.5
@@ -100,34 +100,35 @@
limit=-1;
}
-/** Read a byte. Detect if a ByteBuffer is used, if not
- * use the old method.
- */
-private int doRead() throws IOException {
- //System.out.println(DoRead);
- return reqA.doRead();
-}
-
-private int doRead(byte[] b, int off, int len) throws IOException {
- return reqA.doRead(b,off,len);
-}
-
// ServletInputStream methods
public int read() throws IOException {
- // System.out.println(Read + limit );
- if (limit != -1) {
- if (bytesRead limit) {
- bytesRead++;
- return doRead();
+ if( dL0) debug(read() + limit + + bytesRead );
+ if (limit == -1) {
+ // Ask the adapter for more data. We are in the 'no content-length'
+ // case - i.e. chunked encoding ( acording to http spec CL is required
+ // for everything else.
+ int rd=reqA.doRead();
+ if( rd0 ) {
+ limit=0; // no more bytes can be read.
} else {
- return -1;
+ bytesRead++; // for statistics
}
- } else {
+ return rd;
+ }
+
+ // We have a limit
+ if (bytesRead = limit)
return -1;
- // no content-length, no body
- // return doRead();
+
+ bytesRead++;
+ int rd=reqA.doRead();
+ if( rd0 ) {
+ limit=0; // adapter detected EOF, before C-L finished.
+ // trust the adapter - if it returns EOF it's unlikely it'll give us
+ // any more data
}
+ return rd;
}
public int read(byte[] b) throws IOException {
@@ -135,26 +136,40 @@
}
public int read(byte[] b, int off, int len) throws IOException {
- if (limit != -1) {
- if (bytesRead == limit) {
- return -1;
- }
- if (bytesRead + len limit) {
- len = limit - bytesRead;
- }
- int numRead = doRead(b, off, len);
+ if( dL0) debug(read( + len + ) + limit + + bytesRead );
+ if (limit == -1) {
+ int numRead = reqA.doRead(b, off, len);
if (numRead 0) {
bytesRead += numRead;
}
+ if( numRead 0 ) {
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa RealmBase.java
larryi 01/08/23 20:25:18
Modified:src/share/org/apache/tomcat/modules/aaa RealmBase.java
Log:
Patch for Javadoc.
Submitted by: Christopher Cain
Added some additional Javadoc rewording.
Revision ChangesPath
1.2 +14 -13
jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/RealmBase.java
Index: RealmBase.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/RealmBase.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RealmBase.java2001/07/14 03:20:37 1.1
+++ RealmBase.java2001/08/24 03:25:18 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/RealmBase.java,v 1.1
2001/07/14 03:20:37 nacho Exp $
- * $Revision: 1.1 $
- * $Date: 2001/07/14 03:20:37 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/RealmBase.java,v 1.2
2001/08/24 03:25:18 larryi Exp $
+ * $Revision: 1.2 $
+ * $Date: 2001/08/24 03:25:18 $
*
* The Apache Software License, Version 1.1
*
@@ -97,25 +97,25 @@
protected static StringManager sm =
StringManager.getManager(org.apache.tomcat.resources);
/**
- * Digest algorithm used in passwords thit is same values accepted by
MessageDigest for algorithm
- * plus No ( no encode ) that is the default
+ * Digest algorithm used in passwords. Should be a value accepted by
MessageDigest for algorithm
+ * or No ( no encode ). No is the default.
*/
protected String digest = No;
/**
- * Gets the digest algorithm used for credentials in the database
- * could be the same that MessageDigest accepts vor algorithm and No that
- * is the Default
- * @return
+ * Gets the digest algorithm used for credentials in the database.
+ * Should be a value that MessageDigest accepts for algorithm or No.
+ * No is the Default.
+ * @return the digest algorithm being used, or No if no encoding
*/
public String getDigest() {
return digest;
}
/**
- * Sets the digest algorithm used for credentials in the database
- * could be the same that MessageDigest accepts vor algorithm and No
- * that is the Default
+ * Sets the digest algorithm used for credentials in the database.
+ * Should be a value that MessageDigest accepts for algorithm or No.
+ * No is the Default.
* @param algorithm the Encode type
*/
public void setDigest(String algorithm) {
@@ -127,7 +127,7 @@
* convert the result to a corresponding hex string.
* If exception, the plain credentials string is returned
* @param credentials Password or other credentials to use in authenticating
this username
- * @param algorithm Algorithm used to do th digest
+ * @param algorithm Algorithm used to do the digest
*/
public static final String digest(String credentials,String algorithm ) {
try {
@@ -205,6 +205,7 @@
}
return DECLINED;
}
+
private boolean checkPassword(String username,String credentials) {
// Create the authentication search prepared statement if necessary
// Perform the authentication search
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 Makefile.in
costin 01/08/23 22:19:22
Modified:jk/native/apache-2.0 Makefile.in
Log:
Fix the include, the .in file is used only to generate.
Revision ChangesPath
1.7 +1 -1 jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Makefile.in 2001/07/06 16:39:17 1.6
+++ Makefile.in 2001/08/24 05:19:22 1.7
@@ -15,7 +15,7 @@
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
-include ../common/list.mk.in
+include ../common/list.mk
include ../scripts/build/rules.mk
OEXT=@APACHE20_OEXT@
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
costin 01/08/23 19:24:19
Modified:src/share/org/apache/tomcat/modules/config AutoWebApp.java
src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
src/share/org/apache/tomcat/modules/session
SimpleSessionStore.java
Log:
Small changes I had in my workspace, use the factory-apis to create request, etc.
Revision ChangesPath
1.9 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java
Index: AutoWebApp.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- AutoWebApp.java 2001/08/12 02:09:42 1.8
+++ AutoWebApp.java 2001/08/24 02:24:18 1.9
@@ -256,7 +256,7 @@
( .equals(path) ? / : path ) );
if (dir.isDirectory()) {
- Context ctx=new Context();
+ Context ctx=cm.createContext();
ctx.setContextManager( cm );
ctx.setPath(prefix + path);
if( ! DEFAULT.equals( host ) )
1.16 +2 -2
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java
Index: ErrorHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ErrorHandler.java 2001/07/11 05:19:50 1.15
+++ ErrorHandler.java 2001/08/24 02:24:19 1.16
@@ -371,8 +371,8 @@
if( ! path.startsWith( / ) ) {
return ctx.getServletByName( path );
}
- Request req1=new Request();
- Response res1=new Response();
+ Request req1=cm.createRequest();
+ Response res1=cm.createResponse(req1);
cm.initRequest( req1, res1 );
req1.requestURI().setString( ctx.getPath() + path );
1.17 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java
Index: SimpleSessionStore.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- SimpleSessionStore.java 2001/08/12 02:16:20 1.16
+++ SimpleSessionStore.java 2001/08/24 02:24:19 1.17
@@ -344,7 +344,7 @@
// Recycle or create a Session instance
ServerSession session = (ServerSession)recycled.get();
if (session == null) {
- session = new ServerSession();
+ session = ctx.getContextManager().createServerSession();
session.setManager( this );
}
session.setContext( ctx );
