Mailing List Archive

Those pesky .htaccess files
It's a real pain that everytime someone accesses a document
(say /usr/local/etc/httpd/docs/index.html) the server stats .htaccess
files in /usr, /usr/local, /usr/local/etc, /usr/local/etc/httpd and
/usr/local/etc/httpd/docs first.

How about the option of caching the fact that a .htaccess file does or
doesn't exist in each directory? You could nominate directories to
be cached (so ~/ directories for instance wouldn't be to allow users to
change .htaccess files immediately, others would wait until the server
was restarted).

This could be complex; but even just saying in a config file:

NoAccessFile /usr
NoAccessFile /usr/local
NoAccessFile /usr/local/etc
NoAccessFile /usr/local/etc/httpd

Would save four stats per request! Has anyone profiled Apache/Shambhala
to see how much time is wasted on these stats per request?

Mark
Mark J Cox, mark@telescope.org -- URL:http://www.telescope.org/mark.html
University of Bradford, England ---------- tel +44.1274.384070/fax 391333
Re: Those pesky .htaccess files [ In reply to ]
Date: Fri, 7 Jul 1995 13:01:29 +0100 (BST)
From: Mark J Cox <M.J.Cox@bradford.ac.uk>
X-Sender: mjhcox@compute
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

How about the option of caching the fact that a .htaccess file does or
doesn't exist in each directory? You could nominate directories to
be cached (so ~/ directories for instance wouldn't be to allow users to
change .htaccess files immediately, others would wait until the server
was restarted).

Hmmm... see below for non-cache ways to turn off reading of .htaccess
files in particular directories given the current setup; I'm not sure
they'll all be adequate, but I'd like to know how they break...

FWIW, one idea I've played with is to remember the presence or
absence of the .htaccess file in a directory, and also remember the
relevant last-modified times --- then you could keep the current
behavior (always reread .htaccess files if they change), by stat()ing
the directory itself, and only looking for a .htaccess file where
there used to be none if the last-mod date had changed. The idea here
is that in the common case (directory in cache), you never wind up
stat()ing a file which *does not exist* --- that could be faster on
file systems which have lookup caches, but don't cache nonexistent
files (AFS being a prime offender, since its performance on a cache
miss is just horrendous).

This could be complex; but even just saying in a config file:

NoAccessFile /usr
NoAccessFile /usr/local
NoAccessFile /usr/local/etc
NoAccessFile /usr/local/etc/httpd

FWIW, Shambhala does not currently look for a .htaccess file if there
is a <Directory> section in the access file, or if AllowOverride None
is set. That means that:

<Directory /usr>
</Directory>

(which is admittedly ugly as hell) would have the effect of the
"NoAccessFile /usr" directive. Alternatively, to take it all at one
blow, you could try something like

<Directory />
AllowOverride None
</Directory>

<Directory /usr/local/etc/httpd/htdocs>
Options ...
AllowOverride ...
</Directory>

... which *should* (though beware... I haven't checked) disable
.htaccess files server-wide, and reenable them solely in the htdocs
directory. The trouble with that arrangement is that .htaccess files
also have to be specifically reenabled for UserDirs, and without
wildcard <Directory> specs (yet ;-), it becomes difficult to do that.

Would save four stats per request! Has anyone profiled Apache/Shambhala
to see how much time is wasted on these stats per request?

Last time I tried, it seemed to get about 30% faster (with CGI scripts
disabled and factored out of the mix) if .htaccess files were disabled
completely (even the NCSA base code doesn't bother looking for them
where AllowOverride None is in effect, so you can do this in the
config files).

Some crude statistics indicated that about half of the stat()s for
.htaccess files were for the top few directories (/fs, /fs/web,
/fs/web/docs), so in my case, I figure it would ultimately save 15% to
skip those stat()s --- not overwhelming, but not chicken feed.

rst
Re: Those pesky .htaccess files [ In reply to ]
RST a while ago mentioned that if a <Directory> directive for a particular
directory was found in the global config files the .htaccess file in that
directory would not be parsed. Does NCSA do this?

As it stands any other directives in the .htaccess file (such as
AddDescription) will be ignored if there is a matching <Directory> entry!

Mark
Mark J Cox, mark@telescope.org -- URL:http://www.telescope.org/mark.html
University of Bradford, England ---------- tel +44.1274.384070/fax 391333
Re: Those pesky .htaccess files [ In reply to ]
>From: Mark J Cox <M.J.Cox@bradford.ac.uk>
>Date: Fri, 7 Jul 1995 13:01:29 +0100 (BST)

>It's a real pain that everytime someone accesses a document
>(say /usr/local/etc/httpd/docs/index.html) the server stats .htaccess
>files in /usr, /usr/local, /usr/local/etc, /usr/local/etc/httpd and
>/usr/local/etc/httpd/docs first.
>
>How about the option of caching the fact that a .htaccess file does or
>doesn't exist in each directory? You could nominate directories to
>be cached (so ~/ directories for instance wouldn't be to allow users to
>change .htaccess files immediately, others would wait until the server
>was restarted).
>
>This could be complex; but even just saying in a config file:
>
>NoAccessFile /usr
>NoAccessFile /usr/local
>NoAccessFile /usr/local/etc
>NoAccessFile /usr/local/etc/httpd
>
>Would save four stats per request! Has anyone profiled Apache/Shambhala
>to see how much time is wasted on these stats per request?

Does anyone actually rely on .htaccess files in directories above
DocumentRoot? I would rather that was disabled, but perhaps with a
compatability option.

Of course, .htaccess is a bit of a misnomer, anyway.
Part of the problem is that it can contain two types of directives;
those which could apply to a sub-tree of the directory, and those
which are only useful in the leaf directory.

e.g. consider http://a/dira/dirb/dirc/

/root/dira/.htaccess, /root/dira/dirb/.htaccess and
/root/dira/dirb/dirc/.htaccess might all contain directives such
as AuthName which would apply to subdirectories of dirc/.

However, /root/dira/dirb/dirc/.htaccess might also contain directives
specific to that directory only, such as AddDescription.

Thus, if I want to allow per-directory AddDescription directives, I have
to enable full heirachical .htaccess searching, whereas it reading a single
file in the target directory would suffice.

David.
Re: Those pesky .htaccess files [ In reply to ]
Date: Thu, 13 Jul 95 15:18 BST
From: drtr@ast.cam.ac.uk (David Robinson)

Does anyone actually rely on .htaccess files in directories above
DocumentRoot? I would rather that was disabled, but perhaps with a
compatability option.

The last time this came up, we found out that there were people like
that in the group (I dimly recall that there might have been some on
hyperreal).

One reason for this is that in the old NCSA code, there are things
which work in a .htaccess file but *not* in a directory section, at
least if I read the code right. There's none of that in Shambhala (in
Shambhala, the only difference between <Directory>... </Directory>
and a .htaccess file in the directory is that AllowOverride
restrictions apply to the latter).

rst
Re: Those pesky .htaccess files [ In reply to ]
Date: Thu, 13 Jul 1995 15:47:13 +0100 (BST)
From: Mark J Cox <M.J.Cox@bradford.ac.uk>
X-Sender: mjhcox@discovery.brad.ac.uk
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

RST a while ago mentioned that if a <Directory> directive for a particular
directory was found in the global config files the .htaccess file in that
directory would not be parsed. Does NCSA do this?

As it stands any other directives in the .htaccess file (such as
AddDescription) will be ignored if there is a matching <Directory> entry!

Hmmm... as it happens, the old NCSA code does read both <Directory>
and .htaccess info if both are present... if people are actually
relying on this, it's probably worth changing to be compatible.

rst