<p>When you have a <code>httpd</code> built with <module>mod_http2</module> you need some
basic configuration for it becoming active. The first thing, as with every httpd module,
is that you need to load it:</p>
+<example>
<highlight language="config">
LoadModule http2_module modules/mod_http2.so
</highlight>
+</example>
<p>The second directive you need to add to your server configuration is</p>
+<example>
<highlight language="config">
Protocols h2 http/1.1
</highlight>
+</example>
<p>This allows h2, the secure variant, to be the preferred protocol on your server
connections. When you want to enable all HTTP/2 variants, you simply write:</p>
+<example>
<highlight language="config">
Protocols h2 h2c http/1.1
</highlight>
+</example>
<p>Depending on where you put this directive, it affects all connections or just
the ones to a certain virtual host. You can nest it, as in:</p>
+<example>
<highlight language="config">
Protocols http/1.1
<VirtualHost ...>
Protocols h2 http/1.1
</VirtualHost>
</highlight>
+</example>
<p>This allows only HTTP/1 on connections, except SSL connections to <code>test.example.org</code>
which offer HTTP/2.</p>
<p>The order of protocols mentioned is also relevant. By default, the first one is the
most preferred protocol. When a client offers multiple choices, the one most to the
left is selected. In</p>
+<example>
<highlight language="config">
Protocols http/1.1 h2
</highlight>
+</example>
<p>the most preferred protocol is HTTP/1 and it will always be selected unless a
client <em>only</em> supports h2. Since we want to talk HTTP/2 to clients that
support it, the better order is</p>
+<example>
<highlight language="config">
Protocols h2 h2c http/1.1
</highlight>
+</example>
<p>There is one more thing to ordering: the client has its own preferences, too. If
you want, you can configure your server to select the protocol most preferred by
the client:</p>
+<example>
<highlight language="config">
ProtocolsHonorOrder Off
</highlight>
+</example>
<p>makes the order <em>you</em> wrote the Protocols irrelevant and only the client's
ordering will decide.</p>
<p>A last thing: the protocols you configure are not checked for correctness
<title>Useful tools to debug HTTP/2</title>
<p>The first tool to mention is of course <a href="https://curl.haxx.se">curl</a>. Please make sure that
your version supports HTTP/2 checking its <code>Features</code>:</p>
+<example>
<highlight language="config">
$ curl -V
curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...]
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP <strong>HTTP2</strong>
</highlight>
+</example>
<note><title>macOS Homebrew notes</title>
<p>Homebrew's <code>curl</code> includes HTTP/2 support by default. Install with
<code>brew install curl</code> and follow the displayed caveats to put it ahead
with it in Apache httpd?</p>
<p><module>mod_http2</module> inspects response headers for <code>Link</code> headers
in a certain format:</p>
+<example>
<highlight language="config">
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
</highlight>
+</example>
<p>If the connection supports PUSH, these two resources will be sent to the
client. As a web developer, you may set these headers either directly in
your application response or you configure the server via</p>
+<example>
<highlight language="config">
<Location /xxx.html>
Header add Link "</xxx.css>;rel=preload"
Header add Link "</xxx.js>;rel=preload"
</Location>
</highlight>
+</example>
<p>If you want to use <code>preload</code> links without triggering a PUSH, you
can use the <code>nopush</code> parameter, as in</p>
+<example>
<highlight language="config">
Link </xxx.css>;rel=preload;nopush
</highlight>
+</example>
<p>or you may disable PUSHes for your server entirely with the directive</p>
+<example>
<highlight language="config">
H2Push Off
</highlight>
+</example>
<p>And there is more:</p>
<p>The module will keep a diary of what has been PUSHed for each connection
(hashes of URLs, basically) and will not PUSH the same resource twice. When
client before the response is even ready. This uses the HTTP feature called "Early Hints" and
is described in <rfc>8297</rfc>.</p>
<p>In order to use this, you need to explicitly enable it on the server via</p>
+<example>
<highlight language="config">
H2EarlyHints on
</highlight>
+</example>
<p>(It is not enabled by default since some older browser tripped on such responses.)</p>
<p>If this feature is on, you can use the directive <directive module="mod_http2">H2PushResource</directive> to
trigger early hints and resource PUSHes:</p>
+<example>
<highlight language="config">
<Location /xxx.html>
H2PushResource /xxx.css
H2PushResource /xxx.js
</Location>
</highlight>
+</example>
<p>This will send out a <code>"103 Early Hints"</code> response to a client as soon
as the server <em>starts</em> processing the request. This may be much earlier than
the time the first response headers have been determined, depending on your web
projects / thirdparty / apache / httpd.git / commitdiff
