variables in "include"

Michael Shadle mike503 at gmail.com
Tue Jul 21 00:52:59 MSD 2009


i agree. i think there should be an htaccess on; type deal, and instead of going

/
/home
/home/foo
/home/foo/bar
/home/foo/bar/foo.com

in the search path, it should start in the document root. in php 5.3,
they actually take the file path being requested, and then go
backwards from there, down to the document root level.

so

http://foo.com/1/2/3/

would chekc for

/home/foo/bar/foo.com/1/2/3/
/home/foo/bar/foo.com/1/2/
/home/foo/bar/foo.com/1/
/home/foo/bar/foo.com/

maybe also have a cache and a configuration item of how much memory to
dedicate to the cache...

htaccess on;
htaccess_file_name .htaccess;
htaccess_cache_size shared:htaccess:10m;
htaccess_cache_time 15s;

or something?

On Mon, Jul 20, 2009 at 12:54 PM, Marcus Clyne<maccaday at gmail.com> wrote:
> Hi Kaspars,
>
> Kaspars wrote:
>>
>> Marcus, thank you very much for explaining how things are meant to work in
>> nginx.
>
> You're welcome.
>>
>>> If the config files were analysed at runtime (like .htaccess files on
>>> Apache), that would slow things down.  Also, if the configuration file is
>>> wrong, what do you do?  Better to control it all at start time.
>>
>> I agree, there are lot of benefits of not having any runtime file access
>> action going on. It would be interesting to do some testing on how this
>> affects the performance.
>
> Litespeed, which is an asynchronous event-driven (like Nginx), very fast
> webserver that is largely Apache-compatible allows Apache-style .htaccess
> files to be used on a per-directory basis, and caches them in memory.
>  Although this does have a performance hit, it's still very fast, and with
> the right design, it needn't necessarily have a huge impact on performance
> if implemented in Nginx.  It shouldn't be too hard to implement, but Igor
> may not want to include code that does it in the main source.
>>
>>> If you need specific configurations for each server, then you can't
>>> really get around having a separate server{} block for each one (though you
>>> might be able to group them).
>>> One possible method: [...]
>>
>> I have set it up almost exactly like you described and it works very well.
>
> I'm glad it works well.
>
> Marcus.
>
>
>
>





More information about the nginx mailing list