nginx-0.7.9

[mike]

On 8/12/08, Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Tue, Aug 12, 2008 at 09:30:28PM +0400, Igor Sysoev wrote:
>
> > On Tue, Aug 12, 2008 at 09:47:15AM -0700, mike wrote:
> >
> >
> > > Did Maxim's index patch get in there? to cycle through all the index
> > > files before going to a directory scan?
> > >
> >
> > No, I need think over.
> >
>
> Some random thoughts about:
>
> - Many index files is rare setup.  Setups I've seen usually have at most 3,
> more often 1 or 2.  In case of 2 index'es as far as I understand it doesn't
> make sence to test directory at all - for performance reasons.

I run into at least 2-3 index files quite often.

> - Situation where directory listing is forbidden (i.e. 711 permissions) may
> make sence in shared environments.

Correct. Never had this issue in the past with other webservers.

> - Optimization is good, but only if doesn't change expected behaviour.

How is this an optimization? If the first test fails, then check
directory listing? Isn't it faster to take an enumerated list of
parameters and check those first? You can test for a specific file, as
opposed to opening a directory handle to check the listing or
whatever.

> From the above I think that fallback to sequential index tests in case of
> EACCES returned for directory test is good or at least acceptable solution.

I think your patch works perfectly. If performance is in people's
minds, then they can easily do this themselves by defining a single
index file - it will behave exactly like it does today. However, for
those of us who need a couple index file options (or those with
/index.html /index.$lang.html or whatever the examples are on the wiki
even) Maxim's patch seems to make nginx behave properly in my opinion.

The user has control over how many index files they define, so they
can control their own performance, or order the index files in the
manner in which is quickest for them. It's just simple file testing,
as opposed to opening up the directory before going forward with the
rest of the index file checking. That is actually a negative
performance hit, not a positive one.

Today:

my config might be "index index.html index.php index.htm"

1) check index.html - not found
2) check directory
3) check index.php - not found
4) check index.htm - found
5) if it wasn't found, then do directory listing, or throw access
denied 403 or whatever if not

Maxim's patch:

1) check index.html - not found
2) check index.php - not found
3) check index.htm - found
4) if it wasn't found, then do directory listing, or throw access
denied 403 or whatever if not

Why bother with a directory check? It's an extra step in the middle of
cycling through -predefined- index filenames.