Vote.

[apache] / STATUS

APACHE 2.4 STATUS:                        -*- mode: text; coding: utf-8 -*-
Last modified at [$Date$]

The current version of this file can be found at:

  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/STATUS

Documentation status is maintained separately and can be found at:

  * docs/STATUS in this source tree, or
  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/docs/STATUS

The current development branch of this software can be found at:

  * http://svn.apache.org/repos/asf/httpd/httpd/trunk

Consult the following STATUS files for information on related projects:

  * http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
  * http://svn.apache.org/repos/asf/apr/apr/branches/1.4.x/STATUS
  * http://svn.apache.org/repos/asf/apr/apr-util/branches/1.4.x/STATUS
  * http://svn.apache.org/repos/asf/apr/apr/branches/1.5.x/STATUS
  * http://svn.apache.org/repos/asf/apr/apr-util/branches/1.5.x/STATUS

Patches considered for backport are noted in their branches' STATUS:

  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
  * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/STATUS



Release history:
    [NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
          while x.{even}.z versions are Stable/GA releases.]

    2.4.13  : In development.
    2.4.12  : Tagged on January 22, 2015.
    2.4.11  : Tagged on January 15, 2015. Not released.
    2.4.10  : Tagged on July 15, 2014. Released July 21, 2014
    2.4.9   : Tagged on March 13, 2014. Released on March 17, 2014
    2.4.8   : Tagged on March 11, 2014. Not released.
    2.4.7   : Tagged on November 19, 2013. Released on Nov 25, 2013
    2.4.6   : Tagged on July 15, 2013. Released July, 22, 2013
    2.4.5   : Tagged on July 11, 2013, not released.
    2.4.4   : Tagged on February 18, 2013. Released Feb 25, 2013
    2.4.3   : Tagged on August 17, 2012. Released Aug 18, 2012
    2.4.2   : Tagged on April 5, 2012. Released Apr 17, 2012.
    2.4.1   : Tagged on February 13, 2012. Released Feb 21, 2012.
    2.4.0   : Tagged on January 16, 2012, not released.
    2.3.16  : Tagged on December 15, 2011.
    2.3.15  : Tagged on November 8, 2011. Released Nov. 15, 2011.
    2.3.14  : Tagged on August 1, 2011. Released Aug. 9, 2011.
    2.3.13  : Tagged on June 28, 2011, not released.
    2.3.12  : Tagged on May 11, 2011. Released May 23, 2011.
    2.3.11  : Released as Beta on March 7, 2011.
    2.3.10  : Tagged on December 13, 2010. Released Dec 21, 2010.
    2.3.9   : Tagged on November 23, 2010, not released.
    2.3.8   : Tagged on August 24, 2010.
    2.3.7   : Tagged on August 19, 2010, not released.
    2.3.6   : Released on June 21, 2010.
    2.3.5   : Released on January 26, 2010.
    2.3.4   : Released on December 8, 2009.
    2.3.3   : Tagged on November 11, 2009, not released.
    2.3.2   : Tagged on March 23, 2009, not released.
    2.3.1   : Tagged on January 2, 2009, not released.
    2.3.0   : Tagged on December 6, 2008, not released.

Contributors looking for a mission:

  * Just do an egrep on "TODO" or "XXX" in the source.

  * Review the bug database at: http://issues.apache.org/bugzilla/

  * 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

    After testing, you can append a comment saying "Reviewed and tested".

  * Open bugs in the bug database.

  * See also the STATUS file in the docs/ directory, which lists documentation-specific TODO items.


CURRENT RELEASE NOTES:

  * Forward binary compatibility is expected of Apache 2.4.x releases, such
    that no MMN major number changes will occur after 2.4.1.  Such changes can
    only be made in the trunk.

  * All commits to branches/2.4.x must be reflected in SVN trunk,
    as well, if they apply.  Logical progression is commit to trunk
    then merge into branches/2.4.x, as applicable.

  * Current exceptions for RTC for this branch:
    . mod_lua
    . documentation
    . non-Unix build
    . non-Unix, single-platform code

RELEASE SHOWSTOPPERS:


PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
  [ start all new proposals below, under PATCHES PROPOSED. ]



PATCHES PROPOSED TO BACKPORT FROM TRUNK:
  [ New proposals should be added at the end of the list ]

   * mod_proxy: Add ap_proxy_define_match_worker() and use it for ProxyPassMatch
     and ProxyMatch section to distinguish between normal workers and workers
     with regex substitutions in the name. Implement handling of such workers
     in ap_proxy_get_worker(). Fixes the bug when regex workers were not
     matched and used for request. PR 43513.
     trunk patch: http://svn.apache.org/r1609680
                  http://svn.apache.org/r1609688
                  http://svn.apache.org/r1641381
     ylavic: Merge patch provided (reusing new->real to avoid double de_socketfy() call).
             Also added missing r1609688 to the patchset.
     2.4.x patch: http://people.apache.org/~ylavic/httpd-2.4.x-ap_proxy_define_match_worker.patch
     +1: ylavic
     -0: covener tried to review this one in Austin with Jeff.  Does the added match function 
         really cover a very narrow set of parameters with the way it skips over backreferences?
         Also, why a new API vs. just setting the field inline?

   * mod_proxy_ajp: Fix client connection errors handling and logged status
                    when it occurs.  PR 56823.
     trunk patch: http://svn.apache.org/r1643537
                  http://svn.apache.org/r1643543
                  http://svn.apache.org/r1674056
     2.4.x patch: trunk works (module CHANGES, docs/log-message-tags)
                  http://people.apache.org/~ylavic/httpd-2.4.x-mod_proxy_ajp-client_failed.patch
                  (for convenience/readability)
     +1: ylavic
     trawick: Eric and I were working through this and I (at least) ran into this
              particular roadblock: output_failed sometimes means that we couldn't
              write to the client and sometimes means that we couldn't read from
              the client; later, output_fails triggers setting the status to 400.
              HTTP status shouldn't be 400 for a problem writing to the client.
              (Maybe I missed some guarantee that 400 is only for an error reading
              enough request body??)  I think it would be good to separate output_failed
              from input_failed so that the code is more clear and we can more
              easily tell that the status code is appropriate.  (And unfortunately
              I don't volunteer to make the simple changes and test them :( )
     ylavic: I think the confusion comes from the (original) name output_failed itself,
             since it really means client_failed (i.e. "dialog with [client] %pI failed"),
             as opposed to backend_failed (i.e. "dialog with backend %pI failed").
             When an error occurs on any side (connection), the first flag used regarding
             4xx/5xx vs DONE is data_sent (i.e. to the client), otherwise {4xx,5xx} are
             returned according to {output,backend}_failed. So the clarification is
             possibly as simple as renaming output_failed => client_failed (r1674056 added
             above), WDYT?
             (Note that ap_map_http_request_error-v2.patch proposed below, which collides as
             explained in the comment there, shows the full/expected result wrt mod_proxy_ajp
             returned status/error/AP_FILTER_ERROR, and is maybe a more general (though bigger)
             backport that could include this one).

   * core: Add ap_errorlog_provider to make ErrorLog logging modular. This
           backport keeps syslog logging as part of httpd core and only adds
           API to allow other modules to be used for error logging.
     trunk patch: http://svn.apache.org/r1525597
                  http://svn.apache.org/r1525664
                  http://svn.apache.org/r1525845
                  http://svn.apache.org/r1527003
                  http://svn.apache.org/r1527005
                  http://svn.apache.org/r1532344
                  http://svn.apache.org/r1539988
                  http://svn.apache.org/r1541029
                  http://svn.apache.org/r1543979
                  http://svn.apache.org/r1544156
                  http://svn.apache.org/r1626978
     2.4.x patch: http://people.apache.org/~jkaluza/patches/httpd-2.4.x-errorlog_provider.patch
     +1: jkaluza
     +1: covener w/ doc or code to fix syntax (providername:providerarg not supported like syslog or socacheproviders, 
                 needs 2 args which is not valid in ErrorLog manual)
     trawick: nit: fix "writing" in "/* NULL if we are writting to syslog */"
              (sorry, haven't finished reviewing completely)

   * mod_journald: Add new module mod_journald to log error logs into journald.
                   This patch needs changes done in mod_systemd patch (already
                   proposed for 2.4.x).
     trunk patch: http://svn.apache.org/r1610339
                  http://svn.apache.org/r1621806
     2.4.x patch: http://people.apache.org/~jkaluza/patches/httpd-2.4.x-mod_journald.patch
     +1: jkaluza

   * MPMs: Support SO_REUSEPORT to create multiple duplicated listener
           records for scalability (full log in 2.4.x patch).
     trunk patch: http://svn.apache.org/r1599531
                  http://svn.apache.org/r1599593
                  http://svn.apache.org/r1599601
                  http://svn.apache.org/r1599603
                  http://svn.apache.org/r1601558
                  http://svn.apache.org/r1629909
                  http://svn.apache.org/r1629918
                  http://svn.apache.org/r1629990
                  http://svn.apache.org/r1635521
                  http://svn.apache.org/r1635859
                  http://svn.apache.org/r1640145
                  http://svn.apache.org/r1640161
                  http://svn.apache.org/r1640184
                  http://svn.apache.org/r1640763
                  http://svn.apache.org/r1643179
                  http://svn.apache.org/r1656368
                  http://svn.apache.org/r1679714
     2.4.x patch: http://people.apache.org/~ylavic/httpd-2.4.x-ap_listeners_buckets-v3.patch
     +1: ylavic, jim
     wrowe: the statics are not explicitly initialized for clarity
            ap_log_common is horribly named, perhaps ap_log_mpm_common()?
     ylavic: v3 with s/ap_log_common/ap_log_mpm_common/ (jim's vote discarded).
             globals (including statics) not initialized are implicitely initialized to zero
             per C standard, and go to .bss (zeroed as a whole at load time), whereas the ones
             explicitly initialized (even to 0 depending on the compiler/flags) go to .data and
             have each to be set to their init value (which may take some cycles at load time).
             I personaly don't see explicit initializations to {0} as a win (even for clarity...).

  *) http: Make ap_die() robust against any HTTP error code and not modify
     response status (finally logged) when nothing is to be done. PR 56035.
     trunk patch: http://svn.apache.org/r1657881
                  http://svn.apache.org/r1665643
     2.4.x patch: trunk works (modulo CHANGES)
     +1: ylavic, minfrin

  *) core, modules: Avoid error response/document handling by the core if some
     handler or input filter already did it while reading the request (causing
     a double response body).
     trunk patch: http://svn.apache.org/r1482522 (partial, ap_map_http_request_error() things only!)
                  http://svn.apache.org/r1529988
                  http://svn.apache.org/r1529991
                  http://svn.apache.org/r1643537
                  http://svn.apache.org/r1643543
                  http://svn.apache.org/r1657897
                  http://svn.apache.org/r1665625
                  http://svn.apache.org/r1665721
                  http://svn.apache.org/r1674056
     2.4.x patch: http://people.apache.org/~ylavic/httpd-2.4.x-ap_map_http_request_error-v2.patch
     +1: ylavic
     ylavic: depends on r1657881 above, and also r1643537+r1643543+r1674056 already
             proposed separately (if the latter proposal is accepted before
             this one, I'll take it easily into account with a v3 of the
             2.4.x patch, but currently the code from r1657897+r1665625
             collides, this patch shows the final result on mod_proxy_ajp
             though)

  *) core: Cleanup the request soon/even if some output filter fails to
     handle the EOR bucket.
     trunk patch: http://svn.apache.org/r1666998
     2.4.x patch: trunk works (modulo CHANGES)
     +1: ylavic

  *) http: Don't remove the Content-Length of zero from a HEAD response if
     it comes from an origin server, module or script. Allow the previous
     behaviour (for legacy/buggy modules only, not origin) by also backporting
     the HttpContentLengthHeadZero directive (and also HttpExpectStrict which
     comes for free with the same commit).
     trunk patch: http://svn.apache.org/r1554303
                  http://svn.apache.org/r1678215
     2.4.x patch: http://people.apache.org/~ylavic/httpd-2.4.x-preserve_head_cl_zero.patch
     +1: ylavic
     ylavic: r1554303 issued a major MMN bump, but since the ABI change is two
             ints added at the end of core_server_config, the proposed merge
             does a minor bump only.

  *) mod_authn_dbd, mod_authz_dbd, mod_session_dbd, mod_rewrite: Fix lifetime
     of DB lookup entries independently of the selected DB engine.  PR 46421.
     trunk patch: http://svn.apache.org/r1663647
                  http://svn.apache.org/r1679181
                  http://svn.apache.org/r1679182
     2.4.x patch: trunk works (modulo CHANGES)
     +1: ylavic

OTHER PROPOSALS

   * A list of further possible backports can be found at: 
     http://people.apache.org/~rjung/patches/possible-backports-httpd-trunk-2_4.txt
     If you want to propose one of those, please add them above.


PATCHES/ISSUES THAT ARE BEING WORKED

   * mod_proxy_http: Don't establish or reuse a backend connection before pre-
     fetching the request body, so to minimize the delay between it is supposed
     to be alive and the first bytes sent: this is a best effort to prevent the
     backend from closing because of idle or keepalive timeout in the meantime.
     Also, handle a new "proxy-flushall" environment variable which allows to
     flush any forwarded body data immediately. PR 56541+37920.
     trunk patch: http://svn.apache.org/r1656259
                  http://svn.apache.org/r1656359 (CHANGES entry)
     2.4.x patch: trunk works (modulo CHANGES, docs/log-message-tags)
     +1: ylavic
     -0: jim:  This seems to be a hit to normal performance, to handle an
               error and/or non-normal condition. The pre-fetch is
               expensive, and is always done, even before we know that
               the backend is available to rec' it. I understand the
               error described, but is the fix actually worth it (plus
               it seems to allow for a DDoS vector).
     ylavic: It seems to me that the problem is real since we reuse the
             connection before prefetching 16K (either controlled by the
             client, or by an input filter), we currently always prefetch
             these bytes already. Regarding performance I don't see any
             difference (more cycles) compared with the current code.
             However I think I failed to rebuild the header_brigade when
             the proxy loop is retried (ping), so I need to rework this.
             Do you think we'd better remove the prefetch, or maybe just
             make it nonblocking (by default)?
        jim: Non-blocking seems the best way to handle...


PATCHES/ISSUES THAT ARE STALLED

   * mod_systemd: New module, for integration with systemd on Linux.
     trunk patch: http://svn.apache.org/r1393976
                  http://svn.apache.org/r1393997
                  http://svn.apache.org/r1484554
                  http://svn.apache.org/r1528032
                  http://svn.apache.org/r1528034
                  http://svn.apache.org/r1614821
                  http://svn.apache.org/r1618579
                  http://svn.apache.org/r1618588
     2.4.x patch: http://people.apache.org/~jkaluza/patches/mod_systemd/httpd-2.4.x-mod_systemd.patch
     +1: jkaluza

   * core: Add support for systemd socket activation.
     trunk patch: http://svn.apache.org/r1511033
                  http://svn.apache.org/r1608686
                  http://svn.apache.org/r1608694
                  http://svn.apache.org/r1608703
                  http://svn.apache.org/r1608721
                  http://svn.apache.org/r1608744
     2.4.x patch: http://people.apache.org/~jkaluza/patches/mod_systemd/httpd-2.4.x-socket-activation.patch
     +1: jkaluza

  * core: Stop the HTTP_IN filter from attempting to write error buckets
    to the output filters
    trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1482522
                 https://svn.apache.org/viewvc?view=revision&revision=1482918
    2.4.x patch: /* working on it */
    +1:  jim

  * mod_proxy: Ensure network errors detected by the proxy are returned as
    504 Gateway Timout as opposed to 502 Bad Gateway
    trunk patch: https://svn.apache.org/viewvc?view=revision&revision=1480058
    2.4.x patch: trunk patch works modulo CHANGES
    +1:
    -1: rpluem: This change is still disputed. See
        http://mail-archives.apache.org/mod_mbox/httpd-dev/201305.mbox/%3C1B16B9E3-87BA-4EEF-939C-7C7313B54714%40gbiv.com%3E

  * cross-compile: allow to provide CC_FOR_BUILD so that gen_test_char will be
    compiled by the build compiler instead of the host compiler.
    Also set CC_FOR_BUILD to 'cc' when cross-compilation is detected.
    Trunk patches: http://svn.apache.org/viewvc?view=revision&revision=1327907
                   http://svn.apache.org/viewvc?view=revision&revision=1328390
                   http://svn.apache.org/viewvc?view=revision&revision=1328714
    2.4 patch: http://people.apache.org/~fuankg/diffs/httpd-2.4.x-cross_compile.diff
    fuankg: on hold until we agree for a better and more simple solution ...

   * Makefile.win: Added copying of .vbs / .wsf CGIs to Windows install target.
                   Moved fixing of shebang to separate target so that it is
                   no longer executed by default and all CGIs remain inactive.
     trunk patch: http://svn.apache.org/viewvc?view=revision&revision=1387984
                  http://svn.apache.org/viewvc?view=revision&revision=1421203
                  http://svn.apache.org/viewvc?view=revision&revision=1421591
     2.4.x patch: http://people.apache.org/~fuankg/diffs/httpd-2.4.x-Makefile.win.diff
     +1 fuankg, gsmith
     -.8: trawick
          This commit is essentially deciding that an httpd install on
          Windows now has printenv/testcgi written in 2 more languages.
          To the extent that the usefulness is that it shows how to make scripts
          of these types executable by httpd, I believe that the documentation
          is the proper place to solve that.  To the extent that the usefullness
          is to show how to implement a CGI in these particular languages, I believe
          that the httpd distribution and documentation in general is not the
          place for that.  Historically these types of scripts have caused problems
          for downstream vendorsas well as newbies (and sometimes the intersection
          of those two groups) who don't understand that these are information leaks
          once they are enabled, and the subtlety of the way they are disabled ("Apache
          messed up the first line; let me fix that") contributes to that.
     fuankg notes: I've just added a big warning to all CGI scripts which should now
          make absolutely clear that these CGIs are for testing purpose only - so those
          who enable those scripts with inserting the right shebang should be 100% aware
          of any risks (this should cover your last point).
     jim: trawick, does the above address your concerns?
     trawick: to some extent (somebody reading the script gets an idea)
          Why isn't the configuration requirement documented instead
          of described indirectly in a sample?
          Why are these new samples added to the install without three
          votes?  (I didn't veto it; put your name next to the two
          existing ones and I'll be satisified that enough people
          considered this addition as an appropriate solution for a
          real httpd usability problem.)
     wrowe: I'd agree with trawick, and suggest that these scripts can begin
            their life somewhere in the manual/ tree.  This really seems like
            the place where /usr/share/httpd/examples/ would be useful, but
            there isn't an ordinary directory for that.  Since we want none
            of the scripts to function 'out of the box', what about a new
            cgi-examples/ dir alongside cgi-bin/? Otherwise manual/cgi/examples
            might work?