From 7f31278c4cb34b954fb00b4a263f49dc30cbcdbc Mon Sep 17 00:00:00 2001 From: Tatsuhiro Tsujikawa Date: Mon, 22 May 2017 22:53:49 +0900 Subject: [PATCH] Update doc --- doc/nghttpx.h2r | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/doc/nghttpx.h2r b/doc/nghttpx.h2r index 01f8a94b..908d29c1 100644 --- a/doc/nghttpx.h2r +++ b/doc/nghttpx.h2r @@ -171,6 +171,22 @@ be customized using :option:`--fetch-ocsp-response-file` option. If OCSP query is failed, previous OCSP response, if any, is continued to be used. +:option:`--fetch-ocsp-response-file` option provides wide range of +possibility to manage OCSP response. It can take an arbitrary script +or executable. The requirement is that it supports the command-line +interface of ``fetch-ocsp-response`` script, and it must return a +valid DER encoded OCSP response on success. It must return exit code +0 on success, and 75 for temporary error, and the other error code for +generic failure. For large cluster of servers, it is not efficient +for each server to perform OCSP query using ``fetch-ocsp-response``. +Instead, you can retrieve OCSP response in some way, and store it in a +disk or a shared database. Then specify a program in +:option:`--fetch-ocsp-response-file` to fetch it from those stores. +This could provide a way to share the OCSP response between fleet of +servers, and also any OCSP query strategy can be applied which may be +beyond the ability of nghttpx itself or ``fetch-ocsp-response`` +script. + TLS SESSION RESUMPTION ----------------------