diff options
Diffstat (limited to '')
| -rw-r--r-- | debian/vendor-h2o/srcdoc/configure/mruby.mt | 199 |
1 files changed, 199 insertions, 0 deletions
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 +?> + +? }) |