openresty / openresty/lua-nginx-module
ngx.flush throws runtime error
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 11.8k
- Forks
- 2.1k
- Avg merge
- 6h 1m
- Merged PRs (30d)
- 6
Description
Hi!
I found ngx.flush throws a Lua runtime error after the ngx.print was called by accident.
you can reproduce the problem by the following nginx configuration.
server {
listen 8081;
server_name _;
location / {
content_by_lua_block {
ngx.say("Hello, World!")
ngx.flush()
}
}
}
curl -v http://127.0.0.1:8081/ -H 'If-Unmodified-Since: Mon, 17 Apr 2006 03:10:35 GMT'
Then you will see something like this in the corresponding error.log:
2017/08/02 16:37:50 [error] 21399#21399: *3 lua entry thread aborted: runtime error: content_by_lua(nginx.conf:42):3: no request ctx found
stack traceback:
coroutine 0:
[C]: in function 'flush'
content_by_lua(nginx.conf:42):3: in function <content_by_lua(nginx.conf:42):1>, client: 127.0.0.1, server: _, request: "GET / HTTP/1.1", host: "127.0.0.1:8081"
After reading the related codes, i find the problem is caused by ngx_http_not_modified_header_filter at the earliest, which jumps to ngx_http_filter_finalize_request when ngx_http_test_if_unmodified returns 0, and ngx_http_filter_finalize_request cleans ctx of all the http modules, sets r->filter_finalize to 1.
Then we calling ngx.flush, we will get the provious runtime error because the ctx of ngx_lua is cleaned.
Maybe we should set the ctx of ngx_lua when r->filter_finalize is equal to 1 in ngx_http_lua_ngx_flush, like ngx_http_lua_handle_exit and others? Or we can mark it in the doc?
openresty version in my local machine:
nginx version: openresty/1.11.2.4
built by gcc 7.1.1 20170526 (Red Hat 7.1.1-2) (GCC)
built with OpenSSL 1.0.2k 26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/openresty/nginx --with-cc-opt='-O2
-I/usr/local/openresty/zlib/include -I/usr/local/openresty/pcre/include
-I/usr/local/openresty/openssl/include' --add-module=../ngx_devel_kit-0.3.0
--add-module=../echo-nginx-module-0.60 --add-module=../xss-nginx-module-0.05
--add-module=../ngx_coolkit-0.2rc3 --add-module=../set-misc-nginx-module-0.31
--add-module=../form-input-nginx-module-0.12
--add-module=../encrypted-session-nginx-module-0.06
--add-module=../srcache-nginx-module-0.31 --add-module=../ngx_lua-0.10.8
--add-module=../ngx_lua_upstream-0.06 --add-module=../headers-more-nginx-module-0.32
--add-module=../array-var-nginx-module-0.05 --add-module=../memc-nginx-module-0.18
--add-module=../redis2-nginx-module-0.14 --add-module=../redis-nginx-module-0.3.7
--with-ld-opt='-Wl,-rpath,/usr/local/openresty/luajit/lib -L/usr/local/openresty/zlib/lib
-L/usr/local/openresty/pcre/lib -L/usr/local/openresty/openssl/lib -Wl,
-rpath,/usr/local/openresty/zlib/lib:/usr/local/openresty/pcre/lib:/usr/local/openresty/openssl/lib'
--with-pcre-jit --with-ipv6 --with-stream --with-stream_ssl_module --with-http_v2_module
--without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module
--with-http_stub_status_module --with-http_realip_module --with-http_addition_module
--with-http_auth_request_module --with-http_secure_link_module
--with-http_random_index_module --with-http_gzip_static_module --with-http_sub_module
--with-http_dav_module --with-http_flv_module --with-http_mp4_module
--with-http_gunzip_module --with-threads --with-file-aio --with-dtrace-probes
--with-http_ssl_module
uname -a
Linux Fedora26-64 4.11.11-300.fc26.x86_64 #1 SMP Mon Jul 17 16:32:11 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
I am sorry if something i describe is not clear.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at ngx_http_lua_ngx_flush and compare its handling of r->filter_finalize with ngx_http_lua_handle_exit and related paths. Reproduce the issue with the provided nginx configuration and curl command, then verify that calling ngx.flush after ngx.say no longer produces the reported “no request ctx found” runtime error or that the documented behavior is clear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, lua
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100