Simple php config (nginx 1.7.4 development);
server {
[…]
location ~ .php$ {
try_files $uri $uri/ =404;
index index.html index.htm index.php;
fastcgi_ignore_client_abort on;
fastcgi_pass myLoadBalancer;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
location / {
try_files $uri $uri/ =404;
index index.html index.htm;
}
}
None existing file:
“GET /viewforum.pp?f=3 HTTP/1.1” 404 180 “-”
a proper 404 from nginx.
However a different approach also with a none existing file:
“GET /viewforu.php?f=3 HTTP/1.1” 404 56 “-”
returns a 404 from the backend and a ‘no input file specified’
Neither files exist yet the second test is going past try_files.
Anyone any idea if this is a config issue or a bug?
Posted at Nginx Forum:
Hello!
On Fri, Jul 11, 2014 at 03:36:19PM -0400, itpp2012 wrote:
fastcgi_param SCRIPT_FILENAME
“GET /viewforum.pp?f=3 HTTP/1.1” 404 180 “-”
a proper 404 from nginx.
However a different approach also with a none existing file:
“GET /viewforu.php?f=3 HTTP/1.1” 404 56 “-”
returns a 404 from the backend and a ‘no input file specified’
Neither files exist yet the second test is going past try_files.
Anyone any idea if this is a config issue or a bug?
I would suggest it’s a config issue. Note though that the config
snippet provided isn’t enough to conclude anything.
If in doubt, try debug log.
See A debugging log for details.
–
Maxim D.
http://nginx.org/
Ok, debug session here 2014/07/11 23:20:37 [debug] 256#996: *7 post event 01EE02002014/07/11 23:20:37 - Pastebin.com
I see one try_files phase, maybe a script is processed differently then
a
static file.
Posted at Nginx Forum:
Valentin V. Bartenev Wrote:
On Friday 11 July 2014 17:42:41 itpp2012 wrote:
Ok, debug session here 2014/07/11 23:20:37 [debug] 256#996: *7 post event 01EE02002014/07/11 23:20:37 - Pastebin.com
[…]
It looks like one case of If is Evil… when used in location context | NGINX
Maybe but should an if bypass try_files ? in a none php environment this
works as it should, lots of if’s and other stuff where try_files does
what
it suppose to do, so it should for a php location.
Posted at Nginx Forum:
Hmm, more debugging, this config returns a 404 from the backend (which
it
shouldn’t):
try_files $uri $uri/ =404;
set $maintmode S;
if ($remote_addr ~ “^(192.168..)$”) { set $maintmode L; }
if (-f $document_root/maintenance_mode.html) { set $maintmode
“${maintmode}M”; }
if ($maintmode = SM) { return 503; }
This config returns a 404 from nginx, like it should:
try_files $uri $uri/ =404;
set $maintmode S;
if ($remote_addr ~ “^(192.168..)$”) { set $maintmode L; }
if (-f $document_root/maintenance_mode.html) { set $maintmode
“${maintmode}M”; }
if ($maintmode = SM) { return 503; }
So yes it is an IF issue but to my opinion this should not happen.
Posted at Nginx Forum:
Ok clear enough, I’d still consider it some kind of bug (it makes no
sense
for try_files to be disabled when an if matches), for example using map
and
a single IF does this as well which is more or less nginx’s recommended
way
of doing an IF with map.
Funny thing is when you have a .php location inside a / location
try_files
does work with multiple IF’s and a IF match.
Posted at Nginx Forum:
Hello!
On Sat, Jul 12, 2014 at 06:23:41AM -0400, itpp2012 wrote:
This config returns a 404 from nginx, like it should:
try_files $uri $uri/ =404;
set $maintmode S;
if ($remote_addr ~ “^(192.168..)$”) { set $maintmode L; }
if (-f $document_root/maintenance_mode.html) { set $maintmode
“${maintmode}M”; }
if ($maintmode = SM) { return 503; }
So yes it is an IF issue but to my opinion this should not happen.
Please re-read the link provided by Valentin:
One of the examples there is exactly your case - if any of the if’s
(without “return” inside it) in your configuration is matched, the
“try_files” won’t work.
–
Maxim D.
http://nginx.org/
Hello!
On Sun, Jul 13, 2014 at 05:46:50PM -0400, itpp2012 wrote:
Ok clear enough, I’d still consider it some kind of bug (it makes no sense
for try_files to be disabled when an if matches), for example using map and
a single IF does this as well which is more or less nginx’s recommended way
of doing an IF with map.
Sure. The page in question lists various bugs related to “if”
(may be except the first one, which is explicitly marked as “not
really bug, just how it works”).
And we even have a trac ticket for this:
http://trac.nginx.org/nginx/ticket/86
Funny thing is when you have a .php location inside a / location try_files
does work with multiple IF’s and a IF match.
I suspect you’ve tested it wrong.
–
Maxim D.
http://nginx.org/
Maxim D. Wrote:
And we even have a trac ticket for this:
#86 (the "if" directive have problems in location context) – nginx
A tested workaround with Lua and a single IF with a return then:
location ~ \.php$ {
try_files $uri $uri/ =404;
set $mmode 0;
set_by_lua $notused '
s = 0;
local source_fname = ngx.var.document_root ..
“/maintenance_mode.html”;
local file = io.open(source_fname);
if file then ngx.var.mmode=1; file:close(); end;
s = string.find(ngx.var.remote_addr, “^10.10.20.”);
if s then ngx.var.mmode=0; end;
';
if ($mmode) { return 503; }
index index.html index.htm index.php;
fastcgi_ignore_client_abort on;
fastcgi_pass myLoadBalancer;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
Posted at Nginx Forum:
With pure Lua and no IF (crossposted in openresty group):
location / {
try_files $uri $uri/ =404;
index index.html index.htm;
}
location ~ \.php$ {
try_files $uri $uri/ =404;
rewrite_by_lua '
local s = 0; local v = 0;
local source_fname = ngx.var.document_root ..
“/maintenance_mode.html”;
local file = io.open(source_fname);
if file then v=1; file:close(); end;
if string.find(ngx.var.remote_addr, “^10.10.30.”) then
v=0;
end;
if v>0 then return ngx.exit(503); end;
';
index index.html index.htm index.php;
fastcgi_ignore_client_abort on;
fastcgi_pass myLoadBalancer;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
With nginx for Windows you can use 513 to keep your 503 handler intact.
Posted at Nginx Forum: