W3cubDocs

/Apache HTTP Server

Apache Module mod_http2

Description: Support for the HTTP/2 transport layer
Status: Extension
ModuleIdentifier: http2_module
SourceFile: mod_http2.c
Compatibility: Available in version 2.4.17 and later

Summary

This module provides HTTP/2 (RFC 7540) support for the Apache HTTP Server.

This module relies on libnghttp2 to provide the core http/2 engine.

Warning

This module is experimental. Its behaviors, directives, and defaults are subject to more change from release to release relative to other standard modules. Users are encouraged to consult the "CHANGES" file for potential updates.

You must enable HTTP/2 via Protocols in order to use the functionality described in this document. The HTTP/2 protocol does not require the use of encryption so two schemes are available: h2 (HTTP/2 over TLS) and h2c (HTTP/2 over TCP).

Two useful configuration schemes are:

HTTP/2 in a VirtualHost context (TLS only)

Protocols h2 http/1.1

Allows HTTP/2 negotiation (h2) via TLS ALPN in a secure <VirtualHost>. HTTP/2 preamble checking (Direct mode, see H2Direct) is disabled by default for h2.

HTTP/2 in a Server context (TLS and cleartext)

Protocols h2 h2c http/1.1

Allows HTTP/2 negotiation (h2) via TLS ALPN for secure <VirtualHost>. Allows HTTP/2 cleartext negotiation (h2c) upgrading from an initial HTTP/1.1 connection or via HTTP/2 preamble checking (Direct mode, see H2Direct).

Refer to the official HTTP/2 FAQ for any doubt about the protocol.

How it works

HTTP/2 Dimensioning

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.

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 Worker threads for processing, collects the results and streams them out to the client.

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 mod_status. They are also not counted against directives such as ThreadsPerChild. However they take ThreadsPerChild as default if you have not configured something else via H2MinWorkers and H2MaxWorkers.

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: H2MaxSessionStreams, H2WindowSize and H2StreamMaxMemSize.

H2MaxSessionStreams 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.

H2WindowSize 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.

And last, but not least, H2StreamMaxMemSize 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.

If you serve a lot of static files, H2SessionExtraFiles is of interest. This tells the server how many file handles per HTTP/2 connection it is allowed to waste for better performance. Because when a request produces a static file as the response, the file handle gets passed around and is buffered and not the file contents. That allows to serve many large files without wasting memory or copying data unnecessarily. However file handles are a limited resource for a process, and if too many are used this way, requests may fail under load as the amount of open handles has been exceeded.

Multiple Hosts and Misdirected Requests

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.

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.

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.

If you mix things, Apache httpd will detect it and return a special response code, 421 Misdirected Request, to the client.

Environment Variables

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 %{VAR_NAME}e).

Variable Name: Value Type: Description:
HTTP2 flag HTTP/2 is being used.
H2PUSH flag HTTP/2 Server Push is enabled for this connection and also supported by the client.
H2_PUSH flag alternate name for H2PUSH
H2_PUSHED string empty or PUSHED for a request being pushed by the server.
H2_PUSHED_ON number HTTP/2 stream number that triggered the push of this request.
H2_STREAM_ID number HTTP/2 stream number of this request.
H2_STREAM_TAG string HTTP/2 process unique stream identifier, consisting of connection id and stream id separated by -.

H2CopyFiles Directive

Description: Determine file handling in responses
Syntax:
H2CopyFiles on|off
Default:
H2CopyFiles off
Context: server config, virtual host, directory, .htaccess
Status: Extension
Module: mod_http2
Compatibility: Available in version 2.4.24 and later.

This directive influences how file content is handled in responses. When off, which is the default, file handles are passed from the requestion processing down to the main connection, using the usual Apache setaside handling for managing the lifetime of the file.

When set to on, 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.

An example for such a module is mod_wsgi 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 mod_http2 is done with them.

H2Direct Directive

Description: H2 Direct Protocol Switch
Syntax:
H2Direct on|off
Default:
H2Direct on for h2c, off for h2 protocol
Context: server config, virtual host
Status: Extension
Module: mod_http2

This directive toggles the usage of the HTTP/2 Direct Mode. This should be used inside a <VirtualHost> section to enable direct HTTP/2 communication for that virtual host.

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.

When a server/vhost does not have h2 or h2c enabled via Protocols, the connection is never inspected for a HTTP/2 preamble. H2Direct does not matter then. This is important for connections that use protocols where an initial read might hang indefinitely, such as NNTP.

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.

This makes direct h2c attractive for server to server communication as well, when the connection can be trusted or is secured by other means.

Example

H2Direct on

H2EarlyHints Directive

Description: Determine sending of 103 status codes
Syntax:
H2EarlyHints on|off
Default:
H2EarlyHints off
Context: server config, virtual host
Status: Extension
Module: mod_http2
Compatibility: Available in version 2.4.24 and later.

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.

When set to on, PUSH resources announced with H2PushResource will trigger an interim 103 response before the final response. The 103 response will carry Link headers that advise the preload of such resources.

H2MaxSessionStreams Directive

Description: Maximum number of active streams per HTTP/2 session.
Syntax:
H2MaxSessionStreams n
Default:
H2MaxSessionStreams 100
Context: server config, virtual host
Status: Extension
Module: mod_http2

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 idle or closed according to RFC 7540.

Example

H2MaxSessionStreams 20

H2MaxWorkerIdleSeconds Directive

Description: Maximum number of seconds h2 workers remain idle until shut down.
Syntax:
H2MaxWorkerIdleSeconds n
Default:
H2MaxWorkerIdleSeconds 600
Context: server config
Status: Extension
Module: mod_http2

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 H2MinWorkers.

Example

H2MaxWorkerIdleSeconds 20

H2MaxWorkers Directive

Description: Maximum number of worker threads to use per child process.
Syntax:
H2MaxWorkers n
Context: server config
Status: Extension
Module: mod_http2

This directive sets the maximum number of worker threads to spawn per child process for HTTP/2 processing. If this directive is not used, mod_http2 will chose a value suitable for the mpm module loaded.

Example

H2MaxWorkers 20

H2MinWorkers Directive

Description: Minimal number of worker threads to use per child process.
Syntax:
H2MinWorkers n
Context: server config
Status: Extension
Module: mod_http2

This directive sets the minimum number of worker threads to spawn per child process for HTTP/2 processing. If this directive is not used, mod_http2 will chose a value suitable for the mpm module loaded.

Example

H2MinWorkers 10

H2ModernTLSOnly Directive

Description: Require HTTP/2 connections to be "modern TLS" only
Syntax:
H2ModernTLSOnly on|off
Default:
H2ModernTLSOnly on
Context: server config, virtual host
Status: Extension
Module: mod_http2
Compatibility: Available in version 2.4.18 and later.

This directive toggles the security checks on HTTP/2 connections in TLS mode (https:). This can be used server wide or for specific <VirtualHost>s.

The security checks require that the TSL 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.

The name stems from the Security/Server Side TLS 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.

One purpose of having these checks in mod_http2 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.

Ultimately, the security of the TLS connection is determined by the server configuration directives for mod_ssl.

Example

H2ModernTLSOnly off

H2Push Directive

Description: H2 Server Push Switch
Syntax:
H2Push on|off
Default:
H2Push on
Context: server config, virtual host
Status: Extension
Module: mod_http2
Compatibility: Available in version 2.4.18 and later.

This directive toggles the usage of the HTTP/2 server push protocol feature. This should be used inside a <VirtualHost> section to enable direct HTTP/2 communication for that virtual host.

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.

Server pushes are detected by inspecting the Link headers of responses (see https://tools.ietf.org/html/rfc5988 for the specification). When a link thus specified has the rel=preload attribute, it is treated as a resource to be pushed.

Link headers in responses are either set by the application or can be configured via mod_headers as:

mod_headers example

<Location /index.html>
    Header add Link "</css/site.css>;rel=preload"
    Header add Link "</images/logo.jpg>;rel=preload"
</Location>

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.

HTTP/2 server pushes are enabled by default. This directive allows it to be switch off on all resources of this server/virtual host.

Example

H2Push off

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 authority as the original response is for.

H2PushDiarySize Directive

Description: H2 Server Push Diary Size
Syntax:
H2PushDiarySize n
Default:
H2PushDiarySize 256
Context: server config, virtual host
Status: Extension
Module: mod_http2
Compatibility: Available in version 2.4.19 and later.

This directive toggles the maximum number of HTTP/2 server pushes that are remembered per HTTP/2 connection. This can be used inside the <VirtualHost> section to influence the number for all connections to that virtual host.

The push diary records a digest (currently using a 64 bit number) 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. There is ongoing work to enable a client to disclose a digest of the resources it already has, so the diary maybe initialized by the client on each connection setup.

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.

A size of 0 will effectively disable the push diary.

H2PushPriority Directive

Description: H2 Server Push Priority
Syntax:
H2PushPriority mime-type [after|before|interleaved] [weight]
Default:
H2PushPriority * After 16
Context: server config, virtual host
Status: Extension
Module: mod_http2
Compatibility: Available in version 2.4.18 and later. For having an effect, a nghttp2 library version 1.5.0 or newer is necessary.

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.

HTTP/2 server pushes are always related to a client request. Each such request/response pairs, or streams have a dependency and a weight, together defining the priority of a stream.

When a stream depends 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.

When a stream has more than one dependant, say X1 and X2 both depend on Y, the weight 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.

Ultimately, every stream depends on the root 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.

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.

Only when such a stream results in a PUSH, gets the server to decide what the initial 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.

The default priority rule is:

Default Priority Rule

H2PushPriority * After 16

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.

Interleaved Priority Rule

H2PushPriority text/css Interleaved 256

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 P1ew = Xw * (P1w / 256). 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.

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.

Before Priority Rule

H2PushPriority application/json Before

This says that any pushed stream of content type 'application/json' should be send out before 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.

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.

Last, but not least, there are some specifics of the syntax to be used in this directive:

  1. '*' is the only special content-type that matches all others. 'image/*' will not work.
  2. The default dependency is 'After'.
  3. There are also default weights: for 'After' it is 16, 'interleaved' is 256.

Shorter Priority Rules

H2PushPriority application/json 32         # an After rule
H2PushPriority image/jpeg before           # weight inherited
H2PushPriority text/css   interleaved      # weight 256 default

H2PushResource Directive

Description: Declares resources for early pushing to the client
Syntax:
H2PushResource [add] path [critical]
Context: server config, virtual host, directory, .htaccess
Status: Extension
Module: mod_http2
Compatibility: Available in version 2.4.24 and later.

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.

This directive pushes resources much earlier than adding Link headers via mod_headers. mod_http2 announces these resources in a 103 Early Hints interim response to the client. That means that clients not supporting PUSH will still get early preload hints.

In contrast to setting Link response headers via mod_headers, this directive will only take effect on HTTP/2 connections.

By adding critical 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.

H2SerializeHeaders Directive

Description: Serialize Request/Response Processing Switch
Syntax:
H2SerializeHeaders on|off
Default:
H2SerializeHeaders off
Context: server config, virtual host
Status: Extension
Module: mod_http2

This directive toggles if HTTP/2 requests shall be serialized in HTTP/1.1 format for processing by httpd core or if received binary data shall be passed into the request_recs directly.

Serialization will lower performance, but gives more backward compatibility in case custom filters/hooks need it.

Example

H2SerializeHeaders on

H2SessionExtraFiles Directive

Description: Number of Extra File Handles
Syntax:
H2SessionExtraFiles n
Context: server config, virtual host
Status: Extension
Module: mod_http2

This directive sets maximum number of extra file handles a HTTP/2 session is allowed to use. A file handle is counted as extra when it is transferred from a h2 worker thread to the main HTTP/2 connection handling. This commonly happens when serving static files.

Depending on the processing model configured on the server, the number of connections times number of active streams may exceed the number of file handles for the process. On the other hand, converting every file into memory bytes early results in too many buffer writes. This option helps to mitigate that.

The number of file handles used by a server process is then in the order of:

(h2_connections * extra_files) + (h2_max_worker)

Example

H2SessionExtraFiles 10

If nothing is configured, the module tries to make a conservative guess how many files are safe to use. This depends largely on the MPM chosen.

H2StreamMaxMemSize Directive

Description: Maximum amount of output data buffered per stream.
Syntax:
H2StreamMaxMemSize bytes
Default:
H2StreamMaxMemSize 65536
Context: server config, virtual host
Status: Extension
Module: mod_http2

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.

Example

H2StreamMaxMemSize 128000

H2TLSCoolDownSecs Directive

Description:
Syntax:
H2TLSCoolDownSecs seconds
Default:
H2TLSCoolDownSecs 1
Context: server config, virtual host
Status: Extension
Module: mod_http2
Compatibility: Available in version 2.4.18 and later.

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 <VirtualHost>s.

See H2TLSWarmUpSize for a description of TLS warmup. H2TLSCoolDownSecs 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.

In deployments where connections can be considered reliable, this timer can be disabled by setting it to 0.

The following example sets the seconds to zero, effectively disabling any cool down. Warmed up TLS connections stay on maximum record size.

Example

H2TLSCoolDownSecs 0

H2TLSWarmUpSize Directive

Description:
Syntax:
H2TLSWarmUpSize amount
Default:
H2TLSWarmUpSize 1048576
Context: server config, virtual host
Status: Extension
Module: mod_http2
Compatibility: Available in version 2.4.18 and later.

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 <VirtualHost>s.

Measurements by google performance labs 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.

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.

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.

In deployments where servers are reached locally or over reliable connections only, the value might be decreased with 0 disabling any warmup phase altogether.

The following example sets the size to zero, effectively disabling any warmup phase.

Example

H2TLSWarmUpSize 0

H2Upgrade Directive

Description: H2 Upgrade Protocol Switch
Syntax:
H2Upgrade on|off
Default:
H2Upgrade on for h2c, off for h2 protocol
Context: server config, virtual host
Status: Extension
Module: mod_http2

This directive toggles the usage of the HTTP/1.1 Upgrade method for switching to HTTP/2. This should be used inside a <VirtualHost> section to enable Upgrades to HTTP/2 for that virtual host.

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.

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.

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 H2Direct for an alternative to Upgrade.

This mode only has an effect when h2 or h2c is enabled via the Protocols.

Example

H2Upgrade on

H2WindowSize Directive

Description: Size of Stream Window for upstream data.
Syntax:
H2WindowSize bytes
Default:
H2WindowSize 65535
Context: server config, virtual host
Status: Extension
Module: mod_http2

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).

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.

Example

H2WindowSize 128000

© 2016 The Apache Software Foundation
Licensed under the Apache License, Version 2.0.
https://httpd.apache.org/docs/2.4/en/mod/mod_http2.html