variables in "include"

Marcus Clyne maccaday at
Tue Jul 21 03:52:08 MSD 2009

>> That would be overall less efficient, since if you had htaccess-like files,
>> you would always want to check the uppermost level (because it might say to
>> ignore htaccess files lower down).  If it did, then you will have checked
>> lower-level htaccess files unnecessarily.
> I'm not sure; I think it might be interesting to ask the PHP folks why
> they decided to do it that way. if I'm protecting phpMyAdmin for
> example, it will find my .htaccess file quicker one way vs. the other
> depending on how nested it is.
The point is that for proper security, you'd want to be able to turn off 
htaccess to lower levels in the higher levels.  In order to find the 
higher levels, you'd need to search the highest order directories, 
starting with where the location where htaccess has been enabled.  If 
you must read the highest-level directory's htaccess file, but not 
necessarily the lower-levels' ones, then it makes sense to start at the top.

Wrt PHP, I've not tried it out so I'm not sure precisely how it works.  
I'm assuming that all directories are searched, though, and that 
lower-levels override higher levels.  In that case, it makes sense to 
start at the bottom, since then you will only set each option once - if 
you discover the option at a higher level, then you don't need to save 
it, because you already have an option that is more specific.  It makes 
sense to do it this way if you don't need the option to prevent parsing 
of options in lower directories, but with server-level htaccess files, 
you would want that.
> yeah. hmm. i didn't think that all the way though. caching the
> existence (or lack of) for 15 seconds before it invalidates itself
> wouldn't be useful. it wouldn't be very good. i don't know how
> expensive a basic stat call is. of course, that's why htaccess on;
> could be allowed in any location block, so you could limit the amount
> of overhead if you wish.
The stat call wouldn't be a big overhead if carried out asynchronously, 
but would really slow down the server if it wasn't.


More information about the nginx mailing list