================================================================================ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ================================================================================ $Revision$ $Date$ ================================= Apache Tomcat 6.0 Patch Proposals ================================= RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT: [ start all new proposals below, under PATCHES PROPOSED. ] PATCHES PROPOSED TO BACKPORT: [ New proposals should be added at the end of the list ] * Fix issue where the first request for a deleted JSPs returns as if the JSP still exists. http://svn.apache.org/viewvc?view=rev&revision=683969 +1: markt, funkman 0: remm (looks risky, very minor problem), fhanik - minor problem -1: * Handle session suffix rewrite at JvmRouteBinderValve with parallel requests from same client http://svn.apache.org/viewvc?rev=693378&view=rev +1: pero, fhanik, markt, jim -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026 Never use empty reason phrase. http://svn.apache.org/viewvc?rev=697183&view=rev +1: rjung, mturk, markt, jim 0: remm (also affects to the two other AJP connectors) * Allow huge request body packets for AJP13. This was already applied to connectors, but never carried forward to trunk and tc6.0.x. http://svn.apache.org/viewvc?rev=697192&view=rev Original change: http://svn.apache.org/viewvc?rev=486217&view=rev +1: rjung, mturk, markt, pero, jim 0: remm (also affects to the two other AJP connectors) * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45403 See commit message for details of negligable performance impact http://svn.apache.org/viewvc?rev=701358&view=rev +1: markt, funkman -0: remm (I also do not think the patch is a good idea as a backport) -0: fhanik - the bug talks about WEB-INF/lib and reload, that would be when reload="true" which should be considered development only So to make this bug actually worth while fixing, and not impact performance, then it should only do this check on files that are relevant to the reload of an application, in other words a watched resource * Backport NCDFE fix from trunk (TCK failures without it) http://svn.apache.org/viewvc?rev=640888&view=rev +1: markt +1: fhanik - trivial change 0: remm (no clue how it can cause a NCDF, and the TCK actually works for me; besides that code is really old to me, so where would this come from ?) -1: * Changes required to run with a security manager http://svn.apache.org/viewvc?rev=721286&view=rev (original) http://svn.apache.org/viewvc?rev=721704&view=rev (original) http://svn.apache.org/viewvc?rev=721708&view=rev (original) http://svn.apache.org/viewvc?rev=721886&view=rev (original) http://svn.apache.org/viewvc?rev=746425&view=rev (to address Bill's concerns) +1: markt 0: billbarker: Haven't tried to break it yet, but the 4th patch potentially offers access to static fields in ELContextImpl and ELResolverImpl that could possibly be exploited by a malicious webapp. -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46351 Build script re-factoring Patch provided by Marc Guillemot http://svn.apache.org/viewvc?rev=729681&view=rev +1: markt, jim 0: fhanik - not sure its needed in 6.0 branch if all is working with the old script 0: funkman - ditto -1: * Deprecate unused code (with a view to deleting it in TC7 http://svn.apache.org/viewvc?view=rev&revision=719119 http://svn.apache.org/viewvc?view=rev&revision=719124 +1: markt, fhanik -0: mturk: We cannot change API in the middle of the life cycle. I'm fine with deprecating that in trunk, but IMO there is no reason to deprecate something in maintenance branch. markt: I'd like to delete a lot of stuff (that is already unused) in tc7. Deprecating it in tc6 doesn't stop people using it, nor does it change the functionality of the API. It just gives folks that may be using this old code a warning that it won't be there in the next version. -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=38570 When checking docBase against appBase, make sure we check for an exact match against the appBase http://svn.apache.org/viewvc?rev=742677&view=rev +1: markt, remm, mturk -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=39013 When testing for invalid docBase, test for an exact match with the appBase dir http://svn.apache.org/viewvc?rev=742697&view=rev +1: markt, remm, mturk -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=39396 Don't include TRACEE in OPTIONS response unless we know it hasn't been disabled in the connector http://svn.apache.org/viewvc?rev=742714&view=rev +1: markt, mturk -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46666 keepAliveTimeout should be used regardless of setting of disableUploadTimeout http://svn.apache.org/viewvc?rev=744160&view=rev +1: markt 0: billbarker The original was an optimization to not keep setting the timeout to the same value if we haven't changed it. Of course it is broken, but a better patch would be to set the timeout correctly outside the loop, and retain the disableUploadTimeout check. The first request shouldn't care, since we should already have available() > 0 with the JIO connector. markt I took a look at this. I think you do have to set timeouts inside the loop otherwise the request line read doesn't timeout correctly. I wrote this patch that only sets timeouts when required: http://people.apache.org/~markt/patches/2009-02-12-soTimeout.patch but I'm not sure it is necessary. Is setSoTimeout really that expensive? It takes less than a microsecond on my box. The code would be cleaner if we just took out most of the tests and set the timeout, even if it was already set as required. -1: * Use ThreadLocal rather than syncs for DateFormat to prevent potential bottleneck in cookie creation http://svn.apache.org/viewvc?rev=744238&view=rev +1: markt, fhanik -1: * Fix spelling errors reported on users and dev list http://svn.apache.org/viewvc?rev=746321&view=rev http://svn.apache.org/viewvc?rev=746384&view=rev +1: markt, mturk -1: * Fix error in 2.5 web.xml XSD http://svn.apache.org/viewvc?rev=747863&view=rev +1: markt -1: * UseHttpOnly is a cookie attribute. Our Manager is cookie agnostic, hence the attribute might serve a better purpose being implemented at the Context level http://people.apache.org/~fhanik/tomcat/useHttpOnly.patch This also allows people to configure it globally in conf/context.xml without automatically setting the default manager class +1: fhanik, markt -1: