HanadaLee / openresty

A High Performance Web Server and CDN Cache Server Based on Nginx and LuaJIT

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Name

OpenResty - A High Performance Web Server and CDN Cache Server Based on Nginx and LuaJIT

This image adds luarocks, more patches, modules or lua libraries to the original OpenResty bundle (https://github.com/openresty/openresty).

This bundle is maintained by Hanada (im@hanada.info)

Table of Contents

Description

OpenResty is a full-fledged web application server by bundling the standard nginx core, lots of 3rd-party nginx modules, as well as most of their external dependencies.

This bundle is maintained by Hanada (im@hanada.info), and the original OpenResty bundle is maintained by Yichun Zhang (agentzh).

The bundled software components are copyrighted by the respective copyright holders.

Back to TOC

Components of original OpenResty bundule

Below lists all the components bundled in original OpenResty.

Most of the components are enabled by default, but some are not.

DrizzleNginxModule, PostgresNginxModule, and IconvNginxModule are not enabled by default. You need to specify the --with-http_drizzle_module, --with-http_postgres_module, and --with-http_iconv_module options, respectively, to enable them while building OpenResty.

Before the 1.5.8.1 release, the standard Lua 5.1 interpreter is enabled by default while LuaJIT 2.x is not. So for earlier releases, you need to explicitly specify the --with-luajit option (which is the default for 1.5.8.1+) to use LuaJIT 2.x.

Since the 1.15.8.1 release, the standard Lua 5.1 interpreter is not supported anymore. It is vividly recommended to use OpenResty's branch of LuaJIT (already bundled and enabled by default in OpenResty releases since 1.5.8.1). This fork is regularly synchronized with the upstream LuaJIT repository, receives timely fixes, and implements additional features proper to OpenResty.

Back to TOC

Extra components of current OpenResty bundule

Listed below are all components currently bundled additionally with OpenResty. These components are bundled by Hanada.

Back to TOC

Additional Features

In additional to the standard nginx core features, this bundle also supports the following:

Back to TOC

resolv.conf parsing

syntax: resolver address ... [valid=time] [ipv6=on|off] [local=on|off|path];

default: -

context: http, stream, server, location

Similar to the resolver directive in standard nginx core with additional support for parsing additional resolvers from the resolv.conf file format.

When local=on, the standard path of /etc/resolv.conf will be used. You may also specify arbitrary path to be used for parsing, for example: local=/tmp/test.conf.

When local=off, parsing will be disabled (this is the default).

This feature is not available on Windows platforms.

Back to TOC

syntax: slice_allow_methods GET | HEAD ...;

default: slice_allow_methods GET HEAD;

context: http, server, location

Allow splitting responses into slices if the client request method is listed in this directive. Note that if the slice directive is unset or has the zero value, splitting the response into slices will still be disabled.

  • Syntax: slice_check_etag on | off;

  • Default: slice_check_etag on;

  • Context: http, server, location

Whether to check the consistency of the Etag header in the slice. If it is enabled, the request will be terminated and an error will be reported when Etag mismatch in slice response occurs.

  • Syntax: slice_check_last_modified on | off;

  • Default: slice_check_last_modified off;

  • Context: http, server, location

Whether to check the consistency of the Last-Modified header in the slice. If it is enabled, the request will be terminated and an error will be reported when Last-Modified mismatch in slice response occurs.

Back to TOC

  • Syntax: sub_filter_bypass string ...;

  • Default:

  • Context: http, server, location

Defines conditions under which the response will not be replaced. If at least one value of the string parameters is not empty and is not equal to “0” then the response will not be replaced.

sub_filter_bypass $cookie_nocache $arg_nocache$arg_comment;
sub_filter_bypass $http_pragma    $http_authorization;

Back to TOC

syntax: listen address[:port] [ssl] [https_allow_http] ...;

default: *listen *:80 | :8000;

context: server

When both the ssl and https_allow_http parameters are enabled for the listen directive, both https or http requests will be allowed. This patch comes from Tengine.

Back to TOC

Start each connection with small records (1369 byte default, change with ssl_dyn_rec_size_lo).

After a given number of records (40, change with ssl_dyn_rec_threshold) start sending larger records (4229, ssl_dyn_rec_size_hi).

Eventually after the same number of records, start sending the largest records (ssl_buffer_size).

In case the connection idles for a given amount of time (1s, ssl_dyn_rec_timeout), the process repeats itself (i.e. begin sending small records again).

  • syntax: ssl_dyn_rec_enable bool

  • default: off

  • context: http, server

  • syntax: ssl_dyn_rec_timeout number

  • default: 1000

  • context: http, server

We want the initial records to fit into one TCP segment so we don't get TCP HoL blocking due to TCP Slow Start.

A connection always starts with small records, but after a given amount of records sent, we make the records larger to reduce header overhead.

After a connection has idled for a given timeout, begin the process from the start. The actual parameters are configurable. If ssl_dyn_rec_timeout is 0, we assume ssl_dyn_rec is off.

  • syntax: ssl_dyn_rec_size_lo number

  • default: 1369

  • context: http, server

Default sizes for the dynamic record sizes are defined to fit maximal TLS + IPv6 overhead in a single TCP segment for lo and 3 segments for hi: 1369 = 1500 - 40 (IP) - 20 (TCP) - 10 (Time) - 61 (Max TLS overhead)

  • syntax: ssl_dyn_rec_size_hi number

  • default: 4229

  • context: http, server

4229 = (1500 - 40 - 20 - 10) * 3 - 61

  • syntax: ssl_dyn_rec_threshold number

  • default: 40

  • context: http, server

Back to TOC

Copyright & License

The bundle itself is licensed under the 2-clause BSD license. See LICENSE for details.

About

A High Performance Web Server and CDN Cache Server Based on Nginx and LuaJIT

License:Other


Languages

Language:Dockerfile 100.0%