wrapper/nginx-sid
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

http-lua: Upgrade to 0.10.15

Browse source
This commit is contained in:
Christos Trochalakis 2019-09-09 17:32:06 +03:00
parent 85ba845433
commit 132704ab76
153 changed files with 9493 additions and 1866 deletions
Download patch file Download diff file Expand all files Collapse all files

213
debian/modules/http-lua/doc/HttpLuaModule.wiki vendored
View file

@ -2,6 +2,8 @@
ngx_http_lua_module - Embed the power of Lua into Nginx HTTP Servers.
This module is a core component of OpenResty. If you are using this module, then you are essentially using OpenResty :)
''This module is not distributed with the Nginx source.'' See [[#Installation|the installation instructions]].
= Status =
@ -10,7 +12,7 @@ Production ready.
= Version =
This document describes ngx_lua [https://github.com/openresty/lua-nginx-module/tags v0.10.13] released on 22 April 2018.
This document describes ngx_lua [https://github.com/openresty/lua-nginx-module/tags v0.10.15] released on March 14th, 2019.
= Synopsis =
<geshi lang="nginx">
@ -130,7 +132,9 @@ This document describes ngx_lua [https://github.com/openresty/lua-nginx-module/t
= Description =
This module embeds Lua, via the standard Lua 5.1 interpreter or [http://luajit.org/luajit.html LuaJIT 2.0/2.1], into Nginx and by leveraging Nginx's subrequests, allows the integration of the powerful Lua threads (Lua coroutines) into the Nginx event model.
This module is a core component of OpenResty. If you are using this module, then you are essentially using OpenResty :)
This module embeds Lua, via [http://luajit.org/luajit.html LuaJIT 2.0/2.1], into Nginx and by leveraging Nginx's subrequests, allows the integration of the powerful Lua threads (Lua coroutines) into the Nginx event model.
Unlike [https://httpd.apache.org/docs/trunk/mod/mod_lua.html Apache's mod_lua] and [http://redmine.lighttpd.net/wiki/1/Docs:ModMagnet Lighttpd's mod_magnet], Lua code executed using this module can be ''100% non-blocking'' on network traffic as long as the [[#Nginx API for Lua|Nginx API for Lua]] provided by this module is used to handle
requests to upstream services such as MySQL, PostgreSQL, Memcached, Redis, or upstream HTTP web services.
@ -199,11 +203,11 @@ Nginx cores older than 1.6.0 (exclusive) are *not* supported.
= Installation =
It is *highly* recommended to use [http://openresty.org OpenResty releases] which integrate Nginx, ngx_lua, LuaJIT 2.1, as well as other powerful companion Nginx modules and Lua libraries. It is discouraged to build this module with nginx yourself since it is tricky to set up exactly right. Also, the stock nginx cores have various limitations and long standing bugs that can make some of this modules' features become disabled, not work properly, or run slower. The same applies to LuaJIT as well. OpenResty includes its own version of LuaJIT which gets specifically optimized and enhanced for the OpenResty environment.
It is *highly* recommended to use [http://openresty.org OpenResty releases] which integrate Nginx, ngx_lua, OpenResty's LuaJIT 2.1 branch version, as well as other powerful companion Nginx modules and Lua libraries. It is discouraged to build this module with nginx yourself since it is tricky to set up exactly right. Also, the stock nginx cores have various limitations and long standing bugs that can make some of this modules' features become disabled, not work properly, or run slower. The same applies to LuaJIT as well. OpenResty includes its own version of LuaJIT which gets specifically optimized and enhanced for the OpenResty environment.
Alternatively, ngx_lua can be manually compiled into Nginx:
# Install LuaJIT 2.0 or 2.1 (recommended) or Lua 5.1 (Lua 5.2 is ''not'' supported yet). LuaJIT can be downloaded from the [http://luajit.org/download.html LuaJIT project website] and Lua 5.1, from the [http://www.lua.org/ Lua project website]. Some distribution package managers also distribute LuaJIT and/or Lua.
# LuaJIT can be downloaded from the [https://github.com/openresty/luajit2/releases latest release of OpenResty's LuaJIT branch version]. The official LuaJIT 2.0 and 2.1 releases are also supported, although the performance will be significantly lower in many cases.
# Download the latest version of the ngx_devel_kit (NDK) module [https://github.com/simplresty/ngx_devel_kit/tags HERE].
# Download the latest version of ngx_lua [https://github.com/openresty/lua-nginx-module/tags HERE].
# Download the latest version of Nginx [http://nginx.org/ HERE] (See [[#Nginx Compatibility|Nginx Compatibility]])
@ -271,24 +275,6 @@ To enable one or more of these macros, just pass extra C compiler options to the
./configure --with-cc-opt="-DNGX_LUA_USE_ASSERT -DNGX_LUA_ABORT_AT_PANIC"
</geshi>
== Installation on Ubuntu 11.10 ==
Note that it is recommended to use LuaJIT 2.0 or LuaJIT 2.1 instead of the standard Lua 5.1 interpreter wherever possible.
If the standard Lua 5.1 interpreter is required however, run the following command to install it from the Ubuntu repository:
<geshi lang="bash">
apt-get install -y lua5.1 liblua5.1-0 liblua5.1-0-dev
</geshi>
Everything should be installed correctly, except for one small tweak.
Library name <code>liblua.so</code> has been changed in liblua5.1 package, it only comes with <code>liblua5.1.so</code>, which needs to be symlinked to <code>/usr/lib</code> so it could be found during the configuration process.
<geshi lang="bash">
ln -s /usr/lib/x86_64-linux-gnu/liblua5.1.so /usr/lib/liblua.so
</geshi>
= Community =
== English Mailing List ==
@ -314,7 +300,7 @@ Please submit bug reports, wishlists, or patches by
As from the <code>v0.5.0rc32</code> release, all <code>*_by_lua_file</code> configure directives (such as [[#content_by_lua_file|content_by_lua_file]]) support loading Lua 5.1 and LuaJIT 2.0/2.1 raw bytecode files directly.
Please note that the bytecode format used by LuaJIT 2.0/2.1 is not compatible with that used by the standard Lua 5.1 interpreter. So if using LuaJIT 2.0/2.1 with ngx_lua, LuaJIT compatible bytecode files must be generated as shown:
Please note that the bytecode format used by LuaJIT 2.0/2.1 is not compatible with that used by the standard Lua 5.1 interpreter. So if you are using LuaJIT 2.0/2.1 with ngx_lua, LuaJIT compatible bytecode files must be generated as shown:
<geshi lang="bash">
/path/to/luajit/bin/luajit -b /path/to/input_file.lua /path/to/output_file.ljbc
@ -332,18 +318,6 @@ http://luajit.org/running.html#opt_b
Also, the bytecode files generated by LuaJIT 2.1 is ''not'' compatible with LuaJIT 2.0, and vice versa. The support for LuaJIT 2.1 bytecode was first added in ngx_lua v0.9.3.
Similarly, if using the standard Lua 5.1 interpreter with ngx_lua, Lua compatible bytecode files must be generated using the <code>luac</code> commandline utility as shown:
<geshi lang="bash">
luac -o /path/to/output_file.luac /path/to/input_file.lua
</geshi>
Unlike as with LuaJIT, debug information is included in standard Lua 5.1 bytecode files by default. This can be striped out by specifying the <code>-s</code> option as shown:
<geshi lang="bash">
luac -s -o /path/to/output_file.luac /path/to/input_file.lua
</geshi>
Attempts to load standard Lua 5.1 bytecode files into ngx_lua instances linked to LuaJIT 2.0/2.1 or vice versa, will result in an error message, such as that below, being logged into the Nginx <code>error.log</code> file:
<geshi lang="text">
@ -510,8 +484,7 @@ However, later attempts to manipulate the cosocket object will fail and return t
This issue is due to limitations in the Nginx event model and only appears to affect Mac OS X.
== Lua Coroutine Yielding/Resuming ==
* Because Lua's <code>dofile</code> and <code>require</code> builtins are currently implemented as C functions in both Lua 5.1 and LuaJIT 2.0/2.1, if the Lua file being loaded by <code>dofile</code> or <code>require</code> invokes [[#ngx.location.capture|ngx.location.capture*]], [[#ngx.exec|ngx.exec]], [[#ngx.exit|ngx.exit]], or other API functions requiring yielding in the *top-level* scope of the Lua file, then the Lua error "attempt to yield across C-call boundary" will be raised. To avoid this, put these calls requiring yielding into your own Lua functions in the Lua file instead of the top-level scope of the file.
* As the standard Lua 5.1 interpreter's VM is not fully resumable, the methods [[#ngx.location.capture|ngx.location.capture]], [[#ngx.location.capture_multi|ngx.location.capture_multi]], [[#ngx.redirect|ngx.redirect]], [[#ngx.exec|ngx.exec]], and [[#ngx.exit|ngx.exit]] cannot be used within the context of a Lua [http://www.lua.org/manual/5.1/manual.html#pdf-pcall pcall()] or [http://www.lua.org/manual/5.1/manual.html#pdf-xpcall xpcall()] or even the first line of the <code>for ... in ...</code> statement when the standard Lua 5.1 interpreter is used and the <code>attempt to yield across metamethod/C-call boundary</code> error will be produced. Please use LuaJIT 2.x, which supports a fully resumable VM, to avoid this.
* Because Lua's <code>dofile</code> and <code>require</code> builtins are currently implemented as C functions in LuaJIT 2.0/2.1, if the Lua file being loaded by <code>dofile</code> or <code>require</code> invokes [[#ngx.location.capture|ngx.location.capture*]], [[#ngx.exec|ngx.exec]], [[#ngx.exit|ngx.exit]], or other API functions requiring yielding in the *top-level* scope of the Lua file, then the Lua error "attempt to yield across C-call boundary" will be raised. To avoid this, put these calls requiring yielding into your own Lua functions in the Lua file instead of the top-level scope of the file.
== Lua Variable Scope ==
Care must be taken when importing modules and this form should be used:
@ -817,7 +790,7 @@ This module is licensed under the BSD license.
Copyright (C) 2009-2017, by Xiaozhe Wang (chaoslawful) <chaoslawful@gmail.com>.
Copyright (C) 2009-2018, by Yichun "agentzh" Zhang (章亦春) <agentzh@gmail.com>, OpenResty Inc.
Copyright (C) 2009-2019, by Yichun "agentzh" Zhang (章亦春) <agentzh@gmail.com>, OpenResty Inc.
All rights reserved.
@ -862,6 +835,34 @@ how the result will be used. Below is a diagram showing the order in which direc
![Lua Nginx Modules Directives](https://cloud.githubusercontent.com/assets/2137369/15272097/77d1c09e-1a37-11e6-97ef-d9767035fc3e.png)
== lua_load_resty_core ==
'''syntax:''' ''lua_load_resty_core on|off''
'''default:''' ''lua_load_resty_core on''
'''context:''' ''http''
Controls whether the <code>resty.core</code> module (from
[https://github.com/openresty/lua-resty-core lua-resty-core]) should be loaded
or not. When enabled, this directive is equivalent to executing the following
when the Lua VM is created:
<geshi lang="lua">
require "resty.core"
</geshi>
Note that usage of the <code>resty.core</code> module is recommended, as its
FFI implementation is both faster, safer, and more complete than the Lua C API
of the ngx_lua module.
It must also be noted that the Lua C API of the ngx_lua module will eventually
be removed, and usage of the FFI-based API (i.e. the <code>resty.core</code>
module) will become mandatory. This directive only aims at providing a
temporary backwards-compatibility mode in case of edge-cases.
This directive was first introduced in the <code>v0.10.15</code> release.
== lua_capture_error_log ==
'''syntax:''' ''lua_capture_error_log size''
@ -2196,14 +2197,14 @@ SSL session resumption can then get immediately initiated and bypass the full SS
Please note that TLS session tickets are very different and it is the clients' responsibility
to cache the SSL session state when session tickets are used. SSL session resumptions based on
TLS session tickets would happen automatically without going through this hook (nor the
[[#ssl_session_store_by_lua*|ssl_session_store_by_lua_block]] hook). This hook is mainly
[[#ssl_session_store_by_lua_block|ssl_session_store_by_lua*]] hook). This hook is mainly
for older or less capable SSL clients that can only do SSL sessions by session IDs.
When [[#ssl_certificate_by_lua_block|ssl_certificate_by_lua*]] is specified at the same time,
this hook usually runs before [[#ssl_certificate_by_lua_block|ssl_certificate_by_lua*]].
When the SSL session is found and successfully loaded for the current SSL connection,
SSL session resumption will happen and thus bypass the [[#ssl_certificate_by_lua_block|ssl_certificate_by_lua*]]
hook completely. In this case, NGINX also bypasses the [[#ssl_session_store_by_lua*|ssl_session_store_by_lua_block]]
hook completely. In this case, NGINX also bypasses the [[#ssl_session_store_by_lua_block|ssl_session_store_by_lua*]]
hook, for obvious reasons.
To easily test this hook locally with a modern web browser, you can temporarily put the following line
@ -2626,6 +2627,20 @@ When exceeding this limit, Nginx will stop running the callbacks of newly expire
This directive was first introduced in the <code>v0.8.0</code> release.
== lua_sa_restart ==
'''syntax:''' ''lua_sa_restart on|off''
'''default:''' ''lua_sa_restart on''
'''context:''' ''http''
When enabled, this module will set the `SA_RESTART` flag on nginx workers signal dispositions.
This allows Lua I/O primitives to not be interrupted by nginx's handling of various signals.
This directive was first introduced in the <code>v0.10.14</code> release.
= Nginx API for Lua =
<!-- inline-toc -->
@ -3563,7 +3578,7 @@ This method does not work in HTTP/2 requests yet.
== ngx.req.get_method ==
'''syntax:''' ''method_name = ngx.req.get_method()''
'''context:''' ''set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, balancer_by_lua*''
'''context:''' ''set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, balancer_by_lua*, log_by_lua*''
Retrieves the current request's request method name. Strings like <code>"GET"</code> and <code>"POST"</code> are returned instead of numerical [[#HTTP method constants|method constants]].
@ -4071,7 +4086,7 @@ This function returns <code>nil</code> if
# the request body has been read into disk temporary files,
# or the request body has zero size.
If the request body has not been read yet, call [[#ngx.req.read_body|ngx.req.read_body]] first (or turned on [[#lua_need_request_body|lua_need_request_body]] to force this module to read the request body. This is not recommended however).
If the request body has not been read yet, call [[#ngx.req.read_body|ngx.req.read_body]] first (or turn on [[#lua_need_request_body|lua_need_request_body]] to force this module to read the request body. This is not recommended however).
If the request body has been read into disk files, try calling the [[#ngx.req.get_body_file|ngx.req.get_body_file]] function instead.
@ -4092,7 +4107,7 @@ Retrieves the file name for the in-file request body data. Returns <code>nil</co
The returned file is read only and is usually cleaned up by Nginx's memory pool. It should not be manually modified, renamed, or removed in Lua code.
If the request body has not been read yet, call [[#ngx.req.read_body|ngx.req.read_body]] first (or turned on [[#lua_need_request_body|lua_need_request_body]] to force this module to read the request body. This is not recommended however).
If the request body has not been read yet, call [[#ngx.req.read_body|ngx.req.read_body]] first (or turn on [[#lua_need_request_body|lua_need_request_body]] to force this module to read the request body. This is not recommended however).
If the request body has been read into memory, try calling the [[#ngx.req.get_body_data|ngx.req.get_body_data]] function instead.
@ -4109,7 +4124,9 @@ See also [[#ngx.req.get_body_data|ngx.req.get_body_data]].
Set the current request's request body using the in-memory data specified by the <code>data</code> argument.
If the current request's request body has not been read, then it will be properly discarded. When the current request's request body has been read into memory or buffered into a disk file, then the old request body's memory will be freed or the disk file will be cleaned up immediately, respectively.
If the request body has not been read yet, call [[#ngx.req.read_body|ngx.req.read_body]] first (or turn on [[#lua_need_request_body|lua_need_request_body]] to force this module to read the request body. This is not recommended however). Additionally, the request body must not have been previously discarded by [[#ngx.req.discard_body|ngx.req.discard_body]].
Whether the previous request body has been read into memory or buffered into a disk file, it will be freed or the disk file will be cleaned up immediately, respectively.
This function was first introduced in the <code>v0.3.1rc18</code> release.
@ -4122,11 +4139,13 @@ See also [[#ngx.req.set_body_file|ngx.req.set_body_file]].
Set the current request's request body using the in-file data specified by the <code>file_name</code> argument.
If the request body has not been read yet, call [[#ngx.req.read_body|ngx.req.read_body]] first (or turn on [[#lua_need_request_body|lua_need_request_body]] to force this module to read the request body. This is not recommended however). Additionally, the request body must not have been previously discarded by [[#ngx.req.discard_body|ngx.req.discard_body]].
If the optional <code>auto_clean</code> argument is given a <code>true</code> value, then this file will be removed at request completion or the next time this function or [[#ngx.req.set_body_data|ngx.req.set_body_data]] are called in the same request. The <code>auto_clean</code> is default to <code>false</code>.
Please ensure that the file specified by the <code>file_name</code> argument exists and is readable by an Nginx worker process by setting its permission properly to avoid Lua exception errors.
If the current request's request body has not been read, then it will be properly discarded. When the current request's request body has been read into memory or buffered into a disk file, then the old request body's memory will be freed or the disk file will be cleaned up immediately, respectively.
Whether the previous request body has been read into memory or buffered into a disk file, it will be freed or the disk file will be cleaned up immediately, respectively.
This function was first introduced in the <code>v0.3.1rc18</code> release.
@ -5648,7 +5667,7 @@ See also [[#ngx.shared.DICT.flush_expired|ngx.shared.DICT.flush_expired]] and [[
Flushes out the expired items in the dictionary, up to the maximal number specified by the optional <code>max_count</code> argument. When the <code>max_count</code> argument is given <code>0</code> or not given at all, then it means unlimited. Returns the number of items that have actually been flushed.
Unlike the [[#ngx.shared.DICT.flush_all|flush_all]] method, this method actually free up the memory used by the expired items.
Unlike the [[#ngx.shared.DICT.flush_all|flush_all]] method, this method actually frees up the memory used by the expired items.
This feature was first introduced in the <code>v0.6.3</code> release.
@ -5894,6 +5913,7 @@ Creates and returns a TCP or stream-oriented unix domain socket object (also kno
* [[#tcpsock:settimeout|settimeout]]
* [[#tcpsock:settimeouts|settimeouts]]
* [[#tcpsock:setoption|setoption]]
* [[#tcpsock:receiveany|receiveany]]
* [[#tcpsock:receiveuntil|receiveuntil]]
* [[#tcpsock:setkeepalive|setkeepalive]]
* [[#tcpsock:getreusedtimes|getreusedtimes]]
@ -5991,6 +6011,43 @@ An optional Lua table can be specified as the last argument to this method to sp
* <code>pool</code>
: specify a custom name for the connection pool being used. If omitted, then the connection pool name will be generated from the string template <code>"<host>:<port>"</code> or <code>"<unix-socket-path>"</code>.
* <code>pool_size</code>
: specify the size of the connection pool. If omitted and no
: <code>backlog</code> option was provided, no pool will be created. If omitted
: but <code>backlog</code> was provided, the pool will be created with a default
: size equal to the value of the [[#lua_socket_pool_size|lua_socket_pool_size]]
: directive.
: The connection pool holds up to <code>pool_size</code> alive connections
: ready to be reused by subsequent calls to [[#tcpsock:connect|connect]], but
: note that there is no upper limit to the total number of opened connections
: outside of the pool. If you need to restrict the total number of opened
: connections, specify the <code>backlog</code> option.
: When the connection pool would exceed its size limit, the least recently used
: (kept-alive) connection already in the pool will be closed to make room for
: the current connection.
: Note that the cosocket connection pool is per Nginx worker process rather
: than per Nginx server instance, so the size limit specified here also applies
: to every single Nginx worker process. Also note that the size of the connection
: pool cannot be changed once it has been created.
: This option was first introduced in the <code>v0.10.14</code> release.
* <code>backlog</code>
: if specified, this module will limit the total number of opened connections
: for this pool. No more connections than <code>pool_size</code> can be opened
: for this pool at any time. If the connection pool is full, subsequent
: connect operations will be queued into a queue equal to this option's
: value (the "backlog" queue).
: If the number of queued connect operations is equal to <code>backlog</code>,
: subsequent connect operations will fail and return <code>nil</code> plus the
: error string <code>"too many waiting connect operations"</code>.
: The queued connect operations will be resumed once the number of connections
: in the pool is less than <code>pool_size</code>.
: The queued connect operation will abort once they have been queued for more
: than <code>connect_timeout</code>, controlled by
: [[#tcpsock:settimeouts|settimeouts]], and will return <code>nil</code> plus
: the error string <code>"timeout"</code>.
: This option was first introduced in the <code>v0.10.14</code> release.
The support for the options table argument was first introduced in the <code>v0.5.7</code> release.
This method was first introduced in the <code>v0.5.0rc1</code> release.
@ -6103,6 +6160,36 @@ Since the <code>v0.8.8</code> release, this method no longer automatically close
This feature was first introduced in the <code>v0.5.0rc1</code> release.
== tcpsock:receiveany ==
'''syntax:''' ''data, err = tcpsock:receiveany(max)''
'''context:''' ''rewrite_by_lua*, access_by_lua*, content_by_lua*, ngx.timer.*, ssl_certificate_by_lua*, ssl_session_fetch_by_lua*''
Returns any data received by the connected socket, at most <code>max</code> bytes.
This method is a synchronous operation just like the [[#tcpsock:send|send]] method and is 100% nonblocking.
In case of success, it returns the data received; in case of error, it returns <code>nil</code> with a string describing the error.
If the received data is more than this size, this method will return with exactly this size of data.
The remaining data in the underlying receive buffer could be returned in the next reading operation.
Timeout for the reading operation is controlled by the [[#lua_socket_read_timeout|lua_socket_read_timeout]] config directive and the [[#tcpsock:settimeouts|settimeouts]] method. And the latter takes priority. For example:
<geshi lang="lua">
sock:settimeouts(1000, 1000, 1000) -- one second timeout for connect/read/write
local data, err = sock:receiveany(10 * 1024 * 1024) -- read any data, at most 10K
if not data then
ngx.say("failed to read any data: ", err)
return
end
ngx.say("successfully read: ", data)
</geshi>
This method doesn't automatically close the current connection when the read timeout error occurs. For other connection errors, this method always automatically closes the connection.
This feature was first introduced in the <code>v0.10.14</code> release.
== tcpsock:receiveuntil ==
'''syntax:''' ''iterator = tcpsock:receiveuntil(pattern, options?)''
@ -6255,13 +6342,31 @@ Puts the current socket's connection immediately into the cosocket built-in conn
The first optional argument, <code>timeout</code>, can be used to specify the maximal idle timeout (in milliseconds) for the current connection. If omitted, the default setting in the [[#lua_socket_keepalive_timeout|lua_socket_keepalive_timeout]] config directive will be used. If the <code>0</code> value is given, then the timeout interval is unlimited.
The second optional argument, <code>size</code>, can be used to specify the maximal number of connections allowed in the connection pool for the current server (i.e., the current host-port pair or the unix domain socket file path). Note that the size of the connection pool cannot be changed once the pool is created. When this argument is omitted, the default setting in the [[#lua_socket_pool_size|lua_socket_pool_size]] config directive will be used.
When the connection pool exceeds the available size limit, the least recently used (idle) connection already in the pool will be closed to make room for the current connection.
Note that the cosocket connection pool is per Nginx worker process rather than per Nginx server instance, so the size limit specified here also applies to every single Nginx worker process.
Idle connections in the pool will be monitored for any exceptional events like connection abortion or unexpected incoming data on the line, in which cases the connection in question will be closed and removed from the pool.
The second optional argument <code>size</code> is considered deprecated since
the <code>v0.10.14</code> release of this module, in favor of the
<code>pool_size</code> option of the [[#tcpsock:connect|connect]] method.
Since the <code>v0.10.14</code> release, this option will only take effect if
the call to [[#tcpsock:connect|connect]] did not already create a connection
pool.
When this option takes effect (no connection pool was previously created by
[[#tcpsock:connect|connect]]), it will specify the size of the connection pool,
and create it.
If omitted (and no pool was previously created), the default size is the value
of the [[#lua_socket_pool_size|lua_socket_pool_size]] directive.
The connection pool holds up to <code>size</code> alive connections ready to be
reused by subsequent calls to [[#tcpsock:connect|connect]], but note that there
is no upper limit to the total number of opened connections outside of the
pool.
When the connection pool would exceed its size limit, the least recently used
(kept-alive) connection already in the pool will be closed to make room for
the current connection.
Note that the cosocket connection pool is per Nginx worker process rather
than per Nginx server instance, so the size limit specified here also applies
to every single Nginx worker process. Also note that the size of the connection
pool cannot be changed once it has been created.
If you need to restrict the total number of opened connections, specify both
the <code>pool_size</code> and <code>backlog</code> option in the call to
[[#tcpsock:connect|connect]].
In case of success, this method returns <code>1</code>; otherwise, it returns <code>nil</code> and a string describing the error.
@ -6950,7 +7055,7 @@ This Lua module does not ship with this ngx_lua module itself rather it is shipp
the
[https://github.com/openresty/lua-resty-core lua-resty-core] library.
Please refer to the [https://github.com/openresty/lua-resty-core/blob/ocsp-cert-by-lua-2/lib/ngx/ocsp.md documentation]
Please refer to the [https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/ocsp.md documentation]
for this <code>ngx.ocsp</code> Lua module for more details.
This feature requires at least ngx_lua <code>v0.10.0</code>.