HTTP/2 is the newest version of the HTTP protocol, based off SPDY. Its development was initiated by Google and HTTP/2 is largely based on the codebase and concepts of SPDY.
SPDY has now been deprecated and worldwide adoption for HTTP/2 is in progress. Many hosting companies have already provided support for HTTP/2 due to its added speed.
At the time of writing, DirectAdmin does not provide a one-click way to enable HTTP/2. However, there are multiple ways to achieve HTTP/2 support. The method outlined below has proven to be the most robust and stable approach.
Several components need to be updated in order for HTTP/2 to take effect. Because of this, I strongly advise you to take a snapshot. If possible, follow this guide on a completely new server.
This guide consists of two parts: enabling HTTP/2 support in the web server (Apache) for clients (visitors) and the activation of HTTP/2 in cURL. Enabling HTTP v2 for cURL forces cURL requests originating from your server to make use of HTTP/2 for its destination servers, if possible.
- It’s not required to update both Apache and cURL to use HTTP/2. It’s fine if you follow either guides, as they function separately from each other.
- There have been a few strange cases in which Apache and HTTP/2 seem to function fine, but loading succeeds on ”random” browsers and sites become unreachable (timeout) on others. Simply reverting to the original Apache configuration will fix this, as Apache will not know about HTTP/2 and not attempt to serve content over it.
- Always take a backup or make a snapshot in advance. Enabling HTTP/2 can be a relatively fragile process so it’s important to be able to revert changes if needed.
- Recompiling software can always cause slight downtime. In some cases, this is under a minute, but there’s no way to tell exactly. You should be prepared for some downtime at the very least.
- You need root access to the server for this guide. If you do not have the ability to elevate your permissions level to root, you should contact the server administrator to enable HTTP/2 on the server.
HTTP/2 and SSL
Although it is not a technical requirement from HTTP/2 itself, in most cases you will need an SSL certificate in order to use HTTP/2. As mentioned, HTTP/2 does not technically require this, but many browsers (Safari, Chrome, Firefox, etc.) have created this standard. Content will not be served over HTTP/2 when a page is loaded without SSL using these browsers. Considering most users use these browsers (and others) which also participate in this standard, you should use an SSL certificate.
If you’re looking for a free SSL certificate, you should take a look at one of our Let’s Encrypt guides:
Recommended: Installing Let’s Encrypt on DirectAdmin
Part 1: Apache (web server)
If you are currently making use of a reverse proxy, you should switch back to an Apache-only environment. That is because HTTP/2 is very hard to debug if something goes wrong. By being able to make use of Apache’s integrated HTTP/2 functionality, you are effectively able to eliminate a very large part of trouble.
Step 1: Upgrading OpenSSL
In many cases, your OpenSSL version is not compatible with ALPN, which is required for HTTP/2. Therefore, let’s enable ALPN by updating OpenSSL.
First off, let’s make sure your OpenSSL version is not compatible by executing:
If your OpenSSL version is less than 1.1.0f, execute the following as root. Otherwise, skip to step 2.
cd ~ wget ftp://ftp.openssl.org/source/openssl-1.1.1a.tar.gz tar xzfv openssl-1.1.1a.tar.gz cd openssl-1.1.1a ./config --prefix=/usr/local/lib_http2 no-ssl2 no-ssl3 zlib-dynamic -fPIC make depend make install
Step 2: Installing nghttp2
In order for HTTP/2 to work, we need to install nghttp2. Nghttp2 is an implementation of HTTP/2 (and HPACK) in C. Nghttp2 is a combined version of the HTTP/2 client, server and proxy in C.
To install nghttp2, execute the following commands. Luckily, nghttp2 can be built straight from CustomBuild.
cd /usr/local/directadmin/custombuild ./build update ./build nghttp2
Step 3: Enabling HTTP/2 in Apache
We need to alter a few values in the Apache configuration file in order for it to make use of HTTP/2. When the web server is not getting instructions to use an alternative HTTP version, it won’t make use of it. Therefore we need to add HTTP/2 to the configuration file.
For these changes to take effect, a rebuild of Apache through CustomBuild is necessary. As the parameters and values used by CustomBuild when building software are determined in a dedicated configuration file, best practice is to put these changes in a dedicated custom configuration file.
Note: if you do not put these changes in a custom file, they will most likely be overwritten and your setup will break. Please follow the instructions outlined below.
Execute the following commands in order to create the file and prefill it with the default values so we can alter it afterwards:
mkdir -p /usr/local/directadmin/custombuild/custom/ap2 cp -p /usr/local/directadmin/custombuild/configure/ap2/configure.apache /usr/local/directadmin/custombuild/custom/ap2/configure.apache
As of now, we have a custom file which is identical to the default configuration file for Apache used by CustomBuild. We have to alter the /usr/local/directadmin/custombuild/custom/ap2/configure.apache file by replacing the following string:
"--enable-http2" \ "--enable-ssl-staticlib-deps" \ "--with-ssl=/usr/local/lib_http2" \
Note: Make sure that there is no white space after any of the backslashes. Excess whitespace there will cause the build to break.
Next, rebuild Apache. CustomBuild will use the custom configuration file you have just created:
If this error occurred.
/usr/sbin/httpd: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
The following steps should be taken:
ln -s /usr/local/lib_http2/lib/libssl.so.1.1 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 ln -s /usr/local/lib_http2/lib/libcrypto.so.1.1 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
Step 4: Altering the Apache configuration
Apache has now been rebuilt including the necessary modules and settings for HTTP/2. That means we now have an Apache version installed on our server with support for HTTP/2, but we need to tell Apache to actually use it first.
Add the following lines in /etc/httpd/conf/extra/httpd-includes.conf:
ProtocolsHonorOrder On Protocols h2 h2c http/1.1
Save these changes and rewrite the configuration files so they’re persistent across rebuilds:
cd /usr/local/directadmin/custombuild ./build rewrite_confs
HTTP/2 should now be active on your web (Apache) server.
Step 5: Reboot the server
Reboot the server to make sure that our changes persist across reboots. Please reboot the server though the Vultr control panel or by executing the reboot command.
Step 6: Test HTTP/2
HTTP/2’s functionality can easily be tested by using the following tool: HTTP/2 Test
Considering HTTP/2 is server-specific and cannot be restricted to a specific pair of domains or websites, entering any domain name pointing to the server or even the server IP address should work.
The test will tell you if it’s able to reach the web server through HTTP/2. In case the tool says HTTP/2 is activated on your server, DirectAdmin websites can now be reached through either HTTP/1.1 or HTTP/2. In case HTTP/2 support is not available for the client (visitor) its browser will fall back to HTTP/1.1.
In case the tool cannot reach your web server through HTTP/2, follow above steps again. Generally (as the above steps don’t actively overwrite anything) this won’t damage or break your setup.
Part 2: cURL
I recommend updating cURL so it’s able to reach servers with HTTP/2 support. In case a server does not support HTTP/2, it will fall back to HTTP/1.1.
Step 1: Adding the custom configuration file
Just like with Apache, we will create a custom configuration file so cURL built by CustomBuild will use our custom settings.
Create the directory:
mkdir -p /usr/local/directadmin/custombuild/custom/curl
Create the file:
Copy and paste the following contents to the file:
#!/bin/sh perl -pi -e 's|CURL_CHECK_PKGCONFIG\(zlib\)|#CURL_CHECK_PKGCONFIG(zlib)|g' configure.ac LIBS="-ldl" ./configure --with-nghttp2=/usr/local --with-ssl=/usr/local/lib_http2
As you can see, these contents tell cURL to be compiled using the lib_http2 SSL library.
Save the file and give it the correct permissions:
chmod 700 /usr/local/directadmin/custombuild/custom/curl/configure.curl
Step 2: Building cURL
Next, all we need to do is to build cURL.
cd /usr/local/directadmin/custombuild ./build curl
If this error occurred.
vtls/openssl.c: In function 'Curl_ossl_seed': vtls/openssl.c:454:5: error: implicit declaration of function 'RAND_egd' [-Werror=implicit-function-declaration] int ret = RAND_egd(data->set.str[STRING_SSL_EGDSOCKET]? ^ cc1: some warnings being treated as errors Makefile:2425: recipe for target 'vtls/libcurl_la-openssl.lo' failed make: *** [vtls/libcurl_la-openssl.lo] Error 1 make: Leaving directory '/usr/local/directadmin/custombuild/curl-7.62.0/lib' Makefile:1028: recipe for target 'all' failed make: *** [all] Error 2 make: Leaving directory '/usr/local/directadmin/custombuild/curl-7.62.0/lib' Makefile:929: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 *** The make has failed, would you like to try to make again? (y,n):
The following steps should be taken:
apt-get remove libssl-dev cd /usr/local/directadmin/custombuild ./build curl
cURL has now been compiled with HTTP 2 support.