Google Git Google Git
Sign in
apache/httpd/refs/heads/docs-modern-css/./docs/manual/mod/mod_http2.xml
blob: 70d712e7faabd0f2ebb2736d9c58f547b1d6f4cd [file]
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
<!-- $LastChangedRevision$ -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<modulesynopsis metafile="mod_http2.xml.meta">
<name>mod_http2</name>
<description>Support for the HTTP/2 transport layer</description>
<status>Extension</status>
<sourcefile>mod_http2.c</sourcefile>
<identifier>http2_module</identifier>
<compatibility>Available in version 2.4.17 and later</compatibility>
<summary>
<p>This module provides HTTP/2 (<rfc>7540</rfc>)
support for the Apache HTTP Server.</p>
<p>This module relies on <a href="http://nghttp2.org/">libnghttp2</a>
to provide the core http/2 engine.</p>
<p>You must enable HTTP/2 via <directive module="core">Protocols</directive>
in order to use the functionality described in this document. The
HTTP/2 protocol <a href="https://http2.github.io/faq/#does-http2-require-encryption"
>does not require</a> the use of encryption so two schemes are available:
<code>h2</code> (HTTP/2 over TLS) and <code>h2c</code> (HTTP/2 over TCP).</p>
<p>Two useful configuration schemes are:</p>
<note><title>HTTP/2 in a VirtualHost context (TLS only)</title>
<highlight language="config">
Protocols h2 http/1.1
</highlight>
<p>Allows HTTP/2 negotiation (h2) via TLS ALPN in a secure
<directive module="core" type="section">VirtualHost</directive>.
HTTP/2 preamble checking (Direct mode, see <directive module="mod_http2"
>H2Direct</directive>) is disabled by default for <code>h2</code>.</p>
</note>
<note><title>HTTP/2 in a Server context (TLS and cleartext)</title>
<highlight language="config">
Protocols h2 h2c http/1.1
</highlight>
<p>Allows HTTP/2 negotiation (h2) via TLS ALPN for secure
<directive module="core" type="section">VirtualHost</directive>. Allows
HTTP/2 cleartext negotiation (h2c) upgrading from an initial HTTP/1.1
connection or via HTTP/2 preamble checking (Direct mode, see
<directive module="mod_http2">H2Direct</directive>).</p>
</note>
<p>Refer to the official <a href="https://http2.github.io/faq">HTTP/2 FAQ</a>
for any doubt about the protocol.</p>
</summary>
<section id="how-it-works"><title>How it works</title>
<section id="dimensioning"><title>HTTP/2 Dimensioning</title>
<p>
Enabling HTTP/2 on your Apache Server has impact on the resource
consumption and if you have a busy site, you may need to consider
carefully the implications.
</p>
<p>
The first noticeable thing after enabling HTTP/2 is that your server
processes will start additional threads. The reason for this is that
HTTP/2 gives all requests that it receives to its own <em>Worker</em>
threads for processing, collects the results and streams them out
to the client.
</p>
<p>
In the current implementation, these workers use a separate thread
pool from the MPM workers that you might be familiar with. This is
just how things are right now and not intended to be like this forever.
(It might be forever for the 2.4.x release line, though.) So, HTTP/2
workers, or shorter H2Workers, will not show up in <module>mod_status</module>. They
are also not counted against directives such as <directive module="mpm_common"
>ThreadsPerChild</directive>. However
they take <directive module="mpm_common">ThreadsPerChild</directive>
as default if you have not configured something
else via <directive module="mod_http2">H2MinWorkers</directive> and
<directive module="mod_http2">H2MaxWorkers</directive>.
</p>
<p>
Another thing to watch out for is is memory consumption. Since HTTP/2
keeps more state on the server to manage all the open request, priorities
for and dependencies between them, it will always need more memory
than HTTP/1.1 processing. There are three directives which steer the
memory footprint of a HTTP/2 connection:
<directive module="mod_http2">H2MaxSessionStreams</directive>,
<directive module="mod_http2">H2WindowSize</directive> and
<directive module="mod_http2">H2StreamMaxMemSize</directive>.
</p>
<p>
<directive module="mod_http2">H2MaxSessionStreams</directive> limits the
number of parallel requests that a client can make on a HTTP/2 connection.
It depends on your site how many you should allow. The default is 100 which
is plenty and unless you run into memory problems, I would keep it this
way. Most requests that browsers send are GETs without a body, so they
use up only a little bit of memory until the actual processing starts.
</p>
<p>
<directive module="mod_http2">H2WindowSize</directive> controls how much
the client is allowed to send as body of a request, before it waits
for the server to encourage more. Or, the other way around, it is the
amount of request body data the server needs to be able to buffer. This
is per request.
</p>
<p>
And last, but not least, <directive module="mod_http2">H2StreamMaxMemSize</directive>
controls how much response data shall be buffered. The request sits in
a H2Worker thread and is producing data, the HTTP/2 connection tries
to send this to the client. If the client does not read fast enough,
the connection will buffer this amount of data and then suspend the
H2Worker.
</p>
</section>
<section id="misdirected"><title>Multiple Hosts and Misdirected Requests</title>
<p>
Many sites use the same TLS certificate for multiple virtual hosts. The
certificate either has a wildcard name, such as '*.example.org' or carries
several alternate names. Browsers using HTTP/2 will recognize that and reuse
an already opened connection for such hosts.
</p>
<p>
While this is great for performance, it comes at a price: such vhosts
need more care in their configuration. The problem is that you will have
multiple requests for multiple hosts on the same TLS connection. And that
makes renegotiation impossible, in face the HTTP/2 standard forbids it.
</p>
<p>
So, if you have several virtual hosts using the same certificate and
want to use HTTP/2 for them, you need to make sure that all vhosts have
exactly the same SSL configuration. You need the same protocol,
ciphers and settings for client verification.
</p>
<p>
If you mix things, Apache httpd will detect it and return a special
response code, 421 Misdirected Request, to the client.
</p>
</section>
<section id="envvars"><title>Environment Variables</title>
<p>
This module can be configured to provide HTTP/2 related information
as additional environment variables to the SSI and CGI namespace, as well
as in custom log configurations (see <code>%{VAR_NAME}e</code>).
</p>
<table border="1">
<columnspec><column width=".3"/><column width=".2"/><column width=".5"/>
</columnspec>
<tr>
<th><a name="table3">Variable Name:</a></th>
<th>Value Type:</th>
<th>Description:</th>
</tr>
<tr><td><code>HTTP2</code></td><td>flag</td><td>HTTP/2 is being used.</td></tr>
<tr><td><code>H2PUSH</code></td><td>flag</td><td>HTTP/2 Server Push is enabled for this connection and also supported by the client.</td></tr>
<tr><td><code>H2_PUSH</code></td><td>flag</td><td>alternate name for <code>H2PUSH</code></td></tr>
<tr><td><code>H2_PUSHED</code></td><td>string</td><td>empty or <code>PUSHED</code> for a request being pushed by the server.</td></tr>
<tr><td><code>H2_PUSHED_ON</code></td><td>number</td><td>HTTP/2 stream number that triggered the push of this request.</td></tr>
<tr><td><code>H2_STREAM_ID</code></td><td>number</td><td>HTTP/2 stream number of this request.</td></tr>
<tr><td><code>H2_STREAM_TAG</code></td><td>string</td><td>HTTP/2 process unique stream identifier, consisting of connection id and stream id separated by <code>-</code>.</td></tr>
</table>
</section>
</section>
<directivesynopsis>
<name>H2Direct</name>
<description>H2 Direct Protocol Switch</description>
<syntax>H2Direct on|off</syntax>
<default>H2Direct on for h2c, off for h2 protocol</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<usage>
<p>
This directive toggles the usage of the HTTP/2 Direct Mode. This
should be used inside a
<directive module="core" type="section">VirtualHost</directive>
section to enable direct HTTP/2 communication for that virtual host.
</p>
<p>
Direct communication means that if the first bytes received by the
server on a connection match the HTTP/2 preamble, the HTTP/2
protocol is switched to immediately without further negotiation.
This mode is defined in RFC 7540 for the cleartext (h2c) case. Its
use on TLS connections not mandated by the standard.
</p>
<p>
When a server/vhost does not have h2 or h2c enabled via
<directive module="core">Protocols</directive>,
the connection is never inspected for a HTTP/2 preamble.
<directive>H2Direct</directive>
does not matter then. This is important for connections that
use protocols where an initial read might hang indefinitely, such
as NNTP.
</p>
<p>
For clients that have out-of-band knowledge about a server
supporting h2c, direct HTTP/2 saves the client from having to
perform an HTTP/1.1 upgrade, resulting in better performance
and avoiding the Upgrade restrictions on request bodies.
</p>
<p>
This makes direct h2c attractive for server to server communication
as well, when the connection can be trusted or is secured by other means.
</p>
<example><title>Example</title>
<highlight language="config">
H2Direct on
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2Push</name>
<description>H2 Server Push Switch</description>
<syntax>H2Push on|off</syntax>
<default>H2Push on</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
<context>directory</context>
<context>.htaccess</context>
</contextlist>
<compatibility>Available in version 2.4.18 and later.</compatibility>
<usage>
<p>
This directive toggles the usage of the HTTP/2 server push
protocol feature.
</p>
<p>
The HTTP/2 protocol allows the server to push other resources to
a client when it asked for a particular one. This is helpful
if those resources are connected in some way and the client can
be expected to ask for it anyway. The pushing then saves the
time it takes the client to ask for the resources itself. On the
other hand, pushing resources the client never needs or already
has is a waste of bandwidth.
</p>
<p>
Server pushes are detected by inspecting the <code>Link</code> headers of
responses (see <rfc>8288</rfc> for the
specification of Web Linking). When a link thus specified has the <code>rel=preload</code>
attribute, it is treated as a resource to be pushed.
</p>
<p>
Link headers in responses are either set by the application or
can be configured via <directive module="mod_http2">H2PushResource</directive> or
using <module>mod_headers</module> as:
</p>
<example><title>mod_headers example</title>
<highlight language="config">
&lt;Location /index.html&gt;
Header add Link "&lt;/css/site.css&gt;;rel=preload"
Header add Link "&lt;/images/logo.jpg&gt;;rel=preload"
&lt;/Location&gt;
</highlight>
</example>
<p>
As the example shows, there can be several link headers added
to a response, resulting in several pushes being triggered. There
are no checks in the module to avoid pushing the same resource
twice or more to one client. Use with care.
</p>
<p>
HTTP/2 server pushes are enabled by default. On a server or virtual host,
you may enable/disable this feature for any connection to the host. In addition,
you may disable PUSH for a set of resources in a Directory/Location. This controls
which resources may cause a PUSH, not which resources may be sent via PUSH.
</p>
<example><title>Example</title>
<highlight language="config">
H2Push off
</highlight>
</example>
<p>
Last but not least, pushes happen only when the client signals
its willingness to accept those. Most browsers do, some, like Safari 9,
do not. Also, pushes also only happen for resources from the same
<em>authority</em> as the original response is for.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2PushDiarySize</name>
<description>H2 Server Push Diary Size</description>
<syntax>H2PushDiarySize <var>n</var></syntax>
<default>H2PushDiarySize 256</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.4.19 and later.</compatibility>
<usage>
<p>
This directive toggles the maximum number of HTTP/2 server pushes
that are remembered per HTTP/2 connection. This can be used inside the
<directive module="core" type="section">VirtualHost</directive>
section to influence the number for all connections to that virtual host.
</p>
<p>
The push diary records a digest of pushed
resources (their URL) to avoid duplicate pushes on the same connection.
These value are not persisted, so clients opening a new connection
will experience known pushes again.
</p>
<p>
If the maximum size is reached, newer entries replace the oldest
ones. A diary entry uses 8 bytes, letting a
default diary with 256 entries consume around 2 KB of memory.
</p>
<p>
A size of 0 will effectively disable the push diary.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2PushPriority</name>
<description>H2 Server Push Priority</description>
<syntax>H2PushPriority <var>mime-type</var> [after|before|interleaved] [<var>weight</var>]</syntax>
<default>H2PushPriority * After 16</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.4.18 and later. For having an
effect, a nghttp2 library version 1.5.0 or newer is necessary.</compatibility>
<usage>
<p>
This directive defines the priority handling of pushed responses
based on the content-type of the response. This is usually defined
per server config, but may also appear in a virtual host.
</p>
<p>
HTTP/2 server pushes are always related to a client request. Each
such request/response pairs, or <em>streams</em> have a dependency
and a weight, together defining the <em>priority</em> of a stream.
</p>
<p>
When a stream <em>depends</em> on another, say X depends on Y,
then Y gets all bandwidth before X gets any. Note that this
does not mean that Y will block X. If Y has no data to send,
all bandwidth allocated to Y can be used by X.
</p>
<p>
When a stream has more than one dependent, say X1 and X2 both
depend on Y, the <em>weight</em> determines the bandwidth
allocation. If X1 and X2 have the same weight, they both get
half of the available bandwidth. If the weight of X1 is twice
as large as that for X2, X1 gets twice the bandwidth of X2.
</p>
<p>
Ultimately, every stream depends on the <em>root</em> stream which
gets all the bandwidth available, but never sends anything. So all
its bandwidth is distributed by weight among its children. Which
either have data to send or distribute the bandwidth to their
own children. And so on. If none of the children have data
to send, that bandwidth get distributed somewhere else according
to the same rules.
</p>
<p>
The purpose of this priority system is to always make use of
available bandwidth while allowing precedence and weight
to be given to specific streams. Since, normally, all streams
are initiated by the client, it is also the one that sets
these priorities.
</p>
<p>
Only when such a stream results in a PUSH, gets the server to
decide what the <em>initial</em> priority of such a pushed
stream is. In the examples below, X is the client stream. It
depends on Y and the server decides to PUSH streams P1 and P2
onto X.
</p>
<p>
The default priority rule is:
</p>
<example><title>Default Priority Rule</title>
<highlight language="config">
H2PushPriority * After 16
</highlight>
</example>
<p>
which reads as 'Send a pushed stream of any content-type
depending on the client stream with weight 16'. And so P1
and P2 will be send after X and, as they have equal weight,
share bandwidth equally among themselves.
</p>
<example><title>Interleaved Priority Rule</title>
<highlight language="config">
H2PushPriority text/css Interleaved 256
</highlight>
</example>
<p>
which reads as 'Send any CSS resource on the same dependency and
weight as the client stream'. If P1 has content-type 'text/css',
it will depend on Y (as does X) and its effective weight will be
calculated as <code>P1ew = Xw * (P1w / 256)</code>. With P1w being
256, this will make the effective weight the same as the weight
of X. If both X and P1 have data to send, bandwidth will be allocated
to both equally.
</p>
<p>
With Pw specified as 512, a pushed, interleaved stream would
get double the weight of X. With 128 only half as much. Note that
effective weights are always capped at 256.
</p>
<example><title>Before Priority Rule</title>
<highlight language="config">
H2PushPriority application/json Before
</highlight>
</example>
<p>
This says that any pushed stream of content type 'application/json'
should be send out <em>before</em> X. This makes P1 dependent
on Y and X dependent on P1. So, X will be stalled as long as
P1 has data to send. The effective weight is inherited from the
client stream. Specifying a weight is not allowed.
</p>
<p>
Be aware that the effect of priority specifications is limited
by the available server resources. If a server does not have
workers available for pushed streams, the data for the stream
may only ever arrive when other streams have been finished.
</p>
<p>
Last, but not least, there are some specifics of the syntax
to be used in this directive:
</p>
<ol>
<li>'*' is the only special content-type that matches all others.
'image/*' will not work.</li>
<li>The default dependency is 'After'. </li>
<li>There are also default weights: for 'After' it is 16, 'interleaved' is 256.
</li>
</ol>
<example><title>Shorter Priority Rules</title>
<highlight language="config">
H2PushPriority application/json 32 # an After rule
H2PushPriority image/jpeg before # weight inherited
H2PushPriority text/css interleaved # weight 256 default
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2Upgrade</name>
<description>H2 Upgrade Protocol Switch</description>
<syntax>H2Upgrade on|off</syntax>
<default>H2Upgrade on for h2c, off for h2 protocol</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
<context>directory</context>
<context>.htaccess</context>
</contextlist>
<usage>
<p>
This directive toggles the usage of the HTTP/1.1 Upgrade method
for switching to HTTP/2. This
should be used inside a
<directive module="core" type="section">VirtualHost</directive>
section to enable Upgrades to HTTP/2 for that virtual host.
</p>
<p>
This method of switching protocols is defined in HTTP/1.1 and
uses the "Upgrade" header (thus the name) to announce willingness
to use another protocol. This may happen on any request of a
HTTP/1.1 connection.
</p>
<p>
This method of protocol switching is enabled by default on cleartext
(potential h2c) connections and disabled on TLS (potential h2),
as mandated by RFC 7540.
</p>
<p>
Please be aware that Upgrades are only accepted for requests
that carry no body. POSTs and PUTs with content will never
trigger an upgrade to HTTP/2.
See <directive module="mod_http2">H2Direct</directive> for an
alternative to Upgrade.
</p>
<p>
This mode only has an effect when h2 or h2c is enabled via
the <directive module="core">Protocols</directive>.
</p>
<example><title>Example</title>
<highlight language="config">
H2Upgrade on
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2MaxSessionStreams</name>
<description>Maximum number of active streams per HTTP/2 session.</description>
<syntax>H2MaxSessionStreams <var>n</var></syntax>
<default>H2MaxSessionStreams 100</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<usage>
<p>
This directive sets the maximum number of active streams per HTTP/2 session (e.g. connection)
that the server allows. A stream is active if it is not <code>idle</code> or
<code>closed</code> according to RFC 7540.
</p>
<example><title>Example</title>
<highlight language="config">
H2MaxSessionStreams 20
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2StreamMaxMemSize</name>
<description>Maximum amount of output data buffered per stream.</description>
<syntax>H2StreamMaxMemSize <var>bytes</var></syntax>
<default>H2StreamMaxMemSize 65536</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<usage>
<p>
This directive sets the maximum number of outgoing data bytes buffered in memory
for an active streams. This memory is not allocated per stream as such. Allocations
are counted against this limit when they are about to be done. Stream processing
freezes when the limit has been reached and will only continue when buffered data
has been sent out to the client.
</p>
<example><title>Example</title>
<highlight language="config">
H2StreamMaxMemSize 128000
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2WindowSize</name>
<description>Size of Stream Window for upstream data.</description>
<syntax>H2WindowSize <var>bytes</var></syntax>
<default>H2WindowSize 65535</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<usage>
<p>
This directive sets the size of the window that is used for flow control
from client to server and limits the amount of data the server has to buffer.
The client will stop sending on a stream once the limit has been reached until
the server announces more available space (as it has processed some of the data).
</p><p>
This limit affects only request bodies, not its meta data such as headers. Also,
it has no effect on response bodies as the window size for those are managed
by the clients.
</p>
<example><title>Example</title>
<highlight language="config">
H2WindowSize 128000
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2MinWorkers</name>
<description>Minimal number of worker threads to use per child process.</description>
<syntax>H2MinWorkers <var>n</var></syntax>
<contextlist>
<context>server config</context>
</contextlist>
<usage>
<p>
This directive sets the minimum number of worker threads to spawn
per child process for HTTP/2 processing. If this directive is not used,
<module>mod_http2</module> will chose a value suitable for the <code>mpm</code>
module loaded.
</p>
<example><title>Example</title>
<highlight language="config">
H2MinWorkers 10
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2MaxWorkers</name>
<description>Maximum number of worker threads to use per child process.</description>
<syntax>H2MaxWorkers <var>n</var></syntax>
<contextlist>
<context>server config</context>
</contextlist>
<usage>
<p>
This directive sets the maximum number of worker threads to spawn
per child process for HTTP/2 processing. If this directive is not used,
<module>mod_http2</module> will chose a value suitable for the <code>mpm</code>
module loaded.
</p>
<example><title>Example</title>
<highlight language="config">
H2MaxWorkers 20
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2MaxWorkerIdleSeconds</name>
<description>Maximum number of seconds h2 workers remain idle until shut down.</description>
<syntax>H2MaxWorkerIdleSeconds <var>n</var></syntax>
<default>H2MaxWorkerIdleSeconds 600</default>
<contextlist>
<context>server config</context>
</contextlist>
<usage>
<p>
This directive sets the maximum number of seconds a h2 worker may
idle until it shuts itself down. This only happens while the number of
h2 workers exceeds <directive module="mod_http2">H2MinWorkers</directive>.
</p>
<example><title>Example</title>
<highlight language="config">
H2MaxWorkerIdleSeconds 20
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2SerializeHeaders</name>
<description>Serialize Request/Response Processing Switch</description>
<syntax>H2SerializeHeaders on|off</syntax>
<default>H2SerializeHeaders off</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<usage>
<p>
This directive toggles if HTTP/2 requests shall be serialized in
HTTP/1.1 format for processing by <code>httpd</code> core or if
received binary data shall be passed into the <code>request_rec</code>s
directly.
</p>
<p>
Serialization will lower performance, but gives more backward
compatibility in case custom filters/hooks need it.
</p>
<example><title>Example</title>
<highlight language="config">
H2SerializeHeaders on
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2ModernTLSOnly</name>
<description>Require HTTP/2 connections to be "modern TLS" only</description>
<syntax>H2ModernTLSOnly on|off</syntax>
<default>H2ModernTLSOnly on</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.4.18 and later.</compatibility>
<usage>
<p>
This directive toggles the security checks on HTTP/2 connections
in TLS mode (https:). This can be used server wide or for specific
<directive module="core" type="section">VirtualHost</directive>s.
</p>
<p>
The security checks require that the TLS protocol is at least
TLSv1.2 and that none of the ciphers listed in RFC 7540, Appendix A
is used. These checks will be extended once new security requirements
come into place.
</p>
<p>
The name stems from the
<a href="https://wiki.mozilla.org/Security/Server_Side_TLS">Security/Server Side TLS</a>
definitions at mozilla where "modern compatibility" is defined. Mozilla Firefox and
other browsers require modern compatibility for HTTP/2 connections. As everything
in OpSec, this is a moving target and can be expected to evolve in the future.
</p>
<p>
One purpose of having these checks in <module>mod_http2</module> is to enforce this
security level for all connections, not only those from browsers. The other
purpose is to prevent the negotiation of HTTP/2 as a protocol should
the requirements not be met.
</p>
<p>
Ultimately, the security of the TLS connection is determined by the
server configuration directives for <module>mod_ssl</module>.
</p>
<example><title>Example</title>
<highlight language="config">
H2ModernTLSOnly off
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2TLSWarmUpSize</name>
<description>Configure the number of bytes on TLS connection before doing max writes</description>
<syntax>H2TLSWarmUpSize <var>amount</var></syntax>
<default>H2TLSWarmUpSize 1048576</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.4.18 and later.</compatibility>
<usage>
<p>
This directive sets the number of bytes to be sent in small
TLS records (~1300 bytes) until doing maximum sized writes (16k)
on https: HTTP/2 connections.
This can be used server wide or for specific
<directive module="core" type="section">VirtualHost</directive>s.
</p>
<p>
Measurements by <a href="https://www.igvita.com">google performance
labs</a> show that best performance on TLS connections is reached,
if initial record sizes stay below the MTU level, to allow a
complete record to fit into an IP packet.
</p>
<p>
While TCP adjust its flow-control and window sizes, longer TLS
records can get stuck in queues or get lost and need retransmission.
This is of course true for all packets. TLS however needs the
whole record in order to decrypt it. Any missing bytes at the end
will stall usage of the received ones.
</p>
<p>
After a sufficient number of bytes have been send successfully,
the TCP state of the connection is stable and maximum TLS record
sizes (16 KB) can be used for optimal performance.
</p>
<p>
In deployments where servers are reached locally or over reliable
connections only, the value might be decreased with 0 disabling
any warmup phase altogether.
</p>
<p>
The following example sets the size to zero, effectively disabling
any warmup phase.
</p>
<example><title>Example</title>
<highlight language="config">
H2TLSWarmUpSize 0
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2TLSCoolDownSecs</name>
<description>Configure the number of seconds of idle time on TLS before shrinking writes</description>
<syntax>H2TLSCoolDownSecs <var>seconds</var></syntax>
<default>H2TLSCoolDownSecs 1</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.4.18 and later.</compatibility>
<usage>
<p>
This directive sets the number of seconds of idle time on a TLS
connection before the TLS write size falls back to small (~1300 bytes)
length.
This can be used server wide or for specific
<directive module="core" type="section">VirtualHost</directive>s.
</p>
<p>
See <directive module="mod_http2">H2TLSWarmUpSize</directive> for a
description of TLS warmup. <directive>H2TLSCoolDownSecs</directive> reflects the fact
that connections may deteriorate over time (and TCP flow adjusts)
for idle connections as well. It is beneficial to overall performance
to fall back to the pre-warmup phase after a number of seconds that
no data has been sent.
</p>
<p>
In deployments where connections can be considered reliable, this
timer can be disabled by setting it to 0.
</p>
<p>
The following example sets the seconds to zero, effectively disabling
any cool down. Warmed up TLS connections stay on maximum record
size.
</p>
<example><title>Example</title>
<highlight language="config">
H2TLSCoolDownSecs 0
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2CopyFiles</name>
<description>Determine file handling in responses</description>
<syntax>H2CopyFiles on|off</syntax>
<default>H2CopyFiles off</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
<context>directory</context>
<context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<compatibility>Available in version 2.4.24 and later.</compatibility>
<usage>
<p>
This directive influences how file content is handled in
responses. When <code>off</code>, which is the default, file handles
are passed from the request processing down to the main
connection, using the usual Apache setaside handling for
managing the lifetime of the file.
</p>
<p>
When set to <code>on</code>, file content is copied while the
request is still being processed and the buffered data is passed
on to the main connection. This is better if a third party
module is injecting files with different lifetimes into the response.
</p>
<p>
An example for such a module is <code>mod_wsgi</code> that may place
Python file handles into the response. Those files get close down when
Python thinks processing has finished. That may be well before
<module>mod_http2</module> is done with them.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2PushResource</name>
<description>Declares resources for early pushing to the client</description>
<syntax>H2PushResource [add] <var>path</var> [critical]</syntax>
<contextlist>
<context>server config</context>
<context>virtual host</context>
<context>directory</context>
<context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<compatibility>Available in version 2.4.24 and later.</compatibility>
<usage>
<p>
When added to a directory/location HTTP/2 PUSHes will be attempted
for all paths added via this directive. This directive can be used
several times for the same location.
</p>
<p>
This directive pushes resources much earlier than adding
<code>Link</code> headers via <module>mod_headers</module>.
<module>mod_http2</module> announces these resources in a
<code>103 Early Hints</code> interim response to the client.
That means that clients not supporting PUSH will still get
early preload hints.
</p>
<p>
In contrast to setting <code>Link</code> response headers
via <module>mod_headers</module>, this directive will only
take effect on HTTP/2 connections.
</p>
<p>
By adding <code>critical</code> to such a resource, the server
will give processing it more preference and send its data, once
available, before the data from the main request.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2EarlyHints</name>
<description>Determine sending of 103 status codes</description>
<syntax>H2EarlyHints on|off</syntax>
<default>H2EarlyHints off</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.4.24 and later.</compatibility>
<usage>
<p>
This setting controls if HTTP status 103 interim responses are
forwarded to the client or not. By default, this is currently
not the case since a range of clients still have trouble with
unexpected interim responses.
</p>
<p>
When set to <code>on</code>, PUSH resources announced with
<directive module="mod_http2">H2PushResource</directive> will
trigger an interim 103 response
before the final response. The 103 response will carry <code>Link</code>
headers that advise the <code>preload</code> of such resources.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2Padding</name>
<description>Determine the range of padding bytes added to payload frames</description>
<syntax>H2Padding <var>numbits</var></syntax>
<default>H2Padding 0</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.4.39 and later.</compatibility>
<usage>
<p>
With the default 0, no padding bytes are added to any payload
frames, e.g. HEADERS, DATA and PUSH_PROMISE. This is the behavior
of previous versions. It means that under certain conditions, an
observer of network traffic can see the length of those frames
in the TLS stream.
</p>
<p>
When configuring numbits of 1-8, a random number in range
[0, 2^numbits[ are added to each frame. The random value is chosen
independently for each frame that the module sends back to the client.
</p>
<p>
While more padding bytes give better message length obfuscation, they
are also additional traffic. The optimal number therefore depends on
the kind of web traffic the server carries.
</p>
<p>
The default of 0, e.g. no padding, was chosen for maximum backward
compatibility. There might be deployments where padding bytes are
unwanted or do harm. The most likely cause would be a client that
has a faults implementation.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2OutputBuffering</name>
<description>Determine buffering behavior of output</description>
<syntax>H2OutputBuffering on|off</syntax>
<default>H2OutputBuffering on</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.4.48 and later.</compatibility>
<usage>
<p>
The directive <directive>H2OutputBuffering</directive> controls the buffering of stream output.
The default is on, which is the behavior of previous versions. When off, all
bytes are made available immediately to the main connection for sending them
out to the client. This fixes interop issues with certain flavors of gRPC.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2StreamTimeout</name>
<description>Maximum time waiting when sending/receiving data to stream processing</description>
<syntax>H2StreamTimeout <var>time-interval</var>[s]</syntax>
<default>Value of <directive module="core">Timeout</directive></default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
<context>directory</context>
</contextlist>
<compatibility>Available in version 2.5.1 and later.</compatibility>
<usage>
<p>
<directive>H2StreamTimeout</directive> specifies the maximum time that
a stream being processed will wait for its data to be sent/received.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2MaxDataFrameLen</name>
<description>Maximum bytes inside a single HTTP/2 DATA frame</description>
<syntax>H2MaxDataFrameLen <var>n</var></syntax>
<default>H2MaxDataFrameLen 0</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.5.1 and later.</compatibility>
<usage>
<p>
<directive>H2MaxDataFrameLen</directive> limits the maximum
amount of response body bytes placed into a single HTTP/2 DATA
frame. Setting this to 0 places no limit (but the max size
allowed by the protocol is observed).
</p><p>
The module, by default, tries to use the maximum size possible,
which is somewhat around 16KB. This sets the maximum. When less
response data is available, smaller frames will be sent.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2EarlyHint</name>
<description>Add a response header to be picked up in 103 Early Hints</description>
<syntax>H2EarlyHint <var>name</var> <var>value</var></syntax>
<contextlist>
<context>server config</context>
<context>virtual host</context>
<context>directory</context>
<context>.htaccess</context>
</contextlist>
<compatibility>Available in version 2.5.1 and later.</compatibility>
<usage>
<p>
<directive>H2EarlyHint</directive> allows adding a response
header before the real request processing is started. Such headers
are picked up for "103 Early Hints" intermediate responses. The main
purpose is to send "preload" information to client browsers.
</p><p>
<var>name</var> and <var>value</var> must be valid HTTP header fields
or will lead to failed responses. <directive>H2EarlyHints</directive>
must still be enabled to allow 103 intermediate responses to be sent.
This directive can be repeated several times and header fields of the
same names add.
</p>
<example><title>Example</title>
<highlight language="config">
H2EarlyHint Link "&lt;/my.css&gt;;rel=preload;as=style"
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2WebSockets</name>
<description>En-/Disable WebSockets via HTTP/2</description>
<syntax>H2WebSockets on|off</syntax>
<default>H2WebSockets off</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.5.1 and later.</compatibility>
<usage>
<p>
Use <directive>H2WebSockets</directive> to enable or disable
bootstrapping of WebSockets via the HTTP/2 protocol. This
protocol extension is defined in RFC 8441.
</p><p>
Such requests come as a CONNECT with an extra ':protocol'
header. Such requests are transformed inside the module to
their HTTP/1.1 equivalents before passing it to internal
processing.
</p><p>
This means that HTTP/2 WebSockets can be used for a
<directive module="mod_proxy">ProxyPass</directive> with
'upgrade=websocket' parameter without further changes.
</p><p>
For (3rd party) modules that handle WebSockets directly in the
server, the protocol bootstrapping itself will also work. However
the transfer of data does require extra support in case of HTTP/2.
The negotiated WebSocket will not be able to use the client connection
socket for polling IO related events.
</p><p>
Because enabling this feature might break backward compatibility
for such 3rd party modules, it is not enabled by default.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2ProxyRequests</name>
<description>En-/Disable forward proxy requests via HTTP/2</description>
<syntax>H2ProxyRequests on|off</syntax>
<default>H2ProxyRequests off</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.5.1 and later.</compatibility>
<usage>
<p>
Use <directive>H2ProxyRequests</directive> to enable or disable
handling of HTTP/2 requests in a forward proxy configuration.
</p><p>
Similar to <directive module="proxy">ProxyRequests</directive>, this
triggers the needed treatment of requests when HTTP/2 is enabled
in a forward proxy configuration. Both directive should be enabled.
</p><p>
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2MaxHeaderBlockLen</name>
<description>Maximum size of response headers</description>
<syntax>H2MaxHeaderBlockLen <var>n</var></syntax>
<default>H2MaxHeaderBlockLen 0</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.5.1 and later.</compatibility>
<usage>
<p>
<directive>H2MaxHeaderBlockLen</directive> sets the limit
on the overall size of response headers. A setting of 0
will leave this at the default of 64 KB in nghttp2.
</p>
<p>
Responses with headers larger than this (adding all headers)
will not be processed and result in a reset of the stream.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>H2MaxStreamErrors</name>
<description>Maximum amount of client caused errors to tolerate</description>
<syntax>H2MaxStreamErrors <var>n</var></syntax>
<default>H2MaxStreamErrors 8</default>
<contextlist>
<context>server config</context>
<context>virtual host</context>
</contextlist>
<compatibility>Available in version 2.5.1 and later.</compatibility>
<usage>
<p>
<directive>H2MaxStreamErrors</directive> sets the maximum amount
of tolerated HTTP/2 stream errors caused by the client.
When exceeding this limit, the connection will be closed.
Stream errors are protocol violations on an individual HTTP/2
stream that do not necessitate a connection close by the
protocol specification, but can be a sign of malicious
activity by a client.
</p>
<p>
Set to 0 to tolerate faulty clients.
</p>
</usage>
</directivesynopsis>
</modulesynopsis>