Ngx_openresty mainline version released

Hello folks!

I am pleased to announce that the new mainline version of
ngx_openresty,, is now released:

Special thanks go to all the contributors for making this happen!

Below is the complete change log for this release, as compared to the
last (mainline) release,

  • upgraded the Nginx core to 1.4.3.

  • upgraded LuaNginxModule to 0.9.1.

    • feature: added the new configuration directive
      “lua_use_default_type” for controlling whether to send out a
      default “Content-Type” response header (as defined by the
      default_type directive). default on. thanks aviramc for the

    • feature: now the raw request cosocket returned by
      ngx.req.socket(true) no longer requires the request body to
      be read already, which means that one can use this cosocket
      to read the raw request body data as well. thanks aviramc
      for the original patch.

    • bugfix: when there were no existing “Cache-Control” response
      headers, “ngx.header.cache_control = nil” would
      (incorrectly) create a new “Cache-Control” header with an
      empty value. thanks jinglong for the patch.

    • bugfix: the original letter-case of the header name was lost
      when creating the “Cache-Control” response header via the
      ngx.header.HEADER API.

    • bugfix: ngx.req.set_header(“Host”, value) would overwrite
      the value of $host with bad values. thanks aviramc for the

    • bugfix: use of ngx.exit() to abort pending subrequests in
      other “light threads” might lead to segfault or request hang
      when HTTP 1.0 full buffering is in effect.

    • bugfix: removing a request header might lead to memory
      corruptions. thanks Bjørnar Ness for the report.

    • bugfix: reading ngx.status might get different values than
      $status. thanks Kevin Burke for the report.

    • bugfix: downstream write events might interfere with
      upstream cosockets that are slow to write to. thanks Aviram
      Cohen for the report.

    • bugfix: the bookkeeping state for already-freed user threads
      might be incorrectly used by newly-created threads that were
      completely different, which could lead to bad results.
      thanks Sam Lawrence for the report.

    • bugfix: calling ngx.thread.wait() on a user thread object
      that is already waited (i.e., already dead) would hang
      forever. thanks Sam Lawrence for the report.

    • bugfix: the alert “zero size buf” could be logged when
      assigning an empty Lua string ("") to “ngx.arg[1]” in

    • bugfix: subrequests initiated by ngx.location.capture* could
      trigger unnecessary response header sending actions in the
      subrequest because our capturing output header filter did
      not set “r->header_sent”.

    • bugfix: the Lua error message for the case that ngx.sleep()
      was used in log_by_lua* was not friendly. thanks Jiale Zhi
      for the report.

    • bugfix: now ngx.req.socket(true) returns proper error when
      there is some other “light thread” reading the request body.

    • bugfix: header_filter_by_lua*, body_filter_by_lua*, and
      ngx.location.capture* might not work properly with multiple
      “http {}” blocks in “nginx.conf”. thanks flygoast for the

    • optimize: made and faster for
      LuaJIT 2.x when there is no submatch captures.

    • optimize: pre-allocate space for the Lua tables in various

    • doc: fixed the context for the lua_package_path and
      lua_package_cpath directives. thanks duhoobo for the report.

  • upgraded HeadersMoreNginxModule to 0.23.

    • bugfix: removing request headers via
      more_clear_input_headers might lead to memory corruptions.

    • bugfix: more_set_input_headers might overwrite the value of
      the $host variable with bad values.

    • bugfix: more_set_headers and more_clear_headers might not
      work when multiple “http {}” blocks were used in

    • bugfix: eliminated use of C global variables during
      configuration phase because it might lead to issues when HUP
      reload failed.

  • upgraded SrcacheNginxModule to 0.23.

    • bugfix: this module might not work properly with multiple
      “http {}” blocks in “nginx.conf”.

    • bugfix: we might (incorrectly) return 500 in our output

    • bugfix: we did not set “r->header_sent” when we want to
      discard the header in our header filter.

  • upgraded RdsJsonNginxModule to 0.12.

    • bugfix: in case of multiple “http {}” blocks in
      “nginx.conf”, our output filters might be disabled even when
      this module is configured properly.

    • bugix: we did not check the “NULL” pointer returned by an
      Nginx array element allocation.

  • upgraded RdsCsvNginxModule to 0.05.

    • optimize: we now only register our output filters when this
      module is indeed used (the only exception is when multiple
      “http {}” blocks are used).
  • upgraded XssNginxModule to 0.04.

    • optimize: we now only register our output filters when this
      module is indeed used (the only exception is when multiple
      “http {}” blocks are used).
  • upgraded EchoNginxModule to 0.49.

    • bugfix: echo_before_body and echo_after_body might now work
      properly when multiple “http {}” blocks were used in
  • upgraded LuaRestyRedisLibrary to 0.17.

    • optimize: added an optional argument “n” to init_pipeline()
      as a hint for the number of pipelined commands.

    • optimize: use LuaJIT 2.1’s new primitive to
      pre-allocate space for Lua tables.

  • upgraded LuaRestyUploadLibrary to 0.09.

    • bugfix: removed use of the module() function to prevent bad

    • optimize: Removed use of lua tables and table.concat() for
      simple one-line Lua string concatenations.

  • upgraded LuaRestyMySQLLibrary to 0.14.

    • bugfix: avoided using Lua 5.1’s module() function for
      defining our Lua modules because it has bad side effects.

    • optimize: added an optional new argument “nrows” to the
      query() and read_result() methods, which can speed up things
      a bit.

    • optimize: use LuaJIT v2.1’s new API to optimize
      Lua table allocations. when is missing, just fall
      back to the good old “{}” constructor. this gives 12%
      overall speed-up for a typical result set with 500 rows when
      LuaJIT 2.1 is used.

    • optimize: eliminated use of table.insert() because it is
      slower than “tb[#tb + 1] = val”.

    • optimize: switched over to the multi-argument form of

    • optimize: no longer use Lua tables and table.concat() to
      construct simple query strings.

  • upgraded LuaRestyWebSocketLibrary to 0.02.

    • optimize: use LuaJIT 2.1’s to preallocate space
      for Lua tables, eliminating the overhead of Lua table
  • feature: applied the proxy_host_port_vars patch to the Nginx
    core to make $proxy_host and $proxy_port accessible for dynamic
    languages like Lua and Perl.

  • bugfix: applied the gzip_flush_bug patch to the Nginx core to
    fix request hang caused by the ngx_gzip and ngx_gunzip modules
    when using ngx.flush(true), for example. Thanks Maxim D. for
    the review.

  • bugfix: applied the cache_lock_hang_in_subreq patch to the Nginx
    core to fix the request hang when using proxy_cache_lock in
    subrequests and the cache lock timeout happens.

  • bugfix: backported Maxim D.'s patch to fix an issue in the
    ngx_gzip module: it did not clear “r->connection->buffered” when
    the pending data was already flushed out. this could hang
    LuaNginxModule’s ngx.flush(true) call, for example.

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

OpenResty (aka. ngx_openresty) is a full-fledged web application
server by bundling the standard Nginx core, lots of 3rd-party Nginx
modules and Lua libraries, as well as most of their external
dependencies. See OpenResty’s homepage for details:

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:


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs