Update manual pages
This commit is contained in:
parent
e959e7338e
commit
dd74a6dd34
|
@ -1,6 +1,6 @@
|
||||||
.\" Man page generated from reStructuredText.
|
.\" 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
|
.SH NAME
|
||||||
h2load \- HTTP/2 benchmarking tool
|
h2load \- HTTP/2 benchmarking tool
|
||||||
.
|
.
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
.\" Man page generated from reStructuredText.
|
.\" 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
|
.SH NAME
|
||||||
nghttp \- HTTP/2 client
|
nghttp \- HTTP/2 client
|
||||||
.
|
.
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
.\" Man page generated from reStructuredText.
|
.\" 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
|
.SH NAME
|
||||||
nghttpd \- HTTP/2 server
|
nghttpd \- HTTP/2 server
|
||||||
.
|
.
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
.\" Man page generated from reStructuredText.
|
.\" 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
|
.SH NAME
|
||||||
nghttpx \- HTTP/2 proxy
|
nghttpx \- HTTP/2 proxy
|
||||||
.
|
.
|
||||||
|
@ -137,12 +137,13 @@ Several parameters <PARAM> are accepted after <PATTERN>.
|
||||||
The parameters are delimited by ";". The available
|
The parameters are delimited by ";". The available
|
||||||
parameters are: "proto=<PROTO>", "tls",
|
parameters are: "proto=<PROTO>", "tls",
|
||||||
"sni=<SNI_HOST>", "fall=<N>", "rise=<N>",
|
"sni=<SNI_HOST>", "fall=<N>", "rise=<N>",
|
||||||
"affinity=<METHOD>", "dns", and "redirect\-if\-not\-tls".
|
"affinity=<METHOD>", "dns", "redirect\-if\-not\-tls",
|
||||||
The parameter consists of keyword, and optionally
|
"upgrade\-scheme", and "mruby=<PATH>". The parameter
|
||||||
followed by "=" and value. For example, the parameter
|
consists of keyword, and optionally followed by "=" and
|
||||||
"proto=h2" consists of the keyword "proto" and value
|
value. For example, the parameter "proto=h2" consists
|
||||||
"h2". The parameter "tls" consists of the keyword "tls"
|
of the keyword "proto" and value "h2". The parameter
|
||||||
without value. Each parameter is described as follows.
|
"tls" consists of the keyword "tls" without value. Each
|
||||||
|
parameter is described as follows.
|
||||||
.sp
|
.sp
|
||||||
The backend application protocol can be specified using
|
The backend application protocol can be specified using
|
||||||
optional "proto" parameter, and in the form of
|
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
|
server which requires "https" :scheme pseudo header
|
||||||
field on TLS encrypted connection.
|
field on TLS encrypted connection.
|
||||||
.sp
|
.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
|
Since ";" and ":" are used as delimiter, <PATTERN> must
|
||||||
not contain these characters. Since ";" has special
|
not contain these characters. Since ";" has special
|
||||||
meaning in shell, the option value must be quoted.
|
meaning in shell, the option value must be quoted.
|
||||||
|
@ -1577,6 +1583,13 @@ signal handling feature is disabled.
|
||||||
.B \-\-mruby\-file=<PATH>
|
.B \-\-mruby\-file=<PATH>
|
||||||
Set mruby script file
|
Set mruby script file
|
||||||
.UNINDENT
|
.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
|
.SS Misc
|
||||||
.INDENT 0.0
|
.INDENT 0.0
|
||||||
.TP
|
.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
|
HTTP variables, like authority or request path, and even return custom
|
||||||
response without forwarding request to backend servers.
|
response without forwarding request to backend servers.
|
||||||
.sp
|
.sp
|
||||||
To specify mruby script file, use \fI\%\-\-mruby\-file\fP option. The
|
There are 2 levels of mruby script invocations: global and
|
||||||
script will be evaluated once per thread on startup, and it must
|
per\-pattern. The global mruby script is set by \fI\%\-\-mruby\-file\fP
|
||||||
instantiate object and evaluate it as the return value (e.g.,
|
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
|
\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
|
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
|
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
|
not be invoked. When this method is called in response phase
|
||||||
hook, response from backend server is canceled and discarded.
|
hook, response from backend server is canceled and discarded.
|
||||||
The status code and response header fields should be set
|
The status code and response header fields should be set
|
||||||
before using this method. To set status code, use :rb:meth To
|
before using this method. To set status code, use
|
||||||
set response header fields, use
|
|
||||||
\fI\%Nghttpx::Response#status\fP\&. If status code is not
|
\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
|
\fI\%Nghttpx::Response#set_header\fP\&. When this method is
|
||||||
invoked in response phase hook, the response headers are
|
invoked in response phase hook, the response headers are
|
||||||
filled with the ones received from backend server. To send
|
filled with the ones received from backend server. To send
|
||||||
|
|
|
@ -121,12 +121,13 @@ Connections
|
||||||
The parameters are delimited by ";". The available
|
The parameters are delimited by ";". The available
|
||||||
parameters are: "proto=<PROTO>", "tls",
|
parameters are: "proto=<PROTO>", "tls",
|
||||||
"sni=<SNI_HOST>", "fall=<N>", "rise=<N>",
|
"sni=<SNI_HOST>", "fall=<N>", "rise=<N>",
|
||||||
"affinity=<METHOD>", "dns", and "redirect-if-not-tls".
|
"affinity=<METHOD>", "dns", "redirect-if-not-tls",
|
||||||
The parameter consists of keyword, and optionally
|
"upgrade-scheme", and "mruby=<PATH>". The parameter
|
||||||
followed by "=" and value. For example, the parameter
|
consists of keyword, and optionally followed by "=" and
|
||||||
"proto=h2" consists of the keyword "proto" and value
|
value. For example, the parameter "proto=h2" consists
|
||||||
"h2". The parameter "tls" consists of the keyword "tls"
|
of the keyword "proto" and value "h2". The parameter
|
||||||
without value. Each parameter is described as follows.
|
"tls" consists of the keyword "tls" without value. Each
|
||||||
|
parameter is described as follows.
|
||||||
|
|
||||||
The backend application protocol can be specified using
|
The backend application protocol can be specified using
|
||||||
optional "proto" parameter, and in the form of
|
optional "proto" parameter, and in the form of
|
||||||
|
@ -219,6 +220,11 @@ Connections
|
||||||
server which requires "https" :scheme pseudo header
|
server which requires "https" :scheme pseudo header
|
||||||
field on TLS encrypted connection.
|
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
|
Since ";" and ":" are used as delimiter, <PATTERN> must
|
||||||
not contain these characters. Since ";" has special
|
not contain these characters. Since ";" has special
|
||||||
meaning in shell, the option value must be quoted.
|
meaning in shell, the option value must be quoted.
|
||||||
|
@ -1439,6 +1445,12 @@ Scripting
|
||||||
|
|
||||||
Set mruby script file
|
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
|
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
|
HTTP variables, like authority or request path, and even return custom
|
||||||
response without forwarding request to backend servers.
|
response without forwarding request to backend servers.
|
||||||
|
|
||||||
To specify mruby script file, use :option:`--mruby-file` option. The
|
There are 2 levels of mruby script invocations: global and
|
||||||
script will be evaluated once per thread on startup, and it must
|
per-pattern. The global mruby script is set by :option:`--mruby-file`
|
||||||
instantiate object and evaluate it as the return value (e.g.,
|
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
|
``App.new``). This object is called app object. If app object
|
||||||
defines ``on_req`` method, it is called with :rb:class:`Nghttpx::Env`
|
defines ``on_req`` method, it is called with :rb:class:`Nghttpx::Env`
|
||||||
object on request hook. Similarly, if app object defines ``on_resp``
|
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
|
not be invoked. When this method is called in response phase
|
||||||
hook, response from backend server is canceled and discarded.
|
hook, response from backend server is canceled and discarded.
|
||||||
The status code and response header fields should be set
|
The status code and response header fields should be set
|
||||||
before using this method. To set status code, use :rb:meth To
|
before using this method. To set status code, use
|
||||||
set response header fields, use
|
|
||||||
:rb:attr:`Nghttpx::Response#status`. If status code is not
|
: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
|
:rb:meth:`Nghttpx::Response#set_header`. When this method is
|
||||||
invoked in response phase hook, the response headers are
|
invoked in response phase hook, the response headers are
|
||||||
filled with the ones received from backend server. To send
|
filled with the ones received from backend server. To send
|
||||||
|
|
Loading…
Reference in New Issue