[ANN] OpenResty 1.13.6.1 released

agentzh · 2017-11-14T03:39:18+00:00

Beautiful :) Works like a charm. Thank you.On Tuesday, November 14, 2017 at 3:00:37 AM UTC+1, tokers wrote:Hi!I think a transigent approach may can help you,...

[ANN] OpenResty 1.13.6.1 released

agentzh

Hi there,

I am excited to announce the new formal release, 1.13.6.1, of the
OpenResty web platform based on NGINX and LuaJIT:

https://openresty.org/en/download.html

Both the (portable) source code distribution, the Win32 binary
distribution, and the pre-built binary Linux packages for all those
common Linux distributions are provided on this Download page.

Special thanks go to all our developers and contributors! And thanks
OpenResty Inc. for sponsoring a lot of the OpenResty core development
work.

We have the following highlights in this release:

1. Based on the latest mainline nginx core 1.13.6.

2. Included new component ngx_stream_lua_module which can do nginx TCP
servers with Lua:

https://github.com/openresty/stream-lua-nginx-module#readme

3. New ttl(), expire(), free_space(), and capacity() Lua methods for
lua_shared_dict objects:

https://github.com/openresty/lua-nginx-module/#ngxshareddictttl

4. New resty.limit.count module in lua-resty-limit-traffic for doing
GitHub API style limiting:

https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/count.md#readme

5. Added JIT controlling command-line options to the resty command-line utility:

https://github.com/openresty/resty-cli#synopsis

6. Wildcard support in the more_clear_input_headers directive:

https://github.com/openresty/headers-more-nginx-module/#more_clear_headers

7. HTTP/2 support in the opm client tool (through curl).

The complete change log since the last (formal) release, 1.11.2.5:

* upgraded the Nginx core to 1.13.6.

* see the changes here: http://nginx.org/en/CHANGES

* bundled the new component, ngx_stream_lua_module 0.0.4, which is
also enabled by default. One can disable this 3rd-party Nginx C
module by passing "--without-stream_lua_module" to the
"./configure" script. We provide compatible Lua API with ngx_lua
wherever it makes sense. Currently we support content_by_lua*,
preread_by_lua* (similar to ngx_lua's access_by_lua* ),
log_by_lua*, and balancer_by_lua* in the stream subsystem.
thanks Mashape Inc. for sponsoring the OpenResty Inc. team to do
the development work on rewriting ngx_stream_lua for recent
nginx core version.

* change: applied a patch to the nginx core to make sure the
"server" header in HTTP/2 response shows "openresty" when the
"server_tokens" diretive is turned off.

* feature: added nginx core patches needed
by(https://github.com/openresty/stream-lua-nginx-module)/'s
balancer_by_lua*.

* win32: upgraded PCRE to 8.41.

* upgraded ngx_lua to 0.10.11.

* feature: shdict: added pure C API for getting free page size
and total capacity for lua-resty-core. thanks Hiroaki
Nakamura for the patch.

* feature: added pure C functions for shdict:ttl() and
shdict:expire() API functions. thanks Thibault Charbonnier
for the patch.

* bugfix: *_by_lua_block directives might break nginx config
dump ("-T" switch). thanks Oleg A. Mamontov for the patch.

* bugfix: segmentation faults might happen when pipelined http
requests are used in the downsteram connection. thanks Gao
Yan for the report.

* bugfix: the ssl connections might be drained and reused
prematurely when ssl_certificate_by_lua* or
ssl_session_fetch_by_lua* were used. this might lead to
segmentation faults under load. thanks guanglinlv for the
report and the original patch.

* bugfix: tcpsock:connect(): when the nginx resolver's
"send()" immediately fails without yielding, we didn't clean
up the coroutine ctx state properly. This might lead to
segmentation faults. thanks xiaocang for the report and root
for the patch.

* bugfix: added fallthrough comment to silence GCC 7's
"-Wimplicit-fallthrough". thanks Andriy Kornatskyy for the
report and spacewander for the patch.

* bugfix: tcpsock:settimeout, tcpsock:settimeouts: throws an
error when the timeout argument values overflow. Here we
only support timeout values no greater than the max value of
a 32 bits integer. thanks spacewander for the patch.

* doc: added "413 Request Entity Too Large" to the possible
short circuit response list. thanks Datong Sun for the
patch.

* upgraded lua-resty-core to 0.1.13.

* feature: ngx.balancer now supports the ngx_stream_lua; also
disabled all the other FFI APIs for the stream subsystem for
now.

* feature: resty.core.shdict: added new methods
shdict:free_space() and shdict:capacity(). thanks Hiroaki
Nakamura for the patch.

* feature: implemented the ngx.re.gmatch function with FFI.
thanks spacewander for the patch.

* bugfix: ngx.re: fix an edge-case where re.split() might not
destroy compiled regexes. thanks Thibault Charbonnier for
the patch.

* feature: implemented the shdict:ttl() and shdict:expire()
API functions using FFI.

* upgraded lua-resty-dns to 0.20.

* feature: allows "RRTYPE" values larger than 255. thanks
Peter Wu for the patch.

* upgraded lua-resty-limit-traffic to 0.05.

* feature: added new module resty.limit.count for GitHub API
style request count limiting. thanks Ke Zhu for the original
patch and Ming Wen for the followup tweaks.

* bugfix: resty.limit.traffic: we might not uncommit previous
limiters if a limiter got rejected while committing a state.
thanks Thibault Charbonnier for the patch.

* bugfix: resty.limit.conn: we incorrectly specified the
exceeded connection count as the initial value for the
shdict key decrement which may lead to dead locks when the
key has been evicted in very busy systems. thanks bug had
appeared in v0.04.

* upgraded resty-cli to 0.20.

* feature: resty: impelented the "-j off" option to turn off
the JIT compiler.

* feature: resty: implemented the "-j v" and "-j dump" options
similar to luajit's.

* feature: resty: added new command-line option "-l LIB" to
mimic lua and luajit -l parameter. thanks Michal Cichra for
the patch.

* bugfix: resty: handle "SIGPIPE" ourselves by simply killing
the process. thanks Ingy dot Net for the report.

* bugfix: resty: hot looping Lua scripts failed to respond to
the "INT" signal.

* upgraded opm to 0.0.4.

* bugfix: opm: when curl uses HTTP/2 by default opm would
complain about "bad response status line received". thanks
Donal Byrne and Andrew Redden for the report.

* debug: opm: added more details in the "bad response status
line received from server" error.

* upgraded ngx_headers_more to 0.33.

* feature: add wildcard match support for
more_clear_input_headers.

* doc: fixed more_clear_input_headers usage examples. thanks
Daniel Paniagua for the patch.

* upgraded ngx_encrypted_session to 0.07.

* bugfix: fixed one potential memory leak in an error
condition. thanks dyu for the patch.

* upgraded ngx_rds_json to 0.15.

* bugfix: fixed warnings with C compilers without variadic
macro support.

* doc: added context info for all the config directives.

* upgraded ngx_rds_csv to 0.08.

* tests: varous changes in the test suite.

* upgraded LuaJIT to v2.1-20171103:
https://github.com/openresty/luajit2/tags

* optimize: use more appressive JIT compiler parameters as the
default to help large OpenResty Lua apps. We now use the
following jit.opt defaults: "maxtrace=8000 maxrecord=16000
minstitch=3 maxmcode=40960 -- in KB".

* imported Mike Pall's latest changes:

* "LJ_GC64": Make "ASMREF_L" references 64 bit.

* "LJ_GC64": Fix ir_khash for non-string GCobj.

* DynASM/x86: Fix potential "REL_A" overflow. Thanks to
Joshua Haberman.

* MIPS64: Hide internal function.

* x64/"LJ_GC64": Fix type-check-only variant of SLOAD.
Thanks to Peter Cawley.

* PPC: Add soft-float support to JIT compiler backend.
Contributed by Djordje Kovacevic and Stefan Pejic from
RT-RK.com. Sponsored by Cisco Systems, Inc.

* x64/"LJ_GC64": Fix fallback case of "asm_fuseloadk64()".
Contributed by Peter Cawley.

The HTML version of the change log with lots of helpful hyper-links
can be browsed here:

https://openresty.org/en/changelog-1013006.html

OpenResty is a full-fledged web platform
by bundling the standard Nginx core, Lua/LuaJIT, lots of
3rd-party Nginx modules and Lua libraries, as well as most of their external
dependencies. See OpenResty's homepage for details:

https://openresty.org/

We have run extensive testing on our Amazon EC2 test cluster and
ensured that all the components (including the Nginx core) play well
together. The latest test report can always be found here:

https://qa.openresty.org/

We also always run our OpenResty Edge commercial software based on the
latest open source version of OpenResty in our own global CDN network
(dubbed "mini CDN") powering our openresty.org and openresty.com
websites. See https://openresty.com/ for more details.

Have fun!

Best regards,
Yichun
---
President & CEO of OpenResty Inc.

jonathan

FYI, there is no info on the openresty website about what version the current packages are built with.

it looks like everything is current, so I can migrate from my source version to a binary on this upload -- but it would be nice to actually list the versions for the packages on the site.

agentzh

Hello!

OpenResty's official binary packages are updated upon every formal
release. So I don't think it needs the trouble to always list the
package versions on the web site. If the binary packages are not
built, please file an issue here:

https://github.com/openresty/openresty-packaging/issues

Thanks!

Best regards,
Yichun

On Tue, Feb 13, 2018 at 11:14 PM,  <jon...@findmeon.com> wrote:
> FYI, there is no info on the openresty website about what version the
> current packages are built with.
>
> it looks like everything is current, so I can migrate from my source version
> to a binary on this upload -- but  it would be nice to actually list the
> versions for the packages on the site..

thibaultcha

I was thinking recently of contributing something like:

  ngx.get_deps_versions()

Which would return a table containing the version of each dependencycurrently bundled/in the LUA_PATH/LUA_CPATH environment(NGINX/ngx_lua/lua-resty-core/lua-resty-lrucache/lua-resty-redis, etc...).


On top of this, we can add a resty-cli flag, like so:

  resty --versions

Which would consume this API and output a nice list on stdout of whatthe users can expect from their current OpenResty installation, as in:


  $ resty --versions
  nginx core: 1.13.6
  ngx_lua: v0.10.12rc
  resty-core: v0.1.14rc1
  ...

There could probably be better names for both this API and the resty-cliflag.

This would be particularly useful for developers when reading themodule's APIs documentation stating things like: "this API wasintroduced in release x.y.z of this module".


I sometimes do this manually like so:

resty -e 'print("NGINX: ", ngx.config.nginx_version, "\nngx_lua: ",ngx.config.ngx_lua_version, "\nlua-resty-core: ",require("resty.core").version)'


But this would make this more obvious and natural to users.

Is this a stupid idea?

Thibault

On 2/15/18 11:43 AM, Yichun Zhang (agentzh) wrote:

Hello!

OpenResty's official binary packages are updated upon every formal
release. So I don't think it needs the trouble to always list the
package versions on the web site. If the binary packages are not
built, please file an issue here:

https://github.com/openresty/openresty-packaging/issues

Thanks!

Best regards,
Yichun

On Tue, Feb 13, 2018 at 11:14 PM,  <jon...@findmeon.com> wrote:

FYI, there is no info on the openresty website about what version the
current packages are built with.

it looks like everything is current, so I can migrate from my source version
to a binary on this upload -- but  it would be nice to actually list the
versions for the packages on the site..

agentzh

Hi Thibault,

Seems like this can easily be done by a Lua (opm) module library
instead? It does not have to be in the core, it seems.

Regards,
Yichun

On Thu, Feb 15, 2018 at 11:52 AM, Thibault Charbonnier
<thiba...@fastmail.com> wrote:
> I was thinking recently of contributing something like:
>
>   ngx.get_deps_versions()
>
> Which would return a table containing the version of each dependency
> currently bundled/in the LUA_PATH/LUA_CPATH environment
> (NGINX/ngx_lua/lua-resty-core/lua-resty-lrucache/lua-resty-redis, etc...).
>
> On top of this, we can add a resty-cli flag, like so:
>
>   resty --versions
>
> Which would consume this API and output a nice list on stdout of what the
> users can expect from their current OpenResty installation, as in:
>
>   $ resty --versions
>   nginx core: 1.13.6
>   ngx_lua: v0.10.12rc
>   resty-core: v0.1.14rc1
>   ...
>
> There could probably be better names for both this API and the resty-cli
> flag.
>
> This would be particularly useful for developers when reading the module's
> APIs documentation stating things like: "this API was introduced in release
> x.y.z of this module".
>
> I sometimes do this manually like so:
>
> resty -e 'print("NGINX: ", ngx.config.nginx_version, "\nngx_lua: ",
> ngx.config.ngx_lua_version, "\nlua-resty-core: ",
> require("resty.core").version)'
>
> But this would make this more obvious and natural to users.
>
> Is this a stupid idea?
>
> Thibault
>
>
> On 2/15/18 11:43 AM, Yichun Zhang (agentzh) wrote:
>>
>> Hello!
>>
>> OpenResty's official binary packages are updated upon every formal
>> release. So I don't think it needs the trouble to always list the
>> package versions on the web site. If the binary packages are not
>> built, please file an issue here:
>>
>> https://github.com/openresty/openresty-packaging/issues
>>
>> Thanks!
>>
>> Best regards,
>> Yichun
>>
>> On Tue, Feb 13, 2018 at 11:14 PM,  <jon...@findmeon.com> wrote:
>>>
>>> FYI, there is no info on the openresty website about what version the
>>> current packages are built with.
>>>
>>> it looks like everything is current, so I can migrate from my source
>>> version
>>> to a binary on this upload -- but  it would be nice to actually list the
>>> versions for the packages on the site..

thibaultcha

On 2/17/18 12:37 PM, Yichun Zhang (agentzh) wrote:

Hi Thibault,

Seems like this can easily be done by a Lua (opm) module library
instead? It does not have to be in the core, it seems.

As often, I am only looking at easing OpenResty development and providedevelopers with more tools to build on top of it, hence why the coresuggestion. But I can understand the maintenance burden :)


I will leave this for someone else to implement!

Best,
Thibault