nginx lua api解读

本文主要解读下nginx lua module的主要方法和api。

ngx_lua运行阶段

initialization phase

  • init_by_lua 用在http模块,常用于全局变量的申请
  • init_worker_by_lua 在每个nginx worker进程启动时调用指定的lua代码

rewrite / access phase

  • set_by_lua: 设置一个变量,计算变量供后续使用
  • rewrite_by_lua 可替代HttpRewriteModule的rewrite指令来使用的,优先级低于rewrite指令
  • access_by_lua 可以用来修改请求参数

content phase

  • content_by_lua 由ngx返回内容,而不走proxied后端
  • header_filter_by_lua 可以用来修改后端response的header
  • body_filter_by_lua 一般会在一次请求中被调用多次, 因为这是实现基于 HTTP 1.1 chunked 编码的所谓“流式输出”的。

log phase

  • log_by_lua 在请求结束的时候运行,可以做些统计工作

nginx api for lua

ngx.cookie_time

ngx.cookie_time(ngx.time() + 60 * 30) — 设置Cookie过期时间为30分钟

ngx.ctx

当前请求的上下文

ngx.decode_args

decode为table

local decoded_uri=ngx.decode_args("arg1=day1&arg2= monday");
print_t(decoded_uri);
function print_t(t)
    for k, v in pairs(t) do
        if type(v) == table then
            ngx.say(k, ": ", table.concat(v), "<br/>");
        else
            ngx.say(k, ": ", v, "<br/>");
        end
    end
end

ngx.encode_args

将table编码为表单提交格式,a1=arg1&a2=arg2

ngx.say("encode args ", ngx.encode_args({a1="arg1", a2="arg2"}), "<br/>");

ngx.eof

标识response结束,ngx.eof()只是结束响应流的输出,中断HTTP连接,后面的代码逻辑还会继续在服务端执行

ngx.req.read_body()
local uri_args = ngx.req.get_uri_args(1)
ngx.say(cjson.encode{result="refuse"})
ngx.eof()

ngx.escape_uri

uri编码

local fileName = "专辑列表.csv"
ngx.header.content_type = "text/csv;charset=utf-8"
ngx.header["Content-disposition"] = "attachment;filename=" .. ngx.escape_uri(fileName)

ngx.exec

内部重定向

location /foo {
    content_by_lua '
        return ngx.exec('/some-location', 'a=3&b=5&c=6');
    ';
}

ngx.exit

当传入的status >= 200(200即为ngx.HTTP_OK),ngx.exit() 会中断当前请求,并将传入的状态码(status)返回给nginx。

当传入的status == 0(0即为ngx.OK)则 ngx.exit() 会中断当前执行的phrase(ngx-lua模块处理请求的阶段,如content_by_lua*),进而继续执行下面的phrase。

对于 ngx.exit() 需要进一步注意的是参数status的使用,status可以传入ngx-lua所定义的所有的HTTP状态码常量(如:ngx.HTTP_OK、ngx.HTTP_GONE、ngx.HTTP_INTERNAL_SERVER_ERROR等)和两个ngx-lua模块内核常量(只支持NGX_OK和NGX_ERROR这两个,如果传入其他的如ngx.AGAIN等则进程hang住)。

文档中推荐的 ngx.exit() 最佳实践是同 return 语句组合使用,目的在于增强请求被终止的语义(return ngx.exit(…))。

if not ngx.var.arg_token then
        ngx.log(ngx.ERR, "Unauthorized")
        return ngx.exit(ngx.HTTP_UNAUTHORIZED)
end

配合使用return,增强退出语义,防止出错

ngx.flush

ngx.say("Hello, Lua!")
ngx.flush(true)

设置为true的话,则ngx.print或者ngx.say的内容等写入send buffer之后才返回

ngx.get_phase

返回当前的处理阶段,init, init_worker, ssl_cert, set, rewrite, balancer, access, content, header_filter, body_filter, log, or timer这几个之一

ngx.http_time

ngx.header['Content-Type']  = 'application/json; charset=utf-8';
ngx.header['Expires']       = ngx.http_time( ngx.time() + max_age );
ngx.say(ngx.http_time(1290079655))
-- yields "Thu, 18 Nov 2010 11:27:35 GMT"

ngx.is_subrequest

如果是subrequest则返回true

ngx.localtime

从NGINX’s cache中返回yyyy-mm-dd hh:mm:ss格式的时间

ngx.location.capture

用于子请求,返回: status, header, body, and truncated (a Boolean to represent if the body is truncated).

ngx.log

第一个参数是log基本(one of ngx.STDERR, ngx.EMERG, ngx.ALERT,ngx.CRIT, ngx.ERR, ngx.WARN, ngx.NOTICE, ngx.INFO, and ngx.DEBUG) 后续可以接多个参数来打印log

ngx.now

从NGINX’s cache返回epoch time以来的毫秒数 ngx.now() 是有误差的,因为使用了nginx 自身的时间缓存。对于精度要求较高的计时,应使用下面的调用序列:

ngx.update_time()
local now = ngx.now()

值得一提的是,ngx.now() 只有毫秒精度。

ngx.parse_http_time

 local time = ngx.parse_http_time("Thu, 18 Nov 2010 11:27:35 GMT")
 if time == nil then
     ...
 end

ngx.print

打印到response body.

ngx.say

打印到response body并换行

ngx.status

http status状态码

ngx.time

从nginx cached返回epoch time以来的秒数(no syscall involved unlike Lua’s date library).

ngx.today

从NGINX’s cache返回当前日期,格式 yyyy-mm-dd

ngx.unescape_uri

ngx.say(ngx.unescape_uri("b%20r56+7"))
-- 返回b r56 7

ngx.update_time

更新NGINX’s time cache

ngx.utctime

从NGINX’s cache返回UTC time,格式yyyy-mm-dd hh:mm:ss

doc

  • nginx基本配置与参数说明
  • nginx配置文件说明
  • nginx与lua的执行顺序和步骤说明
  • ngx_lua用例说明
  • ngx_lua 模块
  • lua-nginx-module模块里ngx_lua的所有指令以及可用ngx所有方法
  • 由一条OpenResty Error log谈谈ngx.exit与ngx.eof的区别
  • ngx_Lua模块中的重定向

本文分享自微信公众号 - 码匠的流水账(geek_luandun)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-01-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • nginx lua重置请求参数及常量备忘

    codecraft
  • 频繁GC (Allocation Failure)及young gc时间过长分析

    本文主要分析一个频繁GC (Allocation Failure)及young gc时间过长的case。

    codecraft
  • 聊聊golang的zap的encoder

    Encoder接口内嵌了ObjectEncoder,定义了Clone、EncodeEntry方法;ObjectEncoder接口定义了各种类型的一系列Add方法...

    codecraft
  • nginx1.17.9源码分析之管理配置的结构体(1)

    之前对nginx0.1.0版本进行了部分代码的分析,接下来的时间,打算以最新版的源码为基础,重新开始分析nginx的实现。这是第一篇。

    theanarkh
  • 高并发服务器的设计--架构与瓶颈的设计

    做架构设计,难免有时候被人问及系统的瓶颈在哪,那首先来了解下什么是瓶颈? 打个形象的比方,人的嘴巴可以吞下一整个面包,但是却咽不下去,因为食管不给力,它比较细,...

    李海彬
  • 从nginx1.17.9源码理解nginx -s reload

    使用nginx的时候,我们经常会使用nginx -s reload命令重启。下面我们就分析一下,执行这个命令的时候,nginx里发生了什么?我们从nginx的m...

    theanarkh
  • nginx的timeout(基于nginx1.17.9)

    nginx中使用timeout的地方非常多,本文主要分析客户端和nginx通信时涉及到的几个timeout。

    theanarkh
  • nginx0.1.0之event模块初始化源码分析(3)

    前面已经分析了event初始化的整体流程和第一步create_conf,接下来看一下第二步ngx_conf_parse。这里不分析该函数的代码,该函数主要是遍历...

    theanarkh
  • Nginx vs Envoy vs Mosn 平滑升级原理解析

    本文适合对 Nginx 实现原理比较感兴趣的同学阅读,需要具备一定的网络编程知识。

    poslua
  • nginx1.17.9源码分析之线程池

    我们发现事件驱动的软件都得配一个线程池。libuv和nginx都是。因为事件驱动的软件是单线程。但是有些事情总会引起线程阻塞。所以这个事情就不能放到主线程里做。...

    theanarkh

扫码关注云+社区

领取腾讯云代金券