nghttp2 - HTTP/2 C Library

This is an implementation of the Hypertext Transfer Protocol version 2 in C.

The framing layer of HTTP/2 is implemented as a reusable C library. On top of that, we have implemented an HTTP/2 client, server and proxy.  We have also developed load test and benchmarking tools for HTTP/2.

An HPACK encoder and decoder are available as a public API.

nghttp2 was originally developed based on RFC 7540 HTTP/2 and RFC 7541 HPACK - Header Compression for HTTP/2.  Now we are updating our code to implement RFC 9113.

The nghttp2 code base was forked from the spdylay (https://github.com/tatsuhiro-t/spdylay ) project.

The following endpoints are available to try out our nghttp2 implementation.

https://nghttp2.org/ (TLS + ALPN/NPN and HTTP/3)

This endpoint supports h2, h2-16, h2-14, and http/1.1 via ALPN/NPN and requires TLSv1.2 for HTTP/2 connection.

It also supports HTTP/3.

http://nghttp2.org/ (HTTP Upgrade and HTTP/2 Direct)

h2c and http/1.1.

The following package is required to build the libnghttp2 library:

pkg-config >= 0.20

To build and run the unit test programs, the following package is required:

cunit >= 2.1

To build the documentation, you need to install:

sphinx (http://sphinx-doc.org/ )

If you need libnghttp2 (C library) only, then the above packages are all you need.  Use --enable-lib-only to ensure that only libnghttp2 is built.  This avoids potential build error related to building bundled applications.

To build and run the application programs (nghttp, nghttpd, nghttpx and h2load ) in the src directory, the following packages are required:

OpenSSL >= 1.0.1

libev >= 4.11

zlib >= 1.2.3

libc-ares >= 1.7.5

ALPN support requires OpenSSL >= 1.0.2 (released 22 January 2015). LibreSSL >= 2.2.0 can be used instead of OpenSSL, but OpenSSL has more features than LibreSSL at the time of this writing.

To enable -a option (getting linked assets from the downloaded resource) in nghttp, the following package is required:

libxml2 >= 2.6.26

To enable systemd support in nghttpx, the following package is required:

libsystemd-dev >= 209

The HPACK tools require the following package:

jansson >= 2.5

To build sources under the examples directory, libevent is required:

libevent-openssl >= 2.0.8

To mitigate heap fragmentation in long running server programs (nghttpd and nghttpx ), jemalloc is recommended:

jemalloc

Note

Alpine Linux currently does not support malloc replacement due to musl limitations. See details in issue #762.

To enable mruby support for nghttpx, mruby is required.  We need to build mruby with C++ ABI explicitly turned on, and probably need other mrgems, mruby is manged by git submodule under third-party/mruby directory.  Currently, mruby support for nghttpx is disabled by default.  To enable mruby support, use --with-mruby configure option.  Note that at the time of this writing, libmruby-dev and mruby packages in Debian/Ubuntu are not usable for nghttp2, since they do not enable C++ ABI.  To build mruby, the following packages are required:

ruby

bison

nghttpx supports neverbleed, privilege separation engine for OpenSSL / LibreSSL.  In short, it minimizes the risk of private key leakage when serious bug like Heartbleed is exploited.  The neverbleed is disabled by default.  To enable it, use --with-neverbleed configure option.

To enable the experimental HTTP/3 support for h2load and nghttpx, the following libraries are required:

OpenSSL with QUIC support ; or BoringSSL (commit b0341041b03ea71d8371a9692aedae263fc06ee9)

ngtcp2 0.16.x

nghttp3 0.12.x

Use --enable-http3 configure option to enable HTTP/3 feature for h2load and nghttpx.

In order to build optional eBPF program to direct an incoming QUIC UDP datagram to a correct socket for nghttpx, the following libraries are required:

libbpf-dev >= 0.7.0

Use --with-libbpf configure option to build eBPF program. libelf-dev is needed to build libbpf.

For Ubuntu 20.04, you can build libbpf from the source code.  nghttpx requires eBPF program for reloading its configuration and hot swapping its executable.

Compiling libnghttp2 C source code requires a C99 compiler.  gcc 4.8 is known to be adequate.  In order to compile the C++ source code, gcc >= 6.0 or clang >= 6.0 is required.  C++ source code requires C++14 language features.

Note

To enable mruby support in nghttpx, and use --with-mruby configure option.

Note

Mac OS X users may need the --disable-threads configure option to disable multi-threading in nghttpd, nghttpx and h2load to prevent them from crashing. A patch is welcome to make multi threading work on Mac OS X platform.

Note

To compile the associated applications (nghttp, nghttpd, nghttpx and h2load), you must use the --enable-app configure option and ensure that the specified requirements above are met.  Normally, configure script checks required dependencies to build these applications, and enable --enable-app automatically, so you don't have to use it explicitly.  But if you found that applications were not built, then using --enable-app may find that cause, such as the missing dependency.

Note

In order to detect third party libraries, pkg-config is used (however we don't use pkg-config for some libraries (e.g., libev)). By default, pkg-config searches `.pc file in the standard locations (e.g., /usr/lib/pkgconfig).  If it is necessary to use .pc file in the custom location, specify paths to PKG_CONFIG_PATH` environment variable, and pass it to configure script, like so:

$ ./configure PKG_CONFIG_PATH=/path/to/pkgconfig For pkg-config managed libraries, `_CFLAG and _LIBS environment variables are defined (e.g., OPENSSL_CFLAGS, OPENSSL_LIBS ).  Specifying non-empty string to these variables completely overrides pkg-config.  In other words, if they are specified, pkg-config is not used for detection, and user is responsible to specify the correct values to these variables.  For complete list of these variables, run ./configure -h`.

If you are using Ubuntu 22.04 LTS, run the following to install the required packages:

sudo apt-get install g++ clang make binutils autoconf automake \   autotools-dev libtool pkg-config \   zlib1g-dev libcunit1-dev libssl-dev libxml2-dev libev-dev \   libevent-dev libjansson-dev \   libc-ares-dev libjemalloc-dev libsystemd-dev \   ruby-dev bison libelf-dev ## Building nghttp2 from release tar archive

The nghttp2 project regularly releases tar archives which includes nghttp2 source code, and generated build files.  They can be downloaded from Releases page.

Building nghttp2 from git requires autotools development packages. Building from tar archives does not require them, and thus it is much easier.  The usual build step is as follows:

$ tar xf nghttp2-X.Y.Z.tar.bz2 $ cd nghttp2-X.Y.Z $ ./configure $ make ## Building from git

Building from git is easy, but please be sure that at least autoconf 2.68 is used:

$ git submodule update --init $ autoreconf -i $ automake $ autoconf $ ./configure $ make ## Notes for building on Windows (MSVC)

The easiest way to build native Windows nghttp2 dll is use cmake.  The free version of Visual C++ Build Tools works fine.

Install cmake for windows

Open "Visual C++ ... Native Build Tool Command Prompt", and inside nghttp2 directly, run cmake.

Then run cmake --build to build library.

nghttp2.dll, nghttp2.lib, nghttp2.exp are placed under lib directory.

Note that the above steps most likely produce nghttp2 library only. No bundled applications are compiled.

Under Mingw environment, you can only compile the library, it's libnghttp2-X.dll and libnghttp2.a.

If you want to compile the applications(h2load, nghttp, nghttpx, nghttpd ), you need to use the Cygwin environment.

Under Cygwin environment, to compile the applications you need to compile and install the libev first.

Secondly, you need to undefine the macro __STRICT_ANSI__, if you not, the functions fdopen, fileno and strptime will not available.

the sample command like this:

$ export CFLAGS="-U__STRICT_ANSI__ -I$libev_PREFIX/include -L$libev_PREFIX/lib" $ export CXXFLAGS=$CFLAGS $ ./configure $ make If you want to compile the applications under examples/, you need to remove or rename the event.h from libev's installation, because it conflicts with libevent's installation.

After installing nghttp2 tool suite with make install one might experience a similar error:

nghttpx: error while loading shared libraries: libnghttp2.so.14: cannot open shared object file: No such file or directory This means that the tool is unable to locate the libnghttp2.so shared library.

To update the shared library cache run sudo ldconfig.

Note

Documentation is still incomplete.

To build the documentation, run:

$ make html The documents will be generated under doc/manual/html/.

The generated documents will not be installed with make install.

The online documentation is available at https://nghttp2.org/documentation/

To build h2load and nghttpx with HTTP/3 feature enabled, run the configure script with --enable-http3.

For nghttpx to reload configurations and swapping its executable while gracefully terminating old worker processes, eBPF is required.  Run the configure script with --enable-http3 --with-libbpf to build eBPF program.  The QUIC keying material must be set with --frontend-quic-secret-file in order to keep the existing connections alive during reload.

The detailed steps to build HTTP/3 enabled h2load and nghttpx follow.

Build custom OpenSSL:

$ git clone --depth 1 -b OpenSSL_1_1_1u+quic https://github.com/quictls/openssl $ cd openssl $ ./config --prefix=$PWD/build --openssldir=/etc/ssl $ make -j$(nproc) $ make install_sw $ cd .. Build nghttp3:

$ git clone --depth 1 -b v0.12.0 https://github.com/ngtcp2/nghttp3 $ cd nghttp3 $ autoreconf -i $ ./configure --prefix=$PWD/build --enable-lib-only $ make -j$(nproc) $ make install $ cd .. Build ngtcp2:

$ git clone --depth 1 -b v0.16.0 https://github.com/ngtcp2/ngtcp2 $ cd ngtcp2 $ autoreconf -i $ ./configure --prefix=$PWD/build --enable-lib-only \       PKG_CONFIG_PATH="$PWD/../openssl/build/lib/pkgconfig" $ make -j$(nproc) $ make install $ cd .. If your Linux distribution does not have libbpf-dev >= 0.7.0, build from source:

$ git clone --depth 1 -b v1.2.0 https://github.com/libbpf/libbpf $ cd libbpf $ PREFIX=$PWD/build make -C src install $ cd .. Build nghttp2:

$ git clone https://github.com/nghttp2/nghttp2 $ cd nghttp2 $ git submodule update --init $ autoreconf -i $ ./configure --with-mruby --with-neverbleed --enable-http3 --with-libbpf \       CC=clang-14 CXX=clang++-14 \       PKG_CONFIG_PATH="$PWD/../openssl/build/lib/pkgconfig:$PWD/../nghttp3/build/lib/pkgconfig:$PWD/../ngtcp2/build/lib/pkgconfig:$PWD/../libbpf/build/lib64/pkgconfig" \       LDFLAGS="$LDFLAGS -Wl,-rpath,$PWD/../openssl/build/lib -Wl,-rpath,$PWD/../libbpf/build/lib64" $ make -j$(nproc) The eBPF program reuseport_kern.o should be found under bpf directory.  Pass --quic-bpf-program-file=bpf/reuseport_kern.o option to nghttpx to load it.  See also HTTP/3 section in nghttpx -HTTP/2 proxy - HOW-TO.

Unit tests are done by simply running make check.

We have the integration tests for the nghttpx proxy server.  The tests are written in the Go programming language and uses its testing framework.  We depend on the following libraries:

golang.org/x/net/http2

golang.org/x/net/websocket

https://github.com/tatsuhiro-t/go-nghttp2

Go modules will download these dependencies automatically.

To run the tests, run the following command under integration-tests directory:

$ make it Inside the tests, we use port 3009 to run the test subject server.

nghttp2 v1.0.0 introduced several backward incompatible changes.  In this section, we describe these changes and how to migrate to v1.0.0.

Previously we announced h2-14 and h2c-14.  v1.0.0 implements final protocol version, and we changed ALPN ID to h2 and h2c. The macros NGHTTP2_PROTO_VERSION_ID, NGHTTP2_PROTO_VERSION_ID_LEN, NGHTTP2_CLEARTEXT_PROTO_VERSION_ID, and NGHTTP2_CLEARTEXT_PROTO_VERSION_ID_LEN have been updated to reflect this change.

Basically, existing applications do not have to do anything, just recompiling is enough for this change.

We use "client connection preface" to mean first 24 bytes of client connection preface.  This is technically not correct, since client connection preface is composed of 24 bytes client magic byte string followed by SETTINGS frame.  For clarification, we call "client magic" for this 24 bytes byte string and updated API.

NGHTTP2_CLIENT_CONNECTION_PREFACE was replaced with NGHTTP2_CLIENT_MAGIC.

NGHTTP2_CLIENT_CONNECTION_PREFACE_LEN was replaced with NGHTTP2_CLIENT_MAGIC_LEN.

NGHTTP2_BAD_PREFACE was renamed as NGHTTP2_BAD_CLIENT_MAGIC

The already deprecated NGHTTP2_CLIENT_CONNECTION_HEADER and NGHTTP2_CLIENT_CONNECTION_HEADER_LEN were removed.

If application uses these macros, just replace old ones with new ones. Since v1.0.0, client magic is sent by library (see next subsection), so client application may just remove these macro use.

Previously nghttp2 library did not send client magic, which is first 24 bytes byte string of client connection preface, and client applications have to send it by themselves.  Since v1.0.0, client magic is sent by library via first call of nghttp2_session_send() or nghttp2_session_mem_send().

The client applications which send client magic must remove the relevant code.

Alt-Svc specification is not finalized yet.  To make our API stable, we have decided to remove all Alt-Svc related API from nghttp2.

NGHTTP2_EXT_ALTSVC was removed.

nghttp2_ext_altsvc was removed.

We have already removed the functionality of Alt-Svc in v0.7 series and they have been essentially noop.  The application using these macro and struct, remove those lines.

Previously nghttp2_on_invalid_frame_recv_cb_called took the error_code, defined in nghttp2_error_code, as parameter.  But they are not detailed enough to debug.  Therefore, we decided to use more detailed nghttp2_error values instead.

The application using this callback should update the callback signature.  If it treats `error_co