After reading about locations now I understand that ONLY ONE gets used.
Which means PHP was working fine but HTTP AUTH was only protecting
the non-PHP files in /admin! Am I correct?
I know I can nest location blocks but when I tested, it doesn’t look
like
the settings in the outer block are inherited by the inner block, so the
only advantage to nesting is just narrowing the request type handled by
the block.
For example, if I nest “location /admin” inside the PHP block I still
have
to repeat the entire PHP setup parameters inside the /admin block. Plus
I still need another /admin block outside the PHP block to have HTTP
AUTH on the non-PHP files in /admin. This gets repetative and messy.
So what’s the most smoothe way to have one or more location handlers
that need to be addative like having a global handler for PHP files in
addition to handlers that are specific to the directory, like HTTP AUTH
or other things?
For example, if I nest “location /admin” inside the PHP block I still have
to repeat the entire PHP setup parameters inside the /admin block. Plus
I still need another /admin block outside the PHP block to have HTTP
AUTH on the non-PHP files in /admin. This gets repetative and messy.
So what’s the most smoothe way to have one or more location handlers
that need to be addative like having a global handler for PHP files in
addition to handlers that are specific to the directory, like HTTP AUTH
or other things?
Additive locations are good when you want to make little configurations
even lesser. However, when such configurations grow their maintenance
becomes
a nightmare - you have to look though all configuration to see how a
tiny
change will affect entire configuration. People want not to write less
but
they want to spend less time. These are different things. With right
nginx
configuration you should write more but you will spend much less time
when you will change your configuration. So the recommended way to
configure
your task is following:
