Nginx lua module前端负载均衡ngx.req.read_body，遇到Expect：100-Continue请求时，不能正常向后端转发请求

xizhiyong18

hi all：

我们在前端集群上使用ngx lua加入一些网关功能，需要读取http body，在access_by_lua_file中通过ngx.req.read_body读取，线上发现一个场景，

用户请求中有Expect：100-Continue header时，请求400错误。

通过抓包来看，过程大概如下:

1.客户端发送请求，带有Expect头

2.nginx收到请求后响应100

3.客户端发送body

4.nginx跟后端（tomcat）发起tcp握手，但并没有发送数据

5.20s后tcp连接超时

奇怪的一点是，当我们通过配置lua_need_read_body on时，就不会出现该问题。

xizhiyong18

更新一下：debug lua 代码（access_by_lua_file），发现hang在ngx.req.read_body()

在 2018年7月20日星期五 UTC+8上午11:15:32，xizhi...@gmail.com写道：

hi all：

我们在前端集群上使用ngx lua加入一些网关功能，需要读取http body，在access_by_lua_file中通过ngx.req.read_body读取，线上发现一个场景，
用户请求中有Expect：100-Continue header时，请求400错误。

通过抓包来看，过程大概如下:
1.客户端发送请求，带有Expect头
2.nginx收到请求后响应100
3.客户端发送body
4.nginx跟后端（tomcat）发起tcp握手，但并没有发送数据
5.20s后tcp连接超时

奇怪的一点是，当我们通过配置lua_need_read_body on时，就不会出现该问题。

相关版本：
nginx 1.10.1
lua：5.15

请大神们指导一下^_^

xizhiyong18

再补充信息，我们的调用包在xpcall中

在 2018年7月20日星期五 UTC+8下午12:18:22，xizhi...@gmail.com写道：

更新一下：debug lua 代码（access_by_lua_file），发现hang在ngx.req.read_body()

在 2018年7月20日星期五 UTC+8上午11:15:32，xizhi...@gmail.com写道：
hi all：

我们在前端集群上使用ngx lua加入一些网关功能，需要读取http body，在access_by_lua_file中通过ngx.req.read_body读取，线上发现一个场景，
用户请求中有Expect：100-Continue header时，请求400错误。

通过抓包来看，过程大概如下:
1.客户端发送请求，带有Expect头
2.nginx收到请求后响应100
3.客户端发送body
4.nginx跟后端（tomcat）发起tcp握手，但并没有发送数据
5.20s后tcp连接超时

奇怪的一点是，当我们通过配置lua_need_read_body on时，就不会出现该问题。

相关版本：
nginx 1.10.1
lua：5.15

请大神们指导一下^_^

zchao1995

Hello!

> 我们在前端集群上使用ngx lua加入一些网关功能，需要读取http body，在access_by_lua_file中通过ngx.req.read_body读取，线上发现一个场景，

> 用户请求中有Expect：100-Continue header时，请求400错误。

> 通过抓包来看，过程大概如下:

> 1.客户端发送请求，带有Expect头

> 2.nginx收到请求后响应100

> 3.客户端发送body

> 4.nginx跟后端（tomcat）发起tcp握手，但并没有发送数据

> 5.20s后tcp连接超时

400 是从日志里看到的，还是从返回的 HTTP 响应里看到的。

另外下面你说请求 hang 在了 ngx.req.read_body()，请求是一直 hang 住了吗？那为什么还会和后端去通信。

另外 client_body_buffer_size， client_body_in_file_only，client_body_in_single_buffer 以及 proxy_request_buffering 的配置是怎样的？

xizhiyong18

实际上并不是hang在那里了，而是触发了lua异常 “

attempt to yield across metamethod/C-call boundary

”

后面的没有执行

在 2018年7月23日上午11:52，tokers <zcha...@gmail.com>写道：

Hello!

> 我们在前端集群上使用ngx lua加入一些网关功能，需要读取http body，在access_by_lua_file中通过ngx.req.read_body读取，线上发现一个场景，
> 用户请求中有Expect：100-Continue header时，请求400错误。
>
> 通过抓包来看，过程大概如下:
> 1.客户端发送请求，带有Expect头
> 2.nginx收到请求后响应100
> 3.客户端发送body
> 4.nginx跟后端（tomcat）发起tcp握手，但并没有发送数据
> 5.20s后tcp连接超时

400 是从日志里看到的，还是从返回的 HTTP 响应里看到的。

另外下面你说请求 hang 在了 ngx.req.read_body()，请求是一直 hang 住了吗？那为什么还会和后端去通信。

另外 client_body_buffer_size， client_body_in_file_only，client_body_in_single_buffer 以及 proxy_request_buffering 的配置是怎样的？

--

agentzh

Hello!

2018-07-22 20:54 GMT-07:00 zhiyong:
> 实际上并不是hang在那里了，而是触发了lua异常 “
>
> attempt to yield across metamethod/C-call boundary
>

关于你问的那个问题，那条错误消息已经指明了 root case，我不知道该如何进一步解释，毕竟这是标准 Lua 5.1 解释器实现上的限制，只能自己去看源码了。

OpenResty 正是通过 yield 来实现非阻塞的流程，而不是你说的所谓“破坏了非阻塞的流程”，实际情况恰恰相反。

应当总是使用 LuaJIT，尤其应当总是直接使用 OpenResty。OpenResty 的 LuaJIT
性能会更好，也更稳定。我们很快就会彻底终止 OpenResty 对标准 Lua 解释器的任何兼容性支持了。

Regards,
Yichun

xizhiyong18

首先，多谢春哥的回复。

补充相关的信息如下：

除了上面的信息maillist，目前我们大概定位到了问题的一些线索：

1.为了避免灰度逻辑对正常流程的影响，我们使用xpcall捕获异常（灰度逻辑出现问题，就默认不走灰度，不要对正常逻辑产生影响）

2.只有请求中带有“Expect：100-Continue“ header时才会出现

3.根据社区中YiChun的一些其他相关回复（https://github.com/openresty/lua-nginx-module/issues/490），我试了一下luajit的版本，确实可以解决这个问题

“attempt to yield across metamethod/C-call boundary”，在我遇到的这个场景下，是因为xpcall，还是因为ngx.req.read_body()？因为我尝试了，ngx.req.read_body不包在xpcall中，是ok的；包在xpcall中，但是不调用ngx.req.read_body，也是ok的。

ngx.req.read_body调用，同时包含在xpcall中，当请求头中没有“Expect：100-Continue”时，也没有遇到问题。

是因为“Expect：100-Continue ”请求头，破坏了非阻塞的流程，ngx.req.read_body中触发了yield？

---------

关于上面的问题，请参考春哥回复信息

在 2018年7月23日下午12:38，Yichun Zhang (agentzh) <age...@gmail.com>写道：

Hello!

2018-07-22 20:54 GMT-07:00 zhiyong:
> 实际上并不是hang在那里了，而是触发了lua异常 “
>
> attempt to yield across metamethod/C-call boundary
>

关于你问的那个问题，那条错误消息已经指明了 root case，我不知道该如何进一步解释，毕竟这是标准 Lua 5.1 解释器实现上的限制，只能自己去看源码了。

OpenResty 正是通过 yield 来实现非阻塞的流程，而不是你说的所谓“破坏了非阻塞的流程”，实际情况恰恰相反。

应当总是使用 LuaJIT，尤其应当总是直接使用 OpenResty。OpenResty 的 LuaJIT
性能会更好，也更稳定。我们很快就会彻底终止 OpenResty 对标准 Lua 解释器的任何兼容性支持了。

Regards,
Yichun

--

xizhiyong18

“是因为“Expect：100-Continue ”请求头，破坏了非阻塞的流程，ngx.req.read_body中触发了yield？”

关于我的这个问题，我的意思是，只有请求头中带有这个expect时才会复现以上问题，所以是这个请求头的处理逻辑触发的yield？

因为综合社区中搜索到的信息，xpcall,ngx.location.capture等也会触发“attempt to yield across metamethod/C-call boundary”这个异常。

“在我遇到的这个场景下，是因为xpcall，还是因为ngx.req.read_body()？因为我尝试了，ngx.req.read_body不包在xpcall中，是ok的；包在xpcall中，但是不调用ngx.req.read_body，也是ok的。”

在 2018年7月23日下午2:24，zhiyong <xizhi...@gmail.com>写道：

首先，多谢春哥的回复。

补充相关的信息如下：

除了上面的信息maillist，目前我们大概定位到了问题的一些线索：
1.为了避免灰度逻辑对正常流程的影响，我们使用xpcall捕获异常（灰度逻辑出现问题，就默认不走灰度，不要对正常逻辑产生影响）
2.只有请求中带有“Expect：100-Continue“ header时才会出现
3.根据社区中YiChun的一些其他相关回复（https://github.com/openresty/lua-nginx-module/issues/490），我试了一下luajit的版本，确实可以解决这个问题

“attempt to yield across metamethod/C-call boundary”，在我遇到的这个场景下，是因为xpcall，还是因为ngx.req.read_body()？因为我尝试了，ngx.req.read_body不包在xpcall中，是ok的；包在xpcall中，但是不调用ngx.req.read_body，也是ok的。

ngx.req.read_body调用，同时包含在xpcall中，当请求头中没有“Expect：100-Continue”时，也没有遇到问题。

是因为“Expect：100-Continue ”请求头，破坏了非阻塞的流程，ngx.req.read_body中触发了yield？

---------
关于上面的问题，请参考春哥回复信息

在 2018年7月23日下午12:38，Yichun Zhang (agentzh) <age...@gmail.com>写道：
Hello!

2018-07-22 20:54 GMT-07:00 zhiyong:
> 实际上并不是hang在那里了，而是触发了lua异常 “
>
> attempt to yield across metamethod/C-call boundary
>

关于你问的那个问题，那条错误消息已经指明了 root case，我不知道该如何进一步解释，毕竟这是标准 Lua 5.1 解释器实现上的限制，只能自己去看源码了。

OpenResty 正是通过 yield 来实现非阻塞的流程，而不是你说的所谓“破坏了非阻塞的流程”，实际情况恰恰相反。

应当总是使用 LuaJIT，尤其应当总是直接使用 OpenResty。OpenResty 的 LuaJIT
性能会更好，也更稳定。我们很快就会彻底终止 OpenResty 对标准 Lua 解释器的任何兼容性支持了。

Regards,
Yichun

--

xizhiyong18

这个问题对我来说，一个是想了解到root cause，另一方面，我现在没有openresty的包可用（内部原因），我想确认通过lua_need_request_body设置为on（可能会降低性能），是否真的可以避免在解析http body时（and “Expect：100-Continue ”）出现“attempt to yield across metamethod/C-call boundary”异常。因为为了保持body解析逻辑不对正常业务流程产生影响，我需要通过xpcall来catch住异常。

在 2018年7月23日下午2:31，zhiyong <xizhi...@gmail.com>写道：

“是因为“Expect：100-Continue ”请求头，破坏了非阻塞的流程，ngx.req.read_body中触发了yield？”
关于我的这个问题，我的意思是，只有请求头中带有这个expect时才会复现以上问题，所以是这个请求头的处理逻辑触发的yield？
因为综合社区中搜索到的信息，xpcall,ngx.location.capture等也会触发“attempt to yield across metamethod/C-call boundary”这个异常。
“在我遇到的这个场景下，是因为xpcall，还是因为ngx.req.read_body()？因为我尝试了，ngx.req.read_body不包在xpcall中，是ok的；包在xpcall中，但是不调用ngx.req.read_body，也是ok的。”

在 2018年7月23日下午2:24，zhiyong <xizhi...@gmail.com>写道：
首先，多谢春哥的回复。

补充相关的信息如下：

除了上面的信息maillist，目前我们大概定位到了问题的一些线索：
1.为了避免灰度逻辑对正常流程的影响，我们使用xpcall捕获异常（灰度逻辑出现问题，就默认不走灰度，不要对正常逻辑产生影响）
2.只有请求中带有“Expect：100-Continue“ header时才会出现
3.根据社区中YiChun的一些其他相关回复（https://github.com/openresty/lua-nginx-module/issues/490），我试了一下luajit的版本，确实可以解决这个问题

“attempt to yield across metamethod/C-call boundary”，在我遇到的这个场景下，是因为xpcall，还是因为ngx.req.read_body()？因为我尝试了，ngx.req.read_body不包在xpcall中，是ok的；包在xpcall中，但是不调用ngx.req.read_body，也是ok的。

ngx.req.read_body调用，同时包含在xpcall中，当请求头中没有“Expect：100-Continue”时，也没有遇到问题。

是因为“Expect：100-Continue ”请求头，破坏了非阻塞的流程，ngx.req.read_body中触发了yield？

---------
关于上面的问题，请参考春哥回复信息

在 2018年7月23日下午12:38，Yichun Zhang (agentzh) <age...@gmail.com>写道：
Hello!

2018-07-22 20:54 GMT-07:00 zhiyong:
> 实际上并不是hang在那里了，而是触发了lua异常 “
>
> attempt to yield across metamethod/C-call boundary
>

关于你问的那个问题，那条错误消息已经指明了 root case，我不知道该如何进一步解释，毕竟这是标准 Lua 5.1 解释器实现上的限制，只能自己去看源码了。

OpenResty 正是通过 yield 来实现非阻塞的流程，而不是你说的所谓“破坏了非阻塞的流程”，实际情况恰恰相反。

应当总是使用 LuaJIT，尤其应当总是直接使用 OpenResty。OpenResty 的 LuaJIT
性能会更好，也更稳定。我们很快就会彻底终止 OpenResty 对标准 Lua 解释器的任何兼容性支持了。

Regards,
Yichun

--

agentzh

Hello!

不要纠结了，直接换用 LuaJIT，最好换用 OpenResty 的 LuaJIT，即使你们不能直接整体换用 OpenResty。不用纠结于
100 Continue，大部分 OpenResty 的 Lua API 都可能会 yield 的，并不限于
ngx.req.read_body()。所有会 yield 的 API 都要求可以允许 yield 的 xpcall 实现（以及其他标准
Lua API 的实现）。说了不要用标准 Lua 5.1 解释器，非要用就是自己找麻烦了，有些 API 即使大部分情况下不会
yield，但在网络较慢或数据量较大时也会 yield，这个也会变成定时炸弹了。前面已经说过了。

Regards,
Yichun

xizhiyong18

get~我们会尽快push更新，先替换为luajit

在 2018年7月24日星期二 UTC+8上午9:14:43，agentzh写道：

Hello!

不要纠结了，直接换用 LuaJIT，最好换用 OpenResty 的 LuaJIT，即使你们不能直接整体换用 OpenResty。不用纠结于
100 Continue，大部分 OpenResty 的 Lua API 都可能会 yield 的，并不限于
ngx.req.read_body()。所有会 yield 的 API 都要求可以允许 yield 的 xpcall 实现（以及其他标准
Lua API 的实现）。说了不要用标准 Lua 5.1 解释器，非要用就是自己找麻烦了，有些 API 即使大部分情况下不会
yield，但在网络较慢或数据量较大时也会 yield，这个也会变成定时炸弹了。前面已经说过了。

Regards,
Yichun