At least we should make sure that the OCSP response is targeted to the
expected certificate. This is important because we pass the file path
to the external script, and if the file is replaced because of
renewal, and nghttpx has not reloaded its configuration, the
certificate nghttpx has loaded and the one included in the file
differ. Verifying the OCSP response detects this, and avoids to send
wrong OCSP response.
With --ocsp-startup option, nghttpx starts accepting connections after
initial attempts to get OCSP responses finish. It does not matter
some of the attempts fail. This feature is useful if OCSP responses
must be available before accepting connections.
Previously, nghttpx will use only one single thread inside the worker
process if --workers=1 (this is default). If --workers=N, N > 1, we
use additional threads for accepting connections, or API request
processing, etc.
With this commit, we use the same processing model for N > 1 even if N
== 1. To restore the original single thread execution mode,
--single-worker option is added. If threading is disabled
--single-worker is always true.
nghttpx supports multiple certificates using --subcert option.
Previously, SNI hostname is used to select certificate. With this
commit, signature algorithm presented by client is also taken into
consideration. nghttpx now accepts certificates which share the same
hostname (CN, SAN), but have different signature algorithm (e.g.,
ECDSA+SHA256, RSA+SHA256).
Currently, this feature requires OpenSSL >= 1.0.2. BoringSSL, and
LibreSSL do not work since they lack required APIs.
Normally, we don't have wait for child process to exit, since init can
take care of them. But in containerized environment, pid 0 init might
not be available, and defunct processes can be piled up. This commit
ensures that OCSP and neverbleed processes are waited for before
worker process exits.
Previously, we didn't retry request on connection failure. Sometimes
we hit the edge case where connection is about to lost just when we
write request. To avoid this situation, we now retry request to
failed attempt. We also add ConnectBlocker to MemcachedConnection not
to attempt to connect to memcached if connection could not be made
previously.
Some API processing is very slow (e.g., getaddrinfo). To avoid to
slow down regular request handling, if multi threaded configuration is
enabled, we allocate dedicated worker for API.
Tatsuhiro Tsujikawa