We released nghttp2 v1.12.0.

This release adds 2 new API functions to libnghttp2. It also adds HTTP/1.1 POST support to h2load. nghttpx gets new features, and performance improvements.

We’ve added new API function, nghttp2_option_set_max_send_header_block_length(). Previously, the maximum size of header block to send (calculated using the same algorithm using nghttp2_hd_deflate_bound()) is hard coded as 64KiB. This is probably sufficient in practice, but sometimes it is desirable to send more, for example, testing purposes. nghttp2_option_set_max_send_header_block_length() lets you set this maximum size by application for its demand.

The another new API function is nghttp2_session_set_local_window_size(). Previously, application can increase or even decrease local window size (which is the window size the remote endpoint must obey when sending DATA to local endpoint) by using nghttp2_submit_window_size(). But it was a bit hard to use since it takes the difference against the current window size. It also affects the current received byte count which is not acknowledged by WINDOW_UPDATE frame, which is not always desirable. The new function allows application to set the absolute value of local window size instead of relative value, and libnghttp2 makes it happen. It does not affect the current received byte count.

We have client and server implementations under examples directory written for tutorials. Previously, they only supported NPN TLS extension. Now they finally get ALPN TLS extension support.

h2load has supported HTTP POST for quite sometime, but it turned out that its support was limited to HTTP/2 and SPDY. Now we implemented HTTP POST for HTTP/1.1 as well. There is a known limitation. When HTTP POST is used with HTTP/1.1 connection, -m option is ignored, and it is treated as -m1, which means that HTTP pipelining is disabled.

We added alternative mode to nghttpx frontend, and introduced 2 modes in this release. This mode is set using --frontend option.

The first alternative mode is health monitor mode. It is enabled per listener address by specifying healthmon parameter to --frontend option. If it is enabled, all requests coming from that listener are replied with HTTP 200 status code with no response body, without contacting backend server at all. This mode is useful to do health check for nghttpx itself.

The second alternative mode is API mode. It is enabled per listener address by specifying api parameter to --frontend option. The requests coming from this listener are treated specially as API request. In this release, we have only one API endpoint, which is PUT /api/v1beta1/backendconfig. The client can post snippet of nghttpx configuration file containing backend option lines to this API endpoint. On reception, nghttpx will parse the request body, and replace the backend servers on the fly without restarting nghttpx process. The request body is the same format as the file given to --conf option.

nghttpx gets client IP based session affinity support. It is enabled per forwarding pattern basis (see <PATTERN> in --backend option) by adding affinity=ip parameter. If it is enabled, all connections from the same IP address will be forwarded to the same backend address. The session affinity may break if one of the backend gets unreachable, or backend settings are reloaded or replaced by API.

We identified longer TTFB and connect times (you know h2load has these metrics) when lots of concurrent connections are made to nghttpx. We fixed this issue in this release, and now nghttpx does not exhibit longer waiting times in this condition.