Four different indentions? Normalize this, and add PR 44014 to the list.

It makes it so much easier to bounce entries from 2.2 to 2.0 status

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x@600650 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/STATUS b/STATUS
index b219b58c6cecf8e253136373bf1777831a7a9c78..2a6a387c19be4f6193f0022b8bddf7705fd78ced 100644 (file)
--- a/STATUS
+++ b/STATUS
@@ -85,52 +85,52 @@ Release history:
 
 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:
 
-      http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2.0&keywords=PatchAvailable
+    http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2.0&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.0.x releases, such
-      that no MMN major number changes will occur.  Such changes can only be
-      made in the trunk.
+  * Forward binary compatibility is expected of Apache 2.0.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.0.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, and finally merge into branches/2.0.x, as applicable.
+  * All commits to branches/2.0.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, and finally merge into branches/2.0.x, as applicable.
 
 
 RELEASE SHOWSTOPPERS:
 
-   * core log.c: Authored and Reviewed by both rplume and wrowe within 
-     the same 10 minutes, share only a single apr_file_t/fd between the
-     stderr and server_main->error_log to prevent any lingering write 
-     handles from hanging around in unexpected ways.
-        http://svn.apache.org/viewvc?view=rev&revision=580437
-      PR 43491, solution validated by reporter
-      +1: wrowe, rpluem
+  * core log.c: Authored and Reviewed by both rplume and wrowe within 
+    the same 10 minutes, share only a single apr_file_t/fd between the
+    stderr and server_main->error_log to prevent any lingering write 
+    handles from hanging around in unexpected ways.
+       http://svn.apache.org/viewvc?view=rev&revision=580437
+     PR 43491, solution validated by reporter
+     +1: wrowe, rpluem
 
-   * 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 says: Is this really the correct thing to do on UNIX? I am not sure
-     if all dup2 implementation notice that both fd's are the same. Otherwise
-     they close stdout/stderr first and dup a then closed fd in stdout/stderr,
-     leaving us without stdout/stderr in the child.
+  * 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 says: Is this really the correct thing to do on UNIX? I am not sure
+    if all dup2 implementation notice that both fd's are the same. Otherwise
+    they close stdout/stderr first and dup a then closed fd in stdout/stderr,
+    leaving us without stdout/stderr in the child.
 
 
 
@@ -143,30 +143,35 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
     identify exactly what the proposed changes are!  Add all new
     proposals to the end of this list. ]
 
-    *) Backport 102870; PR 17217; stop linking OpenSSL .so's to support/*
-       binaries (especially when compiled --with-static-support (!)) and
-       fix mod_ssl.so to compile against .a openssl archives.
-         http://svn.apache.org/viewcvs.cgi?rev=102870&view=rev
-       +1: wrowe, colm
-       -1: jim (does not cleanly backport)
-
-    *) Backport 327179; PR 31226; allow ap_add_output_filters_by_type to handle
-       proxied requests.  Basic tests by jorton and [rpluem] show that this works, 
-       nobody can actually remember why this limitation was introduced at all 
-       (r94028) and the mailing list archives also gave no hint.
-         http://svn.apache.org/viewvc?view=rev&revision=327179
-                 
-       +0: covener
-             do we need to make people opt-in for this behavior to 
-             backport it to 2.0.x? What mechanism?
-
-    *) Initialize all algorithms in OpenSSL; PRs 35469, 42035
-       Trunk:
-         http://svn.apache.org/viewvc?view=rev&revision=226777
-       2.0.x:
-         Patch submitted via PR 42035 by Dominique Quatravaux 
-         http://issues.apache.org/bugzilla/attachment.cgi?id=19901
-       +1: trawick
+  * Backport 102870; PR 17217; stop linking OpenSSL .so's to support/*
+    binaries (especially when compiled --with-static-support (!)) and
+    fix mod_ssl.so to compile against .a openssl archives.
+      http://svn.apache.org/viewcvs.cgi?rev=102870&view=rev
+    +1: wrowe, colm
+    -1: jim (does not cleanly backport)
+
+  * Backport 327179; PR 31226; allow ap_add_output_filters_by_type to handle
+    proxied requests.  Basic tests by jorton and [rpluem] show that this works, 
+    nobody can actually remember why this limitation was introduced at all 
+    (r94028) and the mailing list archives also gave no hint.
+      http://svn.apache.org/viewvc?view=rev&revision=327179
+    +0: covener
+          do we need to make people opt-in for this behavior to 
+          backport it to 2.0.x? What mechanism?
+
+  * Initialize all algorithms in OpenSSL; PRs 35469, 42035
+    Trunk:
+      http://svn.apache.org/viewvc?view=rev&revision=226777
+    2.0.x:
+      Patch submitted via PR 42035 by Dominique Quatravaux 
+      http://issues.apache.org/bugzilla/attachment.cgi?id=19901
+    +1: trawick
+
+  * 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 TO BACKPORT THAT ARE ON HOLD OR NOT GOING ANYWHERE SOON: