diff options
Diffstat (limited to '')
32 files changed, 3733 insertions, 0 deletions
diff --git a/debian/vendor-h2o/srcdoc/benchmarks.mt b/debian/vendor-h2o/srcdoc/benchmarks.mt new file mode 100644 index 0000000..a0096cc --- /dev/null +++ b/debian/vendor-h2o/srcdoc/benchmarks.mt @@ -0,0 +1,48 @@ +? my $note = $main::context->{note}; +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Benchmarks")->(sub { + +<h3 id="download-timings">Download Timings</h3> + +<div> +<p> +Providing quick response to user is more important than anything else in web performance tuning. +According to a research conducted by Microsoft, 500msec slowdown in Bing causes their revenue go down by 1.2%<?= $note->(q{<a href="http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html">Velocity and the Bottom Line - O'Reilly Radar</a>}) ?>. +</p> +<p> +The chart below compares the first-paint times and download completion times of different web browsers / HTTP servers on a simulated network of 8Mbps bandwidth with 100ms latency, which is typical for today's mobile networks<?= $note->(q{<a href="https://github.com/kazuho/http2rulez.com">A fork of http2rulez.com</a> was used as the target website; bandwidth and latency were induced to local network using <a href="http://linux-ip.net/articles/Traffic-Control-HOWTO/components.html">qdisc</a>, specifically by running <code>tc qdisc replace dev eth1 root handle 1:0 tbf rate 8192kbit burst 2048 latency 100ms; sudo tc qdisc add dev eth1 parent 1:1 netem delay 100ms</code>, and <code>sysctl -w net.ipv4.tcp_no_metrics_save=1</code>.}) ?>. +</p> +<div align="center"> +<a href="assets/8mbps100msec-nginx195-h2o150.png" target="_blank"><img src="assets/8mbps100msec-nginx195-h2o150.png" height="300"></a> +</div> +<p> +It is clear in the case of this benchmark that the visitors of the web site would be more satisfied, if H2O was used as the HTTP server. +</p> +</div> + +<h3 id="static-file">Static-File Serving</h3> + +<div> +<p> +Below chart shows the scores recorded on Amazon EC2 running two c3.8xlarge instances (server and client) on a single network placement, serving a 612-byte file<?= $note->(q{Configuration files used: <a href="https://gist.github.com/kazuho/def1e71281ed4ae07b95">nginx.conf</a>, <a href="https://gist.github.com/kazuho/969bb99bae31d67e01c4">h2o.conf</a>.}) ?>. +For each measurement, 250 concurrent clients were used<?= $note->(q{<a href="https://github.com/wg/wrk">Wrk</a> was used for HTTP/1 tests. <a href="https://nghttp2.org/documentation/h2load-howto.html">h2load</a> was used for HTTP/2.}) ?>. +<code>open_file_cache</code> was used for Nginx. +H2O implements a open-file-cache that gets updated immediately when the files are replaced. +</p> +<div align="center"> +<a href="assets/staticfile612-nginx1910-h2o170.png" target="_blank"><img src="assets/staticfile612-nginx1910-h2o170.png" height="300"></a> +</div> +</div> + +<h3 id="reverse-proxy">Reverse Proxy</h3> + +<div> +<p> +Presented below is an old chart showing the scores recorded on Amazon EC2 running two c3.8xlarge instances (server and client) on a single network placement<?= $note->("For reverse-proxy tests, another H2O process running on the same host was used as the upstream server") ?><?= $note->("open-file-cache was not used in the static-file benchmark") ?>. +</p> +<div align="center"> +<a href="assets/remotebench.png" target="_blank"><img src="assets/remotebench.png" width="400"></a> +</div> +</div> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure.mt b/debian/vendor-h2o/srcdoc/configure.mt new file mode 100644 index 0000000..5c8799f --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure.mt @@ -0,0 +1,43 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure")->(sub { + +<ul style="list-style: none; font-weight: bold;"> +<li><a href="configure/quick_start.html">Quick Start</a> +<li><a href="configure/command_options.html">Command Options</a> +<li>Configuration File +<ul> +<li><a href="configure/syntax_and_structure.html">Syntax and Structure</a> +</ul> +<li>Configuration Directives +<ul> +<li><a href="configure/base_directives.html">Base</a> +<li><a href="configure/http1_directives.html">HTTP/1</a> +<li><a href="configure/http2_directives.html">HTTP/2</a> +<li><a href="configure/access_log_directives.html">Access Log</a> +<li><a href="configure/compress_directives.html">Compress</a> +<li><a href="configure/errordoc_directives.html">Errordoc</a> +<li><a href="configure/expires_directives.html">Expires</a> +<li><a href="configure/fastcgi_directives.html">FastCGI</a> +<li><a href="configure/file_directives.html">File</a> +<li><a href="configure/headers_directives.html">Headers</a> +<li><a href="configure/mruby_directives.html">Mruby</a> +<li><a href="configure/proxy_directives.html">Proxy</a> +<li><a href="configure/redirect_directives.html">Redirect</a> +<li><a href="configure/reproxy_directives.html">Reproxy</a> +<li><a href="configure/status_directives.html">Status</a> +<li><a href="configure/throttle_response_directives.html">Throttle Response</a> +</ul> +</li> +<li>How-To +<ul> +<li><a href="configure/basic_auth.html">Using Basic Authentication</a></li> +<li><a href="configure/cgi.html">Using CGI</a></li> +<li><a href="configure/mruby.html">Using Mruby</a></li> +<li><a href="configure/dos_detection.html">Using DoS Detection</a></li> +<li><a href="configure/access_control.html">Access Control</a></li> +</ul> +</li> +<li><a href="https://github.com/h2o/h2o/wiki#configuration-examples" target="_blank">Configuration Examples (Wiki)</a> +</ul> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/access_control.mt b/debian/vendor-h2o/srcdoc/configure/access_control.mt new file mode 100644 index 0000000..4a613ac --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/access_control.mt @@ -0,0 +1,273 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Access Control")->(sub { + +<p> +Starting from version 2.1, H2O comes with a DSL-like mruby library which makes it easy to write access control list (ACL). +</p> + +<h2 id="example" class="section-head">Example</h2> + +<p> +Below example uses this Access Control feature to write various access control. +</p> + +<?= $ctx->{example}->('Access Control', <<'EOT'); +paths: + "/": + mruby.handler: | + acl { + allow { addr == "127.0.0.1" } + deny { user_agent.match(/curl/i) && ! addr.start_with?("192.168.") } + respond(503, {}, ["Service Unavailable"]) { addr == malicious_ip } + redirect("https://example.com/", 301) { path =~ /moved/ } + use Htpasswd.new("/path/to/.htpasswd", "realm") { path.start_with?("/admin") } + } + file.dir: /path/to/doc_root +EOT +?> + +<p> +In the example, the handler you get by calling <code>acl</code> method will do the following: +<ul> + <li> + if the remote IP address is exactly equal to "127.0.0.1", the request will be delegated to the next handler (i.e. serve files under /path/to/doc_root) and all following acl settings are ignored + </li> + <li> + otherwise, if the user agent string includes "curl" and the remote IP address doesn't start with "192.168.", this handler immediately returns <code>403 Forbidden</code> response + </li> + <li> + otherwise, if the remote IP address is exactly equal to the <code>malicious_ip</code> variable, this handler immediately returns <code>503 Service Unavailable</code> response + </li> + <li> + otherwise, if the request path matches with the pattern <code>/moved/i</code>, this handler immediately redirects the client to <code>"https://example.com"</code> with <code>301</code> status code + </li> + <li> + otherwise, if the request path starts with <code>/admin</code>, apply Basic Authentication to the request (for details of Basic Authentication, see <a href="configure/basic_auth.html">here</a>). + </li> + <li> + otherwise, the request will be delegated to the next handler (i.e. serve files under /path/to/doc_root) + </li> + +</ul> + +<h2 id="acl-methods" class="section-head">ACL Methods</h2> + +<p> +An ACL handler is built by calling ACL methods, which can be used like directives. +ACL methods can only be used in <code>acl</code> block. +</p> + +<p> +Each ACL method adds a filter to the handler, which checks whether the request matches the provided condition or not. +Every ACL method can be accompanied by a condition block, which should return boolean value. +</p> + +<p> +The filter defined by the method that first matched the accompanying condition gets applied (e.g. response <code>403 Forbidden</code>, redirect to somewhere). +If a condition block is omitted, all requests matches. +If none of the conditions matches the request, the handler returns <code>399</code> and the request will be delegated to the next handler. +</p> + +<? +$ctx->{mruby_method}->( + name => "allow", + desc => q{ Adds a filter which delegates the request to the next handler if the request matches the provided condition. }, +)->(sub { +?> +<pre><code>allow { ..condition.. }</code></pre> +? }) + +<? +$ctx->{mruby_method}->( + name => "deny", + desc => q{ Adds a filter which returns <code>403 Forbidden</code> if the request matches the provided condition. }, +)->(sub { +?> +<pre><code>deny { ..condition.. }</code></pre> +? }) + +<? +$ctx->{mruby_method}->( + name => "redirect", + params => [ + { label => 'location', desc => 'Location to which the client will be redirected. Required.' }, + { label => 'status', desc => 'Status code of the response. Default value: 302' }, + ], + desc => q{ Adds a filter which redirects the client if the request matches the provided condition. }, +)->(sub { +?> +<pre><code>redirect(location, status) { ..condition.. }</code></pre> +? }) + +<? +$ctx->{mruby_method}->( + name => "respond", + params => [ + { label => 'status', desc => 'Status code of the response. Required.' }, + { label => 'header', desc => 'Header key-value pairs of the response. Default value: {}' }, + { label => 'body', desc => 'Body array of the response. Default value: []' }, + ], + desc => q{ Adds a filter which returns arbitrary response if the request matches the provided condition. }, +)->(sub { +?> +<pre><code>respond(status, header, body) { ..condition.. }</code></pre> +? }) + +<? +$ctx->{mruby_method}->( + name => "use", + params => [ + { label => 'proc', desc => 'Callable object that should be applied' }, + ], + desc => q{ Adds a filter which applies the provided handler (callable object) if the request matches the provided condition. }, +)->(sub { +?> +<pre><code>use(proc) { ..condition.. }</code></pre> +? }) + +<h2 id="matching-methods" class="section-head">Matching Methods</h2> + +<p> +In a condition block, you can use helpful methods which return particular properties of the request as string values. +Matching methods can only be used in a condition block of the ACL methods. +</p> + +<? +$ctx->{mruby_method}->( + name => "addr", + params => [ + { label => 'forwarded', desc => 'If true, returns the value of X-Forwarded-For header if it exists. Default value: true' }, + ], + desc => q{ Returns the remote IP address of the request. }, +)->(sub { +?> +<pre><code>addr(forwarded)</code></pre> +? }) + +<? +$ctx->{mruby_method}->( + name => "path", + desc => q{ Returns the requested path string of the request. }, +)->(sub { +?> +<pre><code>path()</code></pre> +? }) + +<? +$ctx->{mruby_method}->( + name => "method", + desc => q{ Returns the HTTP method of the request. }, +)->(sub { +?> +<pre><code>method()</code></pre> +? }) + +<? +$ctx->{mruby_method}->( + name => "header", + params => [ + { label => 'name', desc => 'Case-insensitive header name. Required.' }, + ], + desc => q{ Returns the header value of the request associated with the provided name. }, +)->(sub { +?> +<pre><code>header(name)</code></pre> +? }) + +<? +$ctx->{mruby_method}->( + name => "user_agent", + desc => q{ Shortcut for header("user-agent"). }, +)->(sub { +?> +<pre><code>user_agent()</code></pre> +? }) + +<h2 id="caution" class="section-head">Caution</h2> + +<p> +Several restrictions are introduced to avoid misconfiguration when using <code>acl</code> method. +<ul> +<li><code>acl</code> method can be called only once in each handler configuration</li> +<li>If <code>acl</code> method is used, the handler returned by the configuration directive must be the one returned by the <code>acl</code> method</li> +</ul> +If a configuration violates these restrictions, the server will detect it and refuse to launch with error message. +</p> + +<p> +For example, both of the following examples violate the restrictions above, so the server will refuse to start up. +</p> + +<?= $ctx->{example}->('Misconfiguration Example 1', <<'EOT'); +paths: + "/": + mruby.handler: | + acl { # this block will be ignored! + allow { addr == "127.0.0.1" } + } + acl { + deny + } + file.dir: /path/to/doc_root +EOT +?> + +<?= $ctx->{example}->('Misconfiguration Example 2', <<'EOT'); +paths: + "/": + mruby.handler: | + acl { # this block will be ignored! + allow { addr == "127.0.0.1" } + deny + } + proc {|env| [399, {}, []} + file.dir: /path/to/doc_root +EOT +?> + +<p> +You can correct these like the following: +</p> + +<?= $ctx->{example}->('Valid Configuration Example', <<'EOT'); +paths: + "/": + mruby.handler: | + acl { + allow { addr == "127.0.0.1" } + deny + } + file.dir: /path/to/doc_root +EOT +?> + +<h2 id="how-to" class="section-head">How-To</h2> + +<h3 id="matching-ip-address-blocks">Matching IP Address Blocks</h3> + +<p> +You can match an IP address against predefined list of address blocks using a script named <a href="">trie_addr.rb</a>. +</p> +<p> +Below is an example. +</p> + +<?= $ctx->{example}->('Address Block Matching Example', <<'EOT'); +paths: + "/": + mruby.handler: | + require "trie_addr.rb" + trie = TrieAddr.new.add(["192.168.0.0/16", "172.16.0.0/12"]) + acl { + allow { trie.match?(addr) } + deny + } + file.dir: /path/to/doc_root +EOT +?> + +<p> +This library currently supports only IPv4 addresses. <code>TrieAddr#match?</code> returns <code>false</code> when it receives an invalid IPv4 address (including an IPv6 address) as an argument.. +</p> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/access_log_directives.mt b/debian/vendor-h2o/srcdoc/configure/access_log_directives.mt new file mode 100644 index 0000000..52a585b --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/access_log_directives.mt @@ -0,0 +1,134 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Access Log Directives")->(sub { + +<p> +This document describes the configuration directives of the access_log handler. +</p> + +<? +$ctx->{directive}->( + name => "access-log", + levels => [ qw(global host path extension) ], + see_also => render_mt(<<'EOT'), +<a href="configure/base_directives.html#error-log"><code>error-log</code></a> +<a href="configure/base_directives.html#error-log.emit-request-errors"><code>error-log.emit-request-errors</code></a> +EOT + desc => q{The directive sets the path and optionally the format of the access log.}, +)->(sub { +?> +<p> +If the supplied argument is a scalar, it is treated as the path of the log file, or if the value starts with a <code>|</code>, it is treated as a command to which the log should be emitted. +</p> +<?= $ctx->{example}->('Emit access log to file', <<'EOT') +access-log: /path/to/access-log-file +EOT +?> +<?= $ctx->{example}->('Emit access log through pipe', <<'EOT') +access-log: "| rotatelogs /path/to/access-log-file.%Y%m%d 86400" +EOT +?> + +<p> +If the supplied argument is a mapping, its <code>path</code> property is considered as the path of the log file or the pipe command, and the <code>format</code> property is treated as the format of the log file. +Starting from version 2.2, <code>escape</code> property can be used to specify the escape sequence that should be used to emit unsafe octets. +</p> + +<p> +Two forms of escape sequences are supported. +If <code>apache</code> is specified as the value of the <code>escape</code> property, unsafe octets are emitted in the form of <code>\xNN</code>, where N is a hexadecimal number in lower case. +If <code>json</code> is specified, unsafe octets are emitted in the form of <code>\u00NN</code>. +<code>apache</code> is the default escape method. +</p> + +<?= $ctx->{example}->('Emit access log to file using Common Log Format', <<'EOT') +access-log: + path: /path/to/access-log-file + format: "%h %l %u %t \"%r\" %s %b" + escape: apache +EOT +?> + +<p> +The list of format strings recognized by H2O is as follows. +</p> + +<table> +<tr><th>Format String<th>Description +<tr><td><code>%%</code><td>the percent sign +<tr><td><code>%A</code><td>local address (e.g. <code>4.5.6.7</code>) +<tr><td><code>%b</code><td>size of the response body in bytes +<tr><td><code>%H</code><td>request protocol as sent by the client (e.g. <code>HTTP/1.1</code>) +<tr><td><code>%h</code><td>remote address (e.g. <code>1.2.3.4</code>) +<tr><td><code>%l</code><td>remote logname (always <code>-</code>) +<tr><td><code>%m</code><td>request method (e.g. <code>GET</code>, <code>POST</code>) +<tr><td><code>%p</code><td>local port (<code>%{local}p</code> is a synonym that is supported since version 2.2) +<tr><td><code>%{remote}p</code><td>remote port (since version 2.2) +<tr><td><code>%q</code><td>query string (<code>?</code> is prepended if exists, otherwise an empty string) +<tr><td><code>%r</code><td>request line (e.g. <code>GET / HTTP/1.1</code>) +<tr><td><code>%s</code><td>status code sent to client (e.g. <code>200</code>) +<tr><td><code>%<s</code><td>status code received from upstream (or initially generated) +<tr><td><code>%t</code><td>time when the request was received in format: <code>[02/Jan/2006:15:04:05 -0700]</code> +<tr><td><code>%{<i>FORMAT</i>}t</code><td>time when the request was received using the specified format. <code>FORMAT</code> should be an argument to <code>strftime</code>, or one of: +<table> +<tr><td><code>sec</code><td>number of seconds since Epoch +<tr><td><code>msec</code><td>number of milliseconds since Epoch +<tr><td><code>usec</code><td>number of microseconds since Epoch +<tr><td><code>msec_frac</code><td>millisecond fraction +<tr><td><code>usec_frac</code><td>microsecond fraction +</table> +As an example, it is possible to log timestamps in millisecond resolution using <code>%{%Y/%m/%d:%H:%M:%S}t.%{msec_frac}t</code>, which results in a timestamp like <code>2006-01-02:15:04:05.000</code>. +<tr><td><code>%U</code><td>requested URL path, not including the query string +<tr><td><code>%u</code><td>remote user if the request was authenticated (always <code>-</code>) +<tr><td><code>%V</code><td>requested server name (or the default server name if not specified by the client) +<tr><td><code>%v</code><td>canonical server name +<tr><td><code>%{<i>VARNAME</i>}e</code><td>request environment variable (since version 2.3; see <a href="configure/mruby.html#logging-arbitrary-variable">Logging Arbitrary Variable</a>) +<tr><td><code>%{<i>HEADERNAME</i>}i</code><td>value of the given request header (e.g. <code>%{user-agent}i</code>) +<tr><td><code>%{<i>HEADERNAME</i>}o</code><td>value of the given response header sent to client (e.g. <code>%{set-cookie}o</code>) +<tr><td><code>%<{<i>HEADERNAME</i>}o</code><td>value of the response header received from upstream (or initially generated) +<tr><td><code>%{<i>NAME</i>}x</code><td>various extensions. <code>NAME</code> must be one listed in the following tables. A dash (<code>-</code>) is emitted if the directive is not applicable to the request being logged. +<table> +<caption>Access Timings</caption> +<tr><th>Name<th>Description +<tr><td><code>connect-time</code><td>time spent to establish the connection (i.e. since connection gets <code>accept(2)</code>-ed until first octet of the request is received) +<tr><td><code>request-header-time</code><td>time spent receiving request headers +<tr><td><code>request-body-time</code><td>time spent receiving request body +<tr><td><code>request-total-time</code><td>sum of <code>request-header-time</code> and <code>request-body-time</code> +<tr><td><code>process-time</code><td>time spent after receiving request, before starting to send response +<tr><td><code>response-time</code><td>time spent sending response +<tr><td><code>duration</code><td>sum of <code>request-total-time</code>, <code>process-time</code>, <code>response-time</code> +</table> +<table> +<caption>Connection (since v2.0)</caption> +<tr><th>Name<th>Description +<tr><td><code>connection-id</code><td>64-bit internal ID assigned to every client connection +<tr><td><code>ssl.protocol-version</code><td>SSL protocol version obtained from <a href="https://www.openssl.org/docs/manmaster/ssl/SSL_get_version.html"><code>SSL_get_version</code></a> +<tr><td><code>ssl.session-reused</code><td><code>1</code> if the <a href="configure/base_directives.html#ssl-session-resumption">SSL session was reused</a>, or <code>0</code> if not<?= $ctx->{note}->(q{A single SSL connection may transfer more than one HTTP request.}) ?> +<tr><td><code>ssl.session-id</code><td>base64-encoded value of the session id used for resuming the session (since v2.2) +<tr><td><code>ssl.cipher</code><td>name of the <a href="https://tools.ietf.org/html/rfc5246#appendix-A.5">cipher suite</a> being used, obtained from <a href="https://www.openssl.org/docs/manmaster/ssl/SSL_CIPHER_get_name.html">SSL_CIPHER_get_name</a> +<tr><td><code>ssl.cipher-bits</code><td>strength of the cipher suite in bits +</table> +<table> +<caption>HTTP/2 (since v2.0)</caption> +<tr><th>Name<th>Description +<tr><td><code>http2.stream-id</code><td>stream ID +<tr><td><code>http2.priority.received</code><td>colon-concatenated values of <i>exclusive</i>, <i>parent</i>, <i>weight</i> +<tr><td><code>http2.priority.received.exclusive</code><td>exclusive bit of the most recent priority specified by the client +<tr><td><code>http2.priority.received.parent</code><td>parent stream ID of the most recent priority specified by the client +<tr><td><code>http2.priority.received.weight</code><td>weight of the most recent priority specified by the client +</table> +<table> +<caption>Miscellaneous</caption> +<tr><th>Name<th>Description +<tr><td><code>error</code><td>request-level errors. Unless specified otherwise by using the <a href="configure/base_directives.html#error-log.emit-request-errors"><code>error-log.emit-request-errors</code></a> directive, the same messages are emitted to the <a href="configure/base_directives.html#error-log">error-log</a>. (since v2.1) +</table> +</table> + +<p> +The default format is <code>%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i"</code>, a.k.a. the <a href="http://httpd.apache.org/docs/2.4/mod/mod_log_config.html.en#examples" target="_blank">NCSA extended/combined log format</a>. +</p> +<p> +Note that you may need to quote (and escape) the format string as required by YAML (see <a href="http://www.yaml.org/YAML_for_ruby.html#single-quoted_strings">Yaml Cookbook</a>). +</p> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/base_directives.mt b/debian/vendor-h2o/srcdoc/configure/base_directives.mt new file mode 100644 index 0000000..1f6ffe3 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/base_directives.mt @@ -0,0 +1,690 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Base Directives")->(sub { + +<p> +This document describes the configuration directives common to all the protocols and handlers. +</p> + +<? +$ctx->{directive}->( + name => "hosts", + levels => [ qw(global) ], + desc => q{Maps <code>host:port</code> to the mappings of per-host configs.}, +)->(sub { +?> +<p> +The directive specifies the mapping between the authorities (the host or <code>host:port</code> section of an URL) and their configurations. +The directive is mandatory, and must at least contain one entry. +</p> +<p> +When <code>port</code> is omitted, the entry will match the requests targetting the default ports (i.e. port 80 for HTTP, port 443 for HTTPS) with given hostname. +Otherwise, the entry will match the requests targetting the specified port. +</p> +<p> +Since version 1.7, a wildcard character <code>*</code> can be used as the first component of the hostname. +If used, they are matched using the rule defined in <a href="https://tools.ietf.org/html/rfc2818#section-3.1" target="_blank">RFC 2818 Section 3.1</a>. +For example, <code>*.example.com</code> will match HTTP requests for both <code>foo.example.com</code> and <code>bar.example.com</code>. +Note that an exact match is preferred over host definitions using wildcard characters. +</p> + + +<?= $ctx->{example}->('A host redirecting all HTTP requests to HTTPS', <<'EOT'); +hosts: + "www.example.com:80": + listen: + port: 80 + paths: + "/": + redirect: https://www.example.com/ + "www.example.com:443": + listen: + port: 443 + ssl: + key-file: /path/to/ssl-key-file + certificate-file: /path/to/ssl-certificate-file + paths: + "/": + file.dir: /path/to/doc-root +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "paths", + levels => [ qw(host) ], + desc => q{Mapping of paths and their configurations.}, +)->(sub { +?> +</p> +<p> +The mapping is searched using prefix-match. +The entry with the longest path is chosen when more than one matching paths were found. +An <code>404 Not Found</code> error is returned if no matching paths were found. +</p> +<?= $ctx->{example}->('Configuration with two paths', <<'EOT') +hosts: + "www.example.com": + listen: + port: 80 + paths: + "/": + file.dir: /path/to/doc-root + "/assets": + file.dir: /path/to/assets +EOT +?> +<p> +In releases prior to version 2.0, all the path entries are considered as directories. +When H2O receives a request that exactly matches to an entry in paths that does not end with a slash, the server always returns a 301 redirect that appends a slash. +</p> +<p> +Since 2.0, it depends on the handler of the path whether if a 301 redirect that appends a slash is returned. +Server administrators can take advantage of this change to define per-path configurations (see the examples in <a href="configure/file_directives.html#file.file"><code>file.file</code></a> and the <a href="configure/fastcgi_directives.html">FastCGI handler</a>). +<a href="configure/file_directives.html#file.dir"><code>file.dir</code></a> is an exception that continues to perform the redirection; in case of the example above, access to <code>/assets</code> is redirected to <code>/assets/</code>. +</p> +? }) + +<? +$ctx->{directive}->( + name => "listen", + levels => [ qw(global host) ], + desc => q{Specifies the port at which the server should listen to.}, +)->(sub { +?> +</p> +<p> +In addition to specifying the port number, it is also possible to designate the bind address or the SSL configuration. +</p> +<?= $ctx->{example}->('Various ways of using the Listen Directive', <<'EOT') +# accept HTTP on port 80 on default address (both IPv4 and IPv6) +listen: 80 + +# accept HTTP on 127.0.0.1:8080 +listen: + host: 127.0.0.1 + port: 8080 + +# accept HTTPS on port 443 +listen: + port: 443 + ssl: + key-file: /path/to/key-file + certificate-file: /path/to/certificate-file + +# accept HTTPS on port 443 (using PROXY protocol) +listen: + port: 443 + ssl: + key-file: /path/to/key-file + certificate-file: /path/to/certificate-file + proxy-protocol: ON +EOT +?> +<h4 id="listen-configuration-levels">Configuration Levels</h4> +<p> +The directive can be used either at global-level or at host-level. +At least one <code>listen</code> directive must exist at the global level, or every <i>host</i>-level configuration must have at least one <code>listen</code> directive. +</p> +<p> +Incoming connections accepted by global-level listeners will be dispatched to one of the host-level contexts with the corresponding <code>host:port</code>, or to the first host-level context if none of the contexts were given <code>host:port</code> corresponding to the request. +</p> +<p> +Host-level listeners specify bind addresses specific to the host-level context. +However it is permitted to specify the same bind address for more than one host-level contexts, in which case hostname-based lookup will be performed between the host contexts that share the address. +The feature is useful for setting up a HTTPS virtual host using <a href="https://tools.ietf.org/html/rfc6066">Server-Name Indication (RFC 6066)</a>. +</p> +<?= $ctx->{example}->('Using host-level listeners for HTTPS virtual-hosting', <<'EOT') +hosts: + "www.example.com:443": + listen: + port: 443 + ssl: + key-file: /path/to/www_example_com.key + certificate-file: /path/to/www_example_com.crt + paths: + "/": + file.dir: /path/to/doc-root_of_www_example_com + "www.example.jp:443": + listen: + port: 443 + ssl: + key-file: /path/to/www_example_jp.key + certificate-file: /path/to/www_example_jp.crt + paths: + "/": + file.dir: /path/to/doc-root_of_www_example_jp +EOT +?> +<h4 id="listen-ssl">SSL Attribute</h4> +<p> +The <code style="font-weight: bold;">ssl</code> attribute must be defined as a mapping, and recognizes the following attributes. +</p> +<dl> +<dt id="certificate-file">certificate-file:</dt> +<dd>path of the SSL certificate file (mandatory)</dd> +<dt id="key-file">key-file:</dt> +<dd>path of the SSL private key file (mandatory)</dd> +<dt id="minimum-version">minimum-version:</dt> +<dd> +minimum protocol version, should be one of: <code>SSLv2</code>, <code>SSLv3</code>, <code>TLSv1</code>, <code>TLSv1.1</code>, <code>TLSv1.2</code>. +Default is <code>TLSv1</code> +</dd> +<dt id="min-version">min-verison:</dt> +<dd> +synonym of <code>minimum-version</code> (introduced in version 2.2) +</dd> +<dt id="maximum-version">maximum-version:</dt> +<dd> +maximum protocol version. +Introduced in version 2.2. +Default is the maximum protocol version supported by the server. +</dd> +<dt id="maximum-version">max-version:</dt> +<dd> +synonym of <code>maximum-version</code>. +</dd> +<dt id="cipher-suite">cipher-suite:</dt> +<dd>list of cipher suites to be passed to OpenSSL via SSL_CTX_set_cipher_list (optional)</dd> +<dt id="cipher-preferences">cipher-preference:</dt> +<dd> +side of the list that should be used for selecting the cipher-suite; should be either of: <code>client</code>, <code>server</code>. +Default is <code>client</code>. +</dd> +<dt id="dh-file">dh-file:</dt> +<dd> +path of a PEM file containing the Diffie-Hellman parameters to be used. +Use of the file is recommended for servers using Diffie-Hellman key agreement. +(optional) +</dd> +<dt id="ocsp-update-interval">ocsp-update-interval:</dt> +<dd> +interval for updating the OCSP stapling data (in seconds), or set to zero to disable OCSP stapling. +Default is <code>14400</code> (4 hours). +</dd> +<dt id="ocsp-max-failures">ocsp-max-failures:</dt> +<dd> +number of consecutive OCSP query failures before stopping to send OCSP stapling data to the client. +Default is 3. +</dd> +<dt id="neverbleed">neverbleed:</dt> +<dd> +unless set to <code>OFF</code>, H2O isolates RSA private key operations to an isolated process by using <a href="https://github.com/h2o/neverbleed">Neverbleed</a>. +Default is <code>ON</code>. +</dl> +<p> +<a href="configure/base_directives.html#ssl-session-resumption"><code>ssl-session-resumption</code></a> directive is provided for tuning parameters related to session resumption and session tickets. +</p> +<h4 id="listen-proxy-protocol">The Proxy-Protocol Attribute</h4> +<p> +The <code>proxy-protocol</code> attribute (i.e. the value of the attribute must be either <code>ON</code> or <code>OFF</code>) specifies if the server should recognize the information passed via <a href="http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt">"the PROXY protocol</a> in the incoming connections. +The protocol is used by L4 gateways such as <a href="http://aws.amazon.com/jp/elasticloadbalancing/">AWS Elastic Load Balancing</a> to send peer address to the servers behind the gateways. +</p> +<p> +When set to <code>ON</code>, H2O standalone server tries to parse the first octets of the incoming connections as defined in version 1 of the specification, and if successful, passes the addresses obtained from the protocol to the web applications and the logging handlers. +If the first octets do not accord with the specification, it is considered as the start of the SSL handshake or as the beginning of an HTTP request depending on whether if the <code>ssl</code> attribute has been used. +</p> +<p> +Default is <code>OFF</code>. +</p> +<h4 id="listen-unix-socket">Listening to a Unix Socket</h4> +<p> +If the <code>type</code> attribute is set to <code>unix</code>, then the <code>port</code> attribute is assumed to specify the path of the unix socket to which the standalone server should bound. +Also following attributes are recognized. +</p> +<dl> +<dt>owner</dt> +<dd> +username of the owner of the socket file. +If omitted, the socket file will be owned by the launching user. +</dd> +<dt>permission</dt> +<dd> +an octal number specifying the permission of the socket file. +Many operating systems require write permission for connecting to the socket file. +If omitted, the permission of the socket file will reflect the umask of the calling process. +</dd> +</dl> +<?= $ctx->{example}->('Listening to a Unix Socket accessible only by www-data', <<'EOT') +listen: + type: unix + port: /tmp/h2o.sock + owner: www-data + permission: 600 +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "error-log", + levels => [ qw(global) ], + see_also => render_mt(<<'EOT'), +<a href="configure/base_directives.html#error-log.emit-request-errors"><code>error-log.emit-request-errors</code></a> +EOT + desc => q{Path of the file to which error logs should be appended.}, +)->(sub { +?> +<p> +Default is stderr. +</p> +<p> +If the path starts with <code>|</code>, the rest of the path is considered as a command to which the logs should be piped. +</p> +<?= $ctx->{example}->('Log errors to file', <<'EOT') +error-log: /path/to/error-log-file +EOT +?> +<?= $ctx->{example}->('Log errors through pipe', <<'EOT') +error-log: "| rotatelogs /path/to/error-log-file.%Y%m%d 86400" +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "error-log.emit-request-errors", + levels => [ qw(global host path extension) ], + since => "2.1", + see_also => render_mt(<<'EOT'), +<a href="configure/access_log_directives.html#access-log"><code>access-log</code></a> +<a href="configure/base_directives.html#error-log"><code>error-log</code></a> +EOT + default => "error-log.emit-request-errors: ON", + desc => q{Sets whether if request-level errors should be emitted to the error log.}, +)->(sub { +?> +By setting the value to <code>OFF</code> and by using the <code>%{error}x</code> specifier of the <a href="configure/access_log_directives.html">access-log</a> directive, it is possible to log request-level errors only to the access log. +? }) + +<? +$ctx->{directive}->( + name => "handshake-timeout", + levels => [ qw(global) ], + default => "handshake-timeout: 10", + desc => q{Maximum time (in seconds) that can be spent by a connection before it becomes ready to accept an HTTP request.}, +)->(sub { +?> +Times spent for receiving <a href="configure/base_directives.html#listen-proxy-protocol">the PROXY protocol</a> and TLS handshake are counted. +? }) + +<? +$ctx->{directive}->( + name => "limit-request-body", + levels => [ qw(global) ], + desc => q{Maximum size of request body in bytes (e.g. content of POST).}, +)->(sub { +?> +<p> +Default is 1073741824 (1GB). +</p> +? }) + +<? +$ctx->{directive}->( + name => "max-connections", + levels => [ qw(global) ], + default => 'max-connections: 1024', + desc => q{Number of connections to handle at once at maximum.}, +)->(sub {}); + +$ctx->{directive}->( + name => "max-delegations", + levels => [ qw(global) ], + default => 'max-delegations: 5', + desc => q{Limits the number of delegations (i.e. internal redirects using the <code>X-Reproxy-URL</code> header).}, +)->(sub {}); + +$ctx->{directive}->( + name => "num-name-resolution-threads", + levels => [ qw(global) ], + default => 'num-name-resolution-threads: 32', + desc => q{Maximum number of threads to run for name resolution.}, +)->(sub {}); +?> + +<? +$ctx->{directive}->( + name => "num-ocsp-updaters", + levels => [ qw(global) ], + since => "2.0", + default => 'num-ocsp-updaters: 10', + desc => q{Maximum number of OCSP updaters.}, +)->(sub { +?> +<p> +<a href="https://en.wikipedia.org/wiki/OCSP_stapling">OSCP Stapling</a> is an optimization that speeds up the time spent for establishing a TLS connection. +In order to <i>staple</i> OCSP information, a HTTP server is required to periodically contact the certificate authority. +This directive caps the number of the processes spawn for collecting the information. +</p> +<p> +The use and the update interval of OCSP can be configured using the <a href="configure/base_directives.html#listen-ssl">SSL attributes</a> of the <a href="configure/base_directives.html#listen"><code>listen</code></a> configuration directive. +</p> +? }); + +<? +$ctx->{directive}->( + name => "num-threads", + levels => [ qw(global) ], + desc => q{Number of worker threads.}, +)->(sub { +?> +<p> +Default is the number of the processors connected to the system as obtained by <code>getconf NPROCESSORS_ONLN</code>. +</p> +? }) + +<? +$ctx->{directive}->( + name => "pid-file", + levels => [ qw(global) ], + desc => q{Name of the file to which the process id of the server should be written.}, +)->(sub { +?> +<p> +Default is none. +</p> +? }) + +<? +$ctx->{directive}->( + name => "tcp-fastopen", + levels => [ qw(global) ], + desc => q{Size of the queue used for TCP Fast Open.}, +)->(sub { +?> +<p> +<a href="https://en.wikipedia.org/wiki/TCP_Fast_Open">TCP Fast Open</a> is an extension to the TCP/IP protocol that reduces the time spent for establishing a connection. +On Linux that support the feature, the default value is <code>4,096</code>. +On other platforms the default value is <code>0</code> (disabled). +</p> +? }) + +<? +$ctx->{directive}->( + name => "send-server-name", + levels => [ qw(global) ], + since => '2.0', + desc => q{A boolean flag (<code>ON</code> or <code>OFF</code>) indicating whether if the <code>server</code> response header should be sent.}, + default => q{send-server-name: ON}, + see_also => render_mt(<<'EOT'), +<a href="configure/base_directives.html#server-name"><code>server-name</code></a> +EOT +)->(sub { +?> +? }) + +<? +$ctx->{directive}->( + name => "server-name", + levels => [ qw(global) ], + since => '2.0', + desc => q{Lets the user override the value of the <code>server</code> response header.}, + see_also => render_mt(<<'EOT'), +<a href="configure/base_directives.html#send-server-name"><code>send-server-name</code></a> +EOT +)->(sub { +?> +The default value is <code>h2o/VERSION-NUMBER</code>. +? }) + +<? +$ctx->{directive}->( + name => "setenv", + levels => [ qw(global host path extension) ], + since => '2.0', + desc => 'Sets one or more environment variables.', + see_also => render_mt(<<'EOT'), +<a href="configure/base_directives.html#unsetenv"><code>unsetenv</code></a> +EOT +)->(sub { +?> +<p> +Environment variables are a set of key-value pairs containing arbitrary strings, that can be read from applications invoked by the standalone server (e.g. <a href="configure/fastcgi_directives.html">fastcgi handler</a>, <a href="configure/mruby_directives.html">mruby handler</a>) and the access logger. +</p> +<p> +The directive is applied from outer-level to inner-level. +At each level, the directive is applied after the <a href="configure/base_directives.html#unsetenv"><code>unsetenv</code></a> directive at the corresponding level is applied. +</p> +<p> +Environment variables are retained through internal redirections. +</p> +<?= $ctx->{example}->('Setting an environment variable named <code>FOO</code>', <<'EOT') +setenv: + FOO: "value_of_FOO" +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "unsetenv", + levels => [ qw(global host path extension) ], + since => '2.0', + desc => 'Unsets one or more environment variables.', + see_also => render_mt(<<'EOT'), +<a href="configure/base_directives.html#setenv"><code>setenv</code></a> +EOT +)->(sub { +?> +<p> +The directive can be used to have an exception for the paths that have an environment variable set, or can be used to reset variables after an internal redirection. +</p> +<?= $ctx->{example}->('Setting environment variable for <code>example.com</code> excluding <code>/specific-path</code>', <<'EOT') +hosts: + example.com: + setenv: + FOO: "value_of_FOO" + paths: + /specific-path: + unsetenv: + - FOO + ... +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "ssl-session-resumption", + levels => [ qw(global) ], + desc => q{Configures cache-based and ticket-based session resumption.}, +)->(sub { +?> +<p> +To reduce the latency introduced by the TLS (SSL) handshake, two methods to resume a previous encrypted session are defined by the Internet Engineering Task Force. +H2O supports both of the methods: cache-based session resumption (defined in <a href="https://tools.ietf.org/html/rfc5246">RFC 5246</a>) and ticket-based session resumption (defined in <a href="https://tools.ietf.org/html/rfc5077">RFC 5077</a>). +</p> +<?= $ctx->{example}->('Various session-resumption configurations', <<'EOT'); +# use both methods (storing data on internal memory) +ssl-session-resumption: + mode: all + +# use both methods (storing data on memcached running at 192.168.0.4:11211) +ssl-session-resumption: + mode: all + cache-store: memcached + ticket-store: memcached + cache-memcached-num-threads: 8 + memcached: + host: 192.168.0.4 + port: 11211 + +# use ticket-based resumption only (with secrets used for encrypting the tickets stored in a file) +ssl-session-resumption: + mode: ticket + ticket-store: file + ticket-file: /path/to/ticket-secrets.yaml +EOT +?> +<h4 id="ssl-session-resumption-methods">Defining the Methods Used</h4> +<p> +The <code>mode</code> attribute defines which methods should be used for resuming the TLS sessions. +The value can be either of: <code>off</code>, <code>cache</code>, <code>ticket</code>, <code>all</code>. +Default is <code>all</code>. +</p> +<p> +If set to <code>off</code>, session resumption will be disabled, and all TLS connections will be established via full handshakes. +If set to <code>all</code>, both session-based and ticket-based resumptions will be used, with the preference given to the ticket-based resumption for clients supporting both the methods. +</p> +<p> +For each method, additional attributes can be used to customize their behaviors. +Attributes that modify the behavior of the disabled method are ignored. +</p> +<h4 id="ssl-session-resumption-cache-based">Attributes for Cache-based Resumption</h4> +<p> +Following attributes are recognized if the cache-based session resumption is enabled. +Note that <code>memcached</code> attribute must be defined as well in case the <code>memcached</code> cache-store is used. +</p> +<dl> +<dt>cache-store:</dt> +<dd> +<p> +defines where the cache should be stored, must be one of: <code>internal</code>, <code>memcached</code>. +Default is <code>internal</code>. +</p> +<p> +Please note that if you compiled h2o with OpenSSL 1.1.0 ~ 1.1.0f, session resumption with external cache store would fail due to bug of OpenSSL. +</p> +</dd> +<dt>cache-memcached-num-threads:</dt> +<dd>defines the maximum number of threads used for communicating with the memcached server. +Default is <code>1</code>. +</dd> +<dt>cache-memcached-prefix:</dt> +<dd> +for the <code>memcached</code> store specifies the key prefix used to store the secrets on memcached. +Default is <code>h2o:ssl-session-cache:</code>. +</dd> +</dl> +<h4 id="ssl-session-resumption-ticket-based">Attributes for Ticket-based Resumption</h4> +<p> +Ticket-based session resumption uses master secret(s) to encrypt the keys used for encrypting the data transmitted over TLS connections. +To achieve <a href="https://en.wikipedia.org/wiki/Forward_secrecy" target="_blank">forward-secrecy</a> (i.e. protect past communications from being decrypted in case a master secret gets obtained by a third party), it is essential to periodically change the secret and remove the old ones. +</p> +<p> +Among the three types of stores supported for ticket-based session resumption, the <code>internal</code> store and <code>memcached</code> store implement automatic roll-over of the secrets. +A new master secret is created every 1/4 of the session lifetime (defined by the <code>lifetime</code> attribute), and they expire (and gets removed) after 5/4 of the session lifetime elapse. +</p> +<p> +For the <code>file</code> store, it is the responsibility of the web-site administrator to periodically update the secrets. H2O monitors the file and reloads the secrets when the file is altered. +</p> +<p> +Following attributes are recognized if the ticket-based resumption is enabled. +</p> +<dl> +<dt>ticket-store:</dt> +<dd>defines where the secrets for ticket-based resumption should be / is stored, must be one of: <code>internal</code>, <code>file</code>, <code>memcached</code>. +Default is <code>internal</code>. +<dt>ticket-cipher:</dt> +<dd> +for stores that implement automatic roll-over, specifies the cipher used for encrypting the tickets. +The value must be one recognizable by <code>EVP_get_cipherbyname</code>. +Default is <code>aes-256-cbc</code>. +<dt>ticket-hash:</dt> +<dd> +for stores that implement automatic roll-over, specifies the cipher used for digitally-signing the tickets. +The value must be one recognizable by <code>EVP_get_digestbyname</code>. +Default is <code>sha-256</code>. +</dd> +<dt>ticket-file:</dt> +<dd>for the <code>file</code> store specifies the file in which the secrets are stored</dd> +<dt>ticket-memcached-key:</dt> +<dd> +for the <code>memcached</code> store specifies the key used to store the secrets on memcached. +Default is <code>h2o:ssl-session-ticket</code>. +</dd> +</dl> +<h4 id="ssl-session-resumption-other">Other Attributes</h4> +<p> +Following attributes are common to cache-based and ticket-based session resumption. +</p> +<dl> +<dt>lifetime:</dt> +<dd> +defines the lifetime of a TLS session; when it expires the session cache entry is purged, and establishing a new connection will require a full TLS handshake. +Default value is <code>3600</code> (in seconds). +</dd> +<dt>memcached:</dt> +<dd> +specifies the location of memcached used by the <code>memcached</code> stores. +The value must be a mapping with <code>host</code> attribute specifying the address of the memcached server, and optionally a <code>port</code> attribute specifying the port number (default is <code>11211</code>). +By default, the memcached client uses the <a href="https://github.com/memcached/memcached/blob/master/doc/protocol-binary.xml">BINARY protocol</a>. +Users can opt-in to using the legacy <a href="https://github.com/memcached/memcached/blob/master/doc/protocol.txt">ASCII protocol</a> by adding a <code>protocol</code> attribute set to <code>ASCII</code>. +</dd> +? }) + +<? +$ctx->{directive}->( + name => "temp-buffer-path", + levels => [ qw(global) ], + desc => q{Directory in which temporary buffer files are created.}, + default => q{temp-buffer-path: "/tmp"}, + since => "2.0", + see_also => render_mt(<<'EOT'), +<a href="configure/base_directives.html#user"><code>user</code></a> +EOT +)->(sub { +?> +<p> +H2O uses an internal structure called <code>h2o_buffer_t</code> for buffering various kinds of data (e.g. POST content, response from upstream HTTP or FastCGI server). +When amount of the data allocated in the buffer exceeds 32MB, it starts allocating storage from the directory pointed to by the directive. +</p> +<p> +By using the directive, users can set the directory to one within a memory-backed file system (e.g. <a href="https://en.wikipedia.org/wiki/Tmpfs">tmpfs</a>) for speed, or specify a disk-based file system to avoid memory pressure. +</p> +<p> +Note that the directory must be writable by the running user of the server. +</p> +? }) + +<? +$ctx->{directive}->( + name => "user", + levels => [ qw(global) ], + desc => q{Username under which the server should handle incoming requests.}, +)->(sub { +?> +<p> +If the directive is omitted and if the server is started under root privileges, the server will attempt to <code>setuid</code> to <code>nobody</code>. +</p> +? }) + +<? +$ctx->{directive}->( + name => "crash-handler", + levels => [ qw(global) ], + desc => q{Script to invoke if <code>h2o</code> receives a fatal signal.}, + default => q{crash-handler: "${H2O_ROOT}/share/h2o/annotate-backtrace-symbols"}, + since => "2.1", +)->(sub { +?> +<p>Note: this feature is only available when linking to the GNU libc.</p> + +<p>The script is invoked if one of the <code>SIGABRT</code>, +<code>SIGBUS</code>, <code>SIGFPE</code>, <code>SIGILL</code> or +<code>SIGSEGV</code> signals is received by <code>h2o</code>.</p> + +<p><code>h2o</code> writes the backtrace as provided by +<code>backtrace()</code> and <code>backtrace_symbols_fd</code> to the +standard input of the program.</p> + +<p>If the path is not absolute, it is prefixed with <code>${H2O_ROOT}/</code>.</p> +? }) + +<? +$ctx->{directive}->( + name => "crash-handler.wait-pipe-close", + levels => [ qw(global) ], + desc => q{Whether <code>h2o</code> should wait for the crash handler pipe to close before exiting.}, + default => q{crash-handler.wait-pipe-close: OFF}, + since => "2.1", +)->(sub { +?> +<p>When this setting is <code>ON</code>, <code>h2o</code> will wait +for the pipe to the crash handler to be closed before exiting. +This can be useful if you use a custom handler that inspects the dying +process.</p> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/basic_auth.mt b/debian/vendor-h2o/srcdoc/configure/basic_auth.mt new file mode 100644 index 0000000..918b405 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/basic_auth.mt @@ -0,0 +1,31 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Using Basic Authentication")->(sub { + +<p> +Starting from version 1.7, H2O comes with a mruby script named <a href="https://github.com/h2o/h2o/blob/master/share/h2o/mruby/htpasswd.rb">htpasswd.rb</a> that implements <a href="https://tools.ietf.org/html/rfc2617" target="_blank">Basic Authentication</a>. +The script provides a Rack handler that implements Basic Authentication using password files generated by the <a href="https://httpd.apache.org/docs/2.4/programs/htpasswd.html">htpasswd</a> command. +</p> + +<p> +Below example uses the mruby script to restrict access to the path. +If authentication fails, the mruby handler returns a <code>401 Unauthorized</code> response. +If authentication succeeds, the handler returns a <code>399</code> response, and the request is <a href="configure/mruby.html#delegating-request">delegated</a> internally to the next handler (i.e. <code>file.dir</code>). +</p> + +<?= $ctx->{example}->('Configuring HTTP authentication using htpasswd.rb', <<'EOT'); +paths: + "/": + mruby.handler: | + require "htpasswd.rb" + Htpasswd.new("/path/to/.htpasswd", "realm-name") + file.dir: /path/to/doc_root +EOT +?> + +<p> +In H2O versions prior to 2.0, you should specify <code>"#{$H2O_ROOT}/share/h2o/mruby/htpasswd.rb"</code> as the argument to <code>require</code>, since the directory is not registered as part of <code>$LOAD_PATH</code>. +</p> + +For convenience, the mruby script also forbids access to files or directories that start with <code>.ht</code>. + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/cgi.mt b/debian/vendor-h2o/srcdoc/configure/cgi.mt new file mode 100644 index 0000000..09da7e9 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/cgi.mt @@ -0,0 +1,40 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Using CGI")->(sub { + +<p> +Starting from version 1.7, H2O comes with a FastCGI-to-CGI gateway (<code>fastcgi-cgi</code>), which can be found under <code>share/h2o</code> directory of the installation path. +The gateway can be used for running CGI scripts through the FastCGI handler. +</p> + +<p> +The example below maps <code>.cgi</code> files to be executed by the gateway. +It is also possible to run CGI scripts under different privileges by specifying the <code>user</code> attribute of the directive. +</p> + +<?= $ctx->{example}->('Execute <code>.cgi</code> files using FastCGI-to-CGI gateway', <<'EOT'); +file.custom-handler: + extension: .cgi + fastcgi.spawn: + command: "exec $H2O_ROOT/share/h2o/fastcgi-cgi" +EOT +?> + +The gateway also provides options to for tuning the behavior. A full list of options can be obtained by running the gateway directly with <code>--help</code> option. + +<?= $ctx->{example}->('Output of <code>share/h2o/fastcgi-cgi --help</code>', <<'EOT'); +$ share/h2o/fastcgi-cgi --help +Usage: + share/h2o/fastcgi-cgi [options] + +Options: + --listen=sockfn path to the UNIX socket. If specified, the program will + create a UNIX socket at given path replacing the existing + file (should it exist). If not, file descriptor zero (0) + will be used as the UNIX socket for accepting new + connections. + --max-workers=nnn maximum number of CGI processes (default: unlimited) + --pass-authz if set, preserves HTTP_AUTHORIZATION parameter +EOT +?> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/command_options.mt b/debian/vendor-h2o/srcdoc/configure/command_options.mt new file mode 100644 index 0000000..b9ea030 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/command_options.mt @@ -0,0 +1,36 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Command Options")->(sub { + +<p> +Full list of command options can be viewed by running <code>h2o --help</code>. +Following is the output of <code>--help</code> as of version 1.2.0. +</p> + +<?= $ctx->{code}->(<< 'EOT') +Options: + -c, --conf FILE configuration file (default: h2o.conf) + -m, --mode <mode> specifies one of the following mode + - worker: invoked process handles incoming connections + (default) + - daemon: spawns a master process and exits. `error-log` + must be configured when using this mode, as all + the errors are logged to the file instead of + being emitted to STDERR + - master: invoked process becomes a master process (using + the `share/h2o/start_server` command) and spawns + a worker process for handling incoming + connections. Users may send SIGHUP to the master + process to reconfigure or upgrade the server. + - test: tests the configuration and exits + -t, --test synonym of `--mode=test` + -v, --version prints the version number + -h, --help print this help +EOT +?> + +<p> +The default path of the configuration file may differ depending on the distribution. +Please run <code>h2o --help</code> to find out the location. +</p> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/compress_directives.mt b/debian/vendor-h2o/srcdoc/configure/compress_directives.mt new file mode 100644 index 0000000..57f7a43 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/compress_directives.mt @@ -0,0 +1,82 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Compress Directives")->(sub { + +<p> +The compress handler performs on-the-fly compression - it compresses the contents of an HTTP response as it is being sent, if the client indicates itself to be capable of decompressing the response transparently with the use of <a href="https://tools.ietf.org/html/rfc7231#section-5.3.4"><code>Accept-Encoding</code></a> header</li>, and if the response is deemed compressible according to the following rules. +</p> +<p> +If <code>x-compress-hint</code> response header does not exist or the value is <code>auto</code>, then whether if the response is considered compressible depends on the <code>is_compressible</code> attribute assigned to the content type (see <a href="configure/file_directives.html#file.mime.addtypes"><code>file.mime.addtypes</code></a>). +If <code>x-compress-hint</code> response header exists and the value is <code>on</code>, the response is always considered to be compressible. +If the value of the response header is set to <code>off</code>, then the response never gets compressed. +</p> + +<p> +The following are the configuration directives recognized by the handler. +</p> + +<? +$ctx->{directive}->( + name => "compress", + levels => [ qw(global host path extension) ], + default => "compress: OFF", + see_also => render_mt(<<'EOT'), +<a href="configure/file_directives.html#file.send-compressed"><code>file.send-compressed</code></a>, <a href="configure/file_directives.html#file.mime.addtypes"><code>file.mime.addtypes</code></a> +EOT + since => '2.0', + desc => <<'EOT', +Enables on-the-fly compression of HTTP response. +EOT +)->(sub { +?> +<p> +If the argument is <code>ON</code>, both <a href="https://datatracker.ietf.org/doc/draft-alakuijala-brotli/">brotli</a> and <a href="https://tools.ietf.org/html/rfc1952">gzip</a> compression are enabled. +If the argument is <code>OFF</code>, on-the-fly compression is disabled. +If the argument is a sequence, the elements are the list of compression algorithms to be enabled. +If the argument is a mapping, each key specifies the compression algorithm to be enabled, and the values specify the quality of the algorithms. +</p> +<p> +When both brotli and gzip are enabled and if the client supports both, H2O is hard-coded to prefer brotli. +</p> +<?= $ctx->{example}->('Enabling on-the-fly compression', <<'EOT') +# enable all algorithms +compress: ON + +# enable by name +compress: [ gzip, br ] + +# enable gzip only +compress: [ gzip ] +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "compress-minimum-size", + levels => [ qw(global host path extension) ], + default => "compress-minimum-size: 100", + since => '2.0', + desc => <<'EOT', +Defines the minimum size a files needs to have in order for H2O to compress the request. +EOT +)->(sub {}); +?> + +<? +$ctx->{directive}->( + name => "gzip", + levels => [ qw(global host path extension) ], + default => "gzip: OFF", + see_also => render_mt(<<'EOT'), +<a href="configure/compress_directives.html#compress"><code>compress</code></a> +EOT + since => '1.5', + desc => <<'EOT', +Enables on-the-fly compression of HTTP response using gzip. +EOT +)->(sub { +?> +Equivalent to <code>compress: [ gzip ]</code>. +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/dos_detection.mt b/debian/vendor-h2o/srcdoc/configure/dos_detection.mt new file mode 100644 index 0000000..9cba1bf --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/dos_detection.mt @@ -0,0 +1,101 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Using DoS Detection")->(sub { + +<p> +Starting from version 2.1, H2O comes with a mruby script named <a href="https://github.com/h2o/h2o/blob/master/share/h2o/mruby/dos_detector.rb">dos_detector.rb</a> that implements DoS Detection feature. +The script provides a Rack handler that detects HTTP flooding attacks based on the client's IP address. +</p> + +<h3 id="basic-usage">Basic Usage</h3> + +<p> +Below example uses the mruby script to detect DoS attacks. +The default detecting strategy is simply counting requests within configured period. +If the count exceeds configured threshold, the handler returns a <code>403 Forbidden</code> response. +Otherwise, the handler returns a <code>399</code> response, and the request is <a href="configure/mruby.html#delegating-request">delegated</a> internally to the next handler. +</p> + +<?= $ctx->{example}->('Configuring DoS Detection', <<'EOT'); +paths: + "/": + mruby.handler: | + require "dos_detector.rb" + DoSDetector.new({ + :strategy => DoSDetector::CountingStrategy.new({ + :period => 10, # default + :threshold => 100, # default + :ban_period => 300, # default + }), + }) + file.dir: /path/to/doc_root +EOT +?> + +<p> +In the example above, the handler countup the requests within 10 seconds for each IP address, and when the count exceeds 100, +it returns a <code>403 Forbidden</code> response for the request and marks the client as "Banned" for 300 seconds. While marked as "Banned", the handler returns a <code>403 Forbidden</code> to all requests from the same IP address. +</p> + +<h3 id="configuring-details">Configuring Details</h3> + +<p> +You can pass the following parameters to <code>DoSDetector.new</code> . +<ul> +<li><code>:strategy</code> + <p>The algorithm to detect DoS attacks. You can write and pass your own strategies if needed. The default strategy is <code>DoSDetector.CountingStrategy</code> which takes the following parameters:</p> + <ul> + <li><code>:period</code> + <p>Time window in seconds to count requests. The default value is 10.</p> + </li> + <li><code>:threshold</code> + <p>Threshold count of request. The default value is 100.</p> + </li> + <li><code>:ban_period</code> + <p>Duration in seconds in which "Banned" client continues to be restricted. The default value is 300.</p> + </li> + </ul> +</li> +<li><code>:callback</code> + <p>The callback which is called by the handler with detecting result. You can define your own callback to return arbitrary response, set response headers, etc. The default callback returns <code>403 Forbidden</code> if DoS detected, otherwise delegate the request to the next handler.</p> +</li> +<li><code>:forwarded</code> + <p> + If set true, the handler uses X-HTTP-Forwarded-For header to get client's IP address if the header exists. The default value is true. + </p> +</li> +<li><code>:cache_size</code> + <p> + The capacity of the LRU cache which preserves client's IP address and associated request count. The default value is 128. + </p> +</li> +</ul> +<?= $ctx->{example}->('Configuring Details', <<'EOT'); +paths: + "/": + mruby.handler: | + require "dos_detector.rb" + DoSDetector.new({ + :strategy => DoSDetector::CountingStrategy.new, + :forwarded => false, + :cache_size => 2048, + :callback => proc {|env, detected, ip| + if detected && ! ip.start_with?("192.168.") + [503, {}, ["Service Unavailable"]] + else + [399, {}, []] + end + } + }) + file.dir: /path/to/doc_root +EOT +?> +</p> + +<h3 id="points-to-notice">Points to Notice</h3> +<ul> +<li> + For now, counting requests is "per-thread" and not shared between multiple threads. +</li> +</ul> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/errordoc_directives.mt b/debian/vendor-h2o/srcdoc/configure/errordoc_directives.mt new file mode 100644 index 0000000..94137ae --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/errordoc_directives.mt @@ -0,0 +1,52 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Errordoc Directives")->(sub { + +<p> +This document describes the configuration directives of the errordoc handler. +</p> + +<? +$ctx->{directive}->( + name => "error-doc", + levels => [ qw(global host path extension) ], + desc => <<'EOT', +Specifies the content to be sent when returning an error response (i.e. a response with 4xx or 5xx status code). +EOT +)->(sub { +?> +<p> +The argument must be a mapping containing following attributes, or if it is a sequence, every element must be a mapping with the following attributes. +<ul> +<li><code>status</code> - three-digit number indicating the status code (or sequence of that from version 2.3) +<li><code>url</code> - URL of the document to be served +</ul> +</p> +<p> +URL can either be absolute or relative. +Only <code>content-type</code>, <code>content-language</code>, <code>set-cookie</code> headers obtained from the specified URL are served to the client. +</p> +<p> +<?= $ctx->{example}->('Set error document for 404 status', <<'EOT') +error-doc: + status: 404 + url: /404.html +EOT +?> +<?= $ctx->{example}->('Set error document for 500 and 503 status', <<'EOT') +error-doc: + - status: 500 + url: /internal-error.html + - status: 503 + url: /service-unavailable.html +EOT +?> +<?= $ctx->{example}->('Set error document for 50x statuses (From version 2.3)', <<'EOT') +error-doc: + status: [500, 502, 503, 504] + url: /50x.html +EOT +?> +</p> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/expires_directives.mt b/debian/vendor-h2o/srcdoc/configure/expires_directives.mt new file mode 100644 index 0000000..a3b22f8 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/expires_directives.mt @@ -0,0 +1,32 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Expires Directives")->(sub { + +<p> +This document describes the configuration directives of the expires handler. +</p> + +<? +$ctx->{directive}->( + name => "expires", + levels => [ qw(global host path extension) ], + desc => <<'EOT', +An optional directive for setting the <code>Cache-Control: max-age=</code> header. +EOT +)->(sub { +?> +<ul> +<li>if the argument is <code>OFF</code> the feature is not used +<li>if the value is <code><i>NUMBER</i> <i>UNIT</i></code> then the header is set +<li>the units recognized are: <code>second</code>, <code>minute</code>, <code>hour</code>, <code>day</code>, <code>month</code>, <code>year</code> +<li> the units can also be in plural forms +</ul> +<?= $ctx->{example}->('Set <code>Cache-Control: max-age=86400</code>', <<'EOT') +expires: 1 day +EOT +?> +<p> +You can also find an example that conditionally sets the header depending on the aspects of a request in <a href="configure/mruby.html#modifying-response">Modifying the Response section of the Mruby directives documentation</a>. +</p> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/fastcgi_directives.mt b/debian/vendor-h2o/srcdoc/configure/fastcgi_directives.mt new file mode 100644 index 0000000..2e28708 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/fastcgi_directives.mt @@ -0,0 +1,114 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "FastCGI Directives")->(sub { + +<p> +This document describes the configuration directives of the FastCGI handler. +</p> +<p> +The configuration directives of the FastCGI handler can be categorized into two groups. +<code>Fastcgi.connect</code> and <code>fastcgi.spawn</code> define the address (or the process) to which the requests should be sent. +Other directives customize how the connections to the FastCGI processes should be maintained. +</p> + +<? +$ctx->{directive}->( + name => "fastcgi.connect", + levels => [ qw(path extension) ], + desc => q{The directive specifies the address at where the FastCGI daemon is running.}, +)->(sub { +?> +<p> +If the argument is a mapping, following properties are recognized. +<dl> +<dt><code>host</code> +<dd>name (or IP address) of the server running the FastCGI daemon (ignored if <code>type</code> is <code>unix</code>) +<dt><code>port</code> +<dd>TCP port number or path to the unix socket +<dt><code>type</code> +<dd>either <code>tcp</code> (default) or <code>unix</code> +</dl> +</p> +<p> +If the argument is a scalar, the value is considered as a TCP port number and the host is assumed to be <code>127.0.0.1</code>. +</p> +<?= $ctx->{example}->('Map <code>/app</code> to FastCGI daemon listening to <code>/tmp/fcgi.sock</code>', <<'EOT'); +hosts: + "example.com:80": + paths: + "/app": + fastcgi.connect: + port: /tmp/fcgi.sock + type: unix +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "fastcgi.spawn", + levels => [ qw(path extension) ], + desc => q{The directive specifies the command to start the FastCGI process manager.}, +)->(sub { +?> +<p> +In contrast to <code>fastcgi.connect</code> that connects to a FastCGI server running externally, this directive launches a FastCGI process manager under the control of H2O, and terminates it when H2O quits. +The argument is a <code>/bin/sh -c</code> expression to be executed when H2O boots up. +The HTTP server records the process id of the expression, and sends <code>SIGTERM</code> to the id when it exits. +</p> +<?= $ctx->{example}->('Map <code>.php</code> files to 10 worker processes of <code>/usr/local/bin/php-cgi</code>', <<'EOT'); +file.custom-handler: + extension: .php + fastcgi.spawn: "PHP_FCGI_CHILDREN=10 exec /usr/local/bin/php-cgi" +EOT +?> +<p> +As of version 1.4.0, the spawned process is run under the privileges of user specified by the <a href="configure/base_directives.html#user"><code>user</code></a> directive (in version 1.3.x, the FastCGI process was spawned under the privileges that spawned the H2O standalone server). +It is possible to specify a different user for running the FastCGI process, by providing a mapping that contains an attribute named <code>user</code> together with an attribute named <code>command</code>. +</p> +<?= $ctx->{example}->('Running FastCGI processes under user <code>fastcgi</code>', <<'EOT'); +file.custom-handler: + extension: .php + fastcgi.spawn: + command: "PHP_FCGI_CHILDREN=10 exec /usr/local/bin/php-cgi" + user: fastcgi +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "fastcgi.timeout.io", + levels => [ qw(global host path extension) ], + default => q{fastcgi.timeout.io: 30000}, + desc => q{Sets the I/O timeout of connections to the FastCGI process in milliseconds.}, +)->(sub {}); +?> + +<? +$ctx->{directive}->( + name => "fastcgi.timeout.keepalive", + levels => [ qw(global host path extension) ], + default => q{fastcgi.timeout.keepalive: 0}, + desc => 'Sets the keepl-alive timeout for idle connections in milliseconds.', +)->(sub { +?> +<p> +FastCGI connections will not be persistent if the value is set to zero (default). +</p> +? }) + +<? +$ctx->{directive}->( + name => "fastcgi.send-delegated-uri", + levels => [ qw(global host path extension) ], + default => q{fastcgi.send-delegated-uri: OFF}, + desc => 'Send the modified <code>HTTP_HOST</code> and <code>REQUEST_URI</code> being rewritten in case of internal redirect.', +)->(sub { +?> +<p> +In H2O, it is possible to perform internal redirects (a.k.a. delegations or URL rewrites) using <a href="configure/redirect_directives.html">the <code>redirect</code> directive</a> or <a href="configure/reproxy_directives.html">by returning <code>X-Reproxy-URL</code> headers</a> from web applications. +The directive specifies whether to send the original values to the FastCGI process (default), or if the rewritten values should be sent. +</p> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/file_directives.mt b/debian/vendor-h2o/srcdoc/configure/file_directives.mt new file mode 100644 index 0000000..b56de06 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/file_directives.mt @@ -0,0 +1,244 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "File Directives")->(sub { + +<p> +This document describes the configuration directives of the file handler - a handler that for serving static files. +</p> +<p> +Two directives: <a href="configure/file_directives.html#file.dir"><code>file.dir</code></a> and <a href="configure/file_directives.html#file.file"><code>file.file</code></a> are used to define the mapping. +Other directives modify the behavior of the mappings defined by the two. +</p> + +<? +$ctx->{directive}->( + name => "file.custom-handler", + levels => [ qw(global host path) ], + desc => q{The directive maps extensions to a custom handler (e.g. FastCGI).}, +)->(sub { +?> +<p> +The directive accepts a mapping containing configuration directives that can be used at the <code>extension</code> level, together with a property named <code>extension</code> specifying a extension (starting with <code>.</code>) or a sequence of extensions to which the directives should be applied. +Only one handler must exist within the directives. +</p> +<?= $ctx->{example}->('Mapping PHP files to FastCGI', <<'EOT') +file.custom-handler: + extension: .php + fastcgi.connect: + port: /tmp/fcgi.sock + type: unix + +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "file.dir", + levels => [ qw(path) ], + desc => q{The directive specifies the directory under which should be served for the corresponding path.}, + see_also => render_mt(<<EOT), +<a href="configure/file_directives.html#file.dirlisting"><code>file.dirlisting</code></a>, +<a href="configure/file_directives.html#file.file"><code>file.file</code></a>, +<a href="configure/file_directives.html#file.index"><code>file.index</code></a> +EOT +)->(sub { +?> +<?= $ctx->{example}->('Serving files under different paths', <<'EOT') +paths: + "/": + file.dir: /path/to/doc-root + "/icons": + file.dir: /path/to/icons-dir +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "file.dirlisting", + levels => [ qw(global host path) ], + default => 'file.dirlisting: OFF', + desc => <<'EOT', +A boolean flag (<code>OFF</code>, or <code>ON</code>) specifying whether or not to send the directory listing in case none of the index files exist. +EOT + see_also => render_mt(<<EOT), +<a href="configure/file_directives.html#file.dir"><code>file.dir</code></a> +EOT +)->(sub {}); + +$ctx->{directive}->( + name => "file.etag", + levels => [ qw(global host path) ], + default => 'file.etag: ON', + desc => <<'EOT', +A boolean flag (<code>OFF</code>, or <code>ON</code>) specifying whether or not to send etags. +EOT +)->(sub {}); +?> + +<? +$ctx->{directive}->( + name => "file.file", + levels => [ qw(path) ], + desc => q{The directive maps a path to a specific file.}, + see_also => render_mt(<<EOT), +<a href="configure/file_directives.html#file.dir"><code>file.dir</code></a> +EOT + since => '2.0', +)->(sub { +?> +<?= $ctx->{example}->('Mapping a path to a specific file', <<'EOT') +paths: + /robots.txt: + file.file: /path/to/robots.txt +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "file.index", + levels => [ qw(global host path) ], + default => "file.index: [ 'index.html', 'index.htm', 'index.txt' ]", + desc => q{Specifies the names of the files that should be served when the client sends a request against the directory.}, + see_also => render_mt(<<EOT), +<a href="configure/file_directives.html#file.dir"><code>file.dir</code></a> +EOT +)->(sub { +?> +<p> +The sequence of filenames are searched from left to right, and the first file that existed is sent to the client. +</p> +? }) + +<? +$ctx->{directive}->( + name => "file.mime.addtypes", + levels => [ qw(global host path) ], + see_also => render_mt(<<'EOT'), +<a href="configure/compress_directives.html#compress"><code>compress</code></a>, +<a href="configure/http2_directives.html#http2-casper"><code>http2-casper</code></a>, +<a href="configure/http2_directives.html#http2-reprioritize-blocking-assets"><code>http2-reprioritize-blocking-assets</code></a> +EOT + desc => q{The directive modifies the MIME mappings by adding the specified MIME type mappings.}, +)->(sub { +?> +<?= $ctx->{example}->('Adding MIME mappings', <<'EOT') +file.mime.addtypes: + "application/javascript": ".js" + "image/jpeg": [ ".jpg", ".jpeg" ] +EOT +?> +<p> +The default mappings is hard-coded in <a href="https://github.com/h2o/h2o/blob/master/lib/handler/mimemap/defaults.c.h">lib/handler/mimemap/defaults.c.h</a>. +</p> +<p> +It is also possible to set certain attributes for a MIME type. +The example below maps <code>.css</code> files to <code>text/css</code> type, setting <code>is_compressible</code> flag to <code>ON</code> and <code>priority</code> to highest. +</p> + +<?= $ctx->{example}->('Setting MIME attributes', <<'EOT') +file.mime.settypes: + "text/css": + extensions: [".css"] + is_compressible: yes + priority: highest +EOT +?> + +<p> +Following attributes are recognized. +</p> + +<table> +<tr><th>Attribute<th>Possible Values<th>Description +<tr><td><code>is_compressible</code><td><code>ON</code>, <code>OFF</code><td>if content is compressible +<tr><td><code>priority</code><td><code>highest<code>, <code>normal</code><td>send priority of the content +</table> + +<p> +The <code>priority</code> attribute affects how the HTTP/2 protocol implementation handles the request. +For detail, please refer to the HTTP/2 directives listed in the <i>see also</i> section below. +By default, mime-types for CSS and JavaScript files are the only ones that are given <code>highest</code> priority. +</p> + +? }) + +<? +$ctx->{directive}->( + name => "file.mime.removetypes", + levels => [ qw(global host path) ], + desc => q{Removes the MIME mappings for specified extensions supplied as a sequence of extensions.}, +)->(sub { +?> +<?= $ctx->{example}->('Removing MIME mappings', <<'EOT') +file.mime.removetypes: [ ".jpg", ".jpeg" ] +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "file.mime.setdefaulttype", + levels => [ qw(global host path) ], + default => q{file.mime.setdefaulttype: "application/octet-stream"}, + desc => q{Sets the default MIME-type that is used when an extension does not exist in the MIME mappings}, +)->(sub {}) +?> + +<? +$ctx->{directive}->( + name => "file.mime.settypes", + levels => [ qw(global host path) ], + desc => q{Resets the MIME mappings to given mapping.}, +)->(sub { +?> +<?= $ctx->{example}->('Resetting the MIME mappings to minimum', <<'EOT') +file.mime.settypes: + "text/html": [ ".html", ".htm" ] + "text/plain": ".txt" +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "file.send-compressed", + levels => [ qw(global host path) ], + default => q{file.send-compressed: OFF}, + see_also => render_mt(<<'EOT'), +<a href="configure/compress_directives.html#compress"><code>compress</code></a> +EOT + since => '2.0', + desc => <<'EOT', +A flag indicating how a pre-compressed file should be served. +EOT +)->(sub { +?> +<p> +If set to <code>ON</code>, the handler looks for a file with <code>.br</code> or <code>.gz</code> appended and sends the file, if the client is capable of transparently decoding a <a href="https://datatracker.ietf.org/doc/draft-alakuijala-brotli/">brotli</a> or <a href="https://tools.ietf.org/html/rfc1952">gzip</a>-encoded response. +For example, if a client requests a file named <code>index.html</code> with <code>Accept-Encoding: gzip</code> header and if <code>index.html.gz</code> exists, the <code>.gz</code> file is sent as a response together with a <code>Content-Encoding: gzip</code> response header. +</p> +<p> +If set to <code>OFF</code>, the handler always serves the file specified by the client. +</p> +<p> +Starting from version 2.2, <code>gunzip</code> is also supported. +If set, the handler acts identical to when the value was set to <code>ON</code>. +In addition, the handler will send an uncompressed response by dynamically decompressing the <code>.gz</code> file if the client and the server failed to agree on using a pre-compressed file as the response and if a non-compressed file was not found. +The option is useful when conserving disk space is important; it is possible to remove the uncompressed files in place for gzipped ones. +</p> +? }) + +<? +$ctx->{directive}->( + name => "file.send-gzip", + levels => [ qw(global host path) ], + desc => <<'EOT', +Obsoleted in 2.0. +Synonym of <a href="configure/file_directives.html#file.send-compressed"><code>file.send-compressed</code></a>. +EOT +)->(sub {}) +?> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/headers_directives.mt b/debian/vendor-h2o/srcdoc/configure/headers_directives.mt new file mode 100644 index 0000000..6c2af07 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/headers_directives.mt @@ -0,0 +1,84 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Headers Directives")->(sub { + +<p> +This document describes the configuration directives of the headers handler. +</p> + +<? +$ctx->{directive}->( + name => "header.add", + levels => [ qw(global host path extension) ], + desc => q{Adds a new header line to the response headers, regardless if a header with the same name already exists.}, +)->(sub { +?> +<div class="example"> +<div class="caption">Example. Setting the <code>Set-Cookie</code> header</div> +<pre><code>header.add: "Set-Cookie: test=1"</code></pre> +</div> +? }) + +<? +$ctx->{directive}->( + name => "header.append", + levels => [ qw(global host path extension) ], + desc => <<'EOT', +Adds a new header line, or appends the value to the existing header with the same name, separated by <code>,</code>. +EOT +)->(sub {}); +?> + +<? +$ctx->{directive}->( + name => "header.merge", + levels => [ qw(global host path extension) ], + desc => <<'EOT', +Adds a new header line, or merges the value to the existing header of comma-separated values. +EOT +)->(sub { +?> +<p> +The following example sets the <code>must-revalidate</code> attribute of the <code>Cache-Control</code> header when and only when the attribute is not yet being set. +</p> +<?= $ctx->{example}->('Setting the <code>must-revalidate</code> attribute', <<'EOT') +header.merge: "Cache-Control: must-revalidate" +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "header.set", + levels => [ qw(global host path extension) ], + desc => q{Sets a header line, removing headers with the same name if exists.}, +)->(sub { +?> +<?= $ctx->{example}->('Setting the <code>X-Content-Type-Options: nosniff</code> header', <<'EOT') +header.set: "X-Content-Type-Options: nosniff" +EOT +?> +? }) + +<? +$ctx->{directive}->( + name => "header.setifempty", + levels => [ qw(global host path extension) ], + desc => <<'EOT', +Sets a header line when and only when a header with the same name does not already exist. +EOT +)->(sub {}); + +<? +$ctx->{directive}->( + name => "header.unset", + levels => [ qw(global host path extension) ], + desc => q{Removes headers with given name.}, +)->(sub { +?> +<?= $ctx->{example}->('Removing the <code>X-Powered-By</code> header', <<'EOT') +header.unset: "X-Powered-By" +EOT +?> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/http1_directives.mt b/debian/vendor-h2o/srcdoc/configure/http1_directives.mt new file mode 100644 index 0000000..77894ac --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/http1_directives.mt @@ -0,0 +1,24 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "HTTP/1 Directives")->(sub { + +<p> +This document describes the configuration directives for controlling the HTTP/1 protocol handler. +</p> + +<? +$ctx->{directive}->( + name => "http1-request-timeout", + levels => [ qw(global) ], + default => 'http1-request-timeout: 10', + desc => q{Timeout for incoming requests in seconds.}, +)->(sub {}); + +$ctx->{directive}->( + name => "http1-upgrade-to-http2", + levels => [ qw(global) ], + default => 'http1-upgrade-to-http2: ON', + desc => q{Boolean flag (<code>ON</code> or <code>OFF</code>) indicating whether or not to allow upgrade to HTTP/2.}, +)->(sub {}); +?> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/http2_directives.mt b/debian/vendor-h2o/srcdoc/configure/http2_directives.mt new file mode 100644 index 0000000..7c2fc26 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/http2_directives.mt @@ -0,0 +1,356 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "HTTP/2 Directives")->(sub { + +<p> +H2O provides one of the world's most sophisticated HTTP/2 protocol implementation, including following features. +</p> + +<h3 id="prioritization">Prioritization</h3> + +<p> +H2O is one of the few servers that fully implement prioritization of HTTP responses conformant to what is defined in the <a href="https://tools.ietf.org/html/rfc7540">HTTP/2 specification</a>. +The server implements a O(1) scheduler that determines which HTTP response should be sent to the client, per every 16KB chunk. +</p> +<p> +Unfortunately, some web browsers fail to specify response priorities that lead to best end-user experience. +H2O is capable of detecting such web browsers, and if it does, uses server-driven prioritization; i.e. send responses with certain MIME-types before others. +</p> +<p> +It is possible to tune or turn off server-driven prioritization using directives: <a href="configure/file_directives.html#file.mime.addtypes"><code>file.mime.addtypes</code></a>, <a href="configure/http2_directives.html#http2-reprioritize-blocking-assets"><code>http2-reprioritize-blocking-assets</code></a>. +</p> +<p> +See also: +<ul> +<li><a href="benchmarks.html#download-timings">Download Timings Benchmark</a> +<li><a href="http://blog.kazuhooku.com/2015/06/http2-and-h2o-improves-user-experience.html">HTTP/2 (and H2O) improves user experience over HTTP/1.1 or SPDY</a> +</ul> +</p> + +<h3 id="server-push">Server push</h3> + +<p> +H2O recognizes <code>link</code> headers with <a href="https://w3c.github.io/preload/">preload</a> keyword sent by a backend application server (reverse proxy or FastCGI) or an mruby handler, and pushes the designated resource to a client. +</p> +<?= $ctx->{example}->('A link response header triggering HTTP/2 push', <<'EOT') +link: </assets/jquery.js>; rel=preload; as=script +EOT +?> + +<p>When the HTTP/2 driver of H2O recognizes a <code>link</code> response header with <code>rel=preload</code> attribute set, and if all of the following conditions are met, the specified resource is pushed to the client. +</p> +<ul> +<li>configuration directive <a href="configure/http2_directives.html#http2-push-preload">http2-push-preload</a> is not set to <code>OFF</code></li> +<li>the <code>link</code> header does not have the <code>nopush</code> attribute set</li> +<li>the <code>link</code> header is <i>not</i> part of a pushed response</li> +<li>the client does not disable HTTP/2 push</li> +<li>number of the pushed responses in-flight is below the negotiated threshold</li> +<li>authority of the resource specified is equivalent to the request that tried to trigger the push</li> +<li>(for handlers that return the status code synchronously) the status code of the response to be pushed does not indicate an error (i.e. 4xx or 5xx)</li> +</ul> +<p> +The server also provides a mechanism to track the clients' cache state via cookies, and to push the resources specified with the <code>link</code> header only when it does not exist within the clients' cache. For details, please refer to the documentation of <a href="configure/http2_directives.html#http2-casper"><code>http2-casper</code></a> configuration directive. +</p> +<p> +When a resource is pushed, the priority is determined using the <a href="configure/file_directives.html#file.mime.addtypes"><code>priority</code> attribute</a> of the MIME-type configuration. If the priority is set to <code>highest</code> then the resource will be sent to the client before anything else; otherwise the resource will be sent to client after the main content, as per defined by the HTTP/2 specification. +</p> +<p> +HTTP/1.1 allows a server to send an informational response (see <a href="https://tools.ietf.org/html/rfc7231#section-6.2" target="_blank">RFC 7230 section 6.2</a>) before sending the final response. +Starting from version 2.1, web applications can take advantage of the informational response to initiate HTTP/2 pushes before starting to process the request. +The following example shows how such responses would look like. +</p> +<?= $ctx->{example}->('100 response with link headers', <<'EOT') +HTTP/1.1 100 Continue +Link: </assets/style.css>; rel=preload; as=style +Link: </assets/jquery.js>; rel=preload; as=script + +HTTP/1.1 200 OK +Content-Type: text/html; charset=utf-8 + +<!doctype html> +<html> +<head> +<link rel="stylesheet" type="text/css" href="/assets/style.css"> +<script type="text/javascript" src="/assets/jquery.js"></scrrpt> +... +EOT +?> +<p> +Pushed responses will have <code>x-http2-push: pushed</code> header set; by looking for the header, it is possible to determine if a resource has been pushed. +It is also possible to log the value in the <a href="configure/access_log_directives.html#access-log">access log</a> by specifying <code>%{x-http2-push}o</code>, push responses but cancelled by CASPER will have the value of the header logged as <code>cancelled</code>. +</p> +<p> +See also: +<ul> +<li><a href="http://blog.kazuhooku.com/2015/12/optimizing-performance-of-multi-tiered.html">Optimizing performance of multi-tier web applications using HTTP/2 push</a> +</ul> +</p> + +<h3 id="latency-optimization">Latency Optimization</h3> + +<p> +When using HTTP/2, a client often issues high-priority requests (e.g. requests for CSS and JavaScript files that block the rendering) while a lower-priority response (e.g. HTML) is in flight. +In such case, it is desirable for a server to switch to sending the response of the high-priority requests as soon as it observes the requests. +</p> +<p> +In order to do so, send buffer of the TCP/IP stack should be kept empty except for the packets in-flight, and size of the TLS records must be small enough to avoid head-of-line blocking. +The downside is that obeying the requirement increases the interaction between the server process and kernel, which result in consumption of more CPU cycles and slightly increased latency. +</p> +<p> +Starting from version 2.1, H2O provides directives that lets the users tune how the TCP/IP stack is used depending on the observed RTT, CWND, and the additional latency imposed by the interaction between the server and the OS. +</p> +<p> +For TCP/IP connections with greater RTT and smaller CWND than the configured threshold, the server will try to keep the size of HTTP/2 frames unsent as small as possible so that it can switch to sending a higher-priority response. +Benchmarks suggest that users can expect in average 1 RTT reduction when this optimization is enabled. +For connections that do not meet the criteria, the server will utilize the TCP/IP stack in ordinary ways. +</p> +<p> +The default values of the thresholds have been chosen that the optimization will come into action for mobile and long-distance networks but not when a proxy exists on the network. +</p> +<p> +The optimization is supported only on Linux and OS X. The two are the operating systems that provide access to <code>TCP_INFO</code> and an interface to adjust the size of the unsent buffer (<code>TCP_NOTSENT_LOWAT</code>). +</p> +<p> +Please refer to the documentation of the directives below to configure the optimization: +<ul> +<li><a href="configure/http2_directives.html#http2-latency-optimization-min-rtt"><code>http2-latency-optimization-min-rtt</code></a></li> +<li><a href="configure/http2_directives.html#http2-latency-optimization-max-additional-delay"><code>http2-latency-optimization-max-additional-delay</code></a></li> +<li><a href="configure/http2_directives.html#http2-latency-optimization-max-cwnd"><code>http2-latency-optimization-max-cwnd</code></a></li> +</ul> +</p> +<p> +See also: +<ul> +<li><a href="http://www.slideshare.net/kazuho/reorganizing-website-architecture-for-http2-and-beyond">Reorganizing Website Architecture for HTTP/2 and Beyond</a> pp.14-21</li> +</ul> +</p> + +<p> +The following describes the configuration directives for controlling the HTTP/2 protocol handler. +</p> + +<? +$ctx->{directive}->( + name => "http2-casper", + levels => [ qw(global host) ], + default => "http2-casper: OFF", + see_also => render_mt(<<'EOT'), +<a href="configure/file_directives.html#file.mime.addtypes"><code>file.mime.addtypes</code></a>, +<a href="https://github.com/h2o/h2o/issues/421">issue #421</a> +EOT + desc => <<'EOT', +Configures CASPer (cache-aware server-push). +EOT +)->(sub { +?> +<p> +When enabled, H2O maintains a fingerprint of the web browser cache, and cancels server-push suggested by the handlers if the client is known to be in possession of the content. +The fingerprint is stored in a cookie named <code>h2o_casper</code> using <a href="https://www.imperialviolet.org/2011/04/29/filters.html">Golomb-compressed sets</a> (a compressed encoding of <a href="https://en.wikipedia.org/wiki/Bloom_filter">Bloom filter</a>). +</p> +<p> +If the value is <code>OFF</code>, the feature is disabled. +Push requests (made by the handlers through the use of <code>Link: rel=preload</code> header) are processed regardless of whether if client already has the responses in its cache. +If the value is <code>ON</code>, the feature is enabled with the defaults value specified below. +If the value is mapping, the feature is enabled, recognizing the following attributes. +<dl> +<dt>capacity-bits: +<dd>number of bits used for the fingerprinting. +Roughly speaking, the number of bits should be <code>log2(1/P * number-of-assets-to-track)</code> where P being the probability of false positives. +Default is <code>13</code>, enough for tracking about 100 asset files with 1/100 chance of false positives (i.e. <code>log2(100 * 100) =~ 13</code>). +<dt>tracking-types: +<dd>specifies the types of the content tracked by casper. +If omitted or set to <code>blocking-assets</code>, maintains fingerprint (and cancels server push) for resources with mime-type of <a href="configure/file_directives.html#file.mime.addtypes"><code>highest</code></a> priority. +If set to <code>all</code>, tracks all responses. +</dl> +</p> +It should be noted that the size of the cookie will be <code>log2(P) * number-of-assets-being-tracked</code> bits multiplied by the overhead of Base 64 encoding (<code>4/3</code>). +Therefore with current cookie-based implementation, it is necessary in many cases to restrict the resources being tracked to those have significant effect to user-perceived response time. +</p> + +<?= $ctx->{example}->('Enabling CASPer', <<'EOT') +http2-casper: ON + +# `ON` is equivalent to: +# http2-casper: +# capacity-bits: 13 +# tracking-types: blocking-assets +EOT +?> + +? }); + +<? +my $spec_url = "https://tools.ietf.org/html/draft-benfield-http2-debug-state-01"; +$ctx->{directive}->( + name => "http2-debug-state", + levels => [ qw(host) ], + see_also => render_mt(<<"EOT"), +<a href=\"$spec_url\">HTTP/2 Implementation Debug State (draft-01)</a> +EOT + desc => <<"EOT", +A directive to turn on the <a href=\"$spec_url\">HTTP/2 Implementation Debug State</a>. +EOT +)->(sub { +?> + +<p> +This experimental feature serves a JSON document at the fixed path <code>/.well-known/h2/state</code>, which describes an internal HTTP/2 state of the H2O server. +To know the details about the response fields, please see <a href="<?= $spec_url ?>">the spec</a>. +This feature is only for developing and debugging use, so it's highly recommended that you disable this setting in the production environment. +</p> + +<p> +The value of this directive specifies the property set contained in the response. Available values are <code>minimum</code> or <code>hpack</code>. +If <code>hpack</code> is specified, the response will contain the internal hpack state of the same connection. +If <code>minimum</code> is specified, the response doesn't contain the internal hpack state. +</p> + +<p> +In some circumstances, there may be a risk of information leakage on providing an internal hpack state. For example, the case that some proxies exist between the client and the server, and they share the connections among the clients. +Therefore, you should specify <code>hpack</code> only when the server runs in the environments you can completely control. +</p> + +<p> +This feature is considered experimental yet. +For now, the implementation conforms to the version draft-01 of the specification. +</p> + +? }); + +<? +$ctx->{directive}->( + name => "http2-idle-timeout", + levels => [ qw(global) ], + default => 'http2-idle-timeout: 10', + desc => <<'EOT', +Timeout for idle connections in seconds. +EOT +)->(sub {}); + +$ctx->{directive}->( + name => "http2-max-concurrent-requests-per-connection", + levels => [ qw(global) ], + default => 'http2-max-concurrent-requests-per-connection: 100', + desc => <<'EOT', +Maximum number of requests to be handled concurrently within a single HTTP/2 connection. +EOT +)->(sub { +?> +<p> +The value cannot exceed 256. +</p> +? }) + +<? +$ctx->{directive}->( + name => "http2-latency-optimization-min-rtt", + levels => [ qw(global) ], + since => '2.1', + default => 'http2-latency-optimization-min-rtt: 50', + desc => << 'EOT', +Minimum RTT (in milliseconds) to enable <a href="configure/http2_directives.html#latency-optimization">latency optimization</a>. +EOT +)->(sub { +?> +<p> +Latency optimization is disabled for TCP connections with smaller RTT (round-trip time) than the specified value. +Otherwise, whether if the optimization is used depends on other parameters. +</p> +<p> +Setting this value to 4294967295 (i.e. <code>UINT_MAX</code>) effectively disables the optimization. +</p> +? }) + +<? +$ctx->{directive}->( + name => "http2-latency-optimization-max-additional-delay", + levels => [ qw(global) ], + since => '2.1', + default => 'http2-latency-optimization-max-additional-delay: 0.1', + desc => << 'EOT', +Maximum additional delay (as the ratio to RTT) permitted to get <a href="configure/http2_directives.html#latency-optimization">latency optimization</a> activated. +EOT +)->(sub { +?> +<p> +Latency optimization is disabled if the additional delay imposed by the interaction between the OS and the TCP/IP stack is estimated to be greater than the given threshold. +Otherwise, whether if the optimization is used depends on other parameters. +</p> +? }) + +<? +$ctx->{directive}->( + name => "http2-latency-optimization-max-cwnd", + levels => [ qw(global) ], + since => '2.1', + default => 'http2-latency-optimization-max-cwnd: 65535', + desc => << 'EOT', +Maximum size (in octets) of CWND to get <a href="configure/http2_directives.html#latency-optimization">latency optimization</a> activated. +EOT +)->(sub { +?> +<p> +CWND is a per-TCP-connection variable that represents the number of bytes that can be sent within 1 RTT. +</p> +<p> +The server will not use or stop using latency optimization mode if CWND becomes greater than the configured value. +In such case, average size of HTTP/2 frames buffered unsent will be slightly above the <a href="https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt" target="_blank"><code>tcp_notsent_lowat</code></a> sysctl value. +</p> +?> +? }) + +<? +$ctx->{directive}->( + name => "http2-push-preload", + levels => [ qw(global host) ], + since => '2.1', + default => 'http2-push-preload: ON', + desc => << 'EOT', +A boolean flag (<code>ON</code> or <code>OFF</code>) indicating whether if the server should push resources when observing a <code>link: rel=preload</code> header. +EOT +)->(sub { +?> +? }) + +<? +$ctx->{directive}->( + name => "http2-reprioritize-blocking-assets", + levels => [ qw(global) ], + default => 'http2-reprioritize-blocking-assets: ON', + see_also => render_mt(<<'EOT'), +<a href="configure/file_directives.html#file.mime.addtypes"><code>file.mime.addtypes</code></a>, +<a href="http://blog.kazuhooku.com/2015/06/http2-and-h2o-improves-user-experience.html">HTTP/2 (and H2O) improves user experience over HTTP/1.1 or SPDY</a> +EOT + desc => <<'EOT', +A boolean flag (<code>ON</code> or <code>OFF</code>) indicating if the server should send contents with <code>highest</code> priority before anything else. +EOT +)->(sub { +?> +<p> +To maximize the user-perceived responsiveness of a web page, it is essential for the web server to send blocking assets (i.e. CSS and JavaScript files in <code><HEAD></code>) before any other files such as images. +HTTP/2 provides a way for web browsers to specify such priorities to the web server. +However, as of Sep. 2015, no major web browsers except Mozilla Firefox take advantage of the feature. +</p> +<p> +This option, when enabled, works as a workaround for such web browsers, thereby improving experience of users using the web browsers. +</p> +<p> +Technically speaking, it does the following: +<ul> +<li>if the client uses dependency-based prioritization, do not reprioritize +<li>if the client does not use dependency-based prioritization, send the contents of which their types are given <a href="configure/file_directives.html#file.mime.addtypes"><code>highest</code></a> priority before any other responses +</ul> +</p> +? }); + +<? +$ctx->{directive}->( + name => "http2-graceful-shutdown-timeout", + levels => [ qw(global) ], + default => 'http2-graceful-shutdown-timeout: 0', + desc => <<'EOT', +A timeout in seconds. How long to wait before closing the connection on graceful shutdown. Setting the timeout to <code>0</code> deactivates the feature: H2O will wait for the peer to close the connections. +EOT +)->(sub {}); +?> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/mruby.mt b/debian/vendor-h2o/srcdoc/configure/mruby.mt new file mode 100644 index 0000000..99affa8 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/mruby.mt @@ -0,0 +1,199 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Using Mruby")->(sub { + +<p> +<a href="https://github.com/mruby/mruby">mruby</a> is a lightweight implementation of the Ruby programming language. +With H2O, users can implement their own request handling logic using mruby, either to generate responses or to fix-up the request / response. +</p> + +<h3 id="programming-interface">Rack-based Programming Interface</h3> + +<p> +The interface between the mruby program and the H2O server is based on <a href="http://www.rubydoc.info/github/rack/rack/master/file/SPEC">Rack interface specification</a>. +Below is a simple configuration that returns <i>hello world</i>. +</p> + +<?= $ctx->{example}->('Hello-world in mruby', <<'EOT') +paths: + "/": + mruby.handler: | + Proc.new do |env| + [200, {'content-type' => 'text/plain'}, ["Hello world\n"]] + end +EOT +?> + +<p> +It should be noted that as of H2O version 1.7.0, there are limitations when compared to ordinary web application server with support for Rack such as Unicorn: +<ul> +<li>no libraries provided as part of Rack is available (only the interface is compatible) +</ul> +</p> + +<p> +In addition to the Rack interface specification, H2O recognizes status code <code>399</code> which can be used to delegate request to the next handler. +The feature can be used to implement access control and response header modifiers. +</p> + +<h3 id="access-control">Access Control</h3> + +<p> +By using the <code>399</code> status code, it is possible to implement access control using mruby. +The example below restricts access to requests from <code>192.168.</code> private address. +</p> + +<?= $ctx->{example}->('Restricting access to 192.168.', <<'EOT') +paths: + "/": + mruby.handler: | + lambda do |env| + if /\A192\.168\./.match(env["REMOTE_ADDR"]) + return [399, {}, []] + end + [403, {'content-type' => 'text/plain'}, ["access forbidden\n"]] + end +EOT +?> + +<p> +Support for <a href="configure/basic_auth.html">Basic Authentication</a> is also provided by an mruby script. +</p> + +<h3 id="delegating-request">Delegating the Request</h3> + +<p> +When enabled using the <a href="configure/reproxy_directives.html#reproxy"><code>reproxy</code></a> directive, it is possible to delegate the request from the mruby handler to any other handler. +</p> +<p> +<?= $ctx->{example}->('Rewriting URL with delegation', <<'EOT') +paths: + "/": + mruby.handler: | + lambda do |env| + if /\/user\/([^\/]+)/.match(env["PATH_INFO"]) + return [307, {"x-reproxy-url" => "/user.php?user=#{$1}"}, []] + end + return [399, {}, []] + end +EOT +?> + +<h3 id="modifying-response">Modifying the Response</h3> + +<p> +When the mruby handler returns status code <code>399</code>, H2O delegates the request to the next handler while preserving the headers emitted by the handler. +The feature can be used to add extra headers to the response. +</p> +<p> +For example, the following example sets <code>cache-control</code> header for requests against <code>.css</code> and <code>.js</code> files. +</p> + +<?= $ctx->{example}->('Setting cache-control header for certain types of files', <<'EOT') +paths: + "/": + mruby.handler: | + Proc.new do |env| + headers = {} + if /\.(css|js)\z/.match(env["PATH_INFO"]) + headers["cache-control"] = "max-age=86400" + end + [399, headers, []] + end + file.dir: /path/to/doc-root +EOT +?> + +<p> +Or in the example below, the handler triggers <a href="configure/http2_directives.html#server-push">HTTP/2 server push</a> with the use of <code>Link: rel=preload</code> headers, and then requests a FastCGI application to process the request. +</p> + +<?= $ctx->{example}->('Pushing asset files', <<'EOT') +paths: + "/": + mruby.handler: | + Proc.new do |env| + push_paths = [] + # push css and js when request is to dir root or HTML + if /(\/|\.html)\z/.match(env["PATH_INFO"]) + push_paths << ["/css/style.css", "style"] + push_paths << ["/js/app.js", "script"] + end + [399, push_paths.empty? ? {} : {"link" => push_paths.map{|p| "<#{p[0]}>; rel=preload; as=#{p[1]}"}.join("\n")}, []] + end + fastcgi.connect: ... +EOT +?> + +<h3 id="http-client">Using the HTTP Client</h3> + +<p> +Starting from version 1.7, a HTTP client API is provided. +HTTP requests issued through the API will be handled asynchronously; the client does not block the event loop of the HTTP server. +</p> + +<?= $ctx->{example}->('Mruby handler returning the response of http://example.com', <<'EOT') +paths: + "/": + mruby.handler: | + Proc.new do |env| + req = http_request("http://example.com") + status, headers, body = req.join + [status, headers, body] + end +EOT +?> + +<p> +<code>http_request</code> is the method that issues a HTTP request. +</p> +<p> +The method takes two arguments. +First argument is the target URI. +Second argument is an optional hash; <code>method</code> (defaults to <code>GET</code>), <code>header</code>, <code>body</code> attributes are recognized. +</p> +<p> +The method returns a promise object. +When <code>#join</code> method of the promise is invoked, a three-argument array containing the status code, response headers, and the body is returned. +The response body is also a promise. +Applications can choose from three ways when dealing with the body: a) call <code>#each</code> method to receive the contents, b) call <code>#join</code> to retrieve the body as a string, c) return the object as the response body of the mruby handler. +</p> +<p> +The header and the body object passed to <code>http_request</code> should conform to the requirements laid out by the Rack specification for request header and request body. +The response header and the response body object returned by the <code>#join</code> method of the promise returned by <code>http_request</code> conforms to the requirements of the Rack specification. +</p> +<p> +Since the API provides an asynchronous HTTP client, it is possible to effectively issue multiple HTTP requests concurrently and merge them into a single response. +</p> +<p> +When HTTPS is used, servers are verified using the properties of <a href="configure/proxy_directives.html#proxy.ssl.cafile"><code>proxy.ssl.cafile</code></a> and <a href="configure/proxy_directives.html#proxy.ssl.verify-peer"><code>proxy.ssl.verify-peer</code></a> specified at the global level. +</p> + +<h3 id="logging-arbitrary-variable">Logging Arbitrary Variable</h3> + +<p> +In version 2.3, it is possible from mruby to set and log an arbitrary-named variable that is associated to a HTTP request. +A HTTP response header that starts with <code>x-fallthru-set-</code> is handled specially by the H2O server. Instead of sending the header downstream, the server accepts the value as a request environment variable, taking the suffix of the header name as the name of the variable. +</p> +<p> +This example shows how to read request data, parse json and then log data from mruby. +</p> + +<?= $ctx->{example}->('Logging the content of a POST request via request environment variable', <<'EOT') +paths: + "/": + mruby.handler: | + Proc.new do |env| + input = env["rack.input"] ? env["rack.input"].read : '{"default": "true"}' + parsed_json = JSON.parse(input) + parsed_json["time"] = Time.now.to_i + logdata = parsed_json.to_s + [204, {"x-fallthru-set-POSTDATA" => logdata}, []] + end + access-log: + path: /path/to/access-log.json + escape: json + format: '{"POST": %{POSTDATA}e}' +EOT +?> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/mruby_directives.mt b/debian/vendor-h2o/srcdoc/configure/mruby_directives.mt new file mode 100644 index 0000000..e1d0e2f --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/mruby_directives.mt @@ -0,0 +1,58 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Mruby Directives")->(sub { + +<p> +The following are the configuration directives of the mruby handler. +Please refer to <a href="configure/mruby.html">Using mruby</a> to find out how to write handlers using mruby. +</p> + +<? +$ctx->{directive}->( + name => "mruby.handler", + levels => [ qw(path) ], + see_also => render_mt(<<'EOT'), +<a href="configure/mruby_directives.html#mruby.handler-file"><code>mruby.handler-file</code></a> +EOT + desc => <<'EOT', +Upon start-up evaluates given mruby expression, and uses the returned mruby object to handle the incoming requests. +EOT +)->(sub { +?> + +<?= $ctx->{example}->('Hello-world in mruby', <<'EOT') +mruby.handler: | + Proc.new do |env| + [200, {'content-type' => 'text/plain'}, ["Hello world\n"]] + end +EOT +?> + +<p> +Note that the provided expression is evaluated more than once (typically for every thread that accepts incoming connections). +</p> +? }) + +<? +$ctx->{directive}->( + name => "mruby.handler-file", + levels => [ qw(path) ], + see_also => render_mt(<<'EOT'), +<a href="configure/mruby_directives.html#mruby.handler"><code>mruby.handler</code></a> +EOT + desc => <<'EOT', +Upon start-up evaluates given mruby file, and uses the returned mruby object to handle the incoming requests. +EOT +)->(sub { +?> + +<?= $ctx->{example}->('Hello-world in mruby', <<'EOT') +mruby.handler-file: /path/to/my-mruby-handler.rb +EOT +?> + +<p> +Note that the provided expression is evaluated more than once (typically for every thread that accepts incoming connections). +</p> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/proxy_directives.mt b/debian/vendor-h2o/srcdoc/configure/proxy_directives.mt new file mode 100644 index 0000000..bea7e00 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/proxy_directives.mt @@ -0,0 +1,236 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Proxy Directives")->(sub { + +<p> +Proxy module is the reverse proxy implementation for H2O - it implements a HTTP client that forwards a HTTP request to an upstream server. +</p> +<p> +When forwarding the requests, the module sets following request headers: +<ul> +<li><a href="https://tools.ietf.org/html/rfc7230#section-5.7.1">via</a></li> +<li><a href="http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/x-forwarded-headers.html#x-forwarded-for">x-forwarded-for</a></li> +<li><a href="http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/x-forwarded-headers.html#x-forwarded-proto">x-forwarded-proto</a></li> +</ul> +</p> +<p> +The HTTP client only supports HTTP/1. +Support for HTTPS has been introduced in version 2.0. +</p> +<p> +Following sections describe the configuration directives defined for the module. +</p> + +<? +$ctx->{directive}->( + name => "proxy.reverse.url", + levels => [ qw(path) ], + desc => q{Forwards the requests to the specified URL, and proxies the response.}, +)->(sub { +?> +<?= $ctx->{example}->(q{Forwarding the requests to application server running on <code>127.0.0.1:8080</code>}, <<'EOT') +proxy.reverse.url: "http://127.0.0.1:8080/" +EOT +?> +<p> +If you want load balancing multiple backends, replace 127.0.0.1 with hostname which returns IP addresses via DNS or /etc/hosts. +</p> +<p> +In addition to TCP/IP over IPv4 and IPv6, the proxy handler can also connect to an HTTP server listening to a Unix socket. +Path to the unix socket should be surrounded by square brackets, and prefixed with <code>unix:</code> (e.g. <code>http://[unix:/path/to/socket]/path</code>). +</p> + +? }) + +<? +$ctx->{directive}->( + name => "proxy.preserve-host", + levels => [ qw(global host path extension) ], + default => q{proxy.preserve-host: OFF}, + desc => q{A boolean flag (<code>ON</code> or <code>OFF</code>) designating whether or not to pass <code>Host</code> header from incoming request to upstream.}, +)->(sub {}); +?> + +<? +$ctx->{directive}->( + name => "proxy.preserve-x-forwarded-proto", + levels => [ qw(global) ], + since => "2.0", + default => q{proxy.preserve-x-forwarded-proto: OFF}, + desc => "A boolean flag(<code>ON</code> or <code>OFF</code>) indicating if the server preserve the received <code>x-forwarded-proto</code> request header.", +)->(sub { +?> +<p> +By default, when transmitting a HTTP request to an upstream HTTP server, H2O removes the received <code>x-forwarded-proto</code> request header and sends its own, as a precaution measure to prevent an attacker connecting through HTTP to lie that they are connected via HTTPS. +However in case H2O is run behind a trusted HTTPS proxy, such protection might not be desirable, and this configuration directive can be used to modify the behaviour. +</p> +? }) + +<? +$ctx->{directive}->( + name => "proxy.proxy-protocol", + levels => [ qw(global host path extension) ], + since => "2.1", + see_also => render_mt(<<'EOT'), +<a href="configure/proxy_directives.html#proxy.timeout.keepalive"><code>proxy.timeout.keepalive</code></a> +EOT + default => q{proxy.proxy-protocol: OFF}, + desc => q{A boolean flag (<code>ON</code> or <code>OFF</code>) indicating if <a href="http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt" target="_blank">PROXY protocol</a> should be used when connecting to the application server.}, +)->(sub { +?> +<p> +When using the PROXY protocol, connections to the application server cannot be persistent (i.e. <a href="configure/proxy_directives.html#proxy.timeout.keepalive"><code>proxy.timeout.keepalive</code></a> must be set to zero). +</p> +? }) + +<? +$ctx->{directive}->( + name => "proxy.emit-x-forwarded-headers", + levels => [ qw(global) ], + since => "2.1", + default => q{proxy.emit-x-forwarded-headers: ON}, + desc => "A boolean flag(<code>ON</code> or <code>OFF</code>) indicating if the server will append or add the <code>x-forwarded-proto</code> and <code>x-forwarded-for</code> request headers.", + see_also => render_mt(<<'EOT'), +<a href="configure/proxy_directives.html#proxy.emit-via-header"><code>proxy.emit-via-header</code></a> +EOT +)->(sub { +?> +<p> +By default, when forwarding an HTTP request H2O sends its own <code>x-forwarded-proto</code> and <code>x-forwarded-for</code> request headers (or might append its value in the <code>x-forwarded-proto</code> case, see <code>proxy.preserve-x-forwarded-proto</code>). This might not be always desirable. Please keep in mind security implications when setting this of <code>OFF</code>, since it might allow an attacker to spoof the originator or the protocol of a request. +</p> +? }) + +<? +$ctx->{directive}->( + name => "proxy.emit-via-header", + levels => [ qw(global) ], + since => "2.2", + default => q{proxy.emit-via-header: ON}, + desc => "A boolean flag (<code>ON</code> or <code>OFF</code>) indicating if the server adds or appends an entry to the <code>via</code> request header.", + see_also => render_mt(<<'EOT'), +<a href="configure/proxy_directives.html#proxy.emit-x-forwarded-headers"><code>proxy.emit-x-forwarded-headers</code></a> +EOT +)->(sub {}) +?> + +<? +for my $action (qw(add append merge set setifempty unset)) { + $ctx->{directive}->( + name => "proxy.header.$action", + levels => [ qw(global host path extensions) ], + since => "2.2", + desc => "Modifies the request headers sent to the application server.", + )->(sub { +?> +<p> +The behavior is identical to <a href="configure/headers_directives.html#header.<?= $action ?>"><code>header.<?= $action ?></code></a> except for the fact that it affects the request sent to the application server. +Please refer to the documentation of the <a href="configure/headers_directives.html">headers handler</a> to see how the directives can be used to mangle the headers. +</p> +<? + }); +} +?> + +<? +$ctx->{directive}->( + name => "proxy.ssl.cafile", + levels => [ qw(global host path extension) ], + since => "2.0", + desc => "Specifies the file storing the list of trusted root certificates.", + see_also => render_mt(<<'EOT'), +<a href="configure/proxy_directives.html#proxy.ssl.verify-peer"><code>proxy.ssl.verify-peer</code></a> +EOT +)->(sub { +?> +<p> +By default, H2O uses <code>share/h2o/ca-bundle.crt</code>. The file contains a set of trusted root certificates maintained by Mozilla, downloaded and converted using <a href="https://curl.haxx.se/docs/mk-ca-bundle.html">mk-ca-bundle.pl</a>. +</p> +? }) + +<? +$ctx->{directive}->( + name => "proxy.ssl.session-cache", + levels => [ qw(global host path extension) ], + since => "2.1", + default => "proxy.ssl.session-cache: ON", + desc => "Specifies whether if and how a session cache should be used for TLS connections to the application server.", +)->(sub { +?> +<p> +Since version 2.1, result of the TLS handshakes to the application server is memoized and later used to resume the connection, unless set to <code>OFF</code> using this directive. +If the value is a mapping, then the following two attributes must be specified: +<dl> +<dt>lifetime:</dt> +<dd>validity of session cache entries in seconds</dd> +<dt>capacity:</dt> +<dd>maxmum number of entries to be kept in the session cache</dd> +</dl> +If set to <code>ON</code>, <code>lifetime</code> and <code>capacity</code> will be set to 86,400 (one day) and 4,096. +</p> +? }) + +<? +$ctx->{directive}->( + name => "proxy.ssl.verify-peer", + levels => [ qw(global host path extension) ], + since => "2.0", + desc => "A boolean flag (<code>ON</code> or <code>OFF</code>) indicating if the server certificate and hostname should be verified.", + default => q{proxy.ssl.verify-peer: ON}, + see_also => render_mt(<<'EOT'), +<a href="configure/proxy_directives.html#proxy.ssl.cafile"><code>proxy.ssl.cafile</code></a> +EOT +)->(sub { +?> +<p> +If set to <code>ON</code>, the HTTP client implementation of H2O verifies the peer's certificate using the list of trusted certificates as well as compares the hostname presented in the certificate against the connecting hostname. +</p> +? }) + +<? +$ctx->{directive}->( + name => "proxy.timeout.io", + levels => [ qw(global host path extension) ], + default => q{proxy.timeout.io: 30000}, + desc => q{Sets the upstream I/O timeout in milliseconds.}, +)->(sub {}); +?> + +<? +$ctx->{directive}->( + name => "proxy.timeout.keepalive", + levels => [ qw(global host path extension) ], + default => q{proxy.timeout.keepalive: 2000}, + desc => 'Sets the upstream timeout for idle connections in milliseconds.', +)->(sub { +?> +<p> +Upstream connection becomes non-persistent if the value is set to zero. +The value should be set to something smaller than that being set at the upstream server. +</p> +? }) + +<? +$ctx->{directive}->( + name => "proxy.websocket", + levels => [ qw(global host path extension) ], + default => q{proxy.websocket: OFF}, + desc => q{A boolean flag (<code>ON</code> or <code>OFF</code>) indicating whether or not to allow upgrading the proxied connection to <a href="https://tools.ietf.org/html/rfc6455">the WebSocket protocol</a>.}, +)->(sub { +?> +<p> +When set to <code>ON</code>, the proxied connection will be upgraded to a bi-directional tunnel stream if upgrading to WebSocket connection is permitted by the backend server (i.e. if the backend server responds to a WebSocket handshake with <code>101</code> status code). +</p> +<p> +Support for WebSocket is considered experimental for the time being and therefore is not yet turned on by default. +</p> +? }) + +<? +$ctx->{directive}->( + name => "proxy.websocket.timeout", + levels => [ qw(global host path extension) ], + default => q{proxy.websocket.timeout: 300000}, + desc => q{Sets idle timeout of a WebSocket connection being proxied.}, +)->(sub {}) +?> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/quick_start.mt b/debian/vendor-h2o/srcdoc/configure/quick_start.mt new file mode 100644 index 0000000..3ce0869 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/quick_start.mt @@ -0,0 +1,66 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Quick Start")->(sub { + +<p> +In order to run the H2O standalone HTTP server, you need to write a configuration file. +The minimal configuration file looks like as follows. +</p> + +<?= $ctx->{code}->(<< 'EOT') +listen: + port: 8080 +user: nobody +hosts: + "myhost.example.com": + paths: + /: + file.dir: /path/to/the/public-files +access-log: /path/to/the/access-log +error-log: /path/to/the/error-log +pid-file: /path/to/the/pid-file +EOT +?> + +<p> +The configuration instructs the server to: +<ol> +<li>listen to port 8080</li> +<li>under the privileges of <code>nobody</code></li> +<li>serve files under <code>/path/to/the/public-files</code></li> +<li>emit access logs to file: <code>/path/to/the/access-log</code></li> +<li>emit error logs to <code>/path/to/the/error-log</code></li> +<li>store the process id of the server in <code>/path/to/the/pid-file</code> +</ol> +</p> + +<p> +Enter the command below to start the server. +</p> + +<?= $ctx->{code}->(<< 'EOT') +% sudo h2o -m daemon -c /path/to/the/configuration-file +EOT +?> + +<p> +The command instructs the server to read the configuration file, and start in <code>daemon</code> mode, which dispatches a pair of master and worker processes that serves the HTTP requests. +</p> + +<p> +To stop the server, send <code>SIGTERM</code> to the server. +</p> + +<?= $ctx->{code}->(<< 'EOT') +% sudo kill -TERM `cat /path/to/the/pid-file` +EOT +?> + +<h3>Next Step</h3> + +<p> +Now that you know how to start and stop the server, the next step is to learn the <a href="configure.html">configuration directives and their structure</a>, or see <a href="https://github.com/h2o/h2o/wiki#configuration-examples">the configuration examples</a>. +</p> + +</p> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/redirect_directives.mt b/debian/vendor-h2o/srcdoc/configure/redirect_directives.mt new file mode 100644 index 0000000..8fbdd95 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/redirect_directives.mt @@ -0,0 +1,47 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Redirect Directives")->(sub { + +<p> +This document describes the configuration directives of the redirect handler. +</p> + +<? +$ctx->{directive}->( + name => "redirect", + levels => [ qw(path) ], + desc => q{Redirects the requests to given URL.}, +)->(sub { +?> +<p> +The directive rewrites the URL by replacing the host and path part of the URL at which the directive is used with the given URL. For example, when using the configuration below, requests to <code>http://example.com/abc.html</code> will be redirected to <code>https://example.com/abc.html</code>. +</p> +<p> +If the argument is a scalar, the value is considered as the URL to where the requests should be redirected. +</p> +<p> +Following properties are recognized if the argument is a mapping. +<dl> +<dt><code>url</code> +<dd>URL to redirect to +<dt><code>status</code> +<dd>the three-digit status code to use (e.g. <code>301</code>) +<dt><code>internal</code> +<dd>either <code>YES</code> or <code>NO</code> (default); if set to <code>YES</code>, then the server performs an internal redirect and return the content at the redirected URL +</dl> +</p> +<?= $ctx->{example}->('Redirect all HTTP to HTTPS permanently (except for the files under <code>RSS</code>)', <<'EOT'); +hosts: + "example.com:80": + paths: + "/": + redirect: + status: 301 + url: "https://example.com/" + "/rss": + file.dir: /path/to/rss +EOT +?> + +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/reproxy_directives.mt b/debian/vendor-h2o/srcdoc/configure/reproxy_directives.mt new file mode 100644 index 0000000..3288a65 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/reproxy_directives.mt @@ -0,0 +1,29 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Reproxy Directives")->(sub { + +<p> +This document describes the configuration directives of the reproxy handler. +</p> + +<? +$ctx->{directive}->( + name => "reproxy", + levels => [ qw(global host path extension) ], + default => q{reproxy: OFF}, + desc => <<'EOT', +A boolean flag (<code>ON</code> or <code>OFF</code>) indicating if the server should recognize the <code>X-Reproxy-URL</code> header sent from <a href="configure/proxy_directives.html#proxy.reverse.url">upstream servers</a>. +EOT +)->(sub { +?> +<p> +If H2O recognizes the header, it fetches the contents of the resource specified by the header, and sends the contents as the response to the client. +If the status code associated with the <code>X-Reproxy-URL</code> header is 307 or 308, then the method of the original request is used to obtain the specified resource. +Otherwise, the request method is changed to <code>GET</code>. +</p> +<p> +For example, an upstream server may send an URL pointing to a large image using the <code>X-Reproxy-URL</code> header stored on a distributed file system, and let H2O fetch and return the content to the client, instead of fetching the image by itself. +Doing so would reduce the load on the application server. +</p> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/status_directives.mt b/debian/vendor-h2o/srcdoc/configure/status_directives.mt new file mode 100644 index 0000000..a78689f --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/status_directives.mt @@ -0,0 +1,63 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Status Directives")->(sub { + +<p> +The status handler exposes the current states of the HTTP server. +This document describes the configuration directives of the handler. +</p> + +<? +$ctx->{directive}->( + name => "status", + levels => [ qw(path) ], + since => '2.0', + desc => <<'EOT', +If the argument is <code>ON</code>, the directive registers the status handler to the current path. +EOT +)->(sub { +?> +<p> +Access to the handler should be <a href="configure/mruby.html#access-control">restricted</a>, considering the fact that the status includes the details of in-flight HTTP requests. +The example below uses <a href="configure/basic_auth.html">Basic authentication</a>. +</p> +<?= $ctx->{example}->("Exposing status with Basic authentication", <<'EOT'); +paths: + /server-status: + mruby.handler: | + require "htpasswd.rb" + Htpasswd.new("/path/to/.htpasswd", "status") + status: ON +EOT +?> +<p> +The information returned by the <code>/json</code> handler can be filtered out using the optional <code>show=module1,module2</code> parameter. +There are currently three modules defined: +<ul> +<li><code>requests</code>: displays the requests currently in-flight.</li> +<li><code>durations</code>: displays durations statistics for requests since server start time in seconds (returns all zeros unless <code>duration-stats</code> is <code>ON</code>).</li> +<li><code>errors</code>: displays counters for internally generated errors.</li> +<li><code>main</code>: displays general daemon-wide stats.</li> +</ul> +</p> +? }) + +<? +$ctx->{directive}->( + name => "duration-stats", + levels => [ qw(global) ], + since => '2.1', + default => 'duration-stats: OFF', + desc => q{Gather timing stats for requests.}, +)->(sub { +?> +</p> +<p> +If the argument is <code>ON</code>, this directive populates duration statistics in seconds, to be consumed by status handlers. +Enabling this feature has a noticeable CPU and memory impact. +</p> +<p> +Note that the time spent while processing a request in a blocking manner (such as opening a file or a mruby handler that does invoke a network operation) will not be reflected to the <code>process_time</code> element of the duration stats due to the fact that the timer being used for measuring the time spent is updated only once per loop. +</p> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/syntax_and_structure.mt b/debian/vendor-h2o/srcdoc/configure/syntax_and_structure.mt new file mode 100644 index 0000000..f8f8cd4 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/syntax_and_structure.mt @@ -0,0 +1,216 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Syntax and Structure")->(sub { + +<h3>Syntax</h3> + +<p> +H2O uses <a href="http://www.yaml.org/">YAML</a> 1.1 as the syntax of its configuration file. +</p> + +<h3 id="config_levels">Levels of Configuration</h3> + +<p> +When using the configuration directives of H2O, it is important to understand that there are four configuration levels: global, host, path, extension. +</p> + +<p> +Global-level configurations affect the entire server. +Host-level configurations affect the configuration for the specific hostname (i.e. corresponds to the <a href="http://httpd.apache.org/docs/2.4/vhosts/"><VirtualHost></a> directive of the Apache HTTP Server). +Path-level configurations only affect the behavior of resources specific to the path. +</p> + +<p> +Extension-level configuration affect how files with certain extensions are being served. +For example, it is possible to map files with <code>.php</code> extension to the FastCGI handler running the <code>php-cgi</code> command. +</p> + +<p> +Consider the following example. +</p> + +<?= $ctx->{code}->(<< 'EOT') +hosts: + "example.com": + listen: + port: 443 + ssl: + certificate-file: etc/site1.crt + key-file: etc/site1.key + paths: + "/": + file.dir: htdocs/site1 + "/icons": + file.dir: icons + expires: 1 day + "example.com:80": + listen: + port: 80 + paths: + "/": + redirect: "https://example.com/" +EOT +?> + +<p> +In the example, two host-level configurations exist (under the <code>hosts</code> mapping), each of them listening to different ports. +The first host listens to port 443 using TLS (i.e. HTTPS) using the specified server certificate and key. +It has two path-level configurations, one for <code>/</code> and the other for <code>/icons</code>, each of them pointing to different local directories containing the files to be served. +The latter also has the <code>expires</code> directive set, so that <code>Cache-Control: max-age=86400</code><?= $ctx->{note}->("1 day is equivalent to 86400 seconds") ?> header would be sent. +The second host accepts connections on port 80 (via the plain-text HTTP protocol), and redirects all the requests to the first host using HTTPS. +</p> + +<p> +Certain configuration directives can be used in more than one levels. For example, the <a href="configure/base_directives.html#listen"><code>listen</code></a> can be used either at the global level or at the host level. +<a href="configure/expires_directives.html#expires"><code>Expires</code></a> can be used at all levels. +On the other hand <a href="configure/file_directives.html#file.dir"><code>file.dir</code></a> can only be used at the path level. +</p> + +<h3 id="path-level">Path-level configuration</h3> + +<p> +Values of the path-level configuration define the action(s) to be taken when the server processes a request that prefix-matches to the configured paths. +Each entry of the mapping associated to the paths is evaluated in the order they appear. +</p> + +<p> +Consider the following example. +When receiving a request for <code>https://example.com/foo</code>, <a href="configure/file_directives.html">the file handler</a> is first executed trying to serve a file named <code>/path/to/doc-root/foo</code> as the response. +In case the file does not exist, then <a href="configure/fastcgi_directives.html">the FastCGI handler</a> is invoked. +</p> + +<?= $ctx->{code}->(<< 'EOT') +hosts: + "example.com": + listen: + port: 443 + ssl: + certificate-file: etc/site1.crt + key-file: etc/site1.key + paths: + "/": + file.dir: /path/to/doc-root + fastcgi.connect: + port: /path/to/fcgi.sock + type: unix +EOT +?> + +<p> +Starting from version 2.1, it is also possible to define the path-level configuration as a sequence of mappings instead of a single mapping. +The following example is identical to the previous one. +Notice the dashes placed before the handler directives. +</p> + +<?= $ctx->{code}->(<< 'EOT') +hosts: + "example.com": + listen: + port: 443 + ssl: + certificate-file: etc/site1.crt + key-file: etc/site1.key + paths: + "/": + - file.dir: /path/to/doc-root + - fastcgi.connect: + port: /path/to/fcgi.sock + type: unix +EOT +?> + +<h3 id="yaml_alias">Using YAML Alias</h3> + +<p> +H2O resolves <a href="http://yaml.org/YAML_for_ruby.html#aliases_and_anchors">YAML aliases</a> before processing the configuration file. +Therefore, it is possible to use an alias to reduce the redundancy of the configuration file. +For example, the following configuration reuses the first <code>paths</code> element (that is given an anchor named <code>default_paths</code>) in the following definitions. + +<?= $ctx->{code}->(<< 'EOT') +hosts: + "example.com": + listen: + port: 443 + ssl: + certificate-file: /path/to/example.com.crt + key-file: /path/to/example.com.crt + paths: &default_paths + "/": + file.dir: /path/to/doc-root + "example.org": + listen: + port: 443 + ssl: + certificate-file: /path/to/example.org.crt + key-file: /path/to/example.org.crt + paths: *default_paths +EOT +?> + +<h3 id="yaml_merge">Using YAML Merge</h3> + +<p> +Since version 2.0, H2O recognizes <a href="http://yaml.org/type/merge.html">Merge Key Language-Independent Type for YAML™ Version 1.1</a>. +Users can use the feature to merge an existing mapping against another. +The following example reuses the TLS configuration of <code>example.com</code> in <code>example.org</code>. +</p> + +<?= $ctx->{code}->(<< 'EOT') +hosts: + "example.com": + listen: + port: 443 + ssl: &default_ssl + minimum-version: TLSv1.2 + cipher-suite: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 + certificate-file: /path/to/example.com.crt + key-file: /path/to/example.com.crt + paths: + ... + "example.org": + listen: + port: 443 + ssl: + <<: *default_ssl + certificate-file: /path/to/example.org.crt + key-file: /path/to/example.org.crt + paths: + ... +EOT +?> + +<h3 id="including_files">Including Files</h3> + +<p> +Starting from version 2.1, it is possible to include a YAML file from the configuration file using <code>!file</code> custom YAML tag. +The following example extracts the TLS configuration into <code>default_ssl.conf</code> and include it multiple times in <code>h2o.conf</code>. +</p> + +<?= $ctx->{example}->('default_ssl.conf', << 'EOT') +minimum-version: TLSv1.2 +cipher-suite: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 +certificate-file: /path/to/example.com.crt +key-file: /path/to/example.com.crt +EOT +?> + +<?= $ctx->{example}->('h2o.conf', << 'EOT') +hosts: + "example.com": + listen: + port: 443 + ssl: !file default_ssl.conf + paths: + ... + "example.org": + listen: + port: 443 + ssl: + <<: !file default_ssl.conf + certificate-file: /path/to/example.org.crt + key-file: /path/to/example.org.crt + paths: + ... +EOT +?> + +? }) diff --git a/debian/vendor-h2o/srcdoc/configure/throttle_response_directives.mt b/debian/vendor-h2o/srcdoc/configure/throttle_response_directives.mt new file mode 100644 index 0000000..415c8af --- /dev/null +++ b/debian/vendor-h2o/srcdoc/configure/throttle_response_directives.mt @@ -0,0 +1,44 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Configure", "Throttle Response Directives")->(sub { + +<p> +The throttle response handler performs per response traffic throttling, when an <code>X-Traffic</code> header exists in the response headers. +</p> +<p> +The value of <code>X-Traffic</code> header should be an integer that represents the speed you want in bytes per second. This header CAN be set with <a href="configure/headers_directives.html#header.add"><code>header.add</code></a> so that traffic for static assets can also be easily throttled. +</p> +<p> +The following are the configuration directives recognized by the handler. +</p> + +<? +$ctx->{directive}->( + name => "throttle-response", + levels => [ qw(global host path extension) ], + default => "throttle-response: OFF", + since => '2.1', + desc => <<'EOT', +Enables traffic throttle per HTTP response. +EOT +)->(sub { +?> +<p> +If the argument is <code>ON</code>, the traffic per response is throttled as long as a legal <code>X-Traffic</code> header exists. +If the argument is <code>OFF</code>, traffic throttle per response is disabled. +</p> +<?= $ctx->{example}->('Enabling traffic throttle per response with static file configuration', <<'EOT') +# enable throttle +throttle-response: ON + +# an example host configuration that throttle traffic to ~100KB/s +hosts: + default: + paths: + /: + file.dir: /path/to/assets + header.add: "X-Traffic: 100000" +EOT +?> +? }) + +? }) diff --git a/debian/vendor-h2o/srcdoc/faq.mt b/debian/vendor-h2o/srcdoc/faq.mt new file mode 100644 index 0000000..72899e8 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/faq.mt @@ -0,0 +1,56 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Frequently Asked Questions")->(sub { + +<h3 id="license">What are the license terms?</h3> + +<div> +H2O is licensed under <a href="http://opensource.org/licenses/MIT">the MIT license</a>. +</div> +<div> +Portions of the software use following libraries that are also licensed under the MIT license: <a href="https://github.com/h2o/h2o/blob/master/deps/klib/khash.h">khash.h</a>, <a href="https://github.com/h2o/h2o/blob/master/deps/picohttpparser/">PicoHTTPParser</a>, <a href="https://github.com/h2o/h2o/blob/master/deps/yaml/">libyaml</a>. +</div> + +<div> +Depending on how H2O is configured, the software links against OpenSSL or LibreSSL, both of which are <a href="https://www.openssl.org/source/license.html">dual-licensed under the OpenSSL License and the original SSLeay license</a>. +</div> + +<h3 id="design-docs">Are there any design documents?</h3> + +<div> +Please refer to the main developer's <a href="http://www.slideshare.net/kazuho/h2o-20141103pptx" target="_blank">presentation slides</a> at the HTTP/2 conference, and <a href="http://blog.kazuhooku.com" target="_blank">his weblog</a>. +</div> + +<h3 id="libh2o">How do I use H2O as a library?</h3> + +<div> +<p> +Aside from the standalone server, H2O can also be used as a software library. +The name of the library is <code>libh2o</code>. +</p> +<p> +To build H2O as a library you will need to install the following dependencies: +<ul> +<li><a href="https://github.com/libuv/libuv/">libuv</a> version 1.0 or above</li> +<li><a href="https://www.openssl.org/">OpenSSL</a> version 1.0.2 or above<?= $ctx->{note}->(q{libh2o cannot be linked against the bundled LibreSSL; see <a href="https://github.com/h2o/h2o/issues/290">issue #290</a>}) ?></li> +</ul> +In case the dependencies are installed under a non-standard path, <code>PKG_CONFIG_PATH</code> configuration variable can be used for specifying their paths. For example, the following snippet builds <code>libh2o</code> using the libraries installed in their respective paths. +</p> + +<?= $ctx->{code}->(<< 'EOT') +% PKG_CONFIG_PATH=/usr/local/libuv-1.4/lib/pkgconfig:/usr/local/openssl-1.0.2a/lib/pkgconfig cmake . +% make libh2o +EOT +?> + +<p> +For more information, please refer to the <a href="https://github.com/h2o/h2o/labels/libh2o">GitHub issues tagged as libh2o</a>. +</p> +</div> + +<h3 id="issues">I have a problem. Where should I look for answers?</h3> + +<div> +Please refer to the <a href="https://github.com/h2o/h2o/labels/FAQ">GitHub issues tagged as FAQ</a>. +</div> + +? }) diff --git a/debian/vendor-h2o/srcdoc/index.mt b/debian/vendor-h2o/srcdoc/index.mt new file mode 100644 index 0000000..1d6f93d --- /dev/null +++ b/debian/vendor-h2o/srcdoc/index.mt @@ -0,0 +1,45 @@ +? my $note = $main::context->{note}; +? $_mt->wrapper_file("wrapper.mt")->(sub { + +<div style="margin-top: 3em;"> +<p> +H2O is a new generation HTTP server that <b>provides quicker response to users with less CPU utilization</b> when compared to older generation of web servers. +Designed from ground-up, the server takes full advantage of <a href="https://tools.ietf.org/html/rfc7540">HTTP/2</a> features including <a href="configure/http2_directives.html#prioritization">prioritized content serving</a> and <a href="configure/http2_directives.html#server-push">server push</a>, promising outstanding experience to the visitors of your web site. +<div align="center"> +<a href="assets/8mbps100msec-nginx195-h2o150.png" target="_blank"><img src="assets/8mbps100msec-nginx195-h2o150.png" width="333" height="250"></a> +<a href="assets/staticfile612-nginx1910-h2o170.png" target="_blank"><img src="assets/staticfile612-nginx1910-h2o170.png" width="200" height="250"></a> +</div> +Explanation of the benchmark charts can be found in the <a href="benchmarks.html">benchmarks</a> page. +<p> + +</p> +</div> + +<h3>Key Features</h3> + +<ul> +<li>HTTP/1.0, HTTP/1.1 +<li><a href="configure/http2_directives.html">HTTP/2</a> +<ul> +<li>full support for dependency and weight-based prioritization with <a href="configure/http2_directives.html#http2-reprioritize-blocking-assets">server-side tweaks</a></li> +<li><a href="configure/http2_directives.html#http2-casper">cache-aware server push</a></li> +</ul> +</li> +<li>TCP Fast Open +<li><a href="configure/base_directives.html#listen-ssl">TLS</a> +<ul> +<li>session resumption (standalone & memcached) +<li>session tickets with automatic key rollover +<li>automatic OCSP stapling +<li>forward secrecy & fast AEAD ciphers<?= $note->(q{chacha20-poly1305: see <a href="https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/">Do the ChaCha: better mobile performance with cryptography</a>}) ?></li> +<li><a href="configure/base_directives.html#neverbleed">private key protection using privilege separation</a> +</ul> +</li> +<li><a href="configure/file_directives.html">static file serving</a> +<li><a href="configure/fastcgi_directives.html">FastCGI</a> +<li><a href="configure/proxy_directives.html">reverse proxy</a> +<li><a href="configure/mruby.html">scriptable using mruby</a> (Rack-based) +<li>graceful restart and self-upgrade +</ul> + +? }) diff --git a/debian/vendor-h2o/srcdoc/install.mt b/debian/vendor-h2o/srcdoc/install.mt new file mode 100644 index 0000000..e2a3713 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/install.mt @@ -0,0 +1,121 @@ +? my $ctx = $main::context; +? $_mt->wrapper_file("wrapper.mt", "Install")->(sub { + +<h3 id="binary">Installing a Binary Package</h3> + +<p> +Thanks to others, H2O is provided as a binary package on some environments. +Therefore you may try to at first install the software using your favorite packaging system, and then resort to installing from source as described below. +</p> + +<p> +At the time being, following packages are known to be actively maintained<?= $ctx->{note}->(q{Please open a new issue on <a href="https://github.com/h2o/h2o">Github</a> if you want a new package to get added.}) ?>: +<ul> +<li><a href="http://portsmon.freebsd.org/portoverview.py?category=www&portname=h2o">FreeBSD</a></li> +<li><a href="http://brewformulas.org/H2o">Homebrew (OS X)</a></li> +<li><a href="https://github.com/tatsushid/h2o-rpm">RPM (Fedora, RHEL/CentOS, OpenSUSE)</a></li> +<li><a href="https://hub.docker.com/r/lkwg82/h2o-http2-server/">Docker Image</a></li> +</ul> +</p> + +<h3 id="from-source">Installing from Source</h3> + +<p> +Download a release version from <a href="https://github.com/h2o/h2o/releases">the releases page</a> or clone the master branch from <a href="https://github.com/h2o/h2o/">the source repository</a>, and build it using <a href="http://www.cmake.org/">CMake</a><?= $ctx->{note}->("CMake is a popular build tool that can be found as a binary package on most operating systems.") ?>. +</p> + +<?= $ctx->{code}->(<< 'EOT') +% cmake -DWITH_BUNDLED_SSL=on . +% make +% sudo make install +EOT +?> + +<p> +When complete, H2O will be installed under <code>/usr/local</code>. +</p> + +<p> +Start the installed server using the example configuration to confirm that it actually works (note: without the use of <code>-m</code> option the server runs as a foreground process; press <code>Ctrl-C</code> to stop). +</p> + +<?= $ctx->{code}->(<< 'EOT') +% /usr/local/bin/h2o -c examples/h2o/h2o.conf +EOT +?> + +<p> +The example configuration starts a server that listens to port 8080 (HTTP) and port 8081 (HTTPS). Try to access the ports using the protocols respectively (note: when accessing via HTTPS it is likely that you would see hostname mismatch errors reported by the web browsers). +</p> + +<p> +When complete, proceed to <a href="configure.html">Configure</a> section for how to setup the server. +</p> + +<h4>CMake Options</h4> + +<p> +Following list shows the interesting arguments recognized by CMake. + +<dl> +<dt><code>-DCMAKE_INSTALL_PREFIX=<i>directory</i></code></dt> +<dd> +This option specifies the directory to which H2O will be installed (default: <code>/usr/local</code>). +</dd> +<dt><code>-DWITH_BUNDLED_SSL=<i>on</i>|<i>off</i></code></dt> +<dd> +This option instructs whether or not to use <a href="http://www.libressl.org/">LibreSSL</a> being bundled (default: <code>off</code> if <a href="https://www.openssl.org/">OpenSSL</a> version >= 1.0.2 is found, <code>on</code> if otherwise). Read the section below for comparison between OpenSSL and LibreSSL. +</dd> +<dt><code>-DWITH_MRUBY=<i>on</i>|<i>off</i></code></dt> +<dd> +This option instructs whether or not to build the standalone server with support for <a href="configure/mruby.html">scripting using mruby</a>. +It is turned on by default if the prerequisites (<a href="https://www.gnu.org/software/bison/">bison</a>, <a href="https://www.ruby-lang.org/">ruby</a> and the development files<?= $ctx->{note}->(q{<code>mkmf</code> - a program for building ruby extensions is required. In many distributions, the program is packaged as part of <code>ruby-dev<code> or <code>ruby-devel</code> package.}) ?>) are found. +</dl> +</p> + +<h3>Installing from Source, using OpenSSL</h3> + +<p> +Generally speaking, we believe that using LibreSSL is a better choice for running H2O, since LibreSSL not only is considered to be more secure than OpenSSL but also provides support for new ciphersuites such as <code>chacha20-poly1305</code> which is the preferred method of Google Chrome<?= $ctx->{note}->(q{ref: <a href="https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/">Do the ChaCha: better mobile performance with cryptography</a>}) ?>. However, it is also true that LibreSSL is slower than OpenSSL on some benchmarks. So if you are interested in benchmark numbers, using OpenSSL is a reasonable choice. +</p> + +<p> +The difficulty in using OpenSSL is that the HTTP/2 specification requires the use of an extension to the TLS protocol named ALPN, which has only been supported since OpenSSL 1.0.2<?= $ctx->{note}->("It is possible to build H2O using prior versions of OpenSSL, but some (if not all) web browsers are known for not using HTTP/2 when connecting to servers configured as such.") ?>. Therefore it is highly likely that you would need to manually install or upgrade OpenSSL on your system. +</p> + +<p> +Once you have installed OpenSSL 1.0.2, it is possible to build H2O that links against the library. As an safeguard it is advised to use <code>-DWITH_BUNDLED_SSL</code> set to <code>off</code>, so that the server would not accidentally link against the bundled LibreSSL. +CMake will search for OpenSSL by looking at the default search paths. +</p> + +<?= $ctx->{code}->(<< 'EOT') +% cmake -DWITH_BUNDLED_SSL=off +% make +% sudo make install +EOT +?> + +<p> +Two ways exist to specify the directory in which CMake should search for OpenSSL. +The preferred approach is to use the <code>PKG_CONFIG_PATH</code> environment variable. +</p> + +<?= $ctx->{code}->(<< 'EOT') +% PKG_CONFIG_PATH=/usr/local/openssl-1.0.2/lib/pkgconfig cmake -DWITH_BUNDLED_SSL=off +% make +% sudo make install +EOT +?> + +<p> +In case your OpenSSL installation does not have the <code>lib/pkgconfig</code> directory, you may use <code>OPENSSL_ROOT_DIR</code> environment variable to specify the root directory of the OpenSSL being installed. However, it is likely that CMake version 3.1.2 or above is be required when using this approach<?= $ctx->{note}->(q{ref: <a href="https://github.com/h2o/h2o/issues/277">h2o issue #277</a>, <a href="http://public.kitware.com/Bug/view.php?id=15386">CMake issue 0015386</a>}) ?>. +</p> + +<?= $ctx->{code}->(<< 'EOT') +% OPENSSL_ROOT_DIR=/usr/local/openssl-1.0.2 cmake -DWITH_BUNDLED_SSL=off +% make +% sudo make install +EOT +?> + +? }) diff --git a/debian/vendor-h2o/srcdoc/snippets/directive.mt b/debian/vendor-h2o/srcdoc/snippets/directive.mt new file mode 100644 index 0000000..4b880f3 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/snippets/directive.mt @@ -0,0 +1,28 @@ +? my $ctx = $main::context; +? my ($content, $args) = @_; +<div id="<?= $args->{name} ?>" class="directive-head"> +? if ($args->{since}) { +<div class="directive-since">since v<?= $args->{since} ?></div> +? } +<h3><a href="<?= $ctx->{filename} ?>#<?= $args->{name} ?>"><code>"<?= $args->{name} ?>"</code></a></h3> +</div> + +<dl class="directive-desc"> +<dt>Description:</dt> +<dd> +<p> +<?= Text::MicroTemplate::encoded_string($args->{desc}) ?> +</p> +<?= $content ?> +</dd> +<dt><a href="configure/syntax_and_structure.html#config_levels">Level</a>:</dt> +<dd><?= join(", ", @{$args->{levels}}) ?></dd> +? if ($args->{default}) { +<dt>Default:</dt> +<dd><code><pre><?= $args->{default} ?></pre></code> +? } +? if ($args->{see_also}) { +<dt>See also:</dt> +<dd><?= $args->{see_also} ?></dd> +? } +</dl> diff --git a/debian/vendor-h2o/srcdoc/snippets/mruby_method.mt b/debian/vendor-h2o/srcdoc/snippets/mruby_method.mt new file mode 100644 index 0000000..c500589 --- /dev/null +++ b/debian/vendor-h2o/srcdoc/snippets/mruby_method.mt @@ -0,0 +1,33 @@ +? my $ctx = $main::context; +? my ($content, $args) = @_; +<div id="<?= $args->{name} ?>" class="mruby-method-head"> +? if ($args->{since}) { +<div class="mruby-method-since">since v<?= $args->{since} ?></div> +? } +<h3><a href="<?= $ctx->{filename} ?>#<?= $args->{name} ?>"><code>"<?= $args->{name} ?>"</code></a></h3> +</div> + +<dl class="mruby-method-desc"> +<dt>Description:</dt> +<dd> +<p> +<?= Text::MicroTemplate::encoded_string($args->{desc}) ?> +</p> +<?= $content ?> +</dd> +? if (@{$args->{params} || []}) { +<dt>Parameters:</dt> +<dd> +<dl class="mruby-method-parameters"> +? for my $param (@{ $args->{params} }) { + <dt><?= $param->{label} ?></dt> + <dd><?= $param->{desc} ?></dd> +? } +</dl> +</dd> +? } +? if ($args->{see_also}) { +<dt>See also:</dt> +<dd><?= $args->{see_also} ?></dd> +? } +</dl> diff --git a/debian/vendor-h2o/srcdoc/snippets/wrapper.mt b/debian/vendor-h2o/srcdoc/snippets/wrapper.mt new file mode 100644 index 0000000..86f551d --- /dev/null +++ b/debian/vendor-h2o/srcdoc/snippets/wrapper.mt @@ -0,0 +1,108 @@ +<? + +my ($content, @title) = @_; +my $ctx = $main::context; +my $create_tab = sub { + my ($fn, $tab_topic) = @_; + my $html; + my $cur_topic = $title[0] || 'Top'; + $cur_topic = "FAQ" + if $cur_topic eq 'Frequently Asked Questions'; + if ($cur_topic eq $tab_topic) { + $html = qq{<td class="selected">@{[Text::MicroTemplate::escape_html($tab_topic)]}</td>}; + } else { + $html = qq{<td><a href="@{[Text::MicroTemplate::escape_html($fn)]}">@{[Text::MicroTemplate::escape_html($tab_topic)]}</a></td>}; + } + Text::MicroTemplate::encoded_string($html); +}; + +?><!DOCTYPE html> +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> +<meta name="viewport" content="width=device-width,initial-scale=1,user-scalable=no" /> +? my $base = "../" x (scalar(split '/', $main::context->{filename}) - 1); +? if ($base ne '') { +<base href="<?= $base ?>" /> +? } + +<!-- oktavia --> +<link rel="stylesheet" href="assets/searchstyle.css" type="text/css" /> +<script src="search/jquery-1.9.1.min.js"></script> +<script src="search/oktavia-jquery-ui.js"></script> +<script src="search/oktavia-english-search.js"></script> +<!-- /oktavia --> + +<link rel="stylesheet" href="assets/style.css" type="text/css" /> + +<title><?= join " - ", ($ctx->{filename} ne 'index.html' ? reverse @title : ()), "H2O - the optimized HTTP/2 server" ?></title> +</head> +<body> +<div id="body"> +<div id="top"> + +<h1> +<a href="index.html">H2O</a> +</h1> +<p class="description">the optimized HTTP/1.x, HTTP/2 server</p> + +<!-- oktavia --> +<form id="searchform"> +<input class="search" type="search" name="search" id="search" results="5" value="" placeholder="Search" /> +<div id="searchresult_box"> +<div id="close_search_box">×</div> +<div id="searchresult_summary"></div> +<div id="searchresult"></div> +<div id="searchresult_nav"></div> +<span class="pr">Powered by <a href="https://github.com/shibukawa/oktavia">Oktavia</a></span> +</div> +</form> +<!-- /oktavia --> + +</div> + +<table id="menu"> +<tr> +<?= $create_tab->("index.html", "Top") ?> +<?= $create_tab->("install.html", "Install") ?> +<?= $create_tab->("configure.html", "Configure") ?> +<?= $create_tab->("faq.html", "FAQ") ?> +<td><a href="http://blog.kazuhooku.com/search/label/H2O" target="_blank">Blog</a></td> +<td><a href="http://github.com/h2o/h2o/" target="_blank">Source</a></td> +</tr> +</table> + +<div id="main"> + +? if (@title) { +<h2> +? if (@title > 1) { +? for (my $i = 0; $i < @title - 1; $i++) { +<a href="<?= lc $title[$i] ?>.html"><?= $title[$i] ?></a> > +? } +? } +<?= $title[-1] ?> +</h2> +? } + +?= $content + +? if (my @notes = @{$ctx->{notes}}) { +<div class="notes"> +<h3>Notes:</h3> +<ol> +? for (my $index = 0; $index < @notes; ++$index) { +<li id="note_<?= $index + 1 ?>"><?= $notes[$index] ?></li> +? } +</ol> +</div> +? } + +</div> +<div id="footer"> +<p> +Copyright © 2015 <a href="http://dena.com/intl/">DeNA Co., Ltd.</a> et al. +</p> +</div> +</body> +</html> |