Configure > HTTP/2 Directives
H2O provides one of the world's most sophisticated HTTP/2 protocol implementation, including following features.
Prioritization
H2O is one of the few servers that fully implement prioritization of HTTP responses conformant to what is defined in the HTTP/2 specification. The server implements a O(1) scheduler that determines which HTTP response should be sent to the client, per every 16KB chunk.
Unfortunately, some web browsers fail to specify response priorities that lead to best end-user experience. H2O is capable of detecting such web browsers, and if it does, uses server-driven prioritization; i.e. send responses with certain MIME-types before others.
It is possible to tune or turn off server-driven prioritization using directives: file.mime.addtypes
, http2-reprioritize-blocking-assets
.
See also:
Server push
H2O recognizes link
headers with preload keyword sent by a backend application server (reverse proxy or FastCGI) or an mruby handler, and pushes the designated resource to a client.
link: </assets/jquery.js>; rel=preload
When the HTTP/2 driver of H2O recognizes a link
response header with rel=preload
attribute set, and if all of the following conditions are met, the specified resource is pushed to the client.
- the
link
header does not have thenopush
attribute set - the
link
header is not part of a pushed response - the client does not disable HTTP/2 push
- number of the pushed responses in-flight is below the negotiated threshold
- authority of the resource specified is equivalent to the request that tried to trigger the push
- (for handlers that return the status code synchronously) the status code of the response to be pushed does not indicate an error (i.e. 4xx or 5xx)
The server also provides a mechanism to track the clients' cache state via cookies, and to push the resources specified with the link
header only when it does not exist within the clients' cache. For details, please refer to the documentation of http2-casper
configuration directive.
When a resource is pushed, the priority is determined using the priority
attribute of the MIME-type configuration. If the priority is set to highest
then the resource will be sent to the client before anything else; otherwise the resource will be sent to client after the main content, as per defined by the HTTP/2 specification.
Pushed responses will have x-http2-push: pushed
header set; by looking for the header, it is possible to determine if a resource has been pushed.
It is also possible to log the value in the access log by specifying %{x-http2-push}o
, push responses but cancelled by CASPER will have the value of the header logged as cancelled
.
See also:
The following describes the configuration directives for controlling the HTTP/2 protocol handler.
- Description:
-
Configures CASPer (cache-aware server-push).
When enabled, H2O maintains a fingerprint of the web browser cache, and cancels server-push suggested by the handlers if the client is known to be in possention of the content. The fingerprint is stored in a cookie named
h2o_casper
using Golomb-compressed sets (a compressed encoding of Bloom filter).If the value is
OFF
, the feature is disabled. Push requests (made by the handlers through the use ofLink: rel=preload
header) are processed regardless of whether if client already has the responses in its cache. If the value isON
, the feature is enabled with the defaults value specified below. If the value is mapping, the feature is enabled, recognizing the following attributes.- capacity-bits:
- number of bits used for the fingerprinting.
Roughly speaking, the number of bits should be
log2(1/P * number-of-assets-to-track)
where P being the probability of false positives. Default is13
, enough for tracking about 100 asset files with 1/100 chance of false positives (i.e.log2(100 * 100) =~ 213
). - tracking-types:
- specifies the types of the content tracked by casper.
If omitted or set to
blocking-assets
, maintains fingerprint (and cancels server push) for resources with mime-type ofhighest
priority. If set toall
, tracks all responses.
log2(P) * number-of-assets-being-tracked
bits multiplied by the overhead of Base 64 encoding (4/3
). Therefore with current cookie-based implementation, it is necessary in many cases to restrict the resources being tracked to those have significant effect to user-percieved response time.Example. Enabling CASPerhttp2-casper: ON # `ON` is equivalent to: # http2-casper: # capacity-bits: 13 # tracking-types: blocking-assets
- Level:
- global, host
- Default:
http2-casper: OFF
- See also:
file.mime.addtypes
, issue #421
- Description:
-
Timeout for idle connections in seconds.
- Level:
- global
- Default:
http2-idle-timeout: 10
- Description:
-
Maximum number of requests to be handled concurrently within a single HTTP/2 connection.
The value cannot exceed 256.
- Level:
- global
- Default:
http2-max-concurrent-requests-per-connection: 100
- Description:
-
A boolean flag (
ON
orOFF
) indicating if the server should send contents withhighest
priority before anything else.To maximize the user-perceived reponsiveness of a web page, it is essential for the web server to send blocking assets (i.e. CSS and JavaScript files in
<HEAD>
) before any other files such as images. HTTP/2 provides a way for web browsers to specify such priorities to the web server. However, as of Sep. 2015, no major web browsers except Mozilla Firefox take advantage of the feature.This option, when enabled, works as a workaround for such web browsers, thereby improving experience of users using the web browsers.
Technically speaking, it does the following:
- if the client uses dependency-based prioritization, do not reprioritize
- if the client does not use dependency-based prioritization, send the contents of which their types are given
highest
priority before any other responses
- Level:
- global
- Default:
http2-reprioritize-blocking-assets: ON
- See also:
file.mime.addtypes
, HTTP/2 (and H2O) improves user experience over HTTP/1.1 or SPDY