mod_ssl: follow up to r1868645.

[apache] / STATUS

diff --git a/STATUS b/STATUS
index dfdf2c4ea7b0c443383612ef3ac778b0987c4aff..7e5ad15683152f3ebb6dcc6d12a219e5142ef691 100644 (file)
--- a/STATUS
+++ b/STATUS
@@ -26,7 +26,8 @@ Release history:
     [NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
           while x.{even}.z versions are Stable/GA releases.]
 
-    2.5.0   : In Development.
+    2.5.1   : In development
+    2.5.0   : Tagged on November 8, 2017. Not released.
 
 Contributors looking for a mission:
 
@@ -59,6 +60,8 @@ THINGS THAT SHOULD BE CONSIDERED EARLY IN THE 2.6/3.0 DEVELOPMENT CYCLE:
   * Seriously ramp up/replace test framework and cases to have better
     coverage of existing special cases and behaviours users rely on.
 
+  * Add performance testing to the test framework.
+
   * Competely untangle core filesystem behavior where a filesystem htdocs/
     resource wasn't indicated by the request URI.
 
@@ -66,7 +69,7 @@ THINGS THAT SHOULD BE CONSIDERED EARLY IN THE 2.6/3.0 DEVELOPMENT CYCLE:
     a distinct decoded field used only for local filesystem access.
 
   * Change default prefix from /usr/local/apache2 to something corresponding
-    to the project name. Rename apachectl.
+    to the project name. Rename apachectl to httpdctl.
 
   * Change merge order of <Location> to be most specific match last. This
     is more consistent with <Directory> and allows some optimizations for the
@@ -105,10 +108,57 @@ THINGS THAT SHOULD BE CONSIDERED EARLY IN THE 2.6/3.0 DEVELOPMENT CYCLE:
   * add high-level server configuration directives that can steer/influence
     module defaults/warn/rejects related to security 
   
-  * Ditch HTTP/0.9?
+  * Ditch HTTP/0.9? At least, make HttpProtocolOptions Require1.0 the default.
+
+  * Restructure merge fn table/indexes to ignore modules with no directives,
+    and permit modules with dozens upon dozens of merge values to split these
+    into multiple functional config groups to avoid excessive merging.
+    Retitle from 'per-dir' to 'per-location' to better reflect the always-run
+    sections (location, ifexpr etc), while we phase out the file-oriented
+    bias from httpd.
 
   * New versioning or release cadence.
-  
+
+  * Ditch old APIs when we have the chance with 3.x. Consolidate current
+    functionality into APIs with stronger guarantees. (Specific examples TBD.)
+
+  * Remove as many undesirable-but-kept-for-backwards-compatibility behaviors
+    as possible from current config directives. (Specific examples TBD.)
+
+  * True event-loop/asynchronous support in the server core.
+
+  * Modify configuration syntax to separate meta-directives from runtime
+    directives (e.g. If vs. IfVersion). Allow as much static analysis of the
+    configuration as possible without needing to start the server to figure out
+    what's going on.
+
+  * Support JSON-like configuration files
+
+  * Opaque data structures w/ getters/setters 
+
+  * Generic interface to enable runtime changes (adjusting log level, modifying
+    balancer information, toggling flags on/off). Perhaps modules can register
+    callbacks for making these changes?
+
+  * REST-based administration for existing (balancer/etc) and new dynamic
+    runtime changes (see above)
+
+  * Improve the look of generated pages (status, load-balancer...) with dynamic
+    update of the values. Generate HTML5 pages, instead of 3.2, Get rid of XHTML
+    in the generated pages.
+
+  * Add performance monitoring of the server, of each module (?), in order to help
+    understanding what worth looking at in order to improve overall performance.
+    (https://cdn.wp.nginx.com/wp-content/uploads/2016/12/Amplify-Dashboards-page-base-for-filters.png)
+
+  * Drop CGI-1.1-incompatible behaviors kept for compatibility reasons with
+    "broken" server implementations (PR 51517). (Note that many of them are
+    "broken" *because* of our behaviors.)
+
+  * Add a "normalized" list of headers for a HTTP response, rather then relying
+    on r->headers_out and r->err_headers_out, since mod_headers' behavior is
+    not really user friendly in some scenarios (example in PR 62380). 
+
 
 OLD ISSUES THAT WERE THOUGHT TO BE SHOWSTOPPERS FOR 2.4 BUT OBVIOUSLY WEREN'T: