httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wr...@apache.org
Subject svn commit: r600649 - /httpd/httpd/branches/2.2.x/STATUS
Date Mon, 03 Dec 2007 19:57:07 GMT
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 <victor.stinner inl.fr>]
+       http://svn.apache.org/viewvc?view=rev&rev=600645
+    +1: wrowe
 
 PATCHES/ISSUES THAT ARE STALLED
 



Mime
View raw message