1
0
mirror of https://github.com/apache/httpd.git synced 2026-01-06 09:01:14 +03:00
Files
apache/modules/http2
Yann Ylavic 01d8e196dc mod_proxy_http: rework the flushing strategy when forwarding the request body.
Since the forwarding of 100-continue (end to end) in r1836588, we depended on
reading all of the requested HUGE_STRING_LEN bytes to avoid the flushes, but
this is a bit fragile.

This commit introduces the new stream_reqbody_read() function which will try a
nonblocking read first and, if it fails with EAGAIN, will flush on the backend
side before blocking for the next client side read.

We can then use it in stream_reqbody_{chunked,cl}() to flush client forwarded
data only when necessary. This both allows "optimal" flushing and simplifies
code (note that spool_reqbody_cl() also makes use of the new function but not
its nonblocking/flush functionality, thus only for consistency with the two
others, simplification and common error handling).

Also, since proxy_http_req_t::flushall/subprocess_env::proxy-flushall are now
meaningless (and unused) on the backend side, they are renamed respectively to
prefetch_nonblocking/proxy-prefetch-nonblocking, and solely determine whether
to prefetch in nonblocking mode or not. These flags were trunk only and may
not be really useful if we decided to prefetch in nonblocking mode in any case,
but for 2.4.x the opt-in looks wise.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853407 13f79535-47bb-0310-9956-ffa450edef68
2019-02-11 21:55:43 +00:00
..
2018-01-17 14:41:30 +00:00
2018-01-17 14:41:30 +00:00
2017-02-13 21:00:30 +00:00
2018-01-17 14:41:30 +00:00
2018-01-17 14:41:30 +00:00
2018-01-17 14:41:30 +00:00
2018-04-09 09:39:08 +00:00
2018-01-17 14:41:30 +00:00
2018-01-17 14:41:30 +00:00
2018-01-17 14:41:30 +00:00
2018-01-17 14:41:30 +00:00
2018-04-09 09:39:08 +00:00
2018-04-09 09:39:08 +00:00
2018-01-17 14:41:30 +00:00
2019-02-07 22:32:22 +00:00
2018-07-05 10:21:00 +00:00
2018-03-22 21:27:12 +00:00
2018-02-01 14:42:07 +00:00
2018-01-17 14:41:30 +00:00
2016-03-09 16:52:55 +00:00
2017-03-25 16:07:30 +00:00

The http2 module adds support for the HTTP/2 protocol to the server.

Specifically, it supports the protocols "h2" (HTTP2 over TLS) and "h2c" 
(HTTP2 over plain HTTP connections via Upgrade). Additionally it offers
the "direct" mode for both encrypted and unencrypted connections.

You may enable it for the whole server or specific virtual hosts only. 


BUILD

If you have libnghttp2 (https://nghttp2.org) installed on your system, simply
add 

    --enable-http2

to your httpd ./configure invocation. Should libnghttp2 reside in a unusual
location, add

    --with-nghttp2=<path>

to ./configure. <path> is expected to be the installation prefix, so there
should be a <path>/lib/libnghttp2.*. If your system support pkg-config,
<path>/lib/pkgconfig/libnghttp2.pc will be inspected.

If you want to link nghttp2 statically into the mod_http2 module, you may
similarly to mod_ssl add

    --enable-nghttp2-staticlib-deps

For this, the lib directory should only contain the libnghttp2.a, not its
shared cousins.


CONFIGURATION

If mod_http2 is enabled for a site or not depends on the new "Protocols"
directive. This directive list all protocols enabled for a server or
virtual host.

If you do not specify "Protocols" all available protocols are enabled. For
sites using TLS, the protocol supported by mod_http2 is "h2". For cleartext
http:, the offered protocol is "h2c".

The following is an example of a server that only supports http/1.1 in
general and offers h2 for a specific virtual host.

    ...
    Protocols http/1.1
    <virtualhost *:443>
        Protocols h2 http/1.1
        ...
    </virtualhost>

Please see the documentation of mod_http2 for a complete list and explanation 
of all options.


TLS CONFIGURATION

If you want to use HTTP/2 with a browser, most modern browsers will support
it without further configuration. However, browsers so far only support
HTTP/2 over TLS and are especially picky about the certificate and
encryption ciphers used.

Server admins may look for up-to-date information about "modern" TLS
compatibility under: 

  https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility