On czw, sie 05, 2010 at 03:22:19 -0700, Michael Shadle wrote:
> My biggest pet peeve is the conflicting location blocks. I've often
> mentioned a "super location" idea, something that gets executed at the
> very end of all the other rules, so that something like adding expires
> headers can be done at the very end.

I'd settle for a clean way to cover all of /foo (spanning several
locations, some of them being regex ones) with authentication or other
access controls. I'm currently using an ugly hack in Nginx code for
that. So I guess we're aiming for roughly the same thing.

> The idea of using this "type" methodology is nice though, as nginx
> could in theory factor it in at the very end before it spits out the
> content, examining the content-type header to determine "hey, this is
> text/css! I should apply these rules on it" and not having to setup
> regexp'ed locations that could conflict with other location blocks.

Would you expect it to be processed after static requests only or also
after *_pass?

> However, the biggest thing here is to see if there is a magic way to
> stop "any url ending in .php to be parsed as PHP" using existing nginx
> configuration or a small patch. That would make anyone who says there
> is any sort of security hazard go back into their caves (as nginx
> rarely has anything to be concerned about!)

It's effectively impossible if Nginx doesn't run on the same node as the
backend as it requires matching .../foo.php the URL with .../foo.php the
file and acting upon the results. That's why I think it belongs as an
extension in the static module.

Best regards,
Grzegorz Nosek

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