I really just did that on my test-merge branch??? fueque... reverting r1775787

                                                         -*- coding: utf-8 -*-

Changes with Apache 2.2.32

  *) SECURITY: CVE-2016-8743 (cve.mitre.org)

     Enforce HTTP request grammar corresponding to RFC7230 for request lines

     and request headers, to prevent response splitting and cache pollution by

     malicious clients or downstream proxies. [William Rowe, Stefan Fritsch]

  *) CVE-2016-5387: core: Mitigate [f]cgi "httpoxy" issues.

  *) core: CVE-2016-5387: Mitigate [f]cgi "httpoxy" issues.

     [Dominic Scheirlinck <dominic vendhq.com>, Yann Ylavic]

  *) Validate HTTP response header grammar defined by RFC7230, resulting

     in a 500 error in the event that invalid response header contents are

     detected when serving the response, to avoid response splitting and cache

     pollution by malicious clients, upstream servers or faulty modules.

     [Stefan Fritsch, Eric Covener, Yann Ylavic]

  *) core: Enforce LimitRequestFieldSize after multiple headers with the same

     name have been merged. [Stefan Fritsch]

  *) core: Drop Content-Length header and message-body from HTTP 204 responses.

     PR 51350 [Luca Toscano]

  *) core: Permit unencoded ';' characters to appear in proxy requests and

     Location: response headers. Corresponds to modern browser behavior.

     [William Rowe]

  *) core: ap_rgetline_core now pulls from r->proto_input_filters.

  *) core: Correctly parse an IPv6 literal host specification in an absolute

     URL in the request line. [Stefan Fritsch]

  *) core: New directive RegisterHttpMethod for registering non-standard

     HTTP methods. [Stefan Fritsch]

  *) core: Limit to ten the number of tolerated empty lines between request.

     [Yann Ylavic]

  *) core: reject NULLs in request line or request headers.

  *) Core: reject NULLs in request line or request headers.

     PR 43039 [Nick Kew]

  *) core: Avoid a possible truncation of the faulty header included in the

     HTML response when LimitRequestFieldSize is reached.  [Yann Ylavic]

  *) mod_ssl: Fix a possible memory leak on restart for custom [EC]DH params.

     [Jan Kaluza, Yann Ylavic]

  *) mod_proxy: Fix a regression with 2.2.31 that caused inherited workers to

     use a different scoreboard slot then the original one.  PR 58267.

     failures under Visual Studio 2015 and other mismatched MSVCRT flavors.

     PR59630 [Jan Ehrhardt <phpdev ehrhardt.nl>]

  *) mod_ssl: Fix a possible memory leak on restart for custom [EC]DH params.

     [Jan Kaluza, Yann Ylavic]

  *) core: Support custom ErrorDocuments for HTTP 501 and 414 status codes.

     PR 57167 [Edward Lu <Chaosed0 gmail.com>]

Changes with Apache 2.2.31

  *) Correct win32 build issues for mod_proxy exports, OpenSSL 1.0.x headers.

RELEASE SHOWSTOPPERS:

  *) Rather than odds-and-ends applied out of order, proposing we revert

     r1757240, r1757256, r1757295, r1758671, r1758672, r1775232, all of

     which is now recorded in the 2.2.x-merge-http-strict branch, and

     bring that branch back into 2.2.x for 2.4.32 release.

     Merges;

       -c-1775232 .

       -c-1757672 .

       -c-1757671 .

       -c-1757295 .

       -c-1757256 .

       -c-1757240 .

     [here we are back at 2.2.32-dev bump]

       -r1775685:1775780 https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x-merge-http-strict/

     Roll-up patch of the above (not recommended for casual reading, these

     would be committed individually as noted above... but for only for sanity

     testing the end result. Due to intervening CHANGES/ap_mmn changes, there

     is small delta after reverting the above...)

       https://raw.githubusercontent.com/wrowe/patches/master/httpd-2.2-HEAD-http-protocol-strict.patch

       This patch above does *NOT* apply to the 2.2.31 release, c.f. the delta

       of the 2.2.x-merge-http-strict branch for that information. This is for

       folks who are testing rollbacks plus 2.4.x activity against 2.2.x HEAD!

       Sorry to start from scratch, but yann's correct observation was correct,

       that nothing will apply out-of-order, and everything on 2.2 branch had

       already become disordered.

     +1: wrowe

PATCHES ACCEPTED TO BACKPORT FROM TRUNK:

  [ start all new proposals below, under PATCHES PROPOSED. ]

         http://home.apache.org/~ylavic/patches/httpd-2.2.x-r1753592.patch

      +1: ylavic

  *) Enforce LimitRequestFieldSize after multiple headers with the same

     name have been merged, Ensure LimitRequestFieldSize is always logged.

     Downgrade some more log messages indicating client errors from level error

     to info. Add log messages for various reasons to return HTTP_BAD_REQUEST.

     Correctly return a 400 (Bad request) in case of a HTTP/0.9 request like

     "GET @example.org/foo".

     Add some trace logging to core (using AP_DEBUG_THE_REQUEST macro, because

     the TRACE5 facilities aren't in 2.2.x branch).

     Improve error message (PR 54384).

     Submitted by: sf, rpluem, jailletc36

     [Note: everything in this patch is modifying logging and brings in the

     LimitRequestFieldSize logic used for the lifespan of 2.4.x]

     Trunk version of patch

         http://svn.apache.org/r951900 (server/protocol.c alone)

         http://svn.apache.org/r1178566

         http://svn.apache.org/r1185385

         http://svn.apache.org/r1188745

         http://svn.apache.org/r1352911

         http://svn.apache.org/r1433613

     Backport: (Adjustments dodging 2.4'isms such as APLOGNO's)

         https://raw.githubusercontent.com/wrowe/patches/master/backport-2.2.x-r951900-r1178566-r1185385-r1188745-r1352911-r1433613.patch 

     +1: wrowe, covener

     ylavic: the patch does not apply cleanly? (I tried both w/ and w/o

             backport-2.2.x-r892678.patch first, conflicts in protocol.c)

  *) core: ErrorDocument now works for requests without a Host header.

     Support custom ErrorDocuments for HTTP 501 and 414 status codes.

     PR: 48357, 57167

     Submitted by: trawick,  [Edward Lu <Chaosed0 gmail.com>]

     Trunk version of patch

         http://svn.apache.org/r1392347

         http://svn.apache.org/r1635762

     Backport:

         https://raw.githubusercontent.com/wrowe/patches/master/backport-2.2.x-r1392347-r1635762.patch 

     +1: wrowe, covener

     ylavic: same here (hunk + access_status = HTTP_BAD_REQUEST;)

             depends on the previous one?

  *) core: potential rejection of valid MaxMemFree and ThreadStackSize directives

     trunk patch: https://svn.apache.org/r1542338

     2.4.x patch: https://svn.apache.org/r1542549

</usage>

</directivesynopsis>

<directivesynopsis>

<name>HttpProtocolOptions</name>

<description>Modify restrictions on HTTP Request Messages</description>

<syntax>HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods]

 [Allow0.9|Require1.0]</syntax>

<default>HttpProtocolOptions Strict LenientMethods Allow0.9</default>

<contextlist><context>server config</context>

<context>virtual host</context></contextlist>

<compatibility>2.2.32 or 2.4.24 and later</compatibility>

<usage>

    <p>This directive changes the rules applied to the HTTP Request Line

    (<a href="https://tools.ietf.org/html/rfc7230#section-3.1.1"

      >RFC 7230 &sect;3.1.1</a>) and the HTTP Request Header Fields

    (<a href="https://tools.ietf.org/html/rfc7230#section-3.2"

      >RFC 7230 &sect;3.2</a>), which are now applied by default or using

    the <code>Strict</code> option. Due to legacy modules, applications or

    custom user-agents which must be deperecated the <code>Unsafe</code>

    option has been added to revert to the legacy behaviors. These rules

    are applied prior to request processing, so must be configured at the

    global or default (first) matching virtual host section, by IP/port

    interface (and not by name) to be honored.</p>

    <p>Prior to the introduction of this directive, the Apache HTTP Server

    request message parsers were tolerant of a number of forms of input

    which did not conform to the protocol.

    <a href="https://tools.ietf.org/html/rfc7230#section-9.4"

      >RFC 7230 &sect;9.4 Request Splitting</a> and

    <a href="https://tools.ietf.org/html/rfc7230#section-9.5"

      >&sect;9.5 Response Smuggling</a> call out only two of the potential

    risks of accepting non-conformant request messages, while

    <a href="https://tools.ietf.org/html/rfc7230#section-3.5"

         >RFC 7230 &sect;3.5</a> "Message Parsing Robustness" identify the

    risks of accepting obscure whitespace and request message formatting. 

    As of the introduction of this directive, all grammer rules of the

    specification are enforced in the default <code>Strict</code> operating

    mode, and the strict whitespace suggested by section 3.5 is enforced

    and cannot be relaxed.</p>

    <p>Users are strongly cautioned against toggling the <code>Unsafe</code>

    mode of operation, particularly on outward-facing, publicly accessible

    server deployments.  If an interface is required for faulty monitoring

    or other custom service consumers running on an intranet, users should

    toggle the Unsafe option only on a specific virtual host configured

    to service their internal private network.</p>

    <p>Reviewing the messages logged to the <directive>ErrorLog</directive>,

    configured with <directive>LogLevel</directive> <code>debug</code> level,

    can help identify such faulty requests along with their origin.

    Users should pay particular attention to the 400 responses in the access

    log for invalid requests which were unexpectedly rejected.</p>

    <p><a href="https://tools.ietf.org/html/rfc7231#section-4.1"

         >RFC 7231 &sect;4.1</a> "Request Methods" "Overview" requires that

    origin servers shall respond with an error when an unsupported method

    is encountered in the request line. This already happens when the

    <code>LenientMethods</code> option is used, but administrators may wish

    to toggle the <code>RegisteredMethods</code> option and register any

    non-standard methods using the <directive>RegisterHttpMethod</directive>

    directive, particularly if the <code>Unsafe</code> option has been toggled.

    The <code>RegisteredMethods</code> option should <strong>not</strong>

    be toggled for forward proxy hosts, as the methods supported by the

    origin servers are unknown to the proxy server.</p>

    <p><a href="https://tools.ietf.org/html/rfc2616#section-19.6"

         >RFC 2616 &sect;19.6</a> "Compatibility With Previous Versions" had

    encouraged HTTP servers to support legacy HTTP/0.9 requests. RFC 7230

    superceeds this with "The expectation to support HTTP/0.9 requests has

    been removed" and offers additional comments in 

    <a href="https://tools.ietf.org/html/rfc7230#appendix-A"

      >RFC 7230 Appendix A</a>. The <code>Require1.0</code> option allows

    the user to remove support of the default <code>Allow0.9</code> option's

    behavior.</p>

</usage>

</directivesynopsis>

<directivesynopsis type="section">

<name>IfDefine</name>

<description>Encloses directives that will be processed only

</usage>

</directivesynopsis>

<directivesynopsis>

<name>RegisterHttpMethod</name>

<description>Register non-standard HTTP methods</description>

<syntax>RegisterHttpMethod <var>method</var> [<var>method</var> [...]]</syntax>

<contextlist><context>server config</context></contextlist>

<usage>

<p>HTTP Methods that are not conforming to the relvant RFCs are normally

rejected by request processing in Apache HTTPD. To avoid this, modules

can register non-standard HTTP methods they support.

The <directive>RegisterHttpMethod</directive> allows to register such

methods manually. This can be useful for if such methods are forwared

for external processing, e.g. to a CGI script.</p>

</usage>

</directivesynopsis>

</modulesynopsis>

 * 20051115.40 (2.2.30) Add ap_map_http_request_error()

 * 20051115.41 (2.2.32) Add s member to proxy_server_conf struct and server

 *                      member to proxy_worker struct.

 * 20151115.42 (2.2.32) Add http09_enable, http_conformance, and

 *                      http_methods to core_server_config

 *                      Add ap_scan_http_field_token(),

 *                      ap_scan_http_field_content(),

 *                      and ap_scan_vchar_obstext()

 *                      Replaced fold boolean with with multiple bit flags

 *                      to ap_[r]getline()

 */

#define MODULE_MAGIC_COOKIE 0x41503232UL /* "AP22" */

#ifndef MODULE_MAGIC_NUMBER_MAJOR

#define MODULE_MAGIC_NUMBER_MAJOR 20051115

#endif

#define MODULE_MAGIC_NUMBER_MINOR 42                    /* 0...n */

#define MODULE_MAGIC_NUMBER_MINOR 41                    /* 0...n */

/**

 * Determine if the server's current MODULE_MAGIC_NUMBER is at least a

#define AP_MERGE_TRAILERS_DISABLE  2

    int merge_trailers;

#define AP_HTTP09_UNSET   0

#define AP_HTTP09_ENABLE  1

#define AP_HTTP09_DISABLE 2

    char http09_enable;

#define AP_HTTP_CONFORMANCE_UNSET     0

#define AP_HTTP_CONFORMANCE_UNSAFE    1

#define AP_HTTP_CONFORMANCE_STRICT    2

    char http_conformance;

#define AP_HTTP_METHODS_UNSET         0

#define AP_HTTP_METHODS_LENIENT       1

#define AP_HTTP_METHODS_REGISTERED    2

    char http_methods;

} core_server_config;

/* for AddOutputFiltersByType in core.c */