On 27/08/2010 20:06, Michael Shadle wrote:
> Initial testing shows:
>
> cgi.fix_pathinfo = 0
>
> and Igor's suggestion:
>
> location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
> fastcgi_pass 127.0.0.1:11000;
> fastcgi_param SCRIPT_FILENAME $document_root$script;
> fastcgi_param PATH_INFO $path_info;
> include fastcgi_params;
> }
>
> To be working properly. I need to check out PATH_INFO using old style
> and new style, make sure it still reports the expected behavior for
> PHP scripts (PATH_INFO, PHP_SELF, all that jazz)


I will believe you that this works, but it seems incredibly subtle and I
for one don't quite understand why it's working?

My point is only that we need to document how/why this is the solution
or users will deviate (innocently) and re-introduce the problem


Please, please also lets have the final solution also include an example
of how to efficiently *exclude* a certain directory. A good proportion
of apps that I have seen, ship with example Apache configurations that
do exactly this.

The suggestion was adding an excluded location:

location ^~/images/ {
# just handle as static, don't consult regexps
}

However, the issue I see here is that the user then needs to
specifically configure how that location should be handled, rather than
it being an *exclusion* to the original location

Can we work excluded locations into the regexp (negative lookahead
supported?):

location ~ ^(?!/images/)(?<script>.+\.php)(?<path_info>.*)$ {


The justification for excluding specific locations from the PHP
interpretor is that *most* applications don't encourage uploaded
executable cgi scripts and better apps are going to ship with a
recommendation to disable script execution in the upload directory.
Actually the situation is worse on Apache because there are so many ways
to trick the interpreter to run files. However, it's seems to be such
standard practice on Apache that it seems prudent to include it in our
standardised solution?

Lots of justifications for this via google:

http://www.google.co.uk/search?hl=en&q=disable+php+script+execution+upload

Someone argued that this might be *wanted* by the application... (Some
apps *wants* users to upload .php files which should then be
executable...??!!). I claim that it will be a serious minority of
applications desire this, and the vast majority will want uploaded files
to be non executable (regardless of extension)

Can we please, please, please try and make sure the recommended
configuration includes examples of specifically *excluding* locations
not expected to contain executable scripts... My proposal above...

Ed W
_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx