3 ms·

As the blog post points out, this does look to be a consequence of "IfIsEvil" (http://wiki.nginx.org/IfIsEvil http://wiki.nginx.org/IfIsEvil). The behavior of c

by nbpoole 15y ago

As the blog post points out, this does look to be a consequence of "IfIsEvil" (http://wiki.nginx.org/IfIsEvil http://wiki.nginx.org/IfIsEvil). The behavior of calling the script, not rendering it, and displaying the actual file is very strange though, especially since the if statements appear mutually exclusive. Maybe someone with nginx experience can explain why that would happen.

mnutt 15y ago
Yeah, I love nginx and its syntax is great for the most part but it's easy to fall into the trap of thinking that you're writing in a turing-complete language. Something as simple as using multiple conditions in an if statement and redirecting to https if x-forwarded-proto is not set becomes a huge pain: https://gist.github.com/974486 https://gist.github.com/974486
merlincorey 15y ago
Firstly, everyone should read http://nginx.org/en/docs/http/request_processing.html http://nginx.org/en/docs/http/request_processing.html before they go trying to "figure out what NginX is doing". Secondly... because NginX configuration is declarative and ifs are imperative (the opposite paradigm). The imperative ifs are actually compiled into a little mini language and evaluated at runtime, but under the hood, ifs are hacky locations. This is the ultimate reason why If is Evil in NginX, and always will be. In NginX's declarative setup, you declare each separate location and the behavior that should result within that location. In NginX, only one location wins for ultimate processing! Finally, one must consider the order of evaluation of locations. Specifically, it is something like server if, location = (exact match), location ~ (regex match), location, location if --only one location wins, ever... but it may pass through several locations, especially if you add in error_pages and so on and so forth. So, coming full circle and attempting to answer the question of just why "calling the script, not rendering it, and displaying the actual file"; well, if you have not properly setup your locations such that PHP files always are routed to a PHP processing location, then you will in fact serve PHP files just like any other file. NginX's configuration language is much like any language - if you don't really know what it is doing, it is quite easy to make it do something you didn't expect.

by nbpoole 15y ago

mnutt 15y ago

Yeah, I love nginx and its syntax is great for the most part but it's easy to fall into the trap of thinking that you're writing in a turing-complete language. Something as simple as using multiple conditions in an if statement and redirecting to https if x-forwarded-proto is not set becomes a huge pain: https://gist.github.com/974486 https://gist.github.com/974486

merlincorey 15y ago

Firstly, everyone should read http://nginx.org/en/docs/http/request_processing.html http://nginx.org/en/docs/http/request_processing.html before they go trying to "figure out what NginX is doing". Secondly... because NginX configuration is declarative and ifs are imperative (the opposite paradigm). The imperative ifs are actually compiled into a little mini language and evaluated at runtime, but under the hood, ifs are hacky locations. This is the ultimate reason why If is Evil in NginX, and always will be. In NginX's declarative setup, you declare each separate location and the behavior that should result within that location. In NginX, only one location wins for ultimate processing! Finally, one must consider the order of evaluation of locations. Specifically, it is something like server if, location = (exact match), location ~ (regex match), location, location if --only one location wins, ever... but it may pass through several locations, especially if you add in error_pages and so on and so forth. So, coming full circle and attempting to answer the question of just why "calling the script, not rendering it, and displaying the actual file"; well, if you have not properly setup your locations such that PHP files always are routed to a PHP processing location, then you will in fact serve PHP files just like any other file. NginX's configuration language is much like any language - if you don't really know what it is doing, it is quite easy to make it do something you didn't expect.