Commit 6fdc17af authored by Jim Jagielski's avatar Jim Jagielski
Browse files

Merge r1697855, r1697339, r1696428, r1696266, r1696264, r1695874, r1695727,... 

Merge r1697855, r1697339, r1696428, r1696266, r1696264, r1695874, r1695727, r1692516, r1692486, r1610674, r1685069, r1693918, r1698116, r1698133, r1694950, r1700968, r1701005, r1701145, r1701178 from trunk:

adding ap_get_protocol(c) which safeguards against NULL returns, for use instead of direct calling ap_run_protocol_get

changed Protocols to let vhosts override servers, removed old H2Engine example from readme

creating ap_array_index in util, forwarding scheme into request processing, enabling SSL vars only when scheme is not http:, delayed connection creation until task worker assignment

removed unnecessary lingering_close and sbh update on end of protocol upgrade handling

introducing ap_array_index in util, used in protocol and mod_h2

fixes existing protocol missing in selection if not explicitly proposed

new directive ProtocolsHonorOrder, added documentation for Protocols feature, changed preference selection and config merging

removed accidental code

new Protocols directive and core API changes to enable protocol switching on HTTP Upgrade or ALPN, implemented in mod_ssl and mod_h2

SECURITY (CVE-2014-0117): Fix a crash in mod_proxy.  In a reverse
proxy configuration, a remote attacker could send a carefully crafted
request which could crash a server process, resulting in denial of
service.

Thanks to Marek Kroemeke working with HP's Zero Day Initiative for
reporting this issue.

* server/util.c (ap_parse_token_list_strict): New function.

* modules/proxy/proxy_util.c (find_conn_headers): Use it here.

* modules/proxy/mod_proxy_http.c (ap_proxy_http_process_response):
  Send a 400 for a malformed Connection header.

Submitted by: Edward Lu, breser, covener


http, mod_ssl: Introduce and return the 421 (Misdirected Request) status code
for clients requesting a hostname on a reused connection whose SNI (from the
TLS handshake) does not match.
PR 5802.

This allows HTTP/2 clients to fall back to a new connection as per:
https://tools.ietf.org/html/rfc7540#section-9.1.2

Proposed by: Stefan Eissing <stefan eissing.org>
Reviewed by: ylavic


c89


Allowing protocol_propose hooks to be called with offers=NULL, clarifying semantics as proposed by chaosed0@gmail.com

giving ap_array_index a start parameter, adding ap_array_contains

ap_process_request needs exportation for use in mod_h2 on Windows


final final change to the new ap_array_str_* functions after review

changed Protocols default to http/1.1 only, updated documentation, changed ap_select_protocol() to return NULL when no protocol could be agreed upon

mod_ssl: fix compiler warning (bad cast).

improvements in ap_select_protocol(), supplied by yann ylavic
Submitted by: icing, jorton, ylavic, covener, icing, icing, gsmith, icing, icing, ylavic, icing
Reviewed/backported by: jim


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1705672 13f79535-47bb-0310-9956-ffa450edef68
parent 344cfc9a

STATUS

+0 −30
Original line number Diff line number Diff line
@@ -110,36 +110,6 @@ RELEASE SHOWSTOPPERS: 
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:

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



  *) core/mod_ssl: add Protocols/ProtocolsHonorOrder directives and new 

     protocols hooks to control Upgrade: and ALPN protocol switching.

     HTTP_MISDIRECTED_REQUEST addition and handling in mod_ssl

     trunk patch: http://svn.apache.org/r1697855

                  http://svn.apache.org/r1697339

                  http://svn.apache.org/r1696428

                  http://svn.apache.org/r1696266

                  http://svn.apache.org/r1696264

                  http://svn.apache.org/r1695874

                  http://svn.apache.org/r1695727

                  http://svn.apache.org/r1692516

                  http://svn.apache.org/r1692486

                  http://svn.apache.org/r1610674

                  http://svn.apache.org/r1685069

                  http://svn.apache.org/r1693918

                  http://svn.apache.org/r1698116

                  http://svn.apache.org/r1698133

                  http://svn.apache.org/r1694950

                  http://svn.apache.org/r1700968

                  http://svn.apache.org/r1701005

                  http://svn.apache.org/r1701145

                  http://svn.apache.org/r1701178

     All changes to files in modules/http2 need to be ignored.

     v2: added r1698116, r1693918 to patch

     v3: added changes to ap_array_index and ap_array_contains

     2.4.x patch: https://raw.githubusercontent.com/icing/mod_h2/master/sandbox/httpd/patches/core-protocols-v4.patch

     +1: icing, jim, minfrin

     ylavic: should/could we set the "experimental" bits for the hooks

             protocol_{propose,switch} before backporting?



  *) mod_h2: add HTTP/2 support to httpd, depends on core/mod_ssl changes above

     2.4.x branch for this and core/mod_ssl: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.17-protocols-http2

     See diff and merged changelists via:

docs/manual/mod/core.xml

+68 −0
Original line number Diff line number Diff line
@@ -3589,6 +3589,74 @@ On Windows, from Apache 2.3.3 and later.</compatibility> 
</directivesynopsis>





<directivesynopsis>

    <name>Protocols</name>

    <description>Protocols available for a server/virtual host</description>

    <syntax>Protocols <var>protocol</var> ...</syntax>

    <default>Protocols http/1.1</default>

    <contextlist><context>server config</context><context>virtual host</context></contextlist>

    <compatibility>Only available from Apache 2.4.17 and later.</compatibility>

    

    <usage>

        <p>This directive specifies the list of protocols supported for a

            server/virtual host. The list determines the allowed protocols

            a client may negotiate for this server/host.</p>

        

        <p>You need to set protocols if you want to extend the available

            protocols for a server/host. By default, only the http/1.1 protocol

            (which includes the compatibility with 1.0 and 0.9 clients) is

            allowed.</p>

        

        <p>For example, if you want to support HTTP/2 for a server with TLS, 

            specify:</p>

        

        <highlight language="config">

            Protocols h2 http/1.1

        </highlight>



        <p>Valid protocols are <code>http/1.1</code> for http and https connections,

            <code>h2</code> on https connections and <code>h2c</code> for http

            connections. Modules may enable more protocols.</p>

        

        <p>It is safe to specify protocols that are unavailable/disabled. Such

        protocol names will simply be ignored.</p>

        

        <p>Protocols specified in base servers are inherited for virtual hosts 

            only if the virtual host has no own Protocols directive. Or, the other

            way around, Protocols directives in virtual hosts replace any

            such directive in the base server.

        </p>



    </usage>

    <seealso><directive module="core">ProtocolsHonorOrder</directive></seealso>

</directivesynopsis>





<directivesynopsis>

    <name>ProtocolsHonorOrder</name>

    <description>Protocols available for a server/virtual host</description>

    <syntax>ProtocolsHonorOrder On|Off</syntax>

    <default>ProtocolsHonorOrder On</default>

    <contextlist><context>server config</context><context>virtual host</context></contextlist>

    <compatibility>Only available from Apache 2.4.17 and later.</compatibility>

    

    <usage>

        <p>This directive specifies if the server should honor the order in which

        the <directive>Protocols</directive> directive lists protocols.</p>

        

        <p>If configured Off, the client supplied list order of protocols has 

            precedence over the order in the server configuration.</p>

        

        <p>With <directive>ProtocolsHonorOrder</directive> set to <code>on</code> 

            (default), the client ordering does not matter and only the ordering 

            in the server settings influences the outcome of the protocol 

            negotiation.</p>

        

    </usage>

    <seealso><directive module="core">Protocols</directive></seealso>

</directivesynopsis>





<directivesynopsis>

<name>RLimitCPU</name>

<description>Limits the CPU consumption of processes launched

include/http_core.h

+4 −0
Original line number Diff line number Diff line
@@ -681,6 +681,10 @@ typedef struct { 
#define AP_MERGE_TRAILERS_DISABLE  2

    int merge_trailers;







    apr_array_header_t *protocols;

    int protocols_honor_order;

} core_server_config;



/* for AddOutputFiltersByType in core.c */

include/http_protocol.h

+133 −0
Original line number Diff line number Diff line
@@ -700,6 +700,139 @@ AP_DECLARE_HOOK(const char *,http_scheme,(const request_rec *r)) 
 */

AP_DECLARE_HOOK(apr_port_t,default_port,(const request_rec *r))





#define AP_PROTOCOL_HTTP1		"http/1.1"



/**

 * Determine the list of protocols available for a connection/request. This may

 * be collected with or without any request sent, in which case the request is 

 * NULL. Or it may be triggered by the request received, e.g. through the 

 * "Upgrade" header.

 *

 * This hook will be run whenever protocols are being negotiated (ALPN as

 * one example). It may also be invoked at other times, e.g. when the server

 * wants to advertise protocols it is capable of switching to.

 * 

 * The identifiers for protocols are taken from the TLS extension type ALPN:

 * https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xml

 *

 * If no protocols are added to the proposals, the server not perform any

 * switch. If the protocol selected from the proposals is the protocol

 * already in place, also no protocol switch will be invoked.

 *

 * The client may already have announced the protocols it is willing to

 * accept. These will then be listed as offers. This parameter may also

 * be NULL, indicating that offers from the client are not known and

 * the hooks should propose all protocols that are valid for the

 * current connection/request.

 *

 * All hooks are run, unless one returns an error. Proposals may contain

 * duplicates. The order in which proposals are added is usually ignored.

 * 

 * @param c The current connection

 * @param r The current request or NULL

 * @param s The server/virtual host selected

 * @param offers A list of protocol identifiers offered by the client or

 *               NULL to indicated that the hooks are free to propose 

 * @param proposals The list of protocol identifiers proposed by the hooks

 * @return OK or DECLINED

 */

AP_DECLARE_HOOK(int,protocol_propose,(conn_rec *c, request_rec *r,

                                      server_rec *s,

                                      const apr_array_header_t *offers,

                                      apr_array_header_t *proposals))



/**

 * Perform a protocol switch on the connection. The exact requirements for

 * that depend on the protocol in place and the one switched to. The first 

 * protocol module to handle the switch is the last module run.

 * 

 * For a connection level switch (r == NULL), the handler must on return

 * leave the conn_rec in a state suitable for processing the switched

 * protocol, e.g. correct filters in place.

 *

 * For a request triggered switch (r != NULL), the protocol switch is done

 * before the response is sent out. When switching from "http/1.1" via Upgrade

 * header, the 101 intermediate response will have been sent. The

 * hook needs then to process the connection until it can be closed. Which

 * the server will enforce on hook return.

 * Any error the hook might encounter must already be sent by the hook itself

 * to the client in whatever form the new protocol requires.

 *

 * @param c The current connection

 * @param r The current request or NULL

 * @param s The server/virtual host selected

 * @param choices A list of protocol identifiers, normally the clients whishes

 * @param proposals the list of protocol identifiers proposed by the hooks

 * @return OK or DECLINED

 */

AP_DECLARE_HOOK(int,protocol_switch,(conn_rec *c, request_rec *r,

                                     server_rec *s,

                                     const char *protocol))



/**

 * Return the protocol used on the connection. Modules implementing

 * protocol switching must register here and return the correct protocol

 * identifier for connections they switched.

 *

 * To find out the protocol for the current connection, better call

 * @see ap_get_protocol which internally uses this hook.

 *

 * @param c The current connection

 * @return The identifier of the protocol in place or NULL

 */

AP_DECLARE_HOOK(const char *,protocol_get,(const conn_rec *c))

    

/**

 * Select a protocol for the given connection and optional request. Will return

 * the protocol identifier selected which may be the protocol already in place

 * on the connection. The selected protocol will be NULL if non of the given

 * choices could be agreed upon (e.g. no proposal as made).

 *

 * A special case is where the choices itself is NULL (instead of empty). In

 * this case there are no restrictions imposed on protocol selection.

 *

 * @param c The current connection

 * @param r The current request or NULL

 * @param s The server/virtual host selected

 * @param choices A list of protocol identifiers, normally the clients whishes

 * @return The selected protocol or NULL if no protocol could be agreed upon

 */

AP_DECLARE(const char *) ap_select_protocol(conn_rec *c, request_rec *r, 

                                            server_rec *s,

                                            const apr_array_header_t *choices);



/**

 * Perform the actual protocol switch. The protocol given must have been

 * selected before on the very same connection and request pair.

 *

 * @param c The current connection

 * @param r The current request or NULL

 * @param s The server/virtual host selected

 * @param protocol the protocol to switch to

 * @return APR_SUCCESS, if caller may continue processing as usual

 *         APR_EOF,     if caller needs to stop processing the connection

 *         APR_EINVAL,  if the protocol is already in place

 *         APR_NOTIMPL, if no module performed the switch

 *         Other errors where appropriate

 */

AP_DECLARE(apr_status_t) ap_switch_protocol(conn_rec *c, request_rec *r, 

                                            server_rec *s,

                                            const char *protocol);



/**

 * Call the protocol_get hook to determine the protocol currently in use

 * for the given connection.

 *

 * Unless another protocol has been switch to, will default to

 * @see AP_PROTOCOL_HTTP1 and modules implementing a  new protocol must

 * report a switched connection via the protocol_get hook.

 *

 * @param c The connection to determine the protocol for

 * @return the protocol in use, never NULL

 */

AP_DECLARE(const char *) ap_get_protocol(conn_rec *c);



/** @see ap_bucket_type_error */

typedef struct ap_bucket_error ap_bucket_error;

include/http_request.h

+1 −1
Original line number Diff line number Diff line
@@ -315,7 +315,7 @@ AP_DECLARE(void) ap_allow_standard_methods(request_rec *r, int reset, ...); 
 * the response to the client

 * @param r The current request

 */

void ap_process_request(request_rec *r);

AP_DECLARE(void) ap_process_request(request_rec *r);



/* For post-processing after a handler has finished with a request.

 * (Commonly used after it was suspended)