Re: extreemly simple request to add process name variable to catalina.out
Lance, On 7/7/2011 12:03 PM, Campbell, Lance wrote: Tomcat 6 enhancement: Please consider giving us the ability to change the process name for linux applications. I have identified all of the places I believe this needs to be done. Would you please consider adding the following to the catalina.sh file: 1) In the variable section at the top please add: CATALINA_PROCESS_NAME (Optional) This variable will set the linux process name to a particular value. 2) There needs to be an if statement that checks to see if a value has been passed to CATALINA_PROCESS_NAME. If there has been then the string -a needs to be appended to the front of the value. If not then the value would be . 3) Then replace any occurance of $_RUNJAVA with exec $CATALINA_PROCESS_NAME . This will allow the process to be named. I had no idea that bash's exec built-in allowed for this. Kind of cool. Two question/comments: 1. You can pass any dummy argument to the JVM in order to do things like ps | grep if you just want to look for your process in the process table. Is there some compelling reason to replace java with foo in the process table? Example: CATALINA_OPTS= -DmySearchString ... $CATALINA_BASE/bin/startup.sh Then you can do ps | grep mySearchString and find it. 2. This will only work for bash, not for other shells. In order for any patch to be accepted, you'll have to include a test to determine whether bash is the current shell. -chris signature.asc Description: OpenPGP digital signature
Using reflection to call tcnative methods
All, I've been working in AprLifecycleListener to add FIPS support. I need to make an additional native method call in initializeSSL and I'm wondering why all of the native methods are called using reflection instead of direct method calls. The SSL class, for instance, and the AprLifecycleListener are both in the Tomcat source tree and so they should always be in sync. The only reason I can think of is that native methods can throw any exception they want even if they are not declared in the Java stub, and the InvocationTargetException that wraps any exception through a reflective call will help avoid any problems. Is that it? Is that the reason for the reflective calls? If not, is there another reason? If there's no good reason, then all the reflective-call clutter should be removed. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Using reflection to call tcnative methods
Mladen, On 7/8/2011 11:44 PM, Mladen Turk wrote: On 07/09/2011 04:14 AM, Christopher Schultz wrote: All, I've been working in AprLifecycleListener to add FIPS support. I need to make an additional native method call in initializeSSL and I'm wondering why all of the native methods are called using reflection instead of direct method calls. Think that originates from the initial code when the java part of native was not part of tomcat code. We needed a way to make (at that time a separate .jar) tomcat uses it without run time dependency. That makes sense. If there's no good reason, then all the reflective-call clutter should be removed. +1. There is absolutely no reason to use the reflection any more. Okay. I have a patch I'd like to make that should be as small as possible in general, so I think I shouldn't change the existing reflective calls, at least not in this patch. Should I therefore code my patch to match the existing code (using reflection) and then write another patch to remove the reflection, or should my initial patch just avoid the reflection and the code will have two different calling strategies until both patches are applied? (I'm more concerned with backporting to TC 6 than my initial patches which are of course targeted towards TC 7). I'll wait for another opinion or two before I make any commits. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Distributable contexts and non-serializable session attributes
Rainer,
On 7/10/2011 3:38 PM, Rainer Jung wrote:
Unfortunately I stumbled into some code in StandardSession:
public void setAttribute(String name, Object value, boolean notify) {
...
if ((manager != null) manager.getDistributable()
!(value instanceof Serializable))
throw new IllegalArgumentException
(sm.getString(standardSession.setAttribute.iae, name));
...
}
This means if you enable distributable, then you can no longer set any
non-serializable session attribute. The code is not recent, it goes back
to at least TC 3.3.
I think checking for serializability in StandardSession isn't good,
because AFAIK StandardSession isn't used by any mechanism Tomcat
supports to implement distributable.
And in DeltaSession I would like to have the check optional, i.e. only
check if the configuration wants the attribute to be replicated.
By default all attributes will be replicated as is today, but by
configuration one will be able to choose attributes to replicate using a
regexp against the attribute name.
+1
-chris
signature.asc
Description: OpenPGP digital signature
Re: [SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure and availability vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, Great catch to all who were involved in discovery and mitigation of this vulnerability. Since the APR flavor of this vulnerability uses native code to crash the JVM and/or read files without asking the SecurityManager for permission, does that mean that the APR SSL configuration could be similarly attacked by specifying certificate file, etc. paths that shouldn't be allowed by the SecurityManager? I don't think there's a disclosure here (specifying /etc/passwd for a certificate file doesn't dump /etc/passwd) but there might be opportunities for a JVM crash. - -chris On 7/13/2011 11:33 AM, Mark Thomas wrote: CVE-2011-2526: Apache Tomcat Information disclosure and availability vulnerabilities Severity: low Vendor: The Apache Software Foundation Versions Affected: Tomcat 7.0.0 to 7.0.18 Tomcat 6.0.0 to 6.0.32 Tomcat 5.5.0 to 5.0.33 Previous, unsupported versions may be affected Additionally, these vulnerabilities only occur when all of the following are true: a) untrusted web applications are being used b) the SecurityManager is used to limit the untrusted web applications c) the HTTP NIO or HTTP APR connector is used d) sendfile is enabled for the connector (this is the default) Description: Tomcat provides support for sendfile with the HTTP NIO and HTTP APR connectors. sendfile is used automatically for content served via the DefaultServlet and deployed web applications may use it directly via setting request attributes. These request attributes were not validated. When running under a security manager, this lack of validation allowed a malicious web application to do one or more of the following that would normally be prevented by a security manager: a) return files to users that the security manager should make inaccessible b) terminate (via a crash) the JVM Mitigation: Affected users of all versions can mitigate these vulnerabilities by taking any of the following actions: a) undeploy untrusted web applications b) switch to the HTTP BIO connector (which does not support sendfile) c) disable sendfile be setting useSendfile=false on the connector d) apply the patch(es) listed on the Tomcat security pages (see references) e) upgrade to a version where the vulnerabilities have been fixed Tomcat 7.0.x users may upgrade to 7.0.19 or later once released Tomcat 6.0.x users may upgrade to 6.0.33 or later once released Tomcat 5.5.x users may upgrade to 5.5.34 or later once released Example: Exposing the first 1000 bytes of /etc/passwd HttpServletRequest.setAttribute( org.apache.tomcat.sendfile.filename,/etc/passwd); HttpServletRequest.setAttribute( org.apache.tomcat.sendfile.start,Long.valueOf(0)); HttpServletRequest.setAttribute( org.apache.tomcat.sendfile.end,Long.valueOf(1000)); Specifying a end point after the end of the file will trigger a JVM crash with the HTTP APR connector and an infinite loop with the HTTP NIO connector. Credit: These issues were identified by the Tomcat security team. References: http://tomcat.apache.org/security.html http://tomcat.apache.org/security-7.html http://tomcat.apache.org/security-6.html http://tomcat.apache.org/security-5.html The Apache Tomcat Security Team - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4dxHoACgkQ9CaO5/Lv0PDykgCeNvC61SVMsawzVre/6ZxvR/+2 tvoAnRyoZQd14OJSo7+ExfWKSMnBTRex =jpLx -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Casual proposal for change to WebappClassLoader.clearReferencesThreads
All, Is there any interest in having a configuration option for WCL that allows certain thread names to be ignored during webapp shutdown? See http://markmail.org/message/vqeeyosbqxq3tim6 for a short discussion. It appears that there may sometimes be a race condition where the webapp can't force the termination of an app-started thread that *will* eventually shut down. A minor change could alleviate printing a warning message on redeploy that may worry admins. I'm sure this would be useful to Terence, but I'm not sure if there's wide applicability. Any thoughts? -chris signature.asc Description: OpenPGP digital signature
Re: Casual proposal for change to WebappClassLoader.clearReferencesThreads
Pid, On 7/14/2011 11:25 AM, Pid wrote: On 14/07/2011 16:11, Pid wrote: On 14/07/2011 15:23, Christopher Schultz wrote: All, Is there any interest in having a configuration option for WCL that allows certain thread names to be ignored during webapp shutdown? See http://markmail.org/message/vqeeyosbqxq3tim6 for a short discussion. It appears that there may sometimes be a race condition where the webapp can't force the termination of an app-started thread that *will* eventually shut down. A minor change could alleviate printing a warning message on redeploy that may worry admins. I'm sure this would be useful to Terence, but I'm not sure if there's wide applicability. Why does this help? AFAICS he's not stopped the thread, he's just stopped the scheduler. If he wants the thread to stop he'll have to hit .cancel() on the task. Actually, that might not be true. (Teach me to skim the docs). The OP is really reporting that the timer.cancel() method doesn't block wait for all the running timer task threads to finish. He's properly shutting-down the task scheduling service and all the tasks finish before his code continues. The problem is a race condition between the termination of the worker threads and the thread-checking code in Tomcat. Interrupting a timer task thread might not be possible without jumping through hoops; the OP reports that if the run method is empty, there's no problem - but this would be expected because the run() cycle would be short therefore the timer task thread will win the race between contextDestroyed completing the thread finishing. I thought he said that, with an empty run method, he still needs to call sleep() in order to avoid the race condition. If the thread takes longer (the OP reports ~0.5s) then contextDestroyed() wins and Tomcat reports threads down. Quartz suffers from the same problem (or did last time I looked). The problem is that the OP can't get ahold of the Thread objects themselves in order to do a join() on them. All tasks are cancelled, successfully. His hands are tied by the API. I'm trying to avoid the following progression: 1. TaskScheduler has a race condition, triggers a false alarm in Tomcat 2. IT staff, etc. are directed to ignore Tomcat warnings about threads 3. Tomcat starts reporting legitimate thread problems 4. Everyone ignores them because they have been directed to do so My proposal is to be able to identify which threads have been determined to be non-threatening, and suppress the warning. -chris signature.asc Description: OpenPGP digital signature
Re: tagging tc-native 1.1.21
Jean-Frederic, On 7/25/2011 6:06 AM, jean-frederic clere wrote: On 07/25/2011 11:21 AM, Henri Gomez wrote: nope, let's go for release. BTW, what's the main changes ? Just bug fixes. I will update the changelog now. Nope, it also includes the native part of FIPS mode. I forgot to update the changelog when I did that commit. Now updated. Note that the new FIPS code isn't called by anything on the Java side at this point. I'm still working on the Java portion of this, so the presence of this new code shouldn't impact anything. -chris signature.asc Description: OpenPGP digital signature
Re: tagging tc-native 1.1.21
Mladen, On 7/25/2011 3:16 PM, Mladen Turk wrote: On 07/25/2011 07:31 PM, Christopher Schultz wrote: Jean-Frederic, Nope, it also includes the native part of FIPS mode. I forgot to update the changelog when I did that commit. Now updated. Note that the new FIPS code isn't called by anything on the Java side at this point. I'm still working on the Java portion of this, so the presence of this new code shouldn't impact anything. Think you have that inside trunk. This release is from branches/1.1.x Oh, I didn't realize that the trunk wasn't the tip of the 1.1 branch. What is the policy for merging things like this into the 1.1 branch? Just get 3 votes to put it in there? I'll happily do that if we can get this code into tcnative sooner rather than later -- I'd like the feature in Tomcat to land after it's available in tcnative so we don't have to say yeah, that feature is there, but you can't use it until the next tcnative release. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Servlet 3.1, Tomcat 8 etc.
Mark, On 7/26/2011 1:30 PM, Mark Thomas wrote: The Servlet EG is starting to discuss changes to the Servlet API for 3.1. It would be useful if the option existed to implement some of these changes in Tomcat trunk. The benefits of this are: - we can see how feasible the API changes are to implement - users can try out the new APIs (assuming we do a Tomcat 8 alpha release) How much of this stuff could reasonably be built-into Tomcat 7 without breaking anything? I ask because Tomcat will have to be backward-compatible with earlier versions of the spec, anyway, so is there a real danger to adding to trunk and continuing to release 7.0.x versions from it? Assuming that there are no objections to that plan, that leads to a couple of other questions. 1. Should tomcat/tc7.0.x/trunk be RTC or CTR? If development will stay almost entirely within trunk, I would say RTC, but I'm not sure all development should be separated from the 7.0 branch (see above). 2. With tomcat/trunk becoming the basis for Tomcat 8, I would like to see earlier and more frequent alpha/beta releases than we had for Tomcat 7. That would increase the effective number of versions we are supporting. With that in mind, should we announce end of support for 5.5.x with the last release expected in ~12 months time? +1 to announcing end of support for 5.5 in the first half of 2012. -chris signature.asc Description: OpenPGP digital signature
Re: Servlet 3.1, Tomcat 8 etc.
Mark, On 8/1/2011 2:58 PM, Mark Thomas wrote: On 01/08/2011 19:32, Christopher Schultz wrote: Mark, On 8/1/2011 12:05 PM, Mark Thomas wrote: On 01/08/2011 16:45, Christopher Schultz wrote: Mark, On 7/26/2011 1:30 PM, Mark Thomas wrote: The Servlet EG is starting to discuss changes to the Servlet API for 3.1. It would be useful if the option existed to implement some of these changes in Tomcat trunk. The benefits of this are: - we can see how feasible the API changes are to implement - users can try out the new APIs (assuming we do a Tomcat 8 alpha release) How much of this stuff could reasonably be built-into Tomcat 7 without breaking anything? None. The TCK will fail as soon as any changes are made to the API. Ooh, so until the TCK is updated to tolerate Servlet 3.1, we will be unable to run TCK tests against trunk. That seems ... non-ideal. We won't get the TCK until after the spec has gone final. As an EG member I should have access to it before then but I am new to this so we'll have to wait and see. I guess what I meant was that we wouldn't even be able to run Servlet 3.0 TCK against our TC8 trunk because it would always fail. That means not being able to test the trunk against anything but our own unit tests for quite a while, which is unfortunate. So, the TCK will bomb if we implement extra methods in, say, HttpServletRequest? Since containers are supposed to adjust behavior depending upon the version string used in the deployment descriptor, I had hoped that the TCK would be sensitive to that kind of thing. -chris signature.asc Description: OpenPGP digital signature
Re: tagging tc-native 1.1.21
Rainer and Mladen, On 8/1/2011 4:52 PM, Mladen Turk wrote: On 08/01/2011 09:23 PM, Rainer Jung wrote: On 01.08.2011 16:50, Christopher Schultz wrote: Oh, I didn't realize that the trunk wasn't the tip of the 1.1 branch. AFAIK tcnative 1.1.x is still CTR. Yep CTR, the split was made merely to allow trunk to use the new pollset interrupt APR logic which will of course require an apr 1.4.x as mandatory and break ABI compatibility thus requiring the minor version bump. Thanks for clarification. Committed new FIPS function to 1.1.x branch. -chris signature.asc Description: OpenPGP digital signature
Re: ServletRequestListener.requestDestroyed is called before request leaves a webapp
Mark, On 8/9/2011 4:35 PM, Mark Thomas wrote: Addressing this would mean either: a) moving the error handling to the context (inside the calls to the ServletRequestListener) or +1 This just feels like the right state management level to me. Certainly the default error handler can be called just as easily from this level of the code. -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1157151 - in /tomcat/trunk/java/org/apache/coyote/http11: AbstractInputBuffer.java InternalInputBuffer.java
Mark,
On 8/12/2011 11:17 AM, ma...@apache.org wrote:
+@Override
+public void recycle() {
+super.recycle();
+inputStream = null;
+}
If inputStream != null, should it be close()d? Or is this a shared
reference for which that kind of thing isn't appropriate? Or do we just
let the GC take care of that?
-chris
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r1159673 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java webapps/docs/changelog.xml webapps/docs/config/listeners.xml
Konstantin,
On 8/19/2011 12:34 PM, Konstantin Kolinko wrote:
2011/8/19 schu...@apache.org:
+private boolean awtThreadProtection = false;
+public boolean isAWTThreadProtection() { return awtThreadProtection; }
+public void setAWTThreadProtection(boolean awtThreadProtection) {
+ this.awtThreadProtection = awtThreadProtection;
+}
+ attribute name=awtThreadProtection required=false
Looking at the getter and setter methods, I think the actual name of
the property is AWTThread I have not tried it though.
You're right. Stupid copy/paste.
Wouldn't you forget to apply the same change to trunk (aka Tomcat 8)?
I wasn't sure what was up in the trunk... the changelog is completely
blank. This can't be the first commit to the trunk. Maybe there's no use
in updating the changelog before the first release?
-chris
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r1159673 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java webapps/docs/changelog.xml webapps/docs/config/listeners.xml
Konstantin, On 8/19/2011 3:11 PM, Konstantin Kolinko wrote: Mark cleared the changelog file after creating the branch. The idea is that * work is done on trunk * it is merged to tc7.0.x * items merged to tc7.0.x go into TC7's changelog file and those that won't be merged go into TC8's changelog. There is a comment at the top of trunk's changelog.xml: (...) Until the first Tomcat 8.0.0 release, only changes not back-ported to 7.0.x should be listed here. -- Thanks for the clarification. I'll go ahead and forward-port the patch to trunk. -chris signature.asc Description: OpenPGP digital signature
Re: / on end of context paths breaking existing apps
Tim, On 8/21/2011 5:49 PM, Tim Whittington wrote: The change in [1] has broken existing behaviour in some applications. To echo some of Mark's comments: Consider the following situation: - An application is context path /application - The application has a servlet mapped to /* So, the only valid URIs should be of the form /application/*. Note the / before the *. If you could map something to, say, * (no leading slash), then maybe this could be considered a bug, but since the simplest possible valid URI that maps to your webapp is actually /application/, I don't think it's a bug. Now, it may be interfering with your webapp's operation, but that's a different story. :) This seems wrong - we're considering a path as being part of a context, but establishing a session that will not include that path (for some browsers at least). Who is we, here? The URI path /application is the context path, but not a valid URI within that context. To get a valid URI, you need to add something that starts with a /. This notably makes Cookie based session tracking inconsistent with URL rewriting. Does it? How? What part of your webapp chokes when cookies are received with a path prefix of /application/ instead of /application? -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1159673 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java webapps/docs/changelog.xml webapps/docs/config/listeners.xml
Mark, On 8/23/2011 3:53 PM, Mark Thomas wrote: On 21/08/2011 01:44, Christopher Schultz wrote: Konstantin, On 8/19/2011 3:11 PM, Konstantin Kolinko wrote: Mark cleared the changelog file after creating the branch. The idea is that * work is done on trunk * it is merged to tc7.0.x * items merged to tc7.0.x go into TC7's changelog file and those that won't be merged go into TC8's changelog. There is a comment at the top of trunk's changelog.xml: (...) Until the first Tomcat 8.0.0 release, only changes not back-ported to 7.0.x should be listed here. -- Thanks for the clarification. I'll go ahead and forward-port the patch to trunk. Did this happen? Sorry, it did not happen yet. I will do it in the next few hours unless someone has beaten me to it. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: DO NOT REPLY [Bug 51580] Severe error deploying WAR application (ExpandWar error)
Konstantin, On 8/25/2011 10:08 AM, Konstantin Kolinko wrote: 1. You have a typo in LC_CTYPE command above, s/8851/8859/ Thanks, I'll check that. 2. It might be that it reads the characters correctly, but fails to print them. If it were reading UTF-8 characters as ISO-8859-1, wouldn't there be several '?'s, one for each byte? Yeah, it might be a problem printing to the terminal rather than reading from the archive. -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1161566 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java webapps/docs/config/listeners.xml
Konstantin, On 8/25/2011 10:14 AM, Konstantin Kolinko wrote: Documentation part of this commit is wrong. You added attribute to a wrong listener. (rmiServerPortPlatform ...) Ugh. Thanks for the catch. Fixed. -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1161601 - /tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Konstantin, On 8/25/2011 11:18 AM, kkoli...@apache.org wrote: Add changelog record for r1161566 Thanks for cleaning-up after me. I spent a bunch of time this morning trying to forward-port my fix before I realized that it had already been done. Patch isn't smart enough to say duh, that change has already been made. In my frustration, I forgot that the back-port needed a changelog entry as well. I'll try to be more careful in the future, and commit things in the right order :) -chris signature.asc Description: OpenPGP digital signature
Re: Possible bug in Tomcat Date header handling
Mark and Mick, On 8/26/2011 11:45 AM, Mark Thomas wrote: The fix is to address the root cause which appears to be a poorly configured system clock. I am loath to add a work-around at any point in the Tomcat source code to handle time apparently going backwards rather than forwards. +1 This is not something that should happen on a stable server. DST adjustments will not cause Tomcat to report the same Date header for an hour (or whatever it is in your time zone) after DST rolls back. -chris signature.asc Description: OpenPGP digital signature
Mitigating AJP CPing/Forward-Request packet forgery before next releases
All, https://issues.apache.org/bugzilla/show_bug.cgi?id=51698 Mark's official report to the users' list indicates that setting a secret for the AJP connection does the trick. (I tried this myself before digging-up his message and can confirm that the sample code fails when a secret is set). Should we mention this on the Security page directly for those who didn't read the announcement on the users' list? Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Mitigating AJP CPing/Forward-Request packet forgery before next releases
Mark, On 9/8/2011 11:47 AM, Mark Thomas wrote: On 08/09/2011 16:13, Christopher Schultz wrote: All, https://issues.apache.org/bugzilla/show_bug.cgi?id=51698 Mark's official report to the users' list indicates that setting a secret for the AJP connection does the trick. (I tried this myself before digging-up his message and can confirm that the sample code fails when a secret is set). Should we mention this on the Security page directly for those who didn't read the announcement on the users' list? No reason why not. Go for it. Okay. Any idea if mod_proxy_ajp supports the shared secret? The documentation is so light on actually using mod_proxy_ajp that it might be supported (ProxyPass /foo ajp://bar secret=changeit?) but completely undocumented in the httpd documentation. This is all I could find: http://www.google.com/url?sa=tsource=webcd=1ved=0CBcQFjAAurl=http%3A%2F%2Fwww.gossamer-threads.com%2Flists%2Fapache%2Fdev%2F332363rct=jq=mod_proxy_ajp%20secretei=fCFpTtWRAuPL0QGUo-CDDAusg=AFQjCNHOT2d5i5zlmL06G4eoMG5skYTkVwcad=rja Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Mitigating AJP CPing/Forward-Request packet forgery before next releases
Mark, On 9/8/2011 11:47 AM, Mark Thomas wrote: On 08/09/2011 16:13, Christopher Schultz wrote: Should we mention this on the Security page directly for those who didn't read the announcement on the users' list? No reason why not. Go for it. Also, security-5.html says that Tomcat 5.0.0 - 5.0.33 are affected. It should probably be 5.5.0-5.5.30, right? -chris signature.asc Description: OpenPGP digital signature
Re: Mitigating AJP CPing/Forward-Request packet forgery before next releases
JF, On 9/9/2011 7:02 AM, jean-frederic clere wrote: Yep. We need a directive to set the secret in httpd, I will discuss that in httpd dev list. Thanks for the confirmation. -chris signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Apache Tomcat 7.0.22
Mark, On 9/27/2011 5:36 PM, Mark Thomas wrote: The proposed Apache Tomcat 7.0.22 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.22/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_22/ The proposed 7.0.21 release is: [ ] Broken - do not release [ ] Beta - go ahead and release as 7.0.22 Beta [X] Stable - go ahead and release as 7.0.22 Stable + MD5 sums match. - GPG verifies with a key that Mark appears to use for nothing else, no key signers :( + Source builds properly + All unit tests pass + Javadoc builds with no complaints + Works with casual testing of my own webapps -chris signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Apache Tomcat 7.0.22
Mark, On 9/29/2011 8:09 AM, Mark Thomas wrote: On 28/09/2011 14:43, Christopher Schultz wrote: Mark, On 9/27/2011 5:36 PM, Mark Thomas wrote: The proposed Apache Tomcat 7.0.22 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.22/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_22/ The proposed 7.0.21 release is: [ ] Broken - do not release [ ] Beta - go ahead and release as 7.0.22 Beta [X] Stable - go ahead and release as 7.0.22 Stable + MD5 sums match. - GPG verifies with a key that Mark appears to use for nothing else, no key signers :( Huh? $ gpg --verify catalina-jmx-remote.jar.asc catalina-jmx-remote.jar gpg: Signature made Tue 27 Sep 16:47:07 2011 EDT using RSA key ID 2F6059E7 gpg: Good signature from Mark E D Thomas ma...@apache.org Running --verify wasn't the problem (it verifies). I was talking about other people signing your GPG key. It was also distinct from the other key I had for you (0x33C60243) so I wasn't sure why there were two. Some ASF folks have two, one clearly marked (CODE SIGNING KEY)... it just appears you haven't done the same. Weird... I got no signers when I first obtained your key. Updating the key shows 28 signatures so maybe I was on crack at the time. Or now. http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x10C01C5A2F6059E7 That key is very firmly in the ASF web of trust. It is also in the KEYS file. Yup, all is well. -chris signature.asc Description: OpenPGP digital signature
Release Testing
All, I was thinking about the tests that various folks (Konstantin, Mladen, Rainer, etc.) perform and I was wondering if it might be a good idea for everyone to share their techniques for testing that could be automated. For example, contributing some scripts, etc. to a meta-test framework for things like gpg signature tests, md5 sum tests, checks for ASF references in source files, etc. It's possible that some of those tests may fail in certain environments (e.g. coming from svn instead of downloading the tarball you post) but not in others. I would volunteer to assemble everything into a sort of test suite that we could put into svn and have everyone run against their own local copies in whatever environment they have. It would obviously include things like ant test but also whatever automated checks folks have hand-rolled as they have been testing release candidate builds. Anyone who is interested, go ahead and reply to this thread and attach whatever scripts you already have, or even ideas for things that /could/ be automated but you haven't actually done, yet. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Make the InetAddress object available via ServletRequest?
Francis, On 10/9/2011 10:57 AM, Francis Galiegue wrote: I have my CIDR matching valve/filter ready (still struggling to write unit tests, but it works in real-world situations), and there is something I find quite unoptimized: you have getRemoteHost() and getRemoteAddr() to get the remote host name and IP addresses as strings, but why can't you get hold of the InetAddress object directly? Aside from Mark's excellent response, there are ways to modify or mask the IP or host name of the remote host, and creating additional InetAddress objects and possibly performing additional reverse-DNS lookups for such objects would be a waste of time (though they could probably be done lazily). -chris signature.asc Description: OpenPGP digital signature
Re: ApacheMeetupsNa11 tomcat one?
Jean-Frederic, On 10/11/2011 4:04 AM, jean-frederic clere wrote: Do we want to organize a Tomcat meetup during the ApacheCon? +1 I'll be there. Though the content last year was rather thin, it was nice to meet Keiichi there. I'd be happy to have a meet-up at Whistler (local ski resort), too, if anyone is interested. -chris signature.asc Description: OpenPGP digital signature
Write access to LocalBadContent (and other?) page(s) on wiki
All, I removed some spam from a wiki page and I was going to update LocalBadContent with the URLs added to that page as spam (see below), but it doesn't look like I have such access rights. Can I get promoted? My userid is ChristopherSchultz. Thanks, -chris Spam URLs: http://www.buchete.ro http://www.wokaway.ro/meniu http://www.mailin.fr signature.asc Description: OpenPGP digital signature
Re: ApacheMeetupsNa11 tomcat one?
All, On 10/19/2011 3:52 PM, Rainer Jung wrote: On 18.10.2011 10:15, Keiichi Fujino wrote: I am going to stay in Vancouver from Monday to Friday. I'll be there too, including the weekends before and after. I'm arriving at 12:47 local time on Tuesday and I've got nothing to do until the next morning besides check-into the hotel. If anyone is interested in getting together for some drinks or exploring the city (I've never been to Vancouver) on Thursday, email me privately and I'll give you my mobile number. See you all there! -chris signature.asc Description: OpenPGP digital signature
Re: ApacheMeetupsNa11 tomcat one?
All, On 10/20/2011 4:32 PM, Christopher Schultz wrote: I'm arriving at 12:47 local time on Tuesday and I've got nothing to do until the next morning besides check-into the hotel. If anyone is interested in getting together for some drinks or exploring the city (I've never been to Vancouver) on Thursday s/Thursday/Tuesday/ Sorry for the confusion. -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1187916 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
Rainer,
On 10/23/2011 12:19 PM, rj...@apache.org wrote:
+/*
+ * Find the first occurrence of path in uri tokenized by /.
+ * The comparison is done case insensitive.
+ */
+static const char *find_path_in_uri(const char *uri, const char *path)
+{
+size_t len = strlen(path);
+while (uri = strchr(uri, '/')) {
I think // in a URL will cause this loop to exit early, possibly
avoiding this security check.
+uri++;
+if (!strncmp(uri, path, len)
strncmp doesn't use case-insensitive compare: will this ever match if
you use web-inf (as below)?
+(*(uri + len) == '/' ||
+ strlen(uri) == len)) {
+return uri;
+}
+}
+return NULL;
+}
+
static int uri_is_web_inf(const char *uri)
{
-if (stristr(uri, /web-inf)) {
+if (find_path_in_uri(uri, web-inf)) {
return JK_TRUE;
This will return JK_TRUE if web-inf occurs at any place in the path,
not just at the context level. Is that a problem? I can imagine that a
request for /context/foo/WEB-INF/something might be valid.
-chris
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r1187916 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
Rainer,
On 10/23/2011 12:19 PM, rj...@apache.org wrote:
+static const char *find_path_in_uri(const char *uri, const char *path)
+{
+size_t len = strlen(path);
+while (uri = strchr(uri, '/')) {
+uri++;
+if (!strncmp(uri, path, len)
+(*(uri + len) == '/' ||
+ strlen(uri) == len)) {
+return uri;
+}
+}
Also, 'len' is never updated in the loop, so the call to strncmp could
potentially cause a SIGSEGV -- but only in the cases where something
truly nefarious is going on, anyway.
-chris
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r1187916 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
All, On 10/25/2011 2:03 PM, Christopher Schultz wrote: On 10/23/2011 12:19 PM, rj...@apache.org wrote: +if (!strncmp(uri, path, len) strncmp doesn't use case-insensitive compare: will this ever match if you use web-inf (as below)? Duh just saw Konstantin's response. Apologies for the noise. I still think the // might be a problem, though. -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1187916 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
Rainer,
On 10/25/2011 3:37 PM, Rainer Jung wrote:
On 25.10.2011 20:07, Christopher Schultz wrote:
Rainer,
On 10/23/2011 12:19 PM, rj...@apache.org wrote:
+static const char *find_path_in_uri(const char *uri, const char
*path) +{ +size_t len = strlen(path); +while (uri =
strchr(uri, '/')) { +uri++; +if (!strncmp(uri,
path, len) +(*(uri + len) == '/' || +
strlen(uri) == len)) { +return uri; +} +
}
Also, 'len' is never updated in the loop, so the call to strncmp
could potentially cause a SIGSEGV -- but only in the cases where
something truly nefarious is going on, anyway.
Hmmm, I don't get that: path isn't changed, strncmp() will never
compare beyond terminating '0', and uri+len must be inside uri if
length of path is len, and uri and path coincide for len chars.
Yeah, I'm re-thinking my assertion: the code is probably safe.
On the other hand, why bother using strNcmp instead of just strcmp given
that you are trusting 'path' to be clean already. I guess there's no
reason NOT to use strNcmp when you have a choice.
Of course *(uri+len) could be '0', but that's OK.
Also nevermind about the // : strchr returns a pointer, not an index. :(
-chris
signature.asc
Description: OpenPGP digital signature
Tomcat 7, Valve - Filter conversion, and container-managed authentication/authorization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, Hello, I'm Chris Schultz, the maintainer of the securityfilter project (http://securityfilter.sourceforge.net/) and active member of the tomcat-user mailing list. I've been loosely following the plans for Tomcat 7 and was interested to see that there's an effort to convert existing Tomcat Valve components into Filters, I suppose to make them more flexible and also to increase portability. For those unfamiliar with the project, securityfilter is a filter-based implementation of authentication and authorization that aims to comply with the Java Servlet Specification while offering features above and beyond it. Most of our users have abandoned container-managed auth provided by containers such as Tomcat because of missing features (not specified by the servlet spec) such as barge-in logins, customized after-login pages, and customizability that doesn't tie the web application to any specific container. I inherited the existing securitfyilter code base from Max Cooper and I've been trying to improve the compliance with the servlet spec and to ensure support for the more recent versions of the spec (sf is mostly 2.3 compliant, but we're trying to fill-in all the holes). After adding a few features to the 2.x code base, I'm considering a full re-write of the code for a 3.x version that is more flexible than the current implementation. I was thinking that, as Tomcat contemplates a conversion of container-managed auth from a Valve to a Filter, securityfilter could possibly factor-into that conversion. I'd be happy to convert sf into an Apache commons/incubator project and have Tomcat use it for authentication and authorization. Mark Thomas has indicated his interest in discussing this possibility on the development list, so I'm presenting it to the group. I'd be happy to give more details about my current plans for sf, etc. but I figured that if there was significant interest in the Tomcat/ASF communities, we could discuss what feature set ought to be available. Please let me know if the community is interested in adopting securityfilter and, ultimately, using it in Tomcat. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvYdS8ACgkQ9CaO5/Lv0PCRygCgwJ3Sw9g5YRbgHh/RQqLXdzXz 8IwAoJBEk06BovBRtADh9WfAQMx/F2Zp =dcy8 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, Valve - Filter conversion, and container-managed authentication/authorization
David, On 4/28/2010 6:40 PM, David Jencks wrote: I'd be curious how many of the features in securityfilter can be done with servlet 3 (which includes the ability for an app to programatically force a login) and jaspic (jsr 196) which provides for pluggable authentication dialogs between client and server (to overly simplify it). It looks to me as if all the features in your brief description are now supported by ee specs, which also offer the advantages of container managed authorization. I guess my question would be how much of servlet 3 has been implemented in TC7 at this point? sf could be the basis for both the new features required by the spec as well as achieving the internal goal of converting Valves to Filters. -chris signature.asc Description: OpenPGP digital signature
Re: Some general questions about tomcat instead of GlassFish
Pouya, On 6/12/2010 12:14 PM, j jj wrote: Please use a semi-legitimate name when posting to the list: this should be easy to configure in your email reader. Also, there's no need to put underscores_between_your_words_in_the_subject, as this is not some kind of wiki. Would you please tell me that we can use tomcat instead of GlassFish or no?(Yes/No Why?) Deciding between Tomcat and Glassfish is really a matter of application requirements: GlassFish is a full J2EE server, while Tomcat is limited to a Java servlet container/web server. GlassFish actually uses Tomcat internally as its servlet container and web server, and adds features to it. If you only need a servlet container and web server, Tomcat can meet your needs. If you need additional services provided by a J2EE server (EJB, JMX, etc.) then you'll want GlassFish. Which of JSF or Struts is more compatible with tomcat? Both are equally compatible. Please say to me something about maven,Is this a project management table or no ,What is this ? Maven is a build tool. Whether Tomcat has been mavenized shouldn't be relevant if you are developing web applications for deployment onto Tomcat. -chris signature.asc Description: OpenPGP digital signature
Re: ThreadLocal Clear References Problem
Gurkan, On 1/6/2011 7:08 AM, Gurkan Erdogdu wrote: Could you see the problem in https://issues.apache.org/jira/browse/MYFACES-3006? So, you are stopping a second application from the code shown in the bug? Can you post a working example? -chris signature.asc Description: OpenPGP digital signature
Re: ASF test Jira instance now running Tomcat 7.0.6
Mark, On 1/10/2011 1:02 PM, Mark Thomas wrote: Having tagged and built 7.0.6 I have just switched the ASF test Jira instance [1] from 6.0.29 to 7.0.6. A quick smoke test suggests all is OK. Folks will be testing this instance over the next few weeks prior to the migration of the live Jira instance so if there are any issues we should find them soon. Assuming all goes well, post migration the live Jira instance will run 7.0.6 and will continue to run 7.0.latest. If you have a spare 5 minutes try out the test Jira instance. If you find something that is broken, please let the infrastructure team know. I played with it a bit yesterday and all seemed well (except for all the things about JIRA that I don't like). Please tell me Tomcat bug tracking is staying on Bugzilla for the foreseeable future. -chris signature.asc Description: OpenPGP digital signature
Re: Deploying new Applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie, Technically speaking, this is a discussion best left to the user list. I'm cross-posting. Please consider subscribing to the user list and continuing the discussion there. On 1/13/2011 7:27 AM, Jamie wrote: This works, but is not persistent. i.e. when tomcat is restarted the display name is taken from the context.xml file. Is there any way for Tomcat to set a persistent display name? There have been some discussions about having the manager webapp persist changes to files so they stick across Tomcat restarts. You may want to re-post on the user list with a better subject line to see if you can help with those (slow-going, as I understand) efforts. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vLLgACgkQ9CaO5/Lv0PDYCwCgpWVsZ2Xt9VfNPI33bY3jkNXr voIAn1Za8uVJMsge8HwE6HTub+VEIr7f =7+G5 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Access log changes in 7.0.6
Mark, On 1/14/2011 9:40 AM, Mark Thomas wrote: c) Refactor the access logging. I don't have a clear picture of what this might look like but I am thinking along the lines of: - log to JULI rather than manage files in the access log -1 I think access logging is something where all configuration should take place at the Valve level: forcing users to configure JULI will cause mass hysteria. -chris signature.asc Description: OpenPGP digital signature
Tomcat 7.0.x. still CTR?
All, Since Tomcat 7.0.x went stable, does that change the commit policy, or are we still doing commit-them-review? Thanks, -chris signature.asc Description: OpenPGP digital signature
Current TC 7.0.x/trunk fails to build release
All,
$ svn up
At revision 1061823.
$ ant release
[]
logkit-warning:
[echo]
[echo] *** WARNING ***
[echo] LogKit not found: Cannot Build LogKitLogger
[echo]
jdk1.4-warning:
avalon-framework-warning:
[echo]
[echo] *** WARNING ***
[echo] Avalon-Framework not found: Cannot Build AvalonLogger
[echo]
compile-non-log4j:
[javac]
/home/cschultz/projects/non-chadis/apache-tomcat-7.0.x/trunk/output/extras/logging/commons-logging-1.1.1-src/build2.xml:359:
warning: 'includeantruntime' was not set, defaulting to
build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 11 source files to
/home/cschultz/projects/non-chadis/apache-tomcat-7.0.x/trunk/output/extras/logging/commons-logging-1.1.1-src/target/classes
[javac]
/home/cschultz/projects/non-chadis/apache-tomcat-7.0.x/trunk/output/extras/logging/commons-logging-1.1.1-src/src/java/org/apache/juli/logging/impl/ServletContextCleaner.java:24:
package javax.servlet does not exist
[javac] import javax.servlet.ServletContextEvent;
[javac] ^
[javac]
/home/cschultz/projects/non-chadis/apache-tomcat-7.0.x/trunk/output/extras/logging/commons-logging-1.1.1-src/src/java/org/apache/juli/logging/impl/ServletContextCleaner.java:25:
package javax.servlet does not exist
[javac] import javax.servlet.ServletContextListener;
[javac] ^
[javac]
/home/cschultz/projects/non-chadis/apache-tomcat-7.0.x/trunk/output/extras/logging/commons-logging-1.1.1-src/src/java/org/apache/juli/logging/impl/ServletContextCleaner.java:52:
cannot find symbol
[javac] symbol: class ServletContextListener
[javac] public class ServletContextCleaner implements
ServletContextListener {
[javac] ^
[javac]
/home/cschultz/projects/non-chadis/apache-tomcat-7.0.x/trunk/output/extras/logging/commons-logging-1.1.1-src/src/java/org/apache/juli/logging/impl/ServletContextCleaner.java:61:
cannot find symbol
[javac] symbol : class ServletContextEvent
[javac] location: class
org.apache.juli.logging.impl.ServletContextCleaner
[javac] public void contextDestroyed(ServletContextEvent sce) {
[javac] ^
[javac]
/home/cschultz/projects/non-chadis/apache-tomcat-7.0.x/trunk/output/extras/logging/commons-logging-1.1.1-src/src/java/org/apache/juli/logging/impl/ServletContextCleaner.java:135:
cannot find symbol
[javac] symbol : class ServletContextEvent
[javac] location: class
org.apache.juli.logging.impl.ServletContextCleaner
[javac] public void contextInitialized(ServletContextEvent sce) {
[javac]^
[javac] 5 errors
Is this an environmental problem I have, or is the build really broken?
Thanks,
-chris
signature.asc
Description: OpenPGP digital signature
Re: Current TC 7.0.x/trunk fails to build release
Konstantin, On 1/21/2011 9:47 AM, Konstantin Kolinko wrote: 2011/1/21 Christopher Schultz ch...@christopherschultz.net: $ ant release What is your ant version? 1.8.x is needed. $ ant -version Apache Ant version 1.8.1 compiled on April 30 2010 Buildbot runs ant release repeatedly, and it succeeds Hmm. I'll re-check everything. -chris signature.asc Description: OpenPGP digital signature
Re: bug in TC6 ContainerBase class?
Chuck, On 1/21/2011 10:02 AM, Caldarale, Charles R wrote: From: sebb [mailto:seb...@gmail.com] Subject: Re: bug in TC6 ContainerBase class? There is no requirement for the compiler to reload variables unless the variable is volatile, or there is a shared lock between threads. Correct - with one caveat: if the compiler cannot prove there is no synchronization, it must assume that there is. Also, the method calls can have side effects not discernible by the compiler, including updating of fields not specified in the argument list. Are you saying that effectively most method calls have pre- and post- memory barriers? -chris signature.asc Description: OpenPGP digital signature
Proposal: set default for Connector.allowCasualMultipartParsing to true
All, I've just committed a fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=49711 (HttpServletRequest#getParts() does not work in a Filter) with a new configuration attribute on the Connector called allowCasualMultipartParsing whose default value is false. Please see BZ for details. I propose to make the default for this setting true unless STRICT_SERVLET_COMPLIANCE is set to TRUE. Any comments? -chris signature.asc Description: OpenPGP digital signature
Privileges in Bugzilla
All, I typically use my home email address instead of my @apache.org for everything, including BZ. I don't currently have rights to do things like assign bugs to myself, etc. Can that be done? Or, should I start using my @apache.org email address to do that sort of thing? Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1061929 - in /tomcat/trunk: java/org/apache/catalina/ant/ java/org/apache/catalina/connector/ java/org/apache/tomcat/util/net/ test/org/apache/catalina/connector/ webapps/docs/ webapp
All,
Oops. I over-committed files. Evidently, svn commit doesn't work like
cvs commit.
I'll back-out my changes to:
tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Sorry for the noise.
Thanks,
-chris
On 1/21/2011 12:46 PM, schu...@apache.org wrote:
Author: schultz
Date: Fri Jan 21 17:46:03 2011
New Revision: 1061929
URL: http://svn.apache.org/viewvc?rev=1061929view=rev
Log:
Fixed bug #49711: HttpServletRequest#getParts() does not work in a Filter
- Added Connector attribute allowCasualMultipartParsing (default false)
- Requests that contain multipart/form-data will be parsed in the absence of
@MultipartConfig when the above attribute is set to true
Modified:
tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java
tomcat/trunk/java/org/apache/catalina/connector/Connector.java
tomcat/trunk/java/org/apache/catalina/connector/Request.java
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/trunk/test/org/apache/catalina/connector/TestRequest.java
tomcat/trunk/webapps/docs/changelog.xml
tomcat/trunk/webapps/docs/config/ajp.xml
tomcat/trunk/webapps/docs/config/http.xml
Modified: tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java?rev=1061929r1=1061928r2=1061929view=diff
==
--- tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/ant/AbstractCatalinaTask.java Fri
Jan 21 17:46:03 2011
@@ -170,6 +170,7 @@ public abstract class AbstractCatalinaTa
URLConnection conn = null;
InputStreamReader reader = null;
try {
+openRedirector();
// Create a connection for this command
conn = (new URL(url + command)).openConnection();
Modified: tomcat/trunk/java/org/apache/catalina/connector/Connector.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Connector.java?rev=1061929r1=1061928r2=1061929view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Connector.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Connector.java Fri Jan 21
17:46:03 2011
@@ -246,6 +246,13 @@ public class Connector extends Lifecycle
*/
protected boolean useBodyEncodingForURI = false;
+
+/**
+ * Allow multipart/form-data requests to be parsed even when the
+ * target servlet doesn't specify @MultipartConfig or have a
+ * lt;multipart-configgt; element.
+ */
+protected boolean allowCasualMultipartParsing = false;
protected static HashMapString,String replacements =
new HashMapString,String();
@@ -767,6 +774,32 @@ public class Connector extends Lifecycle
}
+/**
+ * Set to codetrue/code to allow requests mapped to servlets that
+ * do not explicitly declare @MultipartConfig or have
+ * lt;multipart-configgt; specified in web.xml to parse
+ * multipart/form-data requests.
+ *
+ * @param allowCasualMultipartParsing codetrue/code to allow such
+ *casual parsing, codefalse/code otherwise.
+ */
+public void setAllowCasualMultipartParsing(boolean
allowCasualMultipartParsing)
+{
+this.allowCasualMultipartParsing = allowCasualMultipartParsing;
+}
+
+/**
+ * Returns codetrue/code if requests mapped to servlets without
+ * multipart config to parse multipart/form-data requests anyway.
+ *
+ * @return codetrue/code if requests mapped to servlets without
+ *multipart config to parse multipart/form-data requests,
+ *codefalse/code otherwise.
+ */
+protected boolean getAllowCasualMultipartParsing()
+{
+return this.allowCasualMultipartParsing;
+}
/**
* Indicates whether the generation of an X-Powered-By response header
for
Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=1061929r1=1061928r2=1061929view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Fri Jan 21
17:46:03 2011
@@ -2537,7 +2537,7 @@ public class Request
return parts;
}
-
+
private void parseParts() {
// Return immediately if the parts have already been parsed
@@ -2545,13 +2545,22 @@ public class Request
return;
Re: Privileges in Bugzilla
Mark, On 1/21/2011 1:02 PM, Mark Thomas wrote: On 21/01/2011 17:53, Christopher Schultz wrote: All, I typically use my home email address instead of my @apache.org for everything, including BZ. I don't currently have rights to do things like assign bugs to myself, etc. Can that be done? Or, should I start using my @apache.org email address to do that sort of thing? Bug assignment in Bugzilla is disabled since it stops update messages being sent to the dev list when a change is made. Gotcha. Comments for everything, then :) -chris signature.asc Description: OpenPGP digital signature
Re: Proposal: set default for Connector.allowCasualMultipartParsing to true
Konstantin, On 1/21/2011 12:57 PM, Konstantin Kolinko wrote: 2011/1/21 Christopher Schultz ch...@christopherschultz.net: All, I've just committed a fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=49711 (HttpServletRequest#getParts() does not work in a Filter) with a new configuration attribute on the Connector called allowCasualMultipartParsing whose default value is false. Please see BZ for details. I propose to make the default for this setting true unless STRICT_SERVLET_COMPLIANCE is set to TRUE. Any comments? Why is it on Connector? Won't it be better to have it on Context? Hmm... I guess I didn't even think about that. I can certainly move it there, since you're right: it has nothing really to do with the connector. What about it's default setting? -chris signature.asc Description: OpenPGP digital signature
Re: tagging 6.0.31
Jean-Frederic, On 1/22/2011 4:53 AM, jean-frederic clere wrote: Due the regression in NIO we need a release, I plan to tag on Monday afternoon my time, comments? +1 Fixing NIO is a big deal. :) -chris signature.asc Description: OpenPGP digital signature
Re: RemoteIpValve advices
Mark and Henri, On 1/26/2011 4:09 AM, Mark Thomas wrote: On 25/01/2011 23:31, Henri Gomez wrote: FYI, it's the kind of valve required by a Tomcat behind Amazon AWS Load Balancer. I'll detail more later but the current ForwardedValve only handle remote (browser) information and not the local (server) address. More details would be good. I don't see the use case for this at the moment. FWIW, Paul Fremantle gave a talk at ApacheCon NA this year where he demonstrated Tomcat running behind AWSLB. I'm sure they have figured out what changes are necessary to Tomcat to get it running in that environment. Perhaps he's got some code he would be willing to share. Or, perhaps he's not thought if this and would love to hear about this discussion. -chris signature.asc Description: OpenPGP digital signature
Regarding c:forEach and memory usage
All, Today's (duplicate) bug report about held references in JSTL tags has me thinking. What is the resistance to fixing the problem of object retention in these tags? JSP 1.8.2 says that all page-scoped objects are released after the response is written or the request is forwarded to another handler. Doesn't that mean that something like this: c:set var=foos / c:forEach var=foos items=$foos ... /c:forEach will violate the spec by holding-on to the foos list indefinitely instead of flushing it after the response has been sent? I mean, I certainly understand the complaints being filed in BZ because, hey, the tags are holding onto these references and potentially eating up lots of memory. On the other hand, what's the resistance on the Tomcat side to fixing this? I can think of a couple of reasons: 1. This is a spec-compliance issue and the stance of the Tomcat team is that releasing these references violates the spec, and so it won't be done. 2. It's easy to disable tag pooling via configuration, which has the same effect as nulling all the data in these tag handlers. Since it's easy to disable tag pooling, there is no need to modify anything. 3. Nobody feels like writing a patch. I'd love to hear some comments. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Tomcat, OpenSSL and FIPS
Chris, On 1/27/2011 3:54 PM, Chris Beckey wrote: Chris, To set some context, I posted on the tomcat users list serve a question about running OpenSSL in FIPS mode under Tomcat. The last communication was that you may investigate an enhancement. Since then, one of my co-workers took on the C coding side and I took on the Java side. I believe that we have it running now but I still have testing to complete before I'd call it stable As you may know the FIPS compliant version of OpenSSL is not the current version. What we have running is: Tomcat V 6.0.20 OpenSSL FIPS module V 1.2.2 Open SSL V 0.9.6q tcnative V 1.1.20 APR V 1.4.2 I have found that the versions used are critical, these were the newest versions of the libraries I could get to work together, with the exception of Tomcat itself. Usage of 6.0.20 is simply because that is what our application is to be released on. Anyway, the point of this email is to inquire whether you would like the code for integration back into the code base? I also have a fairly detailed list of steps used to do the build(s). Absolutely! Please post patches to the existing bugzilla entry and they will be reviewed by the team. In the future, it would be better to post this kind of thing to the tomcat-dev mailing list (cc'd here). Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Tomcat, OpenSSL and FIPS
William, On 1/31/2011 1:57 PM, William A. Rowe Jr. wrote: On 1/30/2011 8:20 AM, Christopher Schultz wrote: Chris, On 1/27/2011 3:54 PM, Chris Beckey wrote: Chris, To set some context, I posted on the tomcat users list serve a question about running OpenSSL in FIPS mode under Tomcat. The last communication was that you may investigate an enhancement. Since then, one of my co-workers took on the C coding side and I took on the Java side. I believe that we have it running now but I still have testing to complete before I'd call it stable As you may know the FIPS compliant version of OpenSSL is not the current version. What we have running is: Tomcat V 6.0.20 OpenSSL FIPS module V 1.2.2 Open SSL V 0.9.6q tcnative V 1.1.20 APR V 1.4.2 I have found that the versions used are critical, these were the newest versions of the libraries I could get to work together, with the exception of Tomcat itself. Usage of 6.0.20 is simply because that is what our application is to be released on. Anyway, the point of this email is to inquire whether you would like the code for integration back into the code base? I also have a fairly detailed list of steps used to do the build(s). Note this isn't enough, if you did not call FIPS_mode_set(), you aren't running FIPS validated code. I'm pretty sure he's calling it: In the past, I asked if simply using FIPS-approved ciphers were sufficient and he said no. This is why there is a patch coming hopefully in the near future. Note that (the other) Chris is probably not subscribed to the list. Feel free to watch this bug for updates: https://issues.apache.org/bugzilla/show_bug.cgi?id=50570 The nice way to do this would be to enhance tcnative to accept a global config value (not connector-by-connector) to trigger the FIPS_mode_set() at startup, and ensure there is enough error reporting back to the tomcat initialization code to inform the user of the reason for failure, when and if that call is rejected. That's pretty much what will be required, since FIPS mode appears to be per process and cannot be set per socket. -chris signature.asc Description: OpenPGP digital signature
Re: Tomcat, OpenSSL and FIPS
Chris, On 1/31/2011 5:09 PM, Chris Beckey wrote: I just zip'd together the source and attached it to the bug report. The changes are in: [...] Thanks for the ZIP and (hopefully) the forthcoming patches. Would you be willing to join the Tomcat dev list for further discussions (just let me know if you're already on there)? I've got OpenSSL built in FIPS mode, so I should be able to play with it, now. Thanks, -chris signature.asc Description: OpenPGP digital signature
Potential improvements to JspC
All, I'm working on getting JspC to create a .jar file that contains all the compiled JSPs as well as a META-INF/web-fragment.xml file for easy drop into a webapp with no WEB-INF/web.xml modifications in a 3.0-spec webapp. At this point, I have it working with a simple patch to LocalStrings.properties and a set of 3 new ant targets. Here's the problem: it has some environmental requirements that I don't like. I'd like to fix some of them and so I'd like kick-around a few ideas. First, the JspC task requires that your entire webapp essentially be in webapp form before it can really work properly. Specifically, you need to set uriroot to something that contains a WEB-INF/web.xml file as well as the source JSPs and any dependent taglib TLDs in WEB-INF/lib. That may not seem like a big deal, but I happen to have my directory structure laid out in a way that doesn't fit that profile: I have my .jsps in a web directory, my libraries in a lib directory, and my web.xml in a conf directory. These items are only brought together at the last minute using a war task. Thus, it's not particularly convenient for me to build the WAR file, then expand it, then run the JSP precompiler, then /re-war/ the whole webapp. It would be much nicer if I could specify, on the command-line (or via a the ant task, which is how I'm doing it, not) the locations of these items. I would like to update JspC to accept some new settings in lieu of uriroot: jspSourceDir jspClasspath webXml The webXml parameter name isn't going to work, as that's already used for the location of the web.xml file that will be generated during the compilation process. I'm open to suggestions for what to name this parameter. There is already a classpath setting in JspC.java, but it is not accessible via ant for some reason. It's also used to compile the .java files into .class files (or so the documentation says). I'd like to make this settable via ant properties like jasperclasspath ... //jasper. It might make sense to use this classpath to also search for TLDs, etc. but we might also want a jspClasspath to be separate for flexibility. Finally, the jspSourceDir could be the root of where all JSPs are located. All of these settings could be set automagically when using the uriroot setting, so these changes should be backward compatible and not too tough to build. Second, there's no way for an outside process (like JspC for instance) to determine the webapp spec version. The JspConfig class has a private getVersion method that uses private data and returns a spec version number. I'd like to make this information available to outside code. Specifically, I'd like JspC to be able to check the version of the webapp to determine if the generated web.xml fragment should have the servlet 3.0 header and footer, or no header and footer (as is the current behavior). I'd like to make the compiler spec-version-aware because, though precompiled JSPs must be precompiled with the same version of Tomcat as will be used in deployment, there's no guarantee that all precompiled JSPs will be running in 3.0-spec-version webapps. For those cases, I don't want to generate a web-fragment.xml with 3.0-spec-version semantics. Along these lines, I might like to add a setting in JspC that specifically requests 3.0-spec-version semantics (such as emitting a 3.0-spec-version web-fragment.xml file) and will cause an error if the webapp's web.xml does not specify that same (or higher) version. All of the above changes will require some changes to JspConfig, JspCServletContext, and probably some other associated changes to allow the synthesis of several disparate source locations (.jsp, lib, and web.xml source) to look like a legitimate webapp. I'd appreciate any comments anyone might have on the above, especially by anyone who has had intimate dealings with Jasper and JspC. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Potential improvements to JspC
Mark,
On 2/2/2011 6:49 AM, Mark Thomas wrote:
On 02/02/2011 02:49, Christopher Schultz wrote:
I would like to update JspC to accept some new settings in lieu of
uriroot:
jspSourceDir
jspClasspath
webXml
The webXml parameter name isn't going to work, as that's already
used for the location of the web.xml file that will be generated
during the compilation process. I'm open to suggestions for what to
name this parameter.
I'm not so sure this needs to change. webXml has special handling. It
we separate webXml (source) and webXmlFragment (destination) then I
think things should be OK.
The current webXml setting specifies the target for a merged-web.xml
file that JspC will generate automatically by merging the existing
webapp's web.xml and the servlet definitions generated during the
compilation process.
Are you suggesting that we leave that setting alone (I agree) and create
something new like sourceWebXml? I like that. Be aware that
webXmlFragment (destination) already exists. See below.
but we might also want a jspClasspath to be separate for
flexibility.
I don't think we need this.
Okay. It was just a thought, and it's easy to make it backward
compatible so that a user only uses if if they /really/ want to.
Second, there's no way for an outside process (like JspC for instance)
to determine the webapp spec version. The JspConfig class has a private
getVersion method that uses private data and returns a spec version
number. I'd like to make this information available to outside code.
Specifically, I'd like JspC to be able to check the version of the
webapp to determine if the generated web.xml fragment should have the
servlet 3.0 header and footer, or no header and footer (as is the
current behavior).
I'd add a genWebXmlFragment (or similar) that if set tries to generate a
Servlet 3.0 fragment and throws an error if the source isn't a 3.0 webapp.
There's been a setting, webXmlFragment, that already does this, except
that it generates a snip of non-well-formed XML that the user is
expected to integrate into web.xml themselves.
I see us having several options, here:
1. Change the behavior of the webXmlFragment setting so that it always
generates a fragment that has a header and footer that match the
original web.xml DOCTYPE/xmlns. This would break backward
compatibility, as users would have to strip-out these header and
footer. For a manual process, this isn't a big deal. For automated
processes, it would probably be a real pain in the neck. On the other
hand, we don't end up with a bunch of settings that are confusingly
similar (webXmlFragment(exists), webXml(exists),
genWebXmlFragment(new), etc.).
2. Create a new setting that implies a 30-spec-version and throw an
error if the webapp isn't 3.0-spec-version. This has the unfortunate
consequence that we pollute our settings namespace with yet another
web.xml-related setting (see #1 above).
3. Hmm. I thought there were three things when I started. I can't think
of another one. shrug
I'd like to make the compiler spec-version-aware because, though
precompiled JSPs must be precompiled with the same version of Tomcat as
will be used in deployment, there's no guarantee that all precompiled
JSPs will be running in 3.0-spec-version webapps. For those cases, I
don't want to generate a web-fragment.xml with 3.0-spec-version semantics.
Along these lines, I might like to add a setting in JspC that
specifically requests 3.0-spec-version semantics (such as emitting a
3.0-spec-version web-fragment.xml file) and will cause an error if the
webapp's web.xml does not specify that same (or higher) version.
See previous comment.
Any reason not to allow client code to ask JspConfig what the version of
the webapp is, though? This can certainly be one of those incremental
changes. Note that having JspC complain if a 3.0-spec-version feature is
requested (specifically, a 3.0-spec-compliant web-fragment.xml) this
change will be necessary. Otherwise, there's no convenient way to detect
the spec version of the webapp.
General direction looks good to me. I'd recommend several incremental
patches where possible to make reviewing simpler.
Agreed.
One last thing: I have a separate Ant build script called build-jspc.xml
that I've been working in. The idea is that you do an ant call from
within your own webapp's build.xml after setting up all the settings.
This would allow people to use a pre-build set of Ant targets instead of
copy/pasting from the JspC HOWTO web page.
Basically, the instructions would be reduced to something like this:
1. Set the following settings: (list them)
2. Add this to your ant script in your JspC target:
ant antfile=${catalina.home}/../../build-jspc.xml
target=jspc
inheritRefs=true
/
Any objections to including such a separate script in the Tomcat tree
somewhere? Right now, I have it at the top-level, but I'm open to
putting
Re: Connection draining when upload to large
Rainer, On 2/10/2011 8:04 AM, Rainer Jung wrote: It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? +1 I've always wondered why Tomcat drains the input stream instead of just closing it. I could write a client that does a PUT or POST with no Content-Length and just send 1 byte every second or so and tie up a request thread indefinitely. That seems dangerous. -chris signature.asc Description: OpenPGP digital signature
Re: Connection draining when upload to large
William, On 2/10/2011 4:51 PM, William A. Rowe Jr. wrote: On 2/10/2011 7:04 AM, Rainer Jung wrote: Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? In HTTP, this is required if you will reject the request with a status. I didn't realize that. Can you point me to a reference to the portion of the spec that requires that? The behavior is RFC-correct per Apache httpd's design, which has been debated on plenty of occasions and the finger always goes back to RFC 2616 correctness. This seems like something we could allow with a non-default configuration setting. We have all kinds of options in Tomcat that allow non-servlet-spec-compliant behavior. -chris signature.asc Description: OpenPGP digital signature
Re: Connection draining when upload to large
Mark, On 2/11/2011 4:37 AM, Mark Thomas wrote: On 10/02/2011 21:32, Christopher Schultz wrote: Rainer, On 2/10/2011 8:04 AM, Rainer Jung wrote: It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? +1 I've always wondered why Tomcat drains the input stream instead of just closing it. I could write a client that does a PUT or POST with no Content-Length and just send 1 byte every second or so and tie up a request thread indefinitely. That seems dangerous. That is a different issue. You are describing a slowloris attack. The simple mitigation for that is to use the NIO connector. Good point. -chris signature.asc Description: OpenPGP digital signature
Re: Connection draining when upload to large
All, On 2/17/2011 5:41 AM, Mark Thomas wrote: On 17/02/2011 10:30, Rainer Jung wrote: On 10.02.2011 18:44, Mark Thomas wrote: Any hints about where to add stuff to the docs? Are people fine with making it controllable via the request attribute? I'm not particularly comfortable with this. I'm having a hard time coming up with a use case where some requests are swallowed and some are not. +1 I think I'd prefer a per Connector or per Context attribute. +1 -chris signature.asc Description: OpenPGP digital signature
Re: Reaching ulimit values for open files can generate huge log files
Mark,
On 2/21/2011 10:21 AM, Mark Thomas wrote:
The ASF Sonar installation managed to generate 46GB of identical log
messages [1] today in the 8 hours it took to notice it was down.
Ugh. Yeah, that sucks.
Hitting the ulimit doesn't necessarily mean disaster and the process
could still recover. For instance, an out-of-control request might try
to open files in a loop and tie up all the fds for a minute or two
before the request dies and the GC cleans everything back up. In the
meantime, some request processors might suffer but eventually recover.
While better monitoring would/should have identified the problem sooner,
it does demonstrate a problem with the acceptor threads in all three
endpoints. If there is a system-level issue that causes the accept()
call to always fail (such as hitting the ulimit) then the endpoint
essentially enters a loop where it logs an error message for every
iteration of the loop. This will result in many log messages per second.
I like this idea. Does that mean that you'll get once-per-second (or
whatever) errors across all processor threads or once-per-second errors
for each processor thread?
+if (errorDelay == 0) {
+errorDelay = 50;
How about making this initial delay configurable?
+} else if (errorDelay 1600) {
How about making this maximum delay configurable?
+errorDelay = errorDelay * 2;
Geometric growth seems reasonable... I don't see a reason to make this
multiplier configurable.
-chris
signature.asc
Description: OpenPGP digital signature
Re: Reaching ulimit values for open files can generate huge log files
Mark, On 2/21/2011 10:21 AM, Mark Thomas wrote: The ASF Sonar installation managed to generate 46GB of identical log messages [1] today in the 8 hours it took to notice it was down. I've not really looked at how Tomcat does its logging, but do we have an opportunity to do what, say, syslogd does when it emits messages like Last message repeated X times? If the logger could keep a reference to the last log message and do comparisons, this would be possible. On the other hand, reducing the performance of logging isn't a popular thing to do. -chris signature.asc Description: OpenPGP digital signature
Re: Download stats
Mark, On 2/23/2011 10:27 AM, Mark Thomas wrote: I took a quick look at yesterdays log files to see what the proportion of downloads was for the recent 5.5.x, 6.0.x and 7.0.x releases. After a little filtering to try and ensure I was comparing like with like, the results were: Tomcat 5.5.33 - 23% Tomcat 6.0.32 - 35% Tomcat 7.0.8 - 42% Looking across all versions: Tomcat 3.x - 1% Tomcat 4.x - 4% Tomcat 5.0.x - 5% Tomcat 5.5.x - 25% Tomcat 6.0.x - 33% Tomcat 7.0.x - 32% Maybe I don't understand, but how can the relative proportion of TC 6.0 vs. TC 7.0 change when more versions are considered? I would expect that TC 6.0 would always be less than TC 7.0 unless the time frames were different. I think things look pretty good. People certainly aren't scared to download 7.0, which is great. Unfortunately, people are still downloading pre-6.0. :( -chris signature.asc Description: OpenPGP digital signature
Re: Response.getWriter(), getOutputStream(), setContentLength() spec issues
Mark, On 2/25/2011 7:01 AM, Mark Thomas wrote: So, the questions we need to decide: 1. Is the fix for bug 50748 correct? I think it is. +0 2. Should Tomcat try and handle this situation (e.g. if any bytes have been written by a filter, commit the response). This could be tricky to get right when forwards are involved and the response is meant to have been cleared. I'm leaning towards not doing this. The Filter definitely needs to be able to set headers and append content to the response entity. I'm not sure about a Filter having a legitimate reason to write content /before/ the servlet does to the response entity... I'm having trouble thinking of a use case for that. Given that, having the Filter write anything to the response stream/writer seems reasonable to commit the response. On the other hand, why should a filter act any differently than a servlet? What I mean is that the response won't be committed when a servlet writes to the response until the response buffer has been filled, or an explicit flush() has been called. Also, a servlet should have the opportunity to reset the response if possible given the commit state. I think that makes me -1 on this one. 3. Is any filter that writes to the response without wrapping it so any calls to setContentLength() can be intercepted and adjusted as necessary broken? I think it is. +1 Where does this fail the TCK? Do we have a broken Filter, or does the TCK test an unusual/stupid scenario? Thoughts? I'd like to reach some conclusions fairly speedily as this might hold up a 7.0.9 release. If we conclude that the filter is at fault in point 3, we'll need to raise a TCK challenge. I guess that answers my question. We could have a just-pass-the-damned-TCK configuration flag (or maybe something less inflammatory) that would change this behavior to commit-on-write for Filters. -chris signature.asc Description: OpenPGP digital signature
Re: bindOnInit and maxConnections for AJP connectors
Mark, I understand that a fix has already been applied, but... On 4/6/2011 7:16 AM, Mark Thomas wrote: I thought of two options for issue 3: a) Assign a processor (+ inputbuffer, output buffer etc.) to a socket and don't recycle it until the socket is closed. - Increases memory requirements. - Fixes issue 3 - Retains current request processing order. b) Check the input buffer at the end of the loop in Http11Processor#process() and process the next request if there is any data in the input buffer. - No Increase in memory requirements. - Fixes issue 3 - Pipelined requests will get processed earlier (before they would have been placed at the back of the request processing queue) I think option b) is the way to go to fix issue What about a third option that is essentially (a) except that you trim the input buffer and discard the already-processed request(s) from it. The input buffer stays bound to the request and continues where it left-off when another request processor becomes available. That would maintain scheduling fairness and hopefully not require much in the way of memory usage. Since pipelining requests with entities is not a good idea, the chances of getting a large amount of data in the input buffer is relatively low. There's also a limit on the size of that buffer, too. Would that still represent too large of a memory requirement? -chris signature.asc Description: OpenPGP digital signature
Re: Tomcat-oracle secure connection
Ramram, On 4/7/2011 9:46 AM, ramram8 wrote: Does anybody have any idea how to secure a tomcat connection to oracle database (jdbc encryption for example) or any other idea that can be easily implemented. This is a question better asked on the users' list. -chris signature.asc Description: OpenPGP digital signature
JSP Compiler swallows exceptions when removing files
All,
While reading the code for jasper.compiler.Compiler on an unrelated
errand, I noticed that the removeGeneratedFiles and
removeGeneratedClassFiles methods contain this code:
} catch (Exception e) {
// Remove as much as possible, ignore possible exceptions
}
This code appears in both TC 6.0.x trunk and TC 7.0.x trunk.
This situation seems worthy of a log statement, no?
-chris
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r1090072 - /tomcat/tc6.0.x/trunk/STATUS.txt
Konatantin, On 4/7/2011 9:08 PM, Konstantin Kolinko wrote: 2011/4/8 schu...@apache.org: Author: schultz Date: Fri Apr 8 00:41:29 2011 New Revision: 1090072 URL: http://svn.apache.org/viewvc?rev=1090072view=rev Log: Updated. Modified: tomcat/tc6.0.x/trunk/STATUS.txt + +* Backport exception logging from revision 1090022 + http://svn.apache.org/viewvc?view=revisionrevision=1090022 + +1: schultz + -1: Actually it might be not as useful as it might seem. Deletion failures are reported as boolean return value from delete(), not as an exception. It makes sense to backport the relevant change to delete() calls as well, http://svn.apache.org/viewvc?view=revisionrevision=1073393 I'm not sure what you mean. The code actually compiles without any try/catch block there at all, since none of the methods called actually throw IOException. I suspect the catch-all block was there to prevent any really weird things from happening and propagating up the stack. The code comment says delete at much as possible implying that there is a lot of work to do which might be interrupted, but there is only one file to delete in each case: it either does or does not succeed. What change were you suggesting that I actually backport? The replacement of the duplicate code with a method call? -chris signature.asc Description: OpenPGP digital signature
Re: bindOnInit and maxConnections for AJP connectors
Tim, On 4/8/2011 4:50 AM, Tim Whittington wrote: On Fri, Apr 8, 2011 at 2:40 AM, Christopher Schultz ch...@christopherschultz.net wrote: Mark, I understand that a fix has already been applied, but... On 4/6/2011 7:16 AM, Mark Thomas wrote: I thought of two options for issue 3: a) Assign a processor (+ inputbuffer, output buffer etc.) to a socket and don't recycle it until the socket is closed. - Increases memory requirements. - Fixes issue 3 - Retains current request processing order. b) Check the input buffer at the end of the loop in Http11Processor#process() and process the next request if there is any data in the input buffer. - No Increase in memory requirements. - Fixes issue 3 - Pipelined requests will get processed earlier (before they would have been placed at the back of the request processing queue) I think option b) is the way to go to fix issue What about a third option that is essentially (a) except that you trim the input buffer and discard the already-processed request(s) from it. The input buffer stays bound to the request and continues where it left-off when another request processor becomes available. That would maintain scheduling fairness and hopefully not require much in the way of memory usage. Since pipelining requests with entities is not a good idea, the chances of getting a large amount of data in the input buffer is relatively low. There's also a limit on the size of that buffer, too. Would that still represent too large of a memory requirement? The input buffer is 8k by default (max header size), so this could be significant with a large maxConnections. Pruning the buffers to retain only required space would generate a lot of garbage, so probably not a good option either. Are those buffers ever discarded? I guess it comes down to whether the 8k buffer belongs to the connection or to the request. It looks like the bug arises from the buffer being treated like it belongs to the request when it really belongs to the connection. I agree, switching to a request-owned buffer strategy would certainly increase the memory footprint since you'd need a buffer for each pending request (which may be quite high when using NIO an/or async). Thanks for clarifying that. If the fairness becomes a practical problem, reducing maxKeepAliveRequests (100 by default) would force pipelining clients to the back of the queue regularly. How would this work, though? If the bug under discussion arises from a connection essentially disconnecting one of these buffers from the request whence it came, doesn't re-queuing the request re-introduce the bug? -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1090072 - /tomcat/tc6.0.x/trunk/STATUS.txt
Konstantin, On 4/8/2011 3:56 PM, Konstantin Kolinko wrote: This one (combined with yours): http://svn.apache.org/viewvc?view=revisionrevision=1073393 Aah, I didn't realize that the code I was updating had actually just been written. but there is only one file to delete in each case: Interesting. So it never deletes inner classes... (but nobody reported any problems) That appears to be the case. I suppose we could try to delete JavaClassFileName.java, JavaClassFileName.class, JavaClassFileName$*.java, and JavaClassFileName$*.class, which ought to take care of everything and still be somewhat safe... just slower performance since we'd have to do a (single) directory-scan to get the file list. -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1127315 - /tomcat/jk/trunk/xdocs/reference/apache.xml
All, I'm not sure what the policy is on documentation changes and back-porting to already-released versions of mod_jk, but this clarifies how mod_jk works and would be beneficial to have on the web site without having to wait for a new release of mod_jk. Is there a good way to do that, or should we just wait for a new release? Thanks, -chris On 5/24/2011 6:02 PM, schu...@apache.org wrote: Author: schultz Date: Tue May 24 22:02:27 2011 New Revision: 1127315 URL: http://svn.apache.org/viewvc?rev=1127315view=rev Log: Added detailed information about what SSL variables will be sent to Tomcat when JkExtractSSL is enabled. Modified: tomcat/jk/trunk/xdocs/reference/apache.xml Modified: tomcat/jk/trunk/xdocs/reference/apache.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/reference/apache.xml?rev=1127315r1=1127314r2=1127315view=diff == --- tomcat/jk/trunk/xdocs/reference/apache.xml (original) +++ tomcat/jk/trunk/xdocs/reference/apache.xml Tue May 24 22:02:27 2011 @@ -271,7 +271,48 @@ The default value is On. In order to make SSL data available for mod_jk in Apache, you need to set codeSSLOptions +StdEnvVars/code. For the certificate information you also need to add codeSSLOptions +ExportCertData/code. -/p/attribute +/p +p + Specifically, mod_jk will export the following environment variables from + Apache httpd to Tomcat under these request attributes as per the + Servlet Specification 3.0, section 3.8: +/p +table + trthEnv Var/ththRequest Attribute Name/ththType/ththExample/th/tr + tr +tdSSL_CIPHERbr/(or codeJkKEYSIZEIndicator/code)/td +tdjavax.servlet.request.cipher_suite/td +tdjava.lang.String/td +tdDHE-RSA-AES256-SHA/td + /tr + tr +tdSSL_CIPHER_USEKEYSIZEbr/(or codeJkKEYSIZEIndicator/code)/td +tdjavax.servlet.request.key_size/td +tdjava.lang.Integer/td +td256/td + /tr + tr +tdSSL_SESSION_IDbr/(or codeJkSESSIONIndicator/code)/td +tdjavax.servlet.request.ssl_session/td +tdjava.lang.String/td +td905...32E (a hex string)/td + /tr + tr +tdSSL_CLIENT_CERT_CHAIN_in/ibr/(or codeJkCERTCHAINPrefix/codein/i)/td +tdjavax.servlet.request.X509Certificate/td +tdjava.security.X509Certificate[]/td +td(A chain of certs in ascending order of trust, the first one being +ths client's certificate, the second being the signer of that +certificate, and so on)/td + /tr +/table +p + For all other SSL-related variables, use codeJkEnvVar/code for each + variable you want. Please note that, like codeJkEnvVar/code, these + variables are available from the request ibattributes/b/i, not as + environment variables or as request headers. +/p +/attribute attribute name=JkHTTPSIndicator required=falsep Name of the Apache environment variable that contains SSL indication. br/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: mod_jk 1.2.32 [was: Re: svn commit: r1127315 - /tomcat/jk/trunk/xdocs/reference/apache.xml]
Rainer, On 5/26/2011 5:06 AM, Rainer Jung wrote: There are enough changes for a 1.2.32 anyhow, so I would propose we start a new release cycle in about 2 weeks. Sounds great. -chris signature.asc Description: OpenPGP digital signature
Re: Expected behavior of Tomcat under load
Asankha, On 5/26/2011 5:01 AM, Asankha C. Perera wrote: First of all, this is a repost from the user@ list from yesterday, as I think this requires a reply from a developer instead of a user. The dev@ list shouldn't be used as a support forum. The user@ list is the appropriate place to post your question. All the developers also read the user@ list so there's no need to cross-post. You have already received a response on the user@ list asking for more information. Please go back to that list and respond with the requested information. If you are going to report a problem with connections, you'd better give some details about your connection configuration. -chris signature.asc Description: OpenPGP digital signature
Outdated Servlet 3.0 Javadocs available on tomcat.apache.org
All, I just went to check something in the 3.0 Servlet API and the most convenient place I've found is on the Tomcat site. Unfortunately, it looks like it's out of date: http://tomcat.apache.org/tomcat-7.0-doc/servletapi/index.html Many of the 3.0 classes and methods are left undocumented (for example ServletContext.addFilter). http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/ServletContext.html#addFilter%28java.lang.String,%20java.lang.Class%29 It just looks like the API docs up there are from an old publication of the spec. The currently-available javadocs from the spec page are complete with comments, etc. What's the best way to update those javadocs? I'd be happy to do it. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Outdated Servlet 3.0 Javadocs available on tomcat.apache.org
Tim, On 6/1/2011 8:35 AM, Tim Funk wrote: Is the PDF of the spec which is downloadable up to date with respect to comments? The version of the PDF I'm looking at (3.0 Final, 1434610 bytes, dated 10 December 2009) does not include the javadoc at all... it does include some documentation of certain methods... I have only done a casual reading at this point. I don't think the pdf version of the spec is CDDL ... but it may have other conditions on it. There does not appear to be a specific license mentioned in the PDF, though it does limit what the reader can do with it. It says that excerpting brief portions of the Specification is acceptable, but I suspect that copying lots of text like that is a no-no because you can only do it provided that such excerpts do not in the aggregate constitute a significant portion of the Specification. The javadoc is a lot of stuff. One needs to consider whether the javadoc itself is part of the specification or not. :( Downloading both the PDF and the Javadoc ZIP archive require that you accept the SLA which can be found here (http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/servlet-3.0-fr-oth-JSpec-license.html) and appears to be the same agreement as included at the top of the PDF version of the specification. Mark, I never saw anything about the CDDL while poking around the Oracle download site. If we use the Oracle-provided Javadoc ZIP archive rather than generating the Javadocs from the CDDL source, might that be acceptable? I'm certainly not asking for a legal opinion, here, just what your general sense is of these things. It's frustrating that Oracle doesn't just publish the Servlet API javadocs on it's own web site :( -chris signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL] Enable session replication by default.
Keiichi, On 6/7/2011 7:37 AM, Keiichi Fujino wrote: Index: conf/web.xml === --- conf/web.xml (revision 1127122) +++ conf/web.xml (working copy) @@ -4176,4 +4176,6 @@ welcome-fileindex.jsp/welcome-file /welcome-file-list + !-- distributable = -- +distributable/ /web-app -1 This will cause web applications to fail when adding session attributes that are not Serializable. -chris signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Apache Tomcat 7.0.15
Mark, On 6/4/2011 4:21 PM, Mark Thomas wrote: The proposed Apache Tomcat 7.0.15 release is now available for voting. The proposed 7.0.15 release is: [X] Broken - do not release Based upon broken distributable capability. :( -chris signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL] Enable session replication by default.
Mark, On 6/7/2011 2:36 PM, Mark Thomas wrote: On 07/06/2011 19:30, Christopher Schultz wrote: Keiichi, On 6/7/2011 7:37 AM, Keiichi Fujino wrote: Index: conf/web.xml === --- conf/web.xml(revision 1127122) +++ conf/web.xml(working copy) @@ -4176,4 +4176,6 @@ welcome-fileindex.jsp/welcome-file /welcome-file-list + !-- distributable = -- +distributable/ /web-app -1 This will cause web applications to fail when adding session attributes that are not Serializable. Not it won't. This is *not* changing the default value of distributable. That distributable flag is in conf/web.xml, which I assumed set defaults for all web applications. Is distributable handled differently than, say, servlet-mapping or anything else we put into conf/web.xml? I apologize for not having read the code at this point. -chris signature.asc Description: OpenPGP digital signature
Re: Crash in APR when pausing endpoint
Rainer, On 6/13/2011 11:49 AM, Mark Thomas wrote: Analysis and patch make sense to me. +1 Nice analysis. Nice to see I'm not the only one who can code-up a nice race condition. -chris signature.asc Description: OpenPGP digital signature
Re: Diagram for AsyncStateMachine.java
Konstantin, On 6/18/2011 8:15 PM, Konstantin Kolinko wrote: I have redrawn the state diagram for trunk's org/apache/coyote/AsyncStateMachine.java. Would it be worth including the state transitions in AsyncStateMachine.java in dot format for rendering in GraphViz? -chris signature.asc Description: OpenPGP digital signature
Re: OneLineFormatter by default?
Mark, On 6/20/2011 10:54 AM, Mark Thomas wrote: On 20/06/2011 15:51, Rainer Jung wrote: Should we use the new OneLineFormatter as the default juli formatter? I never found anyone who liked the default java.util.logging log format, which spreads all messages out via two lines. One line contains the timestamp, the other line the message. So if your grep for a message, you want find out when it was issued, and if you look for a certain time range, yout wont see the actual messages. Non-sense. Now that we have our nice little OneLineFormatter, why not use it as default? If we use it as default: should be have it as default without config, i.e. as a default in code, or do we want to add the .formatter lines to our loggging.properties? Or add the formatter system property to catalina.properties? I think I would favor having it as a code default, i.e. without any configuration. That might be a surprise for users. +1 Though I also hate the timestamp\nmessage format, too, enough people probably rely on it to seriously break things. I'd lean towards make it the default via config (very easy to revert) and change the code default for 8.x onwards. +1 -chris signature.asc Description: OpenPGP digital signature
Re: Overhauling setclasspath.(bat|sh)?
Rainer, On 6/23/2011 7:33 AM, Rainer Jung wrote: On 21.06.2011 11:40, Konstantin Kolinko wrote: 2011/6/20 Rainer Jung rainer.j...@kippdata.de: 1) Renaming Since quite some time now the setclasspath script doesn't have anything to do with setting a class path. It only searches for JRE / JDK and sets up the path to the Java or JDB binary plus JAVA_ENDORSED_DIRS. So it would be more correct to call it checkjava.sh or setupjava.sh or whatever. Do you think it's too late for TC 7 to rename the script? Good ideas for a new name? The name may be mentioned in mailing list archives or elsewhere. I do not think it is worth renaming, but won't oppose it. Since at least Leon reported back he took the name as a suggestion to include classpath customization in there and I can imagine there are others as well for whom we would break their installation when upgrading, I suggest we postpone renaming to TC 8. That might be the time for a bigger script refactoring using shell and bat functions to keep the catalina and tool-wrapper scripts in sync more easily. It seems reasonable to allow for both setupjava.sh (or whatever the preferred name is) AND setclasspath.sh and prefer the former: if it exists, run that instead of setclasspath.sh. Also, we could issue a WARN message to the console if setclasspath.sh exists yet still run it. -chris signature.asc Description: OpenPGP digital signature
Re: Supporting more general globs in loader definition?
Rainer, On 6/23/2011 10:39 AM, Rainer Jung wrote: Globs in the file name and not the directory part is the most important use case and easy to understand in its consequences. So I lean towards this type of improvement right now. So: /path/to/*.jar (allowed today) /path/to/foo*.jar(proposed) /path/*/foo.jar (not proposed) /path/**/foo.jar (ant-style ** for any depth, not proposed) ? Any reason not to allow globs in the non-filename path portion? I can't really see a use case for actually wanting a path-glob but am interested in your reasoning. -chris signature.asc Description: OpenPGP digital signature
Re: Supporting more general globs in loader definition?
Rainer, On 6/23/2011 4:02 PM, Rainer Jung wrote: But supporting a glob in the file name would also work. I'm always irritated when something that looks like it should work doesn't work. The fact that .../*.jar works but .../foo*.jar does not work is surprising, so I'm in support of adding filename globbing. Ignoring path globbing until someone demands it is perfectly okay with me, too, especially since the implementation is probably more involved. -chris signature.asc Description: OpenPGP digital signature
Tomcat native build requirements
All, I'm reviewing a patch against the Java portion of tcnative, and I wanted to know what level of JDK support we can require. Specifically, StringBuilder is not available before JDK 1.5. Is that acceptable to use at this point? Not sure if we have to support 1.4 JVMs for the tcnative project specifically. Thanks, -chris signature.asc Description: OpenPGP digital signature
Tomcat FIPS mode questions
Chris, I've been reviewing your patches to BZ 50570 (https://issues.apache.org/bugzilla/show_bug.cgi?id=50570) and I have a few questions. First, why did you change the name of the init method to initializeAPR? The method is private and should therefore be safe to re-name, but I was wondering why you did it. Was it to match the terminateAPR method that performs the somewhat opposite functions? In general, patches should change the least amount of code possible, if for no other reason than they are easier to read and evaluate. There are a lot of changes in here which only affect the formatting of the code, etc. and so it's tough going making sure that nothing is changing that shouldn't be. I'm going to be adapting your patch to make fewer changes which I'll re-post back to BZ. If you could verify that it's functionally equivalent to your patch if would be very helpful. (Or, maybe you could re-post your own patch that ignores whitespace changes). Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Tomcat FIPS mode questions
Chris, On 6/28/2011 2:55 PM, Christopher Schultz wrote: I've been reviewing your patches to BZ 50570 (https://issues.apache.org/bugzilla/show_bug.cgi?id=50570) and I have a few questions. Also, why the changes to java/org/apache/tomcat/jni/Library.java? If there's a bug in there (it doesn't look like it has anything to do with FIPS mode), please report it and we'll handle it separately. Thanks, -chris signature.asc Description: OpenPGP digital signature
Looking for review of new FIPS mode patches
All, I have a small patch for tcnative's SSL.c and a somewhat more involved patch for AprLifecycleListener.java, both attached to https://issues.apache.org/bugzilla/show_bug.cgi?id=50570 I'd appreciate some review by those familiar with that code so make sure I haven't made any terrible mistakes before I apply them. Thanks, -chris signature.asc Description: OpenPGP digital signature
No release date for 7.0.16 on web site changelog
All, Though TC7.0.x trunk changelog has the release date, the public web site does not. Can you trigger an update of the website to publish this date? -chris signature.asc Description: OpenPGP digital signature
Re: Time for 6.0.33?
Mark, On 7/1/2011 4:32 AM, Mark Thomas wrote: On 14/06/2011 14:09, Mark Thomas wrote: The changelog is getting quite long for 6.0.x. Is it time for another release? Jean-Frederic - are you able to RM this or do we need to find a volunteer for this one? No replies to this. Is this because no-one thinks it is time for 6.0.33? The list is growing even longer, lately. +1 for 6.0.33. -chris signature.asc Description: OpenPGP digital signature
Re: [ANN] CI for Tomcat 6 and 7 docs now available
Mark, On 9/17/2010 7:27 AM, Mark Thomas wrote: Thanks to the infrastructure team (specifically Gavin in this case) we now have CI builds of the Tomcat 6 7 docs that will update with every commit. Dumb question: what is a CI build? -chris signature.asc Description: OpenPGP digital signature
Writing unit tests
All, I'm attempting a patch for https://issues.apache.org/bugzilla/show_bug.cgi?id=49964 and I'd like to write a few unit tests for it. In the Tomcat 6.0.x trunk, I can only find what appear to be 30-40 test files. Is there a test suite elsewhere that I can download and augment in order to properly test my code, and to test against regressions? Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Writing unit tests
Mark, On 9/20/2010 4:33 PM, Mark Thomas wrote: On 20/09/2010 11:29, Christopher Schultz wrote: All, I'm attempting a patch for https://issues.apache.org/bugzilla/show_bug.cgi?id=49964 and I'd like to write a few unit tests for it. In the Tomcat 6.0.x trunk, I can only find what appear to be 30-40 test files. Is there a test suite elsewhere that I can download and augment in order to properly test my code, and to test against regressions? Not for Tomcat 6. Best option is write the patch for Tomcat 7, add the test cases to the Tomcat 7 unit tests and then think about back-porting to 6. New features always go into the latest version and then get back-ported so you'll need to start with 7 anyway. Gotcha. That also explains why you'd DUP'd the bug against a TC 7 enhancement. I'm glad to work on it either way. I have this working with a small patch against the 6.0.x trunk, but I have a few questions about it: 1. There's a method in catalina.connector.Connector called init(). When does that get called? I had expected that it would be called after all the setXXX attributes had be set on it from the digester upon start-up, but it appears that Connector.init /never/ gets called. That means that my defaults have a hard time being ... defaulted properly. I have a hack in there that does a sanity check when checking the list of methods to see if the current request should be parsed, but it seems like a waste of processing time during the request itself. Should I put my startup code somewhere other than Connector.init()? 2. Coding conventions seem to be applied ... inconsistently. Is there a code style guide that I can actually follow so my code looks right, or should I just look at what's already there in the files I'm modifying and take my best guess at what's appropriate? Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Writing unit tests
Mark, On 9/20/2010 4:52 PM, Mark Thomas wrote: That'll probably be better in 7.0.x. I do wonder what init code you might need. I was expecting a simple boolean attribute. Once that is sorted, we can figure out how to port it to 6.0.x Since I was thinking of allowing any set of HTTP methods, I need to initialize a HashSet of method names that are allowed. The default is the default string for calling the attribute mutator (so, just POST) and the default needs to be applied at some point to generate the HashSet I'm inspecting at request time. I just noticed that TC 7 doesn't have an init() method :) I'll figure it out there and, as you say, we'll figure a way to back-port. 2. Coding conventions seem to be applied ... inconsistently. Is there a code style guide that I can actually follow so my code looks right, or should I just look at what's already there in the files I'm modifying and take my best guess at what's appropriate? Yep. Go with the current style of the file. Gotcha. Thanks again, -chris signature.asc Description: OpenPGP digital signature
