OpenResty 最近发布的正式版本 1.17.8.2 修复了安全漏洞 CVE-2020-11724。这个漏洞是一个 HTTP request smuggling 漏洞，可以实现某种程度上的安全防护绕过。

一种简单粗暴但却被普遍使用的方案，就是每个进程划分属于自己的 list 类型的 shdict key，每隔一段时间查看是否有新消息。这种方式优点在于实现简单，缺点在于难以保证实时性。当然对于绝大多数需要进程间通讯的场景，每 0.1 起一个 timer 来处理新增消息已经足够了。毕竟 0.1 秒的延迟不算长，每秒起 10 个 timer 开销...

另外，如果你没用 OpenResty 自己的 LuaJIT 分支，那么可以直接关掉这个页面了，因为这些 break change 只有在使用了 OpenResty 自己的 LuaJIT 分支才会出现。

如果你用 OpenResty 做过 SSL session reuse，你可能会用到其中的异步获取 SSL session 的特性，比如在 ssl_session_fetch_by_lua* 里面发起非阻塞的网络请求，从 memcache 或别的什么存储服务器上读取 SSL session。ssl_session_fetch_by_lua* 的实现原理，就是在 OpenSSL 的 session get callback 里执行 Lua 代码。然...

编写正确且高效的应用，最为关键是一系列软件工程上的实践，像测试、code review、灰度、监控、压测等等。不过由于这是 OpenResty 大会上的演讲，我会专注于讲讲 OpenResty 和 LuaJIT 的一些小细节，帮助各位听众避免线上踩坑。

还有一笔账值得一算：调用 Lua CFunction 会迫使 LuaJIT 退回到解释模式，而通过 FFI 调用 C 函数则不会。所以不能光计算 FFI 的开销，还要看因为不用 FFI，导致 Lua 代码无法被编译掉的损耗。在代码中大量调用 Lua CFunction，会使得 LuaJIT 的 JIT tracing 变得支离破碎。即使因为 stitch 的缘故，让剩余的部分能够被...

对 C 语言良好的亲和力，一直是 Lua 的优势之一。LuaJIT 在传统的 Lua C API 之外，额外提供 FFI 的方式来调用 C 函数，更是大大提升了跟 C 交互的便利度。甚至有这么一种说法，虽然 LuaJIT 命名是 Lua + JIT，但是好多人是冲着 FFI 去用 LuaJIT 的。[1]

今年的 OpenResty Con 在北京举行，考虑到路途过于遥远，我决定看直播。虽然参与的方式变了，但我依旧跟去年一样，趁着记忆还算清晰写了篇文章，算是“路边社”的新闻稿吧。

lua-resty-core 是 OpenResty 组件的一部分。它由两部分组成，一部分是 resty.core.*，提供了对 lua-nginx-module Lua 接口的替换实现；另一部分是 ngx.*，OpenResty 新的接口一般都会放到这里。跟其他 lua-resty 开头的库一样，lua-resty-core 也是用 Lua 实现的。说到这有人可能会问，既然 lua-nginx-module 已经有了...

有些时候，我们需要通过 Lua 代码操作 Nginx 里面的某些状态，但是想要的 API 并不存在于 OpenResty 之内。这时候，可以选择编写一个 Nginx C 模块，然后暴露出可供 Lua 调用的接口。本文中，我们会分别探讨，如何通过 Nginx 变量或 FFI 的方式去提供 Lua 调用得到的接口。

注意：本文中列出的所有代码只是 Proof Of Concept，基本上都没有进行错误处理。另外对于一些边际情况，也可能没有考虑清楚。所以对于直接复制文中代码到项目中所造成的一切后果，请自负责任。

先看一则示例： {代码...} 拜 Lua 内部实现上的细节所赐，如果传递的数组中带有 nil 值空洞，# 操作符返回的数值并不能反映真实的大小。 直接引用 Lua 5.1 manual 上的说法（Lua 5.2 和 LuaJIT 也是一样的定义）： [链接] The Length Operator The length of a table t is defined to be any integer index n such that ...

先重温下 Lua 里的真值与假值：除了 nil 和 false 为假，其他值都是真。“其他值”这个概念包括0、空字符串、空表，等等。在 Lua 里，通常使用 and 和 or 作为逻辑操作符。比如 true and false 返回 false，而 false or true 返回 true。

我昨天参加了在深圳举办的 OpenResty Con 2016，趁着周末有空记录下与会过程，作为路边社的一篇报道。由于内容基于会上的笔记和事后的回忆，读起来会显得琐碎，具体细节可能会有些出入。

结论： body_filter_by_lua* 可能在一次请求中调用多次，跟响应数据量无关，取决于响应次数 body_filter_by_lua* 的最后一次调用时，ngx.arg[1] 一般为空字符串 body_filter_by_lua* 也会在 subrequest 之中调用 body_filter_by_lua* 有些时候离不开有 header_filter_by_lua* 辅佐 多次调用的 body_filter_by_lua* 正如 ...

在 OpenResty 中使用正则表达式，社区中推荐的做法是使用ngx.re api。比如匹配一个字符串是否为 http(s) 的链接，可以这么写：

无测试，不编码。有持续运行的单元测试，是保持项目健康最基本的要求。在多人协作的内部项目中，这一点尤其重要。基于 OpenResty 的项目开发自然不会例外。

对于 Nginx Amplify 不了解的同学，可以搜索一下，在 Nginx 官网上有介绍。简单来说，就是你可以在服务器上安装一个开源的 Python 写的 Agent。这个 Agent 会上传你的 Nginx 实例各种运行时数据到 Nginx.inc 的（闭源）SAAS平台上。通过这个 SAAS 平台，Nginx.inc 可以替你提供诸如配置检查和优化、监控、报警等功能。