[bug] nginx : ngx_quic_input_handler moved from .h to .c

[miewx]

https://github.com/nginx/nginx/blob/master/src/event/quic/ngx_event_quic.c

https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_util.c error: ‘ngx_quic_input_handler’ undeclared (first use in this function); did you mean ‘ngx_quic_pto_handler’?

[swananan]

To make the Lua SSL phase yield API work properly over HTTP/3 (https://github.com/openresty/lua-nginx-module/pull/2432) , we had to modify Nginx’s code. Here is the patch (https://github.com/openresty/openresty/pull/1063/files) — currently, OpenResty must use this patch to work correctly, and it only supports Nginx 1.27.x. Since this change is only required by OpenResty, Nginx will not accept it upstream, so it can only be maintained as a patch.

When Nginx is updated to 1.29.1, especially with support for the OpenSSL 3.5 QUIC API, OpenResty will update the patch and add support for Nginx 1.29.1. For now, the temporary solution is to use the Nginx version supported by OpenResty, which is Nginx 1.27.1.

[zhuizhuhaomeng]

@swananan We can add a macro to deal with this situation

[swananan]

If we try to work around this by adding a macro in both the patch and the lua-nginx-module, then any lua-nginx-module build without the patch will lose the ability to use the Lua yield API in the HTTP/3 SSL phase — which would essentially hide the problem.

Currently, is the intended usage of lua-nginx-module only through the OpenResty repo’s release versions or packaging? Or is it expected that people can also use lua-nginx-module standalone?

If it’s the latter, then I have an idea: use a macro-based guard, and if the patch is not applied, the SSL Lua yield API will throw an error when called on HTTP/3 requests, instructing the user to either apply the patch or use the latest OpenResty release.

[zhuizhuhaomeng]

People can use the lua-nginx-module standalone.