Update manual pages
This commit is contained in:
Tatsuhiro Tsujikawa
parent
e959e7338e
commit
dd74a6dd34
|
|
@ -1,6 +1,6 @@
|
|||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "H2LOAD" "1" "May 08, 2018" "1.32.0" "nghttp2"
|
||||
.TH "H2LOAD" "1" "Sep 02, 2018" "1.33.0-DEV" "nghttp2"
|
||||
.SH NAME
|
||||
h2load \- HTTP/2 benchmarking tool
|
||||
.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "NGHTTP" "1" "May 08, 2018" "1.32.0" "nghttp2"
|
||||
.TH "NGHTTP" "1" "Sep 02, 2018" "1.33.0-DEV" "nghttp2"
|
||||
.SH NAME
|
||||
nghttp \- HTTP/2 client
|
||||
.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "NGHTTPD" "1" "May 08, 2018" "1.32.0" "nghttp2"
|
||||
.TH "NGHTTPD" "1" "Sep 02, 2018" "1.33.0-DEV" "nghttp2"
|
||||
.SH NAME
|
||||
nghttpd \- HTTP/2 server
|
||||
.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH "NGHTTPX" "1" "May 08, 2018" "1.32.0" "nghttp2"
|
||||
.TH "NGHTTPX" "1" "Sep 02, 2018" "1.33.0-DEV" "nghttp2"
|
||||
.SH NAME
|
||||
nghttpx \- HTTP/2 proxy
|
||||
.
|
||||
|
|
@ -137,12 +137,13 @@ Several parameters <PARAM> are accepted after <PATTERN>.
|
|||
The parameters are delimited by ";". The available
|
||||
parameters are: "proto=<PROTO>", "tls",
|
||||
"sni=<SNI_HOST>", "fall=<N>", "rise=<N>",
|
||||
"affinity=<METHOD>", "dns", and "redirect\-if\-not\-tls".
|
||||
The parameter consists of keyword, and optionally
|
||||
followed by "=" and value. For example, the parameter
|
||||
"proto=h2" consists of the keyword "proto" and value
|
||||
"h2". The parameter "tls" consists of the keyword "tls"
|
||||
without value. Each parameter is described as follows.
|
||||
"affinity=<METHOD>", "dns", "redirect\-if\-not\-tls",
|
||||
"upgrade\-scheme", and "mruby=<PATH>". The parameter
|
||||
consists of keyword, and optionally followed by "=" and
|
||||
value. For example, the parameter "proto=h2" consists
|
||||
of the keyword "proto" and value "h2". The parameter
|
||||
"tls" consists of the keyword "tls" without value. Each
|
||||
parameter is described as follows.
|
||||
.sp
|
||||
The backend application protocol can be specified using
|
||||
optional "proto" parameter, and in the form of
|
||||
|
|
@ -235,6 +236,11 @@ particular backend. This is a workaround for a backend
|
|||
server which requires "https" :scheme pseudo header
|
||||
field on TLS encrypted connection.
|
||||
.sp
|
||||
"mruby=<PATH>" parameter specifies a path to mruby
|
||||
script file which is invoked when this pattern is
|
||||
matched. All backends which share the same pattern must
|
||||
have the same mruby path.
|
||||
.sp
|
||||
Since ";" and ":" are used as delimiter, <PATTERN> must
|
||||
not contain these characters. Since ";" has special
|
||||
meaning in shell, the option value must be quoted.
|
||||
|
|
@ -1577,6 +1583,13 @@ signal handling feature is disabled.
|
|||
.B \-\-mruby\-file=<PATH>
|
||||
Set mruby script file
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-\-ignore\-per\-pattern\-mruby\-error
|
||||
Ignore mruby compile error for per\-pattern mruby script
|
||||
file. If error occurred, it is treated as if no mruby
|
||||
file were specified for the pattern.
|
||||
.UNINDENT
|
||||
.SS Misc
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
|
|
@ -1934,9 +1947,28 @@ server. These hooks allows users to modify header fields, or common
|
|||
HTTP variables, like authority or request path, and even return custom
|
||||
response without forwarding request to backend servers.
|
||||
.sp
|
||||
To specify mruby script file, use \fI\%\-\-mruby\-file\fP option. The
|
||||
script will be evaluated once per thread on startup, and it must
|
||||
instantiate object and evaluate it as the return value (e.g.,
|
||||
There are 2 levels of mruby script invocations: global and
|
||||
per\-pattern. The global mruby script is set by \fI\%\-\-mruby\-file\fP
|
||||
option and is called for all requests. The per\-pattern mruby script
|
||||
is set by "mruby" parameter in \fI\%\-b\fP option. It is invoked for
|
||||
a request which matches the particular pattern. The order of hook
|
||||
invocation is: global request phase hook, per\-pattern request phase
|
||||
hook, per\-pattern response phase hook, and finally global response
|
||||
phase hook. If a hook returns a response, any later hooks are not
|
||||
invoked. The global request hook is invoked before the pattern
|
||||
matching is made and changing request path may affect the pattern
|
||||
matching.
|
||||
.sp
|
||||
Please note that request and response hooks of per\-pattern mruby
|
||||
script for a single request might not come from the same script. This
|
||||
might happen after a request hook is executed, backend failed for some
|
||||
reason, and at the same time, backend configuration is replaced by API
|
||||
request, and then the request uses new configuration on retry. The
|
||||
response hook from new configuration, if it is specified, will be
|
||||
invoked.
|
||||
.sp
|
||||
The all mruby script will be evaluated once per thread on startup, and
|
||||
it must instantiate object and evaluate it as the return value (e.g.,
|
||||
\fBApp.new\fP). This object is called app object. If app object
|
||||
defines \fBon_req\fP method, it is called with \fI\%Nghttpx::Env\fP
|
||||
object on request hook. Similarly, if app object defines \fBon_resp\fP
|
||||
|
|
@ -2224,10 +2256,10 @@ to the backend, and response phase hook for this request will
|
|||
not be invoked. When this method is called in response phase
|
||||
hook, response from backend server is canceled and discarded.
|
||||
The status code and response header fields should be set
|
||||
before using this method. To set status code, use :rb:meth To
|
||||
set response header fields, use
|
||||
before using this method. To set status code, use
|
||||
\fI\%Nghttpx::Response#status\fP\&. If status code is not
|
||||
set, 200 is used. \fI\%Nghttpx::Response#add_header\fP and
|
||||
set, 200 is used. To set response header fields,
|
||||
\fI\%Nghttpx::Response#add_header\fP and
|
||||
\fI\%Nghttpx::Response#set_header\fP\&. When this method is
|
||||
invoked in response phase hook, the response headers are
|
||||
filled with the ones received from backend server. To send
|
||||
|
|
|
|||
|
|
@ -121,12 +121,13 @@ Connections
|
|||
The parameters are delimited by ";". The available
|
||||
parameters are: "proto=<PROTO>", "tls",
|
||||
"sni=<SNI_HOST>", "fall=<N>", "rise=<N>",
|
||||
"affinity=<METHOD>", "dns", and "redirect-if-not-tls".
|
||||
The parameter consists of keyword, and optionally
|
||||
followed by "=" and value. For example, the parameter
|
||||
"proto=h2" consists of the keyword "proto" and value
|
||||
"h2". The parameter "tls" consists of the keyword "tls"
|
||||
without value. Each parameter is described as follows.
|
||||
"affinity=<METHOD>", "dns", "redirect-if-not-tls",
|
||||
"upgrade-scheme", and "mruby=<PATH>". The parameter
|
||||
consists of keyword, and optionally followed by "=" and
|
||||
value. For example, the parameter "proto=h2" consists
|
||||
of the keyword "proto" and value "h2". The parameter
|
||||
"tls" consists of the keyword "tls" without value. Each
|
||||
parameter is described as follows.
|
||||
|
||||
The backend application protocol can be specified using
|
||||
optional "proto" parameter, and in the form of
|
||||
|
|
@ -219,6 +220,11 @@ Connections
|
|||
server which requires "https" :scheme pseudo header
|
||||
field on TLS encrypted connection.
|
||||
|
||||
"mruby=<PATH>" parameter specifies a path to mruby
|
||||
script file which is invoked when this pattern is
|
||||
matched. All backends which share the same pattern must
|
||||
have the same mruby path.
|
||||
|
||||
Since ";" and ":" are used as delimiter, <PATTERN> must
|
||||
not contain these characters. Since ";" has special
|
||||
meaning in shell, the option value must be quoted.
|
||||
|
|
@ -1439,6 +1445,12 @@ Scripting
|
|||
|
||||
Set mruby script file
|
||||
|
||||
.. option:: --ignore-per-pattern-mruby-error
|
||||
|
||||
Ignore mruby compile error for per-pattern mruby script
|
||||
file. If error occurred, it is treated as if no mruby
|
||||
file were specified for the pattern.
|
||||
|
||||
|
||||
Misc
|
||||
~~~~
|
||||
|
|
@ -1777,9 +1789,28 @@ server. These hooks allows users to modify header fields, or common
|
|||
HTTP variables, like authority or request path, and even return custom
|
||||
response without forwarding request to backend servers.
|
||||
|
||||
To specify mruby script file, use :option:`--mruby-file` option. The
|
||||
script will be evaluated once per thread on startup, and it must
|
||||
instantiate object and evaluate it as the return value (e.g.,
|
||||
There are 2 levels of mruby script invocations: global and
|
||||
per-pattern. The global mruby script is set by :option:`--mruby-file`
|
||||
option and is called for all requests. The per-pattern mruby script
|
||||
is set by "mruby" parameter in :option:`-b` option. It is invoked for
|
||||
a request which matches the particular pattern. The order of hook
|
||||
invocation is: global request phase hook, per-pattern request phase
|
||||
hook, per-pattern response phase hook, and finally global response
|
||||
phase hook. If a hook returns a response, any later hooks are not
|
||||
invoked. The global request hook is invoked before the pattern
|
||||
matching is made and changing request path may affect the pattern
|
||||
matching.
|
||||
|
||||
Please note that request and response hooks of per-pattern mruby
|
||||
script for a single request might not come from the same script. This
|
||||
might happen after a request hook is executed, backend failed for some
|
||||
reason, and at the same time, backend configuration is replaced by API
|
||||
request, and then the request uses new configuration on retry. The
|
||||
response hook from new configuration, if it is specified, will be
|
||||
invoked.
|
||||
|
||||
The all mruby script will be evaluated once per thread on startup, and
|
||||
it must instantiate object and evaluate it as the return value (e.g.,
|
||||
``App.new``). This object is called app object. If app object
|
||||
defines ``on_req`` method, it is called with :rb:class:`Nghttpx::Env`
|
||||
object on request hook. Similarly, if app object defines ``on_resp``
|
||||
|
|
@ -2026,10 +2057,10 @@ respectively.
|
|||
not be invoked. When this method is called in response phase
|
||||
hook, response from backend server is canceled and discarded.
|
||||
The status code and response header fields should be set
|
||||
before using this method. To set status code, use :rb:meth To
|
||||
set response header fields, use
|
||||
before using this method. To set status code, use
|
||||
:rb:attr:`Nghttpx::Response#status`. If status code is not
|
||||
set, 200 is used. :rb:meth:`Nghttpx::Response#add_header` and
|
||||
set, 200 is used. To set response header fields,
|
||||
:rb:meth:`Nghttpx::Response#add_header` and
|
||||
:rb:meth:`Nghttpx::Response#set_header`. When this method is
|
||||
invoked in response phase hook, the response headers are
|
||||
filled with the ones received from backend server. To send
|
||||
|
|
|
|||
Loading…
Reference in New Issue