1、增加http 和 stream的连接管理，比如可以实现长连接的关闭等
2、在worker阶段访问数据库等不用timer实现的方式。
3、区分是or自身返回或后端业务返回的HTTP状态码，比如后端返回502或自身返回的502。
4、在SSL阶段增加更多的接口，比如SSL套件设置等。
5、新增动态监听http或 stream端口
6、ngx.location.capture支持更改请求header，以替代resty.http支持负载均衡。

增加动态设置日志级别的功能

去掉timer的功能限制, 至少在worker init之后去掉timer的限制, 可以使用capture等功能.

目前我的做法是发起一个请求到自己, 然后在这个请求里无限循环执行周期任务然后sleep, 以实现一个无限制的timer.
官方应该能更优雅的实现吧, 不用这么hack.

lua entry thread aborted: runtime error: /usr/local/openresty/lualib/resty/mysql.lua:31: ngx_lua 0.9.11+ required

stream模块的resty-mysql支持？

是不是可以做一些增强 nginx upstream 部分的功能，例如在保证处理效率的前提下又能在 lua 处理响应的 body，例如管理对上游的链接池等。

    282441848
    多谢报告，这里应该只需要很小的改动，应该很快就可以修复更新到 opm

        firlas
        你是希望在 timer 里面使用 ngx.location.capture 么？
        这个理论上也可以搞，不过可能相对改动大一些。
        timer 里面选择使用 location.capture 而不使用 cosocket 是出于什么目的呢

        还有其他希望在 timer 里面支持的么？

          imilli
          哈哈，有点多，也欢迎大家一起来贡献，齐头并进发展更快

              doujiang24 目前只遇到ngx.location.capture这个限制.

              原因是原本content_by_lua阶段的逻辑使用了很多capture, 因为考虑capture比完整请求要轻量.
              随着项目发展, 这些逻辑其中一些要跑在timer里了, timer不支持capture, 只好到处去ngx.get_phase()区分.

              看文档时我在想, 既然timer已经"will take one (fake) connection"了, 那不能干脆 take one (fake) request么, 然后timer逻辑发生在这个fake request的content_by阶段, 能使用content阶段所有功能.

              毕竟没看过源码, 很可能想的过于简单.

                feng
                这个 PR 只是完成 shdict 在 stream 和 http 之间共享呢
                完全的合并两个 lua vm，这是另外一个话题，其实合并也不太好

                    firlas
                    确实 timer 还不是完整的请求，没有 content phase 这个概念了呢，执行上也没有了呢
                    要支持的话，还是有一些改动量的，当然也不是要引入 content phase 才可以，有其他路子

                        tweyseo 这个功能太有用.

                        如果考虑到nginx的设计, 请求到所有worker这个改动太大的话, 那一个可以广播自定义数据到所有worker的api怎样

                          tanjinhua 这个我已经用来代替kong的resty-event用在mlcache里了，算上编译过程，整个不算简单易用。要是OR本身可以支持，比如，直接配置listen 9527 BCST;，然后不管外部还是内部，只要是到这个端口的数据都是给所有worker都处理的，这样岂不是更好。

                            tweyseo 是的，系统本身自带肯定更好的，也是比较基本和使用的功能了；但是这个估计要修改 nginx 本身，工作量会比较大的。