Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lua code in header_filter phase still runs after ngx.exit(401) is executed in access phase #2279

Open
ChnMig opened this issue Jan 22, 2024 · 3 comments

Comments

@ChnMig
Copy link

ChnMig commented Jan 22, 2024

I saw in the documentation that using ngx.exit(<200) would make the request return directly to the client without executing the lua code at various stages later, and my colleague told me that was correct, my colleague had previously used an older version of openrest (seems to be 1.19.X)
But I tested linux version 1.21.4.3 and windows version 1.25.3.1 and found that even if I executed ngx.exit(401) during the access phase, it still triggered lua script during the header_filter phase. Why? Did I use it wrong?

my nginx config

events {
    accept_mutex   off;
    worker_connections   20480;
}
http {
	server {
        error_log logs/error.log error;
		listen 80; 
		location / {
			proxy_set_header Host $host;
			access_by_lua_file test/access.lua;
			header_filter_by_lua_file test/header.lua;
		}
	}
} 

test/access.lua

ngx.log(ngx.ERR, "access.lua")
return ngx.exit(401) 

test/header.lua

ngx.log(ngx.ERR, "header.lua")

result (logs/error.log)

2024/01/22 15:47:31 [error] 157014#0: *1 [lua] access.lua:1: access.lua, client: 172.28.64.1, server: , request: "GET / HTTP/1.1", host: "172.28.73.58:80"
2024/01/22 15:47:31 [error] 157014#0: *1 [lua] header.lua:1: header.lua, client: 172.28.64.1, server: , request: "GET / HTTP/1.1", host: "172.28.73.58:80"
@ninjken
Copy link

ninjken commented Feb 7, 2024

I think what the documentation says with regard to your question is

ngx.exit
syntax: ngx.exit(status)
...
When status >= 200 (i.e., ngx.HTTP_OK and above), it will interrupt the execution of the current request and return status code to Nginx.

Literally interpreted, if you call ngx.exit(401) in access phase, nothing else should happen except a 401 HTTP response. But that's not what really happens, but that only request handling phases gets interrupted, and response handling(like header filter) still works. Below is my nginx.conf snippet

location /test {
            access_by_lua_file test/access.lua;
            content_by_lua_file test/content.lua;
            header_filter_by_lua_file test/header.lua;
            log_by_lua_file test/log.lua;
}

Test it and you will see that content_by_lua_file(request handling) is not executed, but both header filter and log phases are still working!

@ChnMig
Copy link
Author

ChnMig commented Feb 18, 2024

I think what the documentation says with regard to your question is

ngx.exit
syntax: ngx.exit(status)
...
When status >= 200 (i.e., ngx.HTTP_OK and above), it will interrupt the execution of the current request and return status code to Nginx.

Literally interpreted, if you call in access phase, nothing else should happen except a 401 HTTP response. But that's not what really happens, but that only request handling phases gets interrupted, and response handling(like header filter) still works. Below is my nginx.conf snippetngx.exit(401)

location /test {
            access_by_lua_file test/access.lua;
            content_by_lua_file test/content.lua;
            header_filter_by_lua_file test/header.lua;
            log_by_lua_file test/log.lua;
}

Test it and you will see that content_by_lua_file(request handling) is not executed, but both header filter and log phases are still working!

If you're right, does that mean the document is wrong? My colleague told me that the old version of lua-nginx-module would return directly, but I don't have the old binary installation package to test:)

@zhuizhuhaomeng
Copy link
Contributor

ngx.exit(>=200) will exit the current phase and enter into the reply state.
The header_filter_by and log_by_lua are stilled be called because they are after the reply state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants