Return-Path: Delivered-To: apmail-httpd-cvs-archive@www.apache.org Received: (qmail 70009 invoked from network); 3 Dec 2007 19:57:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Dec 2007 19:57:37 -0000 Received: (qmail 15632 invoked by uid 500); 3 Dec 2007 19:57:25 -0000 Delivered-To: apmail-httpd-cvs-archive@httpd.apache.org Received: (qmail 15581 invoked by uid 500); 3 Dec 2007 19:57:25 -0000 Mailing-List: contact cvs-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list cvs@httpd.apache.org Received: (qmail 15570 invoked by uid 99); 3 Dec 2007 19:57:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Dec 2007 11:57:25 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.3] (HELO eris.apache.org) (140.211.11.3) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Dec 2007 19:57:05 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 103841A9832; Mon, 3 Dec 2007 11:57:08 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r600649 - /httpd/httpd/branches/2.2.x/STATUS Date: Mon, 03 Dec 2007 19:57:07 -0000 To: cvs@httpd.apache.org From: wrowe@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20071203195708.103841A9832@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: wrowe Date: Mon Dec 3 11:57:01 2007 New Revision: 600649 URL: http://svn.apache.org/viewvc?rev=600649&view=rev Log: Four different indentions? Normalize this, and add PR 44014 to the list. Modified: httpd/httpd/branches/2.2.x/STATUS Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=600649&r1=600648&r2=600649&view=diff ============================================================================== --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Mon Dec 3 11:57:01 2007 @@ -49,29 +49,29 @@ Contributors looking for a mission: - * Just do an egrep on "TODO" or "XXX" in the source. + * Just do an egrep on "TODO" or "XXX" in the source. - * Review the bug database at: http://issues.apache.org/bugzilla/ + * Review the bug database at: http://issues.apache.org/bugzilla/ - * Review the "PatchAvailable" bugs in the bug database: + * Review the "PatchAvailable" bugs in the bug database: - https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable + https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable - After testing, you can append a comment saying "Reviewed and tested". + After testing, you can append a comment saying "Reviewed and tested". - * Open bugs in the bug database. + * Open bugs in the bug database. CURRENT RELEASE NOTES: - * Forward binary compatibility is expected of Apache 2.2.x releases, such - that no MMN major number changes will occur. Such changes can only be - made in the trunk. - - * All commits to branches/2.2.x must be reflected in SVN trunk, - as well, if they apply. Logical progression is commit to trunk, - get feedback and votes on list or in STATUS, then merge into - branches/2.2.x, as applicable. + * Forward binary compatibility is expected of Apache 2.2.x releases, such + that no MMN major number changes will occur. Such changes can only be + made in the trunk. + + * All commits to branches/2.2.x must be reflected in SVN trunk, + as well, if they apply. Logical progression is commit to trunk, + get feedback and votes on list or in STATUS, then merge into + branches/2.2.x, as applicable. RELEASE SHOWSTOPPERS: @@ -79,134 +79,133 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] - * mod_proxy_balancer: Remove the broken attempt to change balancer - params on-the-fly via the admin manager. - trunk: - http://svn.apache.org/viewvc?view=rev&revision=551099 (kinda) - 2.2.x: - http://people.apache.org/~jim/patches/bsel-patch-2.txt - +1: jim, rpluem, trawick + * mod_proxy_balancer: Remove the broken attempt to change balancer + params on-the-fly via the admin manager. + trunk: + http://svn.apache.org/viewvc?view=rev&revision=551099 (kinda) + 2.2.x: + http://people.apache.org/~jim/patches/bsel-patch-2.txt + +1: jim, rpluem, trawick PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ New proposals should be added at the end of the list ] - * mod_rewrite: Also set the Vary header if a rewrite condition is true and - uses a HTTP header, but all remaining rewrite conditions are skipped due - to the [OR] flag. - Trunk version of patch: - http://svn.apache.org/viewcvs.cgi?rev=574201&view=rev - Backport version for 2.2.x of patch: - Trunk version of patch works - +1: rpluem, niq - +0: jim: I'm curious that if this would result in some - "regressions" for some users who either depend on - the old behavior or have worked around it... - rpluem answers: If r574684 is backported (see below) these users can - fix it without workarounds and a clear and promised behaviour. - Relying on the above is relying on a buggy iundocumented behaviour, - but yes I do this sometimes by myself :-). - +1: jim: iff r574684 is also backported - - * mod_rewrite: Add the novary flag to RewriteCond in order to prevent - the appending of HTTP headers used in a rewrite condition to the Vary - header of the response. - Trunk version of patch: - http://svn.apache.org/viewcvs.cgi?rev=574684&view=rev - Backport version for 2.2.x of patch: - Trunk version of patch works - +1: rpluem, jim - - * core log.c: Work around possible solutions rejected by apr for - the old implementation of apr_proc_create(), and explicitly pass - the output and error channels to all log processes created. - This goes all the way back to piped logs failing to run on win32. - Not in or needed at trunk/, as apr 1.3.0 has the proper fix. - http://people.apache.org/~wrowe/httpd-2.0-2.2-procattr-bugfix-log.c.patch - +1: wrowe, rpluem - - * mod_proxy_http: Correctly forward unexpected interim (HTTP 1xx) responses - incorporating ap_send_interim_response core API - PR 16518 - trunk: - http://svn.apache.org/viewvc?view=rev&revision=582630 - http://svn.apache.org/viewvc?view=rev&revision=582652 - http://svn.apache.org/viewvc?view=rev&revision=582631 - http://svn.apache.org/viewvc?view=rev&revision=588806 - 2.2.x: - http://people.apache.org/~niq/16508.patch - +1: niq, rpluem - - * server/protocol.c: Prevent 1-byte overflow on 8192 boundary in - ap_vrprintf(). PR 43310 - trunk: - http://svn.apache.org/viewvc?view=rev&revision=589461 - 2.2.x: - Trunk version of patch works - +1: jim, rpluem - niq: Doesn't allocating 2^n+1 bytes risk being horribly inefficient? - Would it make sense to reduce AP_IOBUFSIZE to 8091 so buf doesn't - go one over a big boundary? - jim: The issue is that we allocate an array of AP_IOBUFSIZE - but go beyond that (note we send the end to curpos+AP_IOBUFSIZE) - so it's not just reducing AP_IOBUFSIZE since then we would - hit the bug at 8191 boundary instead of the 8192 one. - The actual PR suggests simply removing the setting of '\0' - which looks good, but there are loads of places in the related - code where we use AP_IOBUFSIZE, so it seemed safer to me to - simply allocate an extra byte. Note that other sections of - code do this by setting the endpos to one less to "save" - space for the NUL, but they don't have related sections - which assume a set size; this does (AP_IOBUFSIZE). - - * mod_status: For long request lines we only see the front part of - the requests in mod_status, which is useless if they only vary - in their ending bits. Allow admin to specify whether they want - to see the 1st 63 chars of the request, or the last. - trunk: - http://svn.apache.org/viewvc?view=rev&revision=590641 - 2.2.x: - http://people.apache.org/~jim/patches/reqtail-patch.txt - +1: jim, rpluem - - * http_filters: Fix handling of unrecognised Transfer Encodings - PR 43882 - http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?r1=592951&r2=599137 - http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?r1=595672&r2=595671&pathrev=595672 (CHANGES) - +1: niq, rpluem - niq says: modified in 599059 (following suggestion by trawick) - - * mod_proxy: Support variable interpolation in reverse proxy configuration - (revised proposal dealing with wrowe's concerns). - trunk: - http://svn.apache.org/viewvc?view=rev&revision=421686 (code) - http://svn.apache.org/viewvc?view=rev&revision=422178 (code) - http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml?r1=420990&r2=421725 (docs) - http://svn.apache.org/viewvc?view=rev&revision=589371 (code+docs) - 2.2.x: - http://people.apache.org/~niq/proxy-interp.patch - rpluem says: Please add the documentation to your 2.2.x version of your - patch and a minor bump (changes to public mod_proxy.h) and - assume you are +1 to your own proposal. + * mod_rewrite: Also set the Vary header if a rewrite condition is true and + uses a HTTP header, but all remaining rewrite conditions are skipped due + to the [OR] flag. + Trunk version of patch: + http://svn.apache.org/viewcvs.cgi?rev=574201&view=rev + Backport version for 2.2.x of patch: + Trunk version of patch works + +1: rpluem, niq + +0: jim: I'm curious that if this would result in some + "regressions" for some users who either depend on + the old behavior or have worked around it... + rpluem answers: If r574684 is backported (see below) these users can + fix it without workarounds and a clear and promised behaviour. + Relying on the above is relying on a buggy iundocumented behaviour, + but yes I do this sometimes by myself :-). + +1: jim: iff r574684 is also backported + + * mod_rewrite: Add the novary flag to RewriteCond in order to prevent + the appending of HTTP headers used in a rewrite condition to the Vary + header of the response. + Trunk version of patch: + http://svn.apache.org/viewcvs.cgi?rev=574684&view=rev + Backport version for 2.2.x of patch: + Trunk version of patch works + +1: rpluem, jim + * core log.c: Work around possible solutions rejected by apr for + the old implementation of apr_proc_create(), and explicitly pass + the output and error channels to all log processes created. + This goes all the way back to piped logs failing to run on win32. + Not in or needed at trunk/, as apr 1.3.0 has the proper fix. + http://people.apache.org/~wrowe/httpd-2.0-2.2-procattr-bugfix-log.c.patch + +1: wrowe, rpluem + + * mod_proxy_http: Correctly forward unexpected interim (HTTP 1xx) responses + incorporating ap_send_interim_response core API + PR 16518 + trunk: + http://svn.apache.org/viewvc?view=rev&revision=582630 + http://svn.apache.org/viewvc?view=rev&revision=582652 + http://svn.apache.org/viewvc?view=rev&revision=582631 + http://svn.apache.org/viewvc?view=rev&revision=588806 + 2.2.x: + http://people.apache.org/~niq/16508.patch + +1: niq, rpluem - * mod_ssl: Enable to build with OpenSSL 0.9.9 - trunk: - http://svn.apache.org/viewvc?view=rev&revision=598019 - 2.2.x: - Trunk patches apply - +1: fuankg, rpluem + * server/protocol.c: Prevent 1-byte overflow on 8192 boundary in + ap_vrprintf(). PR 43310 + trunk: + http://svn.apache.org/viewvc?view=rev&revision=589461 + 2.2.x: + Trunk version of patch works + +1: jim, rpluem + niq: Doesn't allocating 2^n+1 bytes risk being horribly inefficient? + Would it make sense to reduce AP_IOBUFSIZE to 8091 so buf doesn't + go one over a big boundary? + jim: The issue is that we allocate an array of AP_IOBUFSIZE + but go beyond that (note we send the end to curpos+AP_IOBUFSIZE) + so it's not just reducing AP_IOBUFSIZE since then we would + hit the bug at 8191 boundary instead of the 8192 one. + The actual PR suggests simply removing the setting of '\0' + which looks good, but there are loads of places in the related + code where we use AP_IOBUFSIZE, so it seemed safer to me to + simply allocate an extra byte. Note that other sections of + code do this by setting the endpos to one less to "save" + space for the NUL, but they don't have related sections + which assume a set size; this does (AP_IOBUFSIZE). + + * mod_status: For long request lines we only see the front part of + the requests in mod_status, which is useless if they only vary + in their ending bits. Allow admin to specify whether they want + to see the 1st 63 chars of the request, or the last. + trunk: + http://svn.apache.org/viewvc?view=rev&revision=590641 + 2.2.x: + http://people.apache.org/~jim/patches/reqtail-patch.txt + +1: jim, rpluem + + * http_filters: Fix handling of unrecognised Transfer Encodings + PR 43882 + http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?r1=592951&r2=599137 + http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?r1=595672&r2=595671&pathrev=595672 (CHANGES) + +1: niq, rpluem + niq says: modified in 599059 (following suggestion by trawick) - * mod_substitute: New module for on-the-fly response rewrite-like - capability. + * mod_proxy: Support variable interpolation in reverse proxy configuration + (revised proposal dealing with wrowe's concerns). trunk: - http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/experimental/mod_substitute.c?view=log - Don't even bother... - 2.2.x: - http://people.apache.org/~jim/patches/mod_substitute-2.2.txt - +1: jim - +0: rpluem says: There is much copying in do_pattmatch in the flatten case - and I would like to see the usage of tpool in the usage of - the SEDSCAT macro. + http://svn.apache.org/viewvc?view=rev&revision=421686 (code) + http://svn.apache.org/viewvc?view=rev&revision=422178 (code) + http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml?r1=420990&r2=421725 (docs) + http://svn.apache.org/viewvc?view=rev&revision=589371 (code+docs) + 2.2.x: + http://people.apache.org/~niq/proxy-interp.patch + rpluem says: Please add the documentation to your 2.2.x version of your + patch and a minor bump (changes to public mod_proxy.h) and + assume you are +1 to your own proposal. + + * mod_ssl: Enable to build with OpenSSL 0.9.9 + trunk: + http://svn.apache.org/viewvc?view=rev&revision=598019 + 2.2.x: + Trunk patches apply + +1: fuankg, rpluem + + * mod_substitute: New module for on-the-fly response rewrite-like + capability. + trunk: + http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/experimental/mod_substitute.c?view=log + Don't even bother... + 2.2.x: + http://people.apache.org/~jim/patches/mod_substitute-2.2.txt + +1: jim + +0: rpluem says: There is much copying in do_pattmatch in the flatten case + and I would like to see the usage of tpool in the usage of + the SEDSCAT macro. * mod_filter: Don't try to support chained filters when it doesn't work PR 43956 @@ -233,6 +232,12 @@ Backport version for 2.2.x of patch: Trunk version of patch works +1: rpluem, + + * http_protocol: Escape request method in 413 error reporting. + Determined to be not generally exploitable, but a flaw in any case. + PR 44014 [Victor Stinner ] + http://svn.apache.org/viewvc?view=rev&rev=600645 + +1: wrowe PATCHES/ISSUES THAT ARE STALLED