Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
markt   2005/05/11 14:39:41
  Modified:catalina/src/share/org/apache/catalina/authenticator
FormAuthenticator.java SavedRequest.java
   webapps/docs changelog.xml
  Log:
  Include request body in saved request when using FORM authentication.
   - Fixes problem with saved request assuming platform default encoding for 
POSTed
parameters.
   - Improves restoration of request by using CoyoteRequest
This is way too risky to do it for any POST (which could be a file 
upload), and I think it could lead to easy DoSes, so I share Bill's 
concerns.

Saving parameters in general is risky as well, obviously ...
IMO, webapps need to be better designed, and auth should happen before 
sending forms.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Kristiina Markkula
Olen työmatkalla ja takaisin toimistolla 16.5.2005.

Back at the office May 16th.

Kristiina Markkula
GSM +358 50 560132


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

2005-05-12 Thread Bill Barker
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 147 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-12052005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-12052005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-12052005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-12052005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-12052005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 3112052005, brutus:brutus-public:3112052005
Gump E-mail Identifier (unique within run) #18.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

2005-05-12 Thread Bill Barker
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 147 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-12052005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-12052005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-12052005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-12052005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-12052005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 3112052005, brutus:brutus-public:3112052005
Gump E-mail Identifier (unique within run) #18.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[EMAIL PROTECTED]: Project jakarta-tomcat-catalina (in module jakarta-tomcat-catalina) failed

2005-05-12 Thread bobh
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-catalina has an issue affecting its community 
integration.
This issue affects 2 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-catalina :  Servlet 2.4 Reference Implementation
- jakarta-tomcat-jk :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property ant.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.home.
 -DEBUG- Dependency on jaf exists, no need to add for property activation.home.
 -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for 
property tomcat-coyote.home.
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/gump_work/build_jakarta-tomcat-catalina_jakarta-tomcat-catalina.html
Work Name: build_jakarta-tomcat-catalina_jakarta-tomcat-catalina (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dtomcat33.home=--UnSet-- 
-Dcatalina.build=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Djmx.home=/usr/local/gump/packages/jmx-1_2-ri 
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar 
-Djtc.home=/usr/local/gump/public/workspace/jakarta-tomcat-connectors 
-Djasper.home=/usr/local/gump/public/workspace/jakarta-tomcat-jasper_tc5/jasper2
 -Dant.home=/usr/local/gump/public/workspace/ant/dist -Dcompile.source=1.4 
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-12052005.jar
 
-Dcatalina.deploy=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build
 -Djaas.jar=/usr/local/gump/packages/jaas1_0/lib/jaas.jar 
-Dcommons-fileupload.jar=/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-12052005.jar
 
-Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar
 -Dactivation.home=/usr/local/gump/packages/jaf-1.0.1 
-Dcatalina.home=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Dcommons-launcher.jar=/usr/local/gump/public/workspace/jakarta-commons/launcher/dist/bin/commons-launcher.jar
 -Dtomcat.build=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar
 
-Dcommons-modeler.jar=/usr/local/gump/public/workspace/jakarta-commons/modeler/dist/commons-modeler-12052005.jar
 
-Dtomcat-coyote.home=/usr/local/gump/public/workspace/jakarta-tomcat-connectors/coyote
 
-Dcommons-logging-api.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar
 
-Dtomcat-dbcp.jar=/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/naming-factory-dbcp.jar
 -Djta.jar=/usr/local/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar 
deploy-catalina 
[Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-catalina]
CLASSPATH: 

[EMAIL PROTECTED]: Project jakarta-tomcat-catalina (in module jakarta-tomcat-catalina) failed

2005-05-12 Thread bobh
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-catalina has an issue affecting its community 
integration.
This issue affects 2 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-catalina :  Servlet 2.4 Reference Implementation
- jakarta-tomcat-jk :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property ant.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.home.
 -DEBUG- Dependency on jaf exists, no need to add for property activation.home.
 -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for 
property tomcat-coyote.home.
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/gump_work/build_jakarta-tomcat-catalina_jakarta-tomcat-catalina.html
Work Name: build_jakarta-tomcat-catalina_jakarta-tomcat-catalina (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dtomcat33.home=--UnSet-- 
-Dcatalina.build=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Djmx.home=/usr/local/gump/packages/jmx-1_2-ri 
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar 
-Djtc.home=/usr/local/gump/public/workspace/jakarta-tomcat-connectors 
-Djasper.home=/usr/local/gump/public/workspace/jakarta-tomcat-jasper_tc5/jasper2
 -Dant.home=/usr/local/gump/public/workspace/ant/dist -Dcompile.source=1.4 
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-12052005.jar
 
-Dcatalina.deploy=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build
 -Djaas.jar=/usr/local/gump/packages/jaas1_0/lib/jaas.jar 
-Dcommons-fileupload.jar=/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-12052005.jar
 
-Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar
 -Dactivation.home=/usr/local/gump/packages/jaf-1.0.1 
-Dcatalina.home=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Dcommons-launcher.jar=/usr/local/gump/public/workspace/jakarta-commons/launcher/dist/bin/commons-launcher.jar
 -Dtomcat.build=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar
 
-Dcommons-modeler.jar=/usr/local/gump/public/workspace/jakarta-commons/modeler/dist/commons-modeler-12052005.jar
 
-Dtomcat-coyote.home=/usr/local/gump/public/workspace/jakarta-tomcat-connectors/coyote
 
-Dcommons-logging-api.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar
 
-Dtomcat-dbcp.jar=/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/naming-factory-dbcp.jar
 -Djta.jar=/usr/local/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar 
deploy-catalina 
[Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-catalina]
CLASSPATH: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup HostConfig.java LocalStrings.properties SetContextPropertiesRule.java

2005-05-12 Thread remm
remm2005/05/12 02:29:54

  Modified:catalina/src/share/org/apache/catalina/startup
HostConfig.java LocalStrings.properties
SetContextPropertiesRule.java
  Log:
  - 34840: Found a way to tweak behavior when using an external WAR.
  - Ignore docBase if the context is inside the host appBase, as it is 
duplicated by the context file name. Not doing so creates a mess in some cases.
  
  Revision  ChangesPath
  1.60  +20 -7 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java
  
  Index: HostConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java,v
  retrieving revision 1.59
  retrieving revision 1.60
  diff -u -r1.59 -r1.60
  --- HostConfig.java   14 Mar 2005 11:52:04 -  1.59
  +++ HostConfig.java   12 May 2005 09:29:54 -  1.60
  @@ -53,7 +53,6 @@
* @author Remy Maucherat
* @version $Revision$ $Date$
*/
  -
   public class HostConfig
   implements LifecycleListener {
   
  @@ -575,15 +574,27 @@
   context.setPath(contextPath);
   // Add the associated docBase to the redeployed list if it's a 
WAR
   boolean isWar = false;
  +boolean isExternal = false;
   if (context.getDocBase() != null) {
   File docBase = new File(context.getDocBase());
   if (!docBase.isAbsolute()) {
   docBase = new File(appBase(), context.getDocBase());
   }
  -deployedApp.redeployResources.put(docBase.getAbsolutePath(),
  +// If external docBase, register .xml as redeploy first
  +if 
(!docBase.getAbsolutePath().startsWith(appBase().getAbsolutePath())) {
  +isExternal = true;
  +deployedApp.redeployResources.put
  +(contextXml.getAbsolutePath(), new 
Long(contextXml.lastModified()));
  +
deployedApp.redeployResources.put(docBase.getAbsolutePath(),
   new Long(docBase.lastModified()));
  -if 
(docBase.getAbsolutePath().toLowerCase().endsWith(.war)) {
  -isWar = true;
  +if 
(docBase.getAbsolutePath().toLowerCase().endsWith(.war)) {
  +isWar = true;
  +}
  +} else {
  +
log.warn(sm.getString(hostConfig.deployDescriptor.localDocBaseSpecified,
  + docBase));
  +// Ignore specified docBase
  +context.setDocBase(null);
   }
   }
   host.addChild(context);
  @@ -628,8 +639,10 @@
   addWatchedResources(deployedApp, null, context);
   }
   // Add the context XML to the list of files which should 
trigger a redeployment
  -deployedApp.redeployResources.put
  -(contextXml.getAbsolutePath(), new 
Long(contextXml.lastModified()));
  +if (!isExternal) {
  +deployedApp.redeployResources.put
  +(contextXml.getAbsolutePath(), new 
Long(contextXml.lastModified()));
  +}
   }
   } catch (Throwable t) {
   log.error(sm.getString(hostConfig.deployDescriptor.error,
  
  
  
  1.15  +1 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/LocalStrings.properties,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- LocalStrings.properties   15 Feb 2005 15:42:58 -  1.14
  +++ LocalStrings.properties   12 May 2005 09:29:54 -  1.15
  @@ -47,6 +47,7 @@
   hostConfig.deploy=Deploying web application directory {0}
   hostConfig.deployDescriptor=Deploying configuration descriptor {0}
   hostConfig.deployDescriptor.error=Error deploying configuration descriptor 
{0}
  +hostConfig.deployDescriptor.localDocBaseSpecified=A docBase {0} inside the 
host appBase has been specified, and will be ignored
   hostConfig.deployDir=Deploying web application directory {0}
   hostConfig.deployDir.error=Error deploying web application directory {0}
   hostConfig.deployJar=Deploying web application archive {0}
  
  
  
  1.2   +1 -1  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/SetContextPropertiesRule.java
  
  Index: SetContextPropertiesRule.java
  ===
  RCS file: 

Question about ByteChunk.substract implementation

2005-05-12 Thread Arvind Srinivasan
Why does the implementation of the substract() methods of
org.apache.tomcat.util.buf.ByteChunk.java
(http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java?rev=1.24view=markup)
assume that in.realReadBytes will manipulate the start and end pointers
of ByteChunk?
org.apache.coyote.http11.InternalInputBuffer.doRead [which gets invoked
along the realReadBytes codepath] calls ByteChunk.setBytes (which
initializes start, end etc) so the scenario below doesn't occur with the
coyote connector. Just wondering if this is a contract that other
buffering connector implementations must adhere to.
In the code below, when buff needs to be refilled (e.g. start = end =
buff.length = 8192), and if realReadBytes doesn't reset start to 0, then
buff[start++] results in an IndexOutOfBoundsException. The other
substract() variants have a similar issue.
   public int substract()
throws IOException {
if ((end - start) == 0) {
if (in == null)
return -1;
int n = in.realReadBytes( buff, 0, buff.length );
if (n  0)
return -1;
}
return (buff[start++]  0xFF);
}
I expected to see start, off and end rest in the substract() method itself.
   public int substract()
throws IOException {
if ((end - start) == 0) {
if (in == null)
return -1;
int n = in.realReadBytes( buff, 0, buff.length );
start = off = 0;
   end = n;
}
return (buff[start++]  0xFF);
}

Thanks,
 Arvind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 34840] - updating war - tomcat removes mycontext.xml

2005-05-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34840.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34840


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 11:45 ---
Martin: your problem is not really related, please don't reopen the report.

Gernot: I think I have found a way to tweak the order of the resources so that
the behavior is better. I found it is possible as Tomcat will never remove any
resources which are not inside the Host appBase, so in this case it works well
to put the context file first (so it is never removed when a less relevant
resource - such as the WAR - is updated). Hopefully, I didn't get it wrong.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 34693] - Tomcat infinite wait on noised network

2005-05-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34693.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34693


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 12:27 ---
If you cannot point out any defect inside Tomcat, then we'll have to assume this
is caused by a bad configuration of your network stack.
- INVALID

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Tim Funk
Would it be worthwhile to use a new property?
maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to 
disable saving post.

Of course this doesn't mitigate a malicious person issuing many POSTS under 
the configured threshold.

-Tim
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
markt   2005/05/11 14:39:41
  Modified:catalina/src/share/org/apache/catalina/authenticator
FormAuthenticator.java SavedRequest.java
   webapps/docs changelog.xml
  Log:
  Include request body in saved request when using FORM authentication.
   - Fixes problem with saved request assuming platform default 
encoding for POSTed
parameters.
   - Improves restoration of request by using CoyoteRequest

This is way too risky to do it for any POST (which could be a file 
upload), and I think it could lead to easy DoSes, so I share Bill's 
concerns.

Saving parameters in general is risky as well, obviously ...
IMO, webapps need to be better designed, and auth should happen before 
sending forms.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 34873] - Tomcat server doesnt startup due to whitespace in installation directory

2005-05-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34873.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34873





--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 14:01 ---
This works for me. Please give (a lot) more details, or post to tomcat-user.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Remy Maucherat
Tim Funk wrote:
Would it be worthwhile to use a new property?
maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to 
disable saving post.

Of course this doesn't mitigate a malicious person issuing many POSTS 
under the configured threshold.
I think I disagree. Even if you are not trying to do a DoS, it is very 
easy to do it non intentionally if you save any post data (file upload).

We'd need to restrict saved POST size severely, as well as restrict more 
by default any form POST data.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread remm
remm2005/05/12 06:01:05

  Modified:jasper2/src/share/org/apache/jasper/servlet
JspCServletContext.java
   webapps/docs changelog.xml
  Log:
  - 34465: jspc without web.xml.
  - Submitted by Yoichi Hirose.
  
  Revision  ChangesPath
  1.4   +7 -1  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java
  
  Index: JspCServletContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JspCServletContext.java   17 Mar 2004 19:23:05 -  1.3
  +++ JspCServletContext.java   12 May 2005 13:01:04 -  1.4
  @@ -235,7 +235,13 @@
   if (!path.startsWith(/))
   throw new MalformedURLException(Path ' + path +
   ' does not start with '/');
  -return (new URL(myResourceBaseURL, path.substring(1)));
  +URL url = new URL(myResourceBaseURL, path.substring(1));
  +if (file.equals(url.getProtocol())) {
  +if (!(new File(url.getFile())).exists()) {
  +return null;
  +}
  +}
  +return url;
   
   }
   
  
  
  
  1.308 +7 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.307
  retrieving revision 1.308
  diff -u -r1.307 -r1.308
  --- changelog.xml 11 May 2005 21:39:41 -  1.307
  +++ changelog.xml 12 May 2005 13:01:04 -  1.308
  @@ -153,6 +153,10 @@
   default encoding. A side effect of this fix is that the bodies of 
POST requests that
   require FORM authentication are now buffered and made available 
after a sucessful login. (markt)
 /fix
  +  fix
  +bug34840/bug: Better handling of external WARs redeployment, and 
ignore docBase specified
  +in context file if within the Host appBase (remm)
  +  /fix
   /changelog
 /subsection
 
  @@ -199,6 +203,9 @@
   bug34652/bug: Add the ability to get SMAPs when precompiling, 
submitted by
   Daryl Robbins (remm)
 /update
  +  fix
  +bug34465/bug: Jspc failure if there is no web.xml, submitted by 
Yoichi Hirose (remm)
  +  /fix
   /changelog
 /subsection
 
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 34892] New: - CATALINA_BASE should have common/lib/ and server/lib/

2005-05-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34892.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34892

   Summary: CATALINA_BASE should have common/lib/ and server/lib/
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I am using a shared TomCat 5.5 installation, so my CATALINA_HOME and
CATALINA_BASE are different. However, the standard TomCat installation is not
really usable in this way, because only shared folder is relative to
CATALINA_BASE, but folders common and server are relative to CATALINA_HOME. 

That makes impossible to use JDBC drivers, which must be placed in common/lib/,
and user realm implementations, which must be placed in server/lib, specific to
each TomCat instance.

It took me a long time to find out that this can be changed by editing
$CATALINA_BASE/conf/catalina.properties and changing for example line
common.loader=${catalina.home}/common/classes,${catalina.home}/common/i18n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/lib/*.jar,${catalina.base}/common/lib/*.jar
by adding 
${catalina.base}/common/lib/*.jar,${catalina.base}/common/classes,
to that line before the other directories.

So here is the diff:
32c32

common.loader=${catalina.base}/common/lib/*.jar,${catalina.base}/common/classes,${catalina.home}/common/classes,${catalina.home}/common/i18n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/lib/*.jar
---

common.loader=${catalina.home}/common/classes,${catalina.home}/common/i18n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/lib/*.jar
45c45

server.loader=${catalina.base}/server/classes,${catalina.base}/server/lib/*.jar,${catalina.home}/server/classes,${catalina.home}/server/lib/*.jar
---
 server.loader=${catalina.home}/server/classes,${catalina.home}/server/lib/*.jar

That makes the CATALINA_BASE really usable. When the change is made, the
RUNNING.txt should mention it.

Martin

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 34892] - CATALINA_BASE should have common/lib/ and server/lib/

2005-05-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34892.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34892


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 15:30 ---
I disagree.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 34892] - CATALINA_BASE should have common/lib/ and server/lib/

2005-05-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34892.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34892





--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 15:36 ---
(In reply to comment #1)
 I disagree.

Why ? Why shared.loader knows about CATALINA_BASE and common.loader and
server.loader ignores it ? That doesn't make sense.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 34895] New: - IE: Action canceled if servlet returns pdf and authentification is activated

2005-05-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34895.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34895

   Summary: IE: Action canceled if servlet returns pdf and
authentification is activated
   Product: Tomcat 5
   Version: 5.5.9
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have a Servlet (e.g. fop example servlet) that generate and return a pdf 
document. Content-Type for response is set to application/pdf.
URL: http://myserver/fop/fop?xml=test.xmlxsl=test.xslext=.pdf

IE opens acrobat and shows pdf well if authentification is disabled.
If authentification is enabled IE 6.0 does not display the document. It asks to 
save the content and shows then an error message or displays Action canceled.

This is the authentification part in web.xml:
  security-constraint
web-resource-collection
  web-resource-nameAll/web-resource-name
  url-pattern//url-pattern
/web-resource-collection
auth-constraint
  role-name*/role-name
/auth-constraint
user-data-constraint
 transport-guaranteeNONE/transport-guarantee
/user-data-constraint
  /security-constraint

  login-config
auth-methodBASIC/auth-method
realm-nameGenerate PDF/realm-name
  /login-config

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Bill Barker
- Original Message - 
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 12, 2005 6:01 AM
Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml


remm2005/05/12 06:01:05
 Modified:jasper2/src/share/org/apache/jasper/servlet
   JspCServletContext.java
  webapps/docs changelog.xml
 Log:
 - 34465: jspc without web.xml.
 - Submitted by Yoichi Hirose.
 -return (new URL(myResourceBaseURL, path.substring(1)));
 +URL url = new URL(myResourceBaseURL, path.substring(1));
 +if (file.equals(url.getProtocol())) {
 +if (!(new File(url.getFile())).exists()) {
 +return null;
 +}
 +}
A huge -1 to this.  I can't believe that a Windows user would even think 
commit junk like this. ;-) 


This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Bill Barker
- Original Message - 
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Thursday, May 12, 2005 5:28 AM
Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml


Tim Funk wrote:
Would it be worthwhile to use a new property?
maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to 
disable saving post.

Of course this doesn't mitigate a malicious person issuing many POSTS 
under the configured threshold.
I think I disagree. Even if you are not trying to do a DoS, it is very easy 
to do it non intentionally if you save any post data (file upload).

We'd need to restrict saved POST size severely, as well as restrict more by 
default any form POST data.

I agree.  I'd even be +1 to further restricting the saved body size for 
CLIENT-CERT auth, and that one is only saved for the time of one request. 
Since the body in a FORM auth is going to be saved for much longer, it's 
even more important to restrict it.

And this is even more important for mod_jk users, since they will never get 
a chance to recover the data that they have posted :(.


Rémy

This message is intended only for the use of the person(s) listed above as 
the intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0

2005-05-12 Thread William A. Rowe, Jr.
Apparently there was something peculiar with the line endings in
the previous generation of these files.

Here is the patch below, compressed with --ignore-space:

Index: mod_jk.dsp
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -b -r1.10 -r1.11
--- mod_jk.dsp  15 Feb 2005 12:02:27 -  1.10
+++ mod_jk.dsp  11 May 2005 23:38:30 -  1.11
@@ -42,8 +42,8 @@
 # PROP Intermediate_Dir Release

 # PROP Ignore_Export_Lib 0

 # PROP Target_Dir 

-# ADD BASE CPP /nologo /MD /W3 /Zi /O2 /D WIN32 /D NDEBUG /D _WINDOWS /D 
_MBCS /D _USRDLL /D MOD_JK_EXPORTS /FD /c

-# ADD CPP /nologo /MD /W3 /Zi /O2 /I ..\common /I $(APACHE1_HOME)\include 
/I $(APACHE1_HOME)\src\include /I $(APACHE1_HOME)\src\os\win32 /I 
$(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D WIN32 /D NDEBUG 
/D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS 
/FdRelease\mod_jk_src /FD /c

+# ADD BASE CPP /nologo /MD /W3 /O2 /Oy- /Zi /D WIN32 /D NDEBUG /D 
_WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FD /c
+# ADD CPP /nologo /MD /W3 /O2 /Oy- /Zi /I ..\common /I 
$(APACHE1_HOME)\include /I $(APACHE1_HOME)\src\include /I 
$(APACHE1_HOME)\src\os\win32 /I $(JAVA_HOME)\include /I 
$(JAVA_HOME)\include\win32 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D 
_USRDLL /D MOD_JK_EXPORTS /FdRelease\mod_jk_src /FD /c
 # ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /win32

 # ADD MTL /nologo /D NDEBUG /mktyplib203 /win32

 # ADD BASE RSC /l 0x409 /d NDEBUG

Index: mod_jk.dsp
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.dsp,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -b -r1.12 -r1.13
--- mod_jk.dsp  15 Feb 2005 12:02:28 -  1.12
+++ mod_jk.dsp  11 May 2005 23:38:30 -  1.13
@@ -42,8 +42,8 @@
 # PROP Intermediate_Dir Release

 # PROP Ignore_Export_Lib 0

 # PROP Target_Dir 

-# ADD BASE CPP /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS /FD /c

-# ADD CPP /nologo /MD /W3 /Zi /O2 /I ..\common /I $(JAVA_HOME)\include /I 
$(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I 
$(APACHE2_HOME)\srclib\apr\include /I 
$(APACHE2_HOME)\srclib\apr-util\include /D NDEBUG /D WIN32 /D _WINDOWS 
/D HAVE_APR /FdRelease/mod_jk_src /FD /c

+# ADD BASE CPP /nologo /MD /W3 /O2 /Oy- /Zi /D WIN32 /D NDEBUG /D 
_WINDOWS /FD /c
+# ADD CPP /nologo /MD /W3 /O2 /Oy- /Zi /I ..\common /I 
$(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I 
$(APACHE2_HOME)\include /I $(APACHE2_HOME)\srclib\apr\include /I 
$(APACHE2_HOME)\srclib\apr-util\include /D NDEBUG /D WIN32 /D _WINDOWS 
/D HAVE_APR /FdRelease/mod_jk_src /FD /c
 # ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /win32

 # ADD MTL /nologo /D NDEBUG /mktyplib203 /win32

 # ADD BASE RSC /l 0x409 /d NDEBUG


and here is the commit log that bounced - in all it's ugly glory:

wrowe   2005/05/11 16:38:30

  Modified:jk/native/apache-1.3 mod_jk.dsp
   jk/native/apache-2.0 mod_jk.dsp
  Log:
Add the /Oy- following /O2, to disable this optimization.  It specifically
re-enables stack frame mechanics to help analize user.dmp files or perform
JIT debugging of a crash(ing) Apache instance.  Same patch in the works
for httpd itself, making mod_jk and httpd crashes somewhat more traceable.
  
Did not add /Gs0 per brane's comments, leaving the stack frame probes
configured as /Gs (implied by /O2).
  
  Reviewed by:  stoddard, brane
  
  Revision  ChangesPath
  1.11  +287 -287  
 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp
  
  Index: mod_jk.dsp
  ===
  RCS file: 
 /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- mod_jk.dsp15 Feb 2005 12:02:27 -  1.10
  +++ mod_jk.dsp11 May 2005 23:38:30 -  1.11
  @@ -1,287 +1,287 @@
  -# Microsoft Developer Studio Project File - Name=mod_jk - Package 
 Owner=4
  -# Microsoft Developer Studio Generated Build File, Format Version 6.00
  -# ** DO NOT EDIT **
  -
  -# TARGTYPE Win32 (x86) Dynamic-Link Library 0x0102
  -
  -CFG=mod_jk - Win32 Debug
  -!MESSAGE This is not a valid makefile. To build this project using NMAKE,
  -!MESSAGE use the Export Makefile command and run
  -!MESSAGE 
  -!MESSAGE NMAKE /f mod_jk.mak.
  -!MESSAGE 
  -!MESSAGE You can specify a configuration when running NMAKE
  -!MESSAGE by defining the macro CFG on the command line. For example:
  -!MESSAGE 
  -!MESSAGE NMAKE /f mod_jk.mak CFG=mod_jk - Win32 Debug
  -!MESSAGE 
  -!MESSAGE Possible choices for configuration are:
  -!MESSAGE 
  -!MESSAGE mod_jk - Win32 Release (based on Win32 (x86) Dynamic-Link 
 Library)
  -!MESSAGE mod_jk - Win32 Debug (based on Win32 (x86) Dynamic-Link 
 

Web standards in Tomcat webapps

2005-05-12 Thread Beton, Richard
Hi all,

I'm new to this list - forgive me for bargeing in (if I am).

I'd like to see the webapps distributed with Tomcat upgraded to use web 
standards. I couldn't find any mention of this in bugzilla.

* Is this a Good Thing?  (...I think it is)

* Is anyone already doing it?

* I've attached a first stab at one of the jsp pages: the ROOT/index.jsp 
page.  It uses basic CSS but I don't think I used any CSS2 features that 
might be less backward-compatible.

* I may have spare lunchtimes etc when I might slowly work my way 
through other pages ... if there is enough interest in getting this done.

Rick




cvs -z3 -q diff -u index.jsp (in directory 
C:\rdb\sw\apache\jakarta-tomcat-catalina\webapps\ROOT)
Index: index.jsp
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/webapps/ROOT/index.jsp,v
retrieving revision 1.17
diff -u -r1.17 index.jsp
--- index.jsp15 Jan 2005 18:18:31 -1.17
+++ index.jsp12 May 2005 16:10:42 -
@@ -1,157 +1,173 @@
-!doctype html public -//w3c//dtd html 4.0 transitional//en 
http://www.w3.org/TR/REC-html40/strict.dtd;
+?xml version=1.0 encoding=ISO-8859-1?
+!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
+   http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
 %@ page session=false %
-html
+html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
 head
-meta http-equiv=Content-Type content=text/html; 
charset=iso-8859-1
 title%= application.getServerInfo() %/title
 style type=text/css
-  !--
+  /*![CDATA[*/
 body {
 color: #00;
 background-color: #FF;
-font-family: Arial, Times New Roman, Times;
-font-size: 16px;
+font-family: Arial, Times New Roman, Times, serif;
+margin: 10px 0px;
 }
 
-A:link {
-color: blue
+img {
+border: none;
 }
 
-A:visited {
-color: blue
+a:link, a:visited {
+color: blue;
+}
+
+th {
+font-family: Verdana, Times New Roman, Times, serif;
+font-size: 110%;
+font-weight: normal;
+font-style: italic;
+background: #D2A41C;
+text-align: left;
 }
 
 td {
 color: #00;
-font-family: Arial, Times New Roman, Times;
-font-size: 16px;
+font-family: Arial, Helvetica, sans-serif;
+}
+
+td.menu {
+background: #FFDC75;
+}
+
+.center {
+text-align: center;
 }
 
 .code {
 color: #00;
-font-family: Courier New, Courier;
-font-size: 16px;
+font-family: Courier New, Courier, monospace;
+font-size: 110%;
+margin-left: 2.5em;
+}
+
+#banner {
+margin-bottom: 12px;
+}
+
+p#congrats {
+margin-top: 0;
+font-weight: bold;
+text-align: center;
+}
+
+p#footer {
+text-align: right;
+font-size: 80%;
 }
-  --
+  /*]]*/
 /style
 /head
 
 body
 
 !-- Header --
-table width=100%
+table id=banner width=100%
 tr
-td align=left width=130a 
href=http://jakarta.apache.org/tomcat/index.html;img src=tomcat.gif 
height=92 width=130 border=0 alt=The Mighty Tomcat - MEOW!/td
-td align=left valign=top
-table
-trtd align=left valign=topb%= 
application.getServerInfo() %/b/td/tr
-/table
-/td
-td align=righta href=http://jakarta.apache.org/;img 
src=jakarta-banner.gif height=48 width=505 border=0 alt=The 
Jakarta Project/a/td
+td align=left style=width:130pxa 
href=http://jakarta.apache.org/tomcat/index.html;img src=tomcat.gif 
height=92 width=130
+alt=The Mighty Tomcat - MEOW!//a/td
+td align=left valign=topb%= 
application.getServerInfo() %/b/td
+td align=righta href=http://jakarta.apache.org/;img 
src=jakarta-banner.gif height=48 width=505 alt=The Jakarta 
Project//a/td
 /tr
 /table
 
-br
-
 table
 tr
 
 !-- Table of Contents --
 td valign=top
-table width=100% border=1 cellspacing=0 
cellpadding=3 bordercolor=#00
+table width=100% border=1 cellspacing=0 cellpadding=3
 tr
-td bgcolor=#D2A41C bordercolor=#00 
align=left nowrap
-font face=Verdana 
size=+1iAdministration/inbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/font
-/td
+thAdministration/th
 /tr
 tr
-td bgcolor=#FFDC75 bordercolor=#00 nowrap
-a href=manager/statusStatus/abr
-a href=adminTomcat Administration/abr
-a href=manager/htmlTomcat 

Re: Code Submission - Wild Card Aliases

2005-05-12 Thread Remy Maucherat
George Sexton wrote:
OK, here is what I believe is the final version of the Mapper code with
support for wildcard matching.
The new code is approximately 14.7% faster, executing the 1,000,000
iteration test loop in 7480 ms versus 8772.5 ms for the original code, a
difference of 1292.5 ms. Times were computed by executing the main()
function 10 times, and recording the results. The median value was then
calculated and used for reporting. For those interested, the times for the
tests are below.
Here are the files:
HostMap.java - New File to act as a container for hosts. It contains
searching methods to find hosts.
http://www.mhsoftware.com/~gsexton/HostMap.java
Mapper.diff - Diff between 5.5.9 mapper and the current one. Because of the
abstraction of the host mapping into a new class it's not super useful, but
included for completeness.
http://www.mhsoftware.com/~gsexton/Mapper.diff
Mapper.java - Complete, modified Mapper.java file.
http://www.mhsoftware.com/~gsexton/Mapper.java
Harness_output.diff - Difference between the test harness output using the
5.5.9 code, and the modified code.
http://www.mhsoftware.com/~gsexton/harness_output.diff
Once I sort out the correct method of setting the default # of Alias
Matches, I will submit the complete set as a diff. Unless someone else want
to do the parameter setting. Right now the default # of alias matches is
hard-wired to 16.
Some people have asked me to integrate the test harness into a Junit testing
module. Unfortunately, I don't have any experience w/ Junit, so I don't
think I would be a good candidate for this.
There's one final thing. During previous discussions, it was kind of hinted
I should put the alias match limiting in the Connector. It seems kind of
ugly since this seems to apply at the host or alias level. Does anyone have
thoughts on this?
For testing purposes, a P3 600 Mhz running SUSE Linux 9.2, w/ JDK
1.4.2_06-b03 was used.
I like it to some extent (haven't fully verified it, though), but I'm 
still not hot about adding the newly found hosts to the host list. 
Even if it's slower, I think I'd prefer a separate prefix matching step, 
since filling the list with new hosts is likely going to create problems 
and add special cases (ex: managing hosts when you have a host as 
www.foo.com and another less relevant *.foo.com).

For exact matches (which is done in a few places inside Tomcat), using 
hash codes might work a bit faster, so it could be beneficial.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Mark Thomas
So the issues are:
1. AJP/1.3 compatibility
2. Potential DoS
As far as DoS goes, with the previous behaviour any parameters POSTed 
would be persisted in the session until the authentication was completed 
or the session timed out.  Therefore, the same issue exists with both 
the old and new implementation. (a)

The size of the the POST is already limited by maxPostSize for both
FORM and CLIENT-CERT auth. Is the proposal to add another parameter to
the connector to optionally further limit the saved POST size when 
authenticating? (b)

Given (a), I don't see a significant difference in risk between the old 
and new behaviour. I am happy to mitigate this risk by implementing (b). 
As maxPostSize applies to any POST, including during CLIENT-CERT auth my 
own view is that the new parameter should apply only to the 
FormAuthenticator valve and should default to 0 (ie no data saved). -1 
would mean use whatever value is specified for maxPostSize and any value 
0 would be the limit unless maxPostSize was smaller in which case 
maxPostSize would override the new parameter. The docs for this 
parameter would include a health warning about the risks of permitting 
the saving of POSTed data during FORM authentication.

I obviously also need to look at AJP/1.3 compatibility. Any hints/tips 
gratefully received.

If these issues aren't resolved by the time of the next release, I'll
revert the saving the raw data part of the patch.
Mark
Bill Barker wrote:
- Original Message - From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Thursday, May 12, 2005 5:28 AM
Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

Tim Funk wrote:
Would it be worthwhile to use a new property?
maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 
to disable saving post.

Of course this doesn't mitigate a malicious person issuing many POSTS 
under the configured threshold.

I think I disagree. Even if you are not trying to do a DoS, it is very 
easy to do it non intentionally if you save any post data (file upload).

We'd need to restrict saved POST size severely, as well as restrict 
more by default any form POST data.

I agree.  I'd even be +1 to further restricting the saved body size for 
CLIENT-CERT auth, and that one is only saved for the time of one 
request. Since the body in a FORM auth is going to be saved for much 
longer, it's even more important to restrict it.

And this is even more important for mod_jk users, since they will never 
get a chance to recover the data that they have posted :(.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Mark Thomas
So the issues are:
1. AJP/1.3 compatibility
2. Potential DoS
As far as DoS goes, with the previous behaviour any parameters POSTed 
would be persisted in the session until the authentication was completed 
or the session timed out.  Therefore, the same issue exists with both 
the old and new implementation. (a)

The size of the the POST is already limited by maxPostSize for both
FORM and CLIENT-CERT auth. Is the proposal to add another parameter to
the connector to optionally further limit the saved POST size when 
authenticating? (b)

Given (a), I don't see a significant difference in risk between the old 
and new behaviour. I am happy to mitigate this risk by implementing (b). 
As maxPostSize applies to any POST, including during CLIENT-CERT auth my 
own view is that the new parameter should apply only to the 
FormAuthenticator valve and should default to 0 (ie no data saved). -1 
would mean use whatever value is specified for maxPostSize and any value 
0 would be the limit unless maxPostSize was smaller in which case 
maxPostSize would override the new parameter. The docs for this 
parameter would include a health warning about the risks of permitting 
the saving of POSTed data during FORM authentication.

I obviously also need to look at AJP/1.3 compatibility. Any hints/tips 
gratefully received.

If these issues aren't resolved by the time of the next release, I'll
revert the saving the raw data part of the patch.
Mark
Bill Barker wrote:

Tim Funk wrote:
Would it be worthwhile to use a new property?
maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 
to disable saving post.

Of course this doesn't mitigate a malicious person issuing many POSTS 
under the configured threshold.

I think I disagree. Even if you are not trying to do a DoS, it is very 
easy to do it non intentionally if you save any post data (file upload).

We'd need to restrict saved POST size severely, as well as restrict 
more by default any form POST data.

I agree.  I'd even be +1 to further restricting the saved body size for 
CLIENT-CERT auth, and that one is only saved for the time of one 
request. Since the body in a FORM auth is going to be saved for much 
longer, it's even more important to restrict it.

And this is even more important for mod_jk users, since they will never 
get a chance to recover the data that they have posted :(.


Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Web standards in Tomcat webapps

2005-05-12 Thread Schalk Neethling
Richard
If it is decided to move forward with this, I would also be willing to 
chip in and help the conversion to XHTML + CSS.

Beton, Richard wrote:
Hi all,
I'm new to this list - forgive me for bargeing in (if I am).
I'd like to see the webapps distributed with Tomcat upgraded to use web 

standards. I couldn't find any mention of this in bugzilla.
* Is this a Good Thing?  (...I think it is)
* Is anyone already doing it?
* I've attached a first stab at one of the jsp pages: the ROOT/index.jsp 
page.  It uses basic CSS but I don't think I used any CSS2 features that 
might be less backward-compatible.

* I may have spare lunchtimes etc when I might slowly work my way 

through other pages ... if there is enough interest in getting this done.
Rick


cvs -z3 -q diff -u index.jsp (in directory 

C:\rdb\sw\apache\jakarta-tomcat-catalina\webapps\ROOT)
Index: index.jsp
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/webapps/ROOT/index.jsp,v
retrieving revision 1.17
diff -u -r1.17 index.jsp
--- index.jsp15 Jan 2005 18:18:31 -1.17
+++ index.jsp12 May 2005 16:10:42 -
@@ -1,157 +1,173 @@
-!doctype html public -//w3c//dtd html 4.0 transitional//en 

http://www.w3.org/TR/REC-html40/strict.dtd;
+?xml version=1.0 encoding=ISO-8859-1?
+!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
+   http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
%@ page session=false %
-html
+html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
head
-meta http-equiv=Content-Type content=text/html; 

charset=iso-8859-1
title%= application.getServerInfo() %/title
style type=text/css
-  !--
+  /*![CDATA[*/
body {
color: #00;
background-color: #FF;
-font-family: Arial, Times New Roman, Times;
-font-size: 16px;
+font-family: Arial, Times New Roman, Times, serif;
+margin: 10px 0px;
}

-A:link {
-color: blue
+img {
+border: none;
}

-A:visited {
-color: blue
+a:link, a:visited {
+color: blue;
+}
+
+th {
+font-family: Verdana, Times New Roman, Times, serif;
+font-size: 110%;
+font-weight: normal;
+font-style: italic;
+background: #D2A41C;
+text-align: left;
}

td {
color: #00;
-font-family: Arial, Times New Roman, Times;
-font-size: 16px;
+font-family: Arial, Helvetica, sans-serif;
+}
+
+td.menu {
+background: #FFDC75;
+}
+
+.center {
+text-align: center;
}

.code {
color: #00;
-font-family: Courier New, Courier;
-font-size: 16px;
+font-family: Courier New, Courier, monospace;
+font-size: 110%;
+margin-left: 2.5em;
+}
+
+#banner {
+margin-bottom: 12px;
+}
+
+p#congrats {
+margin-top: 0;
+font-weight: bold;
+text-align: center;
+}
+
+p#footer {
+text-align: right;
+font-size: 80%;
}
-  --
+  /*]]*/
/style
/head

body

!-- Header --
-table width=100%
+table id=banner width=100%
tr
-td align=left width=130a 

href=http://jakarta.apache.org/tomcat/index.html;img src=tomcat.gif 

height=92 width=130 border=0 alt=The Mighty Tomcat - MEOW!/td
-td align=left valign=top
-table
-trtd align=left valign=topb%= 

application.getServerInfo() %/b/td/tr
-/table
-/td
-td align=righta href=http://jakarta.apache.org/;img 
src=jakarta-banner.gif height=48 width=505 border=0 alt=The 

Jakarta Project/a/td
+td align=left style=width:130pxa 

href=http://jakarta.apache.org/tomcat/index.html;img src=tomcat.gif 

height=92 width=130
+alt=The Mighty Tomcat - MEOW!//a/td
+td align=left valign=topb%= 

application.getServerInfo() %/b/td
+td align=righta href=http://jakarta.apache.org/;img 
src=jakarta-banner.gif height=48 width=505 alt=The Jakarta 

Project//a/td
/tr
/table

-br
-
table
tr

!-- Table of Contents --
td valign=top
-table width=100% border=1 cellspacing=0 

cellpadding=3 bordercolor=#00
+table width=100% border=1 cellspacing=0 cellpadding=3
tr
-td bgcolor=#D2A41C bordercolor=#00 

align=left nowrap
-font face=Verdana 

size=+1iAdministration/inbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/font
-/td
+thAdministration/th
/tr
tr
-td bgcolor=#FFDC75 bordercolor=#00 nowrap
-a href=manager/statusStatus/abr
- 

cvs commit: jakarta-tomcat-connectors/jk/native/iis/installer

2005-05-12 Thread William A. Rowe, Jr.

wrowe   2005/05/12 11:46:22

  Modified:jk/native/iis/installer License.rtf
  Log:
Fix the License.rtf after -kb'ing the file (the various \x10 \x11 \x13 all 
 have
specific meanings to this format.)
  
Cuts HTTP Server Subcomponents from the license text.  If any additional 
 terms
apply to mod_jk, I didn't find corresponding NOTICE files in this 
 repository.
  
  Revision  ChangesPath
  1.2   +71 -265   
 jakarta-tomcat-connectors/jk/native/iis/installer/License.rtf
  
  Index: License.rtf
  ===
  RCS file: 
 /home/cvs/jakarta-tomcat-connectors/jk/native/iis/installer/License.rtf,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  Binary files /tmp/cvsYze2Of and /tmp/cvsaS9gES differ
  
  
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Bill Barker

- Original Message -
From: Mark Thomas [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, May 12, 2003 10:34 AM
Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml


So the issues are:
1. AJP/1.3 compatibility
2. Potential DoS

As far as DoS goes, with the previous behaviour any parameters POSTed
would be persisted in the session until the authentication was completed
or the session timed out.  Therefore, the same issue exists with both
the old and new implementation. (a)

The size of the the POST is already limited by maxPostSize for both
FORM and CLIENT-CERT auth. Is the proposal to add another parameter to
the connector to optionally further limit the saved POST size when
authenticating? (b)

The check on maxPostSize in the Request isn't applied to any 'chunked' POST
body, and also not to any 'multipart/form-data'.  I don't see any place else
that checks it except when CLIENT-CERT auth saves the request body.


Given (a), I don't see a significant difference in risk between the old
and new behaviour. I am happy to mitigate this risk by implementing (b).
As maxPostSize applies to any POST, including during CLIENT-CERT auth my
own view is that the new parameter should apply only to the
FormAuthenticator valve and should default to 0 (ie no data saved). -1
would mean use whatever value is specified for maxPostSize and any value
 0 would be the limit unless maxPostSize was smaller in which case
maxPostSize would override the new parameter. The docs for this
parameter would include a health warning about the risks of permitting
the saving of POSTed data during FORM authentication.


No.  Previously only the Parameters were saved, and limited by maxPostSize.
Now you are saving off file-upload posts as well, and these aren't limited
anywhere.

I obviously also need to look at AJP/1.3 compatibility. Any hints/tips
gratefully received.


It should be something like:
   request.getCoyoteRequest().action(ActionCode.ACTION_SET_BODY_REPLAY,
body);

but that won't work either unless Jk-Coyote gets cleaned up a bit (the
ActionHook implementation is one of those it's ugly but it works things at
the moment :).  I could do the cleanup if the consensus is that this is the
way to go.

If these issues aren't resolved by the time of the next release, I'll
revert the saving the raw data part of the patch.

Mark






This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/nt_service nt_service.dsp

2005-05-12 Thread William A. Rowe, Jr.

wrowe   2005/05/12 11:55:09

  Modified:jk/native/domino dsapi.dsp
   jk/native/iis isapi.dsp isapi_redirect.rc isapi_redirect.reg
   jk/native/iis/installer isapi-redirector-win32-msi.ism
   jk/native/isapi tomcat_redirector.reg
   jk/native/netscape nsapi.dsp
   jk/native/nt_service nt_service.dsp
  Log:
All of the following -text- files suffered from /r/r/n problems.
  
Wiping superfluous /r codes - whitespace only patch.
  
  Revision  ChangesPath
  1.10  +305 -305  jakarta-tomcat-connectors/jk/native/domino/dsapi.dsp
  
  
 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/domino/dsapi.dsp.diff?r1=1.9r2=1.10
  
  
  1.15  +299 -299  jakarta-tomcat-connectors/jk/native/iis/isapi.dsp
  
  
 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/iis/isapi.dsp.diff?r1=1.14r2=1.15
  
  
  1.4   +53 -53
 jakarta-tomcat-connectors/jk/native/iis/isapi_redirect.rc
  
  
 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/iis/isapi_redirect.rc.diff?r1=1.3r2=1.4
  
  
  1.2   +9 -9  
 jakarta-tomcat-connectors/jk/native/iis/isapi_redirect.reg
  
  
 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/iis/isapi_redirect.reg.diff?r1=1.1r2=1.2
  
  
  1.9   +4595 
 -4595jakarta-tomcat-connectors/jk/native/iis/installer/isapi-redirector-win32-msi.ism
  
  
 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/iis/installer/isapi-redirector-win32-msi.ism.diff?r1=1.8r2=1.9
  
  
  1.2   +9 -9  
 jakarta-tomcat-connectors/jk/native/isapi/tomcat_redirector.reg
  
  
 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/isapi/tomcat_redirector.reg.diff?r1=1.1r2=1.2
  
  
  1.15  +275 -275  jakarta-tomcat-connectors/jk/native/netscape/nsapi.dsp
  
  
 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/netscape/nsapi.dsp.diff?r1=1.14r2=1.15
  
  
  1.10  +199 -199  
 jakarta-tomcat-connectors/jk/native/nt_service/nt_service.dsp
  
  
 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/nt_service/nt_service.dsp.diff?r1=1.9r2=1.10
  
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-connectors/jni/native/src shm.c ssl.c

2005-05-12 Thread William A. Rowe, Jr.

wrowe  2005/05/12 12:28:03

  Modified:jni/native libtcnative.dsp libtcnative.dsw tcnative.dsp
   jni/native/build win32ver.awk
   jni/native/src shm.c ssl.c
  Log:
Fix more ^M polution, whitespace changes, only.
  
  Revision  ChangesPath
  1.6   +218 -218  jakarta-tomcat-connectors/jni/native/libtcnative.dsp
  
  Index: libtcnative.dsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/libtcnative.dsp,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- libtcnative.dsp   3 Feb 2005 07:48:56 -   1.5
  +++ libtcnative.dsp   12 May 2005 19:28:03 -  1.6
  @@ -1,218 +1,218 @@
  -# Microsoft Developer Studio Project File - Name=libtcnative - Package 
 Owner=4
  -# Microsoft Developer Studio Generated Build File, Format Version 6.00
  -# ** DO NOT EDIT **
  -
  -# TARGTYPE Win32 (x86) Dynamic-Link Library 0x0102
  -
  -CFG=libtcnative - Win32 Debug
  -!MESSAGE This is not a valid makefile. To build this project using NMAKE,
  -!MESSAGE use the Export Makefile command and run
  -!MESSAGE 
  -!MESSAGE NMAKE /f libtcnative.mak.
  -!MESSAGE 
  -!MESSAGE You can specify a configuration when running NMAKE
  -!MESSAGE by defining the macro CFG on the command line. For example:
  -!MESSAGE 
  -!MESSAGE NMAKE /f libtcnative.mak CFG=libtcnative - Win32 Debug
  -!MESSAGE 
  -!MESSAGE Possible choices for configuration are:
  -!MESSAGE 
  -!MESSAGE libtcnative - Win32 Release (based on Win32 (x86) Dynamic-Link 
 Library)
  -!MESSAGE libtcnative - Win32 Debug (based on Win32 (x86) Dynamic-Link 
 Library)
  -!MESSAGE 
  -
  -# Begin Project
  -# PROP AllowPerConfigDependencies 0
  -# PROP Scc_ProjName 
  -# PROP Scc_LocalPath 
  -CPP=cl.exe
  -MTL=midl.exe
  -RSC=rc.exe
  -
  -!IF  $(CFG) == libtcnative - Win32 Release
  -
  -# PROP BASE Use_MFC 0
  -# PROP BASE Use_Debug_Libraries 0
  -# PROP BASE Output_Dir Release
  -# PROP BASE Intermediate_Dir Release
  -# PROP BASE Target_Dir 
  -# PROP Use_MFC 0
  -# PROP Use_Debug_Libraries 0
  -# PROP Output_Dir Release
  -# PROP Intermediate_Dir Release
  -# PROP Ignore_Export_Lib 0
  -# PROP Target_Dir 
  -# ADD BASE CPP /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS /FD 
 /c
  -# ADD CPP /nologo /MD /W3 /Zi /O2 /I ./include /I ../apr/include /I 
 ../apr/include/arch/win32 /I $(JAVA_HOME)/include /I 
 $(JAVA_HOME)/include/win32 /I ../openssl/inc32 /D NDEBUG /D 
 TCN_DECLARE_EXPORT /D WIN32 /D _WINDOWS /D WIN32_LEAN_AND_MEAN /D 
 NO_IDEA /D NO_RC5 /D NO_MDC2 /D OPENSSL_NO_IDEA /D OPENSSL_NO_RC5 
 /D OPENSSL_NO_MDC2 /D HAVE_OPENSSL /D HAVE_SSL_SET_STATE=1 
 /FdRelease\libtcnative_src /FD /c
  -# ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /o /win32 NUL
  -# ADD MTL /nologo /D NDEBUG /mktyplib203 /o /win32 NUL
  -# ADD BASE RSC /l 0x409 /d NDEBUG
  -# ADD RSC /l 0x409 /d NDEBUG
  -BSC32=bscmake.exe
  -# ADD BASE BSC32 /nologo
  -# ADD BSC32 /nologo
  -LINK32=link.exe
  -# ADD BASE LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib 
 wldap32.lib psapi.lib ole32.lib /nologo /base:0x6EE0 /subsystem:windows 
 /dll /debug /machine:I386 /opt:ref
  -# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib 
 psapi.lib ole32.lib libeay32.lib ssleay32.lib /nologo /base:0x6EE0 
 /subsystem:windows /dll /debug /machine:I386 /out:Release/libtcnative-1.dll 
 /libpath:../openssl/out32dll /libpath:../openssl/out32 /opt:ref
  -
  -!ELSEIF  $(CFG) == libtcnative - Win32 Debug
  -
  -# PROP BASE Use_MFC 0
  -# PROP BASE Use_Debug_Libraries 1
  -# PROP BASE Output_Dir Debug
  -# PROP BASE Intermediate_Dir Debug
  -# PROP BASE Target_Dir 
  -# PROP Use_MFC 0
  -# PROP Use_Debug_Libraries 1
  -# PROP Output_Dir Debug
  -# PROP Intermediate_Dir Debug
  -# PROP Ignore_Export_Lib 0
  -# PROP Target_Dir 
  -# ADD BASE CPP /nologo /MDd /W3 /GX /Zi /Od /D WIN32 /D _DEBUG /D 
 _WINDOWS /FD /c
  -# ADD CPP /nologo /MDd /W4 /GX /Zi /Od /I ./include /I ../apr/include 
 /I ../apr/include/arch/win32 /I $(JAVA_HOME)/include /I 
 $(JAVA_HOME)/include/win32 /I ../openssl/inc32 /D _DEBUG /D 
 TCN_DECLARE_EXPORT /D WIN32 /D _WINDOWS /D WIN32_LEAN_AND_MEAN /D 
 NO_IDEA /D NO_RC5 /D NO_MDC2 /D OPENSSL_NO_IDEA /D OPENSSL_NO_RC5 
 /D OPENSSL_NO_MDC2 /D HAVE_OPENSSL /D HAVE_SSL_SET_STATE=1 
 /FdDebug\libtcnative_src /FD /c
  -# ADD BASE MTL /nologo /D _DEBUG /mktyplib203 /o /win32 NUL
  -# ADD MTL /nologo /D _DEBUG /mktyplib203 /o /win32 NUL
  -# ADD BASE RSC /l 0x409 /d _DEBUG
  -# ADD RSC /l 0x409 /d _DEBUG
  -BSC32=bscmake.exe
  -# ADD BASE BSC32 /nologo
  -# ADD BSC32 /nologo
  -LINK32=link.exe
  -# ADD BASE LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib 
 wldap32.lib psapi.lib ole32.lib /nologo /base:0x6EE0 /subsystem:windows 
 /dll /incremental:no /debug /machine:I386
  -# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib 
 psapi.lib ole32.lib libeay32.lib ssleay32.lib /nologo 

Admin Application messes up HTTPS Connectors in server.xml

2005-05-12 Thread Ankit Shah
Hi,
The Tomcat admin utility doesn't save the HTTPS connectors properly. It 
misses out the 'sslProtocol' attribute and this results in the failed 
connector. Does anyone have a fix around this?

The following is the current state of our server:
Tomcat 5.5.9 with 1.4.2 compatibility add-on.
JRE version 1.4.2_05

My Tests and results:
About certificates:
We are using our own keytool generated unsigned certificates. 
Everytime i point firefox to the admin app, it will present the 
certificate for my approval. I temporarily accept the certificate for my 
session.

1. Install tomcat, configure an HTTPS connector
Run the admin app and change a parameter (acceptCount in my case: 
raised it from 8 to 10) and click Save and then Commit Changes

Restart tomcat. Restart Firefox. Pointing the browser to the admin 
app homepage will not load anything.
No Certificate presented!!

2. Manually did a diff on server.xml and server.xml.backup . The 
difference is the missing 'sslProtocol' attribute. The docs say this 
attribute is optional, but that doesn't seem like the case. Added the 
attribute manually
sslProtocol=TLS

Restart Tomcat. Restart Firefox. Certificate presented. Admin App 
Homepage Loaded.

3. By seeing the server.xml written out by Admin app, it is clear that 
only attributes with non-default values are written out.
From the admin app, set SSL Protocol field's value to SSL. Save. 
Commit Changes

Restart Tomcat. Restart Firefox. NO Certificate Presented. Admin 
App homepage NOT loaded.

In server.xml - sslProtocol attribute is NOT written out.

I also inspected the logs (Generated by Log4J and logging level set to 
debug)

Upon save:
bean is updated with sslProtocol's new value
Upon Commit:
the list of attributes for the connector doesn't have sslProtocol 
as one of the attributes that will be written out

Can you help me how i can make admin application available for Tomcat 
administration by the assigned administrators? What fixes will be needed. 
If there are any known get-arounds for this.

Thanks in advance for all your help and appreciate your patience in 
reading through my email.

Ankit




cvs commit: jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni OS.java

2005-05-12 Thread William A. Rowe, Jr.

wrowe  2005/05/12 12:29:47

  Modified:jni/java/org/apache/tomcat/jni OS.java Address.java
  Log:
More ^M polution fixed, whitespace changes only.
  
  Revision  ChangesPath
  1.5   +15 -15
 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/OS.java
  
  Index: OS.java
  ===
  RCS file: 
 /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/OS.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- OS.java   18 Jan 2005 10:22:50 -  1.4
  +++ OS.java   12 May 2005 19:29:47 -  1.5
  @@ -73,23 +73,23 @@
* Gather system info.
* PRE
* On exit the inf array will be filled with:
  - * inf[0]  - Physical RAM
  - * inf[1]  - Available RAM
  - * inf[2]  - Total page file (swap + Physical RAM)
  - * inf[3]  - Free page file
  + * inf[0]  - Physical RAM
  + * inf[1]  - Available RAM
  + * inf[2]  - Total page file (swap + Physical RAM)
  + * inf[3]  - Free page file
* inf[4]  - Memory Load
  - *
  - * inf[5]  - Idle Time in microseconds
  - * inf[6]  - Kernel Time in microseconds
  + *
  + * inf[5]  - Idle Time in microseconds
  + * inf[6]  - Kernel Time in microseconds
* inf[7]  - User Time in microseconds
  - *
  - * inf[8]  - Process creation time (apr_time_t)
  - * inf[9]  - Process Kernel Time in microseconds
  + *
  + * inf[8]  - Process creation time (apr_time_t)
  + * inf[9]  - Process Kernel Time in microseconds
* inf[10] - Process User Time in microseconds
  - *
  - * inf[11] - Current working set size.
  - * inf[12] - Peak working set size.
  - * inf[13] - Number of page faults.
  + *
  + * inf[11] - Current working set size.
  + * inf[12] - Peak working set size.
  + * inf[13] - Number of page faults.
* /PRE
* @param inf array that will be filled with system informations.
*/
  
  
  
  1.5   +8 -8  
 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Address.java
  
  Index: Address.java
  ===
  RCS file: 
 /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Address.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- Address.java  16 Apr 2005 16:45:13 -  1.4
  +++ Address.java  12 May 2005 19:29:47 -  1.5
  @@ -72,13 +72,13 @@
*/
   public static native String getnameinfo(long sa, int flags);
   
  -/**
  - * Return the IP address (in numeric address string format) in
  - * an APR socket address.  APR will allocate storage for the IP address 
  - * string from the pool of the apr_sockaddr_t.
  - * @param ss The socket address to reference.
  - * @return The IP address.
  - */
  +/**
  + * Return the IP address (in numeric address string format) in
  + * an APR socket address.  APR will allocate storage for the IP address 
  + * string from the pool of the apr_sockaddr_t.
  + * @param ss The socket address to reference.
  + * @return The IP address.
  + */
   public static native String getip(long sa);
   
   /**
  
  
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Event log message: Somebody try to hack into the site!!!

2005-05-12 Thread Warren Barton - BGT Partners
Hello, I have Tomcat served via an IIS ISAPI filter on Windows 2003, all
is working well except... I get this message repeatedly each day in my
Windows Event Viewer:

Application Event Log failure message: [1] Emerg: [jk_isapi_plugin.c
(434)]: HttpFilterProc [/web-inf/] points to the web-inf or meta-inf
directory. Somebody try to hack into the site!!!

I've googled and yahooed as much as I can on this one, nothing
definitive. What servlet actions could trigger this message, or what
actions at all for that matter? Any help is greatly appreciated!

Thanks,

- Warren


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Event log message: Somebody try to hack into the site!!!

2005-05-12 Thread Jay Burgess
The beauty of open source is that you can look at the source. :)  I searched for
your error string and ran across the following in the HttpFilterProc() function
in jk_isapi_plugin.c.  It looks like it's trapping for an attempt to access
WEB-INF or META-INF directly (which is illegal), and correctly logging an error
and returning 403 Forbidden.

/*
 * Check if somebody is feeding us with his own TOMCAT data headers.
 * We reject such postings !
 */
env-l-jkLog(env, env-l, JK_LOG_DEBUG,
HttpFilterProc check if [%s] is pointing to the web-inf directory\n, 
uri);

if(jk_requtil_uriIsWebInf(uri)) {
env-l-jkLog(env, env-l,  JK_LOG_EMERG, 
HttpFilterProc [%s] points to the web-inf or meta-inf
 directory.\nSomebody try to hack into the site!!!\n, uri);
write_error_response(pfc,403 Forbidden, HTML_ERROR_403);
workerEnv-globalEnv-releaseEnv( workerEnv-globalEnv, env );
return SF_STATUS_REQ_FINISHED;
}

Jay

| Jay Burgess [Vertical Technology Group]
| Essential Technology Links via RSS
| http://www.vtgroup.com/

-Original Message-
From: Warren Barton - BGT Partners [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 12, 2005 3:15 PM
To: tomcat-dev@jakarta.apache.org
Subject: Event log message: Somebody try to hack into the site!!!

Hello, I have Tomcat served via an IIS ISAPI filter on Windows 2003, all
is working well except... I get this message repeatedly each day in my
Windows Event Viewer:

Application Event Log failure message: [1] Emerg: [jk_isapi_plugin.c
(434)]: HttpFilterProc [/web-inf/] points to the web-inf or meta-inf
directory. Somebody try to hack into the site!!!

I've googled and yahooed as much as I can on this one, nothing
definitive. What servlet actions could trigger this message, or what
actions at all for that matter? Any help is greatly appreciated!

Thanks,

- Warren


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-connectors/jk/xdocs/howto apache.xml

2005-05-12 Thread William A. Rowe, Jr.

wrowe  2005/05/12 13:26:59

  Modified:jk/native2 CHANGES.txt
   jk/xdocs/howto apache.xml
  Log:
Last of the ^M bogosity I could uncover.  Think that we are ready for
a new tarball :)
  
  Revision  ChangesPath
  1.19  +6 -6  jakarta-tomcat-connectors/jk/native2/CHANGES.txt
  
  Index: CHANGES.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/CHANGES.txt,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- CHANGES.txt   12 May 2005 18:37:14 -  1.18
  +++ CHANGES.txt   12 May 2005 20:26:59 -  1.19
  @@ -1,12 +1,12 @@
   JAKARTA TOMCAT CONNECTORS 2 (JK2) CHANGELOG:-*-text-*-
   Last modified at [$Date$]
   
  -AS OF NOVEMBER 15, 2004, JK2 IS NO LONGER SUPPORTED. ALL BUGS RELATED TO 
 JK2 
  -WILL BE MARKED AS WONTFIX. IN ITS PLACE, SOME OF ITS FEATURES HAVE BEEN 
  +AS OF NOVEMBER 15, 2004, JK2 IS NO LONGER SUPPORTED. ALL BUGS RELATED TO 
 JK2 
  +WILL BE MARKED AS WONTFIX. IN ITS PLACE, SOME OF ITS FEATURES HAVE BEEN 
   BACKPORTED TO JK1. MOST OF THOSE FEATURES WILL BE SEEN IN 1.2.7 AND LATER
  -VERSIONS.
  -
  -ANOTHER ALTERNATIVE IS THE AJP ADDITION TO MOD_PROXY WHICH WILL BE PART OF 
  +VERSIONS.
  +
  +ANOTHER ALTERNATIVE IS THE AJP ADDITION TO MOD_PROXY WHICH WILL BE PART OF 
   APACHE 2.1.
   
   Changes in JK2 HEAD:
  
  
  
  1.8   +2 -2  jakarta-tomcat-connectors/jk/xdocs/howto/apache.xml
  
  Index: apache.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/howto/apache.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- apache.xml13 Apr 2005 12:17:07 -  1.7
  +++ apache.xml12 May 2005 20:26:59 -  1.8
  @@ -294,7 +294,7 @@
   source
   # Load mod_jk module
   LoadModulejk_module  libexec/mod_jk.so
  -# Declare the module for lt;IfModule directivegt; (remove this line 
 on Apache 2.0.x)
  +# Declare the module for lt;IfModule directivegt; (remove this line 
 on Apache 2.0.x)
   AddModule mod_jk.c
   # Where to find workers.properties
   JkWorkersFile /etc/httpd/conf/workers.properties
  
  
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Mark Thomas
Bill Barker wrote:
From: Mark Thomas [EMAIL PROTECTED]
So the issues are:
1. AJP/1.3 compatibility
2. Potential DoS
As far as DoS goes, with the previous behaviour any parameters POSTed
would be persisted in the session until the authentication was completed
or the session timed out.  Therefore, the same issue exists with both
the old and new implementation. (a)
The size of the the POST is already limited by maxPostSize for both
FORM and CLIENT-CERT auth. Is the proposal to add another parameter to
the connector to optionally further limit the saved POST size when
authenticating? (b)

The check on maxPostSize in the Request isn't applied to any 'chunked' POST
body, and also not to any 'multipart/form-data'.  I don't see any place else
that checks it except when CLIENT-CERT auth saves the request body.
I stand corrected. This is easy to fix if it is agreed that this, or 
something similar to it, is the way forward.

Given (a), I don't see a significant difference in risk between the old
and new behaviour. I am happy to mitigate this risk by implementing (b).
As maxPostSize applies to any POST, including during CLIENT-CERT auth my
own view is that the new parameter should apply only to the
FormAuthenticator valve and should default to 0 (ie no data saved). -1
would mean use whatever value is specified for maxPostSize and any value
0 would be the limit unless maxPostSize was smaller in which case
maxPostSize would override the new parameter. The docs for this
parameter would include a health warning about the risks of permitting
the saving of POSTed data during FORM authentication.

No.  Previously only the Parameters were saved, and limited by maxPostSize.
Now you are saving off file-upload posts as well, and these aren't limited
anywhere.
As above, putting the limit in is easy.
I obviously also need to look at AJP/1.3 compatibility. Any hints/tips
gratefully received.

It should be something like:
   request.getCoyoteRequest().action(ActionCode.ACTION_SET_BODY_REPLAY,
body);
but that won't work either unless Jk-Coyote gets cleaned up a bit (the
ActionHook implementation is one of those it's ugly but it works things at
the moment :).  I could do the cleanup if the consensus is that this is the
way to go.
Any help would be great. It took me a while to figure out how to get 
this far.

If these issues aren't resolved by the time of the next release, I'll
revert the saving the raw data part of the patch.
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JK 1.2.12 is broken and can not be released as stable

2005-05-12 Thread William A. Rowe, Jr.
Ok, all of the file ^M fixes within jakarta-tomcat-connectors
are finished.  I added the /Oy- flag as there was unanimous
concensus for -that- change.  I left out the /Gs0 since legit
concerns were raised.  Think we are ready for a tarball :)

-kb files which should not have been are now -ko.  It's easier
than diddling the ,v files directly, and I've never found the
cvs admin magic to take away the -k flag altogether.

You need a clean checkout to observe the actual tree, cvs up
does a lousy job of picking up -k flag changes.

Win32 images should be checked out on win32 cvs.  Short of that,
there is also some lovely magic in apr/build/lineends.pl that
fixes only files it should touch.  (This works on unix to take
in win32 files, and on win32 to take in unix files.)

Unix users can now feel free to modify .dsp files etc as needed,
without playing ^M games.

Truly hope it helps.  Sorry for having to route through rowe-clan,
it seems tomcat-dev hates my apache.org persona.  (tomcat cvs did
not complain, but it's forwarded onto tomcat-dev.)  

Bill


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JK 1.2.12 is broken and can not be released as stable

2005-05-12 Thread Mark Thomas
William A. Rowe, Jr. wrote:
Truly hope it helps.  Sorry for having to route through rowe-clan,
it seems tomcat-dev hates my apache.org persona.  (tomcat cvs did
not complain, but it's forwarded onto tomcat-dev.)  
This should now be fixed. Let me know if it isn't.
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


[Q/PATCH] ws_write call to ap_rflush

2005-05-12 Thread Jean-Jacques Clar


Callingap_rflush() at the end of ws_write() in mod_jk.c is causing me 
problems when doing downloads from the server toa client.
Performance degradation and, less importantly, memory usage, are the problems.

During calls to ap_rwrite() in ws_write, a brigade is created and
used to move data.When done, a call to apr_brigade_destroy()
is made.A call to apr_pool_cleanup_kill() ensures that the registered
cleanupentry is removed from the cleanups linked list associated 
with the request pool. Thebrigade is then cleaned up.

After that, a callisdone to ap_rflush() within ws_writeto do what seems to me
the same operations that were just made.ap_rflush is alsocreating a brigade
on every call and adds its cleanup function to the cleanups list. 
The brigades created by ap_rflush will not be destroyed before the
request is finished, if I understand correctly. 
ap_rflush job is to destroy the brigade created by the ap_rwrite
operation, whichwas already done and removed from the cleanups
list previously. In my test, at the beginning of a download, mod_jk is doing 
about 250 calls to ap_rflush() every seconds. This is when the cleanups list 
is of reasonable size,gets much slower quickly because of the time spent 
scanning the cleanups list. 
I am downloading large files ( 1GB), it takes time and
by the time I get to the end of the download, my cleanups list has grow
to over 20 members and it has to be scanned unsuccessfully from beginning to
end in search of a brigade that was previously removed.

Removing the call to ap_rflush() is working great for me:
I ran stress and functional testing on my server w/ no apparent problems.

My questionare:
Whyis ws_write() calling ap_rflush()? I am sure other users are suffering from it.
Could it be just removed?
If it is essential, any suggestions fora workaround for my problem?

This is a link to a bug that is related to the extra brigade created by
ap_rflush():

http://issues.apache.org/bugzilla/show_bug.cgi?id=34589

Thank you very much,

Jean-Jacques
Index: jk/native/apache-2.0/mod_jk.c
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.143
diff -u -r1.143 mod_jk.c
--- jk/native/apache-2.0/mod_jk.c   7 May 2005 08:15:47 -   1.143
+++ jk/native/apache-2.0/mod_jk.c   12 May 2005 21:07:16 -
@@ -388,17 +388,6 @@
 
 }
 
-/*
- * To allow server push. After writing full buffers
- */
-#ifndef AS400
-if (ap_rflush(p-r) != APR_SUCCESS) {
-ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_CRIT, 0,
- NULL, mod_jk: Error flushing);
-return JK_FALSE;
-}
-#endif
-
 }
 
 return JK_TRUE;

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK 1.2.12 is broken and can not be released as stable

2005-05-12 Thread Günter Knauf
Hi,

 What is the thought, is 1.2.10 stable?  1.2.8?  Or 1.2.6?  I'm partial
 to 1.2.8 myself.
from what I see in our NetWare forums I can only agree to Klaus and say that 
everything after 1.2.6 has some kind of issues - that was also the reason why I 
dint move the NetWare bins to its place until yesterday...
also it seems that currently many of our NetWare users dont want to test next 
round since they tested already 1.2.8 and 1.2.10 and had to go back to 1.2.6

Guenter.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

2005-05-12 Thread Jan Luehe


[EMAIL PROTECTED] wrote:
 remm2005/05/12 06:01:05
 
   Modified:jasper2/src/share/org/apache/jasper/servlet
 JspCServletContext.java
webapps/docs changelog.xml
   Log:
   - 34465: jspc without web.xml.
   - Submitted by Yoichi Hirose.
   
   Revision  ChangesPath
   1.4   +7 -1  
 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java
   
   Index: JspCServletContext.java
   ===
   RCS file: 
 /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java,v
   retrieving revision 1.3
   retrieving revision 1.4
   diff -u -r1.3 -r1.4
   --- JspCServletContext.java 17 Mar 2004 19:23:05 -  1.3
   +++ JspCServletContext.java 12 May 2005 13:01:04 -  1.4
   @@ -235,7 +235,13 @@
if (!path.startsWith(/))
throw new MalformedURLException(Path ' + path +
' does not start with '/');
   -return (new URL(myResourceBaseURL, path.substring(1)));
   +URL url = new URL(myResourceBaseURL, path.substring(1));
   +if (file.equals(url.getProtocol())) {
   +if (!(new File(url.getFile())).exists()) {
   +return null;
   +}
   +}
   +return url;

}

I don't think this is very efficient. Normally, the resource
with the given path will exist. It is just in the case
of web.xml that it may not exist.

Why not check specifically for existence of web.xml, as follows:


Index: JspConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java,v
retrieving revision 1.18
diff -u -r1.18 JspConfig.java
--- JspConfig.java  24 Mar 2005 04:08:01 -  1.18
+++ JspConfig.java  13 May 2005 00:09:22 -
@@ -16,6 +16,7 @@

 package org.apache.jasper.compiler;

+import java.io.File;
 import java.io.InputStream;
 import java.util.Iterator;
 import java.util.Vector;
@@ -63,10 +64,12 @@

 try {
 URL uri = ctxt.getResource(WEB_XML);
-if (uri == null) {
+if (uri == null
+|| (file.equals(uri.getProtocol())
+ !(new File(uri.getFile())).exists())) {
// no web.xml
 return;
-   }
+}

 is = uri.openStream();
 InputSource ip = new InputSource(is);


Jan




Jan


   
   
   
   1.308 +7 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
   
   Index: changelog.xml
   ===
   RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
   retrieving revision 1.307
   retrieving revision 1.308
   diff -u -r1.307 -r1.308
   --- changelog.xml   11 May 2005 21:39:41 -  1.307
   +++ changelog.xml   12 May 2005 13:01:04 -  1.308
   @@ -153,6 +153,10 @@
default encoding. A side effect of this fix is that the bodies of 
 POST requests that
require FORM authentication are now buffered and made available 
 after a sucessful login. (markt)
  /fix
   +  fix
   +bug34840/bug: Better handling of external WARs redeployment, 
 and ignore docBase specified
   +in context file if within the Host appBase (remm)
   +  /fix
/changelog
  /subsection
  
   @@ -199,6 +203,9 @@
bug34652/bug: Add the ability to get SMAPs when precompiling, 
 submitted by
Daryl Robbins (remm)
  /update
   +  fix
   +bug34465/bug: Jspc failure if there is no web.xml, submitted 
 by Yoichi Hirose (remm)
   +  /fix
/changelog
  /subsection
  
   
   
   
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 34904] New: - include in jsp returns out of order

2005-05-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34904.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34904

   Summary: include in jsp returns out of order
   Product: Tomcat 5
   Version: 5.0.27
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet  JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


have the following code in my jsp, which is called by a forward from my
Controller servlet. The various Dispatchers are either servlets or jsps declared
in my web.xml.
All the servlets and jsps get run correctly. The problem is the output. The
output of the root jsp and the 3-4 included jsps are arbitrarily rearranged, see
below. Bizarre shuffling, not reverse order, but a different order and not
interleaved with the text from the jsp. How do I fix this problem?

Code:

BODY
jsp:include page=WEB-INF/jsps/portal/header.jsp flush=true/
% if(option1) {
application.getNamedDispatcher(Option1Servlet).include(request,response);
} else { %
tabletr
% if(option2) { %
td% 
  
application.getNamedDispatcher(Option2Servlet).include(request,response); 
%/td
%  } %
td% 
   application.getNamedDispatcher(page).include(request,response); %/td
td% 
   application.getNamedDispatcher(InfoServlet).include(request,response);
%/td
/tr/table
%  } %
/BODY



generated html:

BODY
 
 
Page text  // from the page dispatcher
 
Info servlet text   // from the infoservlet dispatcher
 
Header form text // from the header.jsp dispatcher
 
 
tabletr
 
td/td
td/td
/tr/table
 
/BODY

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]