So is "rewrite_by_lua" also evil?

Nginx User nginx at
Tue Oct 11 16:03:32 UTC 2011

I have the following simplified setup ...

server {
	location @proxy {
		include /etc/nginx/firewall.default;
	location ~ ^.+\.php$ {
		content_by_lua 'ngx.exec("@proxy");';
	location / {
		try_files $uri $uri/ @proxy;
Basically, everything that cannot be found by nginx, as well as php
requests, are sent to the proxy

Now, note the filter.default file in the @proxy location. I use this
to run some tests on these requests for security and my logs show them
catching all sorts of exploit attempts.

Anyway, when I have the following (simplified) in firewall.default ....

if ($http_user_agent ~* libwww ) {
	return 403;

... everything is fine. When a php request is made, libwww user agents
are denied and others get the php output.

When I use the following (simplified) rewrite_by_lua equivalent instead ....

rewrite_by_lua '
	if ngx.var.http_user_agent == "libwww" then

The php file is downloaded. Obviously I don't have the "libwww" when
testing so I suppose the lua "if" block is skipped at which point the
physical php file is found and sent to the user as is and the
proxy_pass directive is not run.

Looks similar to the sort of unexpected behaviour from the rewrite
module's "if".

Any ideas what gives? Why isn't rewrite_by_lua behaving like the rewrite module?


More information about the nginx mailing list