Apache Module mod_http2

Available Languages: en | + fr

+ + + + +

Description:	Support for the HTTP/2 transport layer
Status:	Extension
Module Identifier:	http2_module
Source File:	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.

+ +

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.

+ +

Topics

How it works

Directives

+ +

Bugfix checklist

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

+ + +

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

+ +

H2OutputBuffering Directive

+ + + + + + + + +

Description:	Determine buffering behaviour of output
Syntax:	`H2OutputBuffering on\|off`
Default:	`H2OutputBuffering on`
Context:	server config, virtual host
Status:	Extension
Module:	mod_http2
Compatibility:	Available in version 2.4.48 and later.

+ The directive H2OutputBuffering controls the buffering of stream output. + The default is on, which is the behaviour 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 flavours of gRPC. +

+ +

H2Padding Directive

+ + + + + + + + +

Description:	Determine the range of padding bytes added to payload frames
Syntax:	`H2Padding numbits`
Default:	`H2Padding 0`
Context:	server config, virtual host
Status:	Extension
Module:	mod_http2
Compatibility:	Available in version 2.4.39 and later.

+ With the default 0, no padding bytes are added to any payload + frames, e.g. HEADERS, DATA and PUSH_PROMISE. This is the behaviour + 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. +

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

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

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

+ +

H2Push Directive

+ + + + + + + + +

Description:	H2 Server Push Switch
Syntax:	`H2Push on\|off`
Default:	`H2Push on`
Context:	server config, virtual host, directory, .htaccess
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. +

+ 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 H2PushResource or + using 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. 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. +

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

+ 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 dependent, 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: +

'*' is the only special content-type that matches all others. + 'image/*' will not work.
The default dependency is 'After'.
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

+ +

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:	Configure the number of seconds of idle time on TLS before shrinking writes
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:	Configure the number of bytes on TLS connection before doing max writes
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, directory, .htaccess
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

+ +

Apache Module mod_http2

Summary

HTTP/2 in a VirtualHost context (TLS only)

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

Topics

Directives

Bugfix checklist

See also

Example

Example

Example

Example

Example

Example

mod_headers example

Example

Default Priority Rule

Interleaved Priority Rule

Before Priority Rule

Shorter Priority Rules

Example

Example

Example

Example

Example

Example