bug: 502 error when using ext-plugin-post-resp due to HTTP/2/HTTP/3 request without Content-Length header

[Goend]

Current Behavior

1. Enable http2 on the APISIX gateway listener.
2. Configure a route or Ingress that uses the ext-plugin-post-resp plugin.
3. Make sure the request reaches the ext-plugin-post-resp code path.
   For example, attach an ApisixPluginConfig with ext-plugin-post-resp enabled to an Ingress.
4. Send an HTTP/2 GET request that has no request body and no Content-Length header.
   Example:

curl -k -i --http2 'https://(host)/xx/'

5. Observe that APISIX returns 502.

Relevant code path

• apisix/plugins/ext-plugin-post-resp.lua
• apisix/core/request.lua

The failure is triggered by logic equivalent to:

if (var.server_protocol == "HTTP/2.0" or var.server_protocol == "HTTP/3.0")
and not content_length then
return nil, "HTTP2/HTTP3 request without a Content-Length header"
end

Expected Behavior

The request should not fail.
For an HTTP/2 or HTTP/3 GET request without a body, APISIX should treat the request body as empty and continue normally. Content-Length should not be required in this case.

Error Logs

[lua] ext-plugin-post-resp.lua:153: phase_func(): failed to request: HTTP2/HTTP3 request without a Content-Length header
[lua] plugin.lua:1198: common_phase(): ext-plugin-post-resp exits with http status code 502

Steps to Reproduce

Refer to the Current Behavior section

Environment

• APISIX version (run apisix version): 3.15.0
• Operating system (run uname -a):
• OpenResty / Nginx version (run openresty -V or nginx -V):
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info):
• APISIX Dashboard version, if relevant:
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[Goend]

Based on #10887
, this validation requirement is incompatible with the ext-plugin-post-resp plugin’s need to pass Content-Length. Therefore, ngx.req.read_body should be used instead.

[Goend]

However, in #13243 directly used ngx.req.read_body() and did not encounter any requirement that the Content-Length header must be present—it worked normally. So I’m confused about the reason for introducing this restriction. Even after reading #10887 still can’t understand it.

I think it is reasonable for request.lua to have this limitation, since it aligns with https://github.com/openresty/lua-nginx-module/tree/v0.10.26#ngxreqread_body.

But for the ext-plugin-post-resp plugin, why does this restriction not apply? For the ext-plugin-post-resp plugin, if the Content-Length header is missing here, could it potentially cause issues in HTTP/2 or HTTP/3 scenarios? I would like to have more information.

[Goend]

@juzhiyuan Do you have any suggestions regarding this issue? Is it possible that the ext-plugin is not currently compatible with HTTP/2, and therefore not recommended for use under HTTP/2?

[Baoyuantop]

Hi @Goend, The solution in PR #13243 (which only bypasses the issue in ext-plugin-post-resp) is merely a stopgap measure, for the following reasons:

• Over 20 other plugins that call core.request.get_body() still have the same issue
• It bypasses security mechanisms such as the max_size check in core.request.get_body()

Recommended solution: Fix the validation logic in the get_body() function in core/request.lua:

-- check content-length header for http2/http3
 do
     local var = ctx and ctx.var or ngx.var
     local content_length = tonumber(var.http_content_length)
     if (var.server_protocol == "HTTP/2.0" or var.server_protocol == "HTTP/3.0")
         and not content_length then
         -- No Content-Length in H2/H3: treat as no body (not an error)
         return nil
     end
 end

Change return nil, err to return nil (no body, no error), so that:

• All plugins that call get_body() automatically benefit
• For POST/PUT requests that actually require a body, the caller will check if the return value is nil and handle it as needed
• The integrity of safety checks such as max_size is preserved

[Goend]

@Baoyuantop However, in the documentation at https://github.com/openresty/lua-nginx-module/tree/v0.10.26#ngxreqread_body
, it states:
"Due to the stream processing feature of HTTP/2 or HTTP/3, this API could potentially block the entire request. Therefore, this API is effective only when HTTP/2 or HTTP/3 requests send the Content-Length header. For requests with versions lower than HTTP/2, this API can still be used without any problems."
Does this limitation need to be strictly followed? Otherwise, it may introduce hidden issues and make troubleshooting more difficult.

It was initially restricted in PR openresty/lua-nginx-module#2237
In commit openresty/lua-nginx-module@e0d19f7, the restriction was partially lifted, and the documentation was updated to state that this method is not supported under HTTP/2.
Later, in commit openresty/lua-nginx-module@6e29c1a, the restriction regarding the lack of HTTP/2 support for this method was further relaxed.

Therefore, it seems that in the latest version this restriction has already been lifted, and this part of the logic which about validate of Content-Length can be removed. What do you think?