In Apache httpd, what work does the server do on every single request when .htaccess files are enabled, and how does the AllowOverride directive change it?

## What an .htaccess file is An `.htaccess` file is a fragment of Apache configuration that lives in a content directory rather than in the server's own config files. Its directives apply to that directory and everything below it. Its point is delegation: a user who can write into a document tree but has no permission to edit `httpd.conf` and no permission to reload the server can still change behaviour for their own subtree — the classic shared-hosting arrangement. That delegation is the whole benefit, and the mechanism that provides it is also the whole cost. ## The per-request directory walk Server configuration is read once, at startup or reload, and held in memory. `.htaccess` cannot work that way, because the point is that it takes effect the moment somebody saves it, with no reload. So httpd must look for it while handling the request. The lookup is not a single check on the file's own directory. httpd walks the whole filesystem path. For a document root of `/var/www/html` and a request for `/a/b/page.html`, it will look for: ``` /.htaccess /var/.htaccess /var/www/.htaccess /var/www/html/.htaccess /var/www/html/a/.htaccess /var/www/html/a/b/.htaccess ``` Six filesystem lookups, most of which normally miss. Every file that *is* found is opened, read and parsed on that request; httpd 2.4 keeps no parsed cache of them. A directive block that appears in the server config is parsed once for the lifetime of the process; the same block in `.htaccess` is parsed once per hit. Merging runs top down: the shallowest file applies first, and directives in deeper files override it. Note that this merge is *directive*-level, not file-level — but mod_rewrite is a special case worth knowing: per-directory rewrite rules are **not** inherited by a child `.htaccess` that has its own `RewriteEngine On`, unless you ask for it with `RewriteOptions Inherit`. ## What AllowOverride actually controls `AllowOverride` is valid only inside a `<Directory>` section (since 2.3.9 it is rejected anywhere else, including in `.htaccess` itself — otherwise a user could grant themselves more power). It does two jobs at once: 1. **Whether the walk happens at all.** `AllowOverride None` for a tree means httpd does not go looking for `.htaccess` in it. 2. **Which directives are permitted** when it does. The value is a set of groups: `AuthConfig`, `FileInfo`, `Indexes`, `Limit`, `Options[=...]`, or `All`. `FileInfo` is the one that matters for this topic — `RewriteRule`, `RewriteCond`, `RewriteBase`, `Redirect`, `ErrorDocument` and `Header` live there. A `.htaccess` containing a directive the current `AllowOverride` does not permit does not get quietly ignored: the request fails with 500 and the error log records the offending directive as "not allowed here". `AllowOverrideList` (2.3.11 and later) is the escape hatch for the case where you want to permit two named directives without opening a whole group. The default changed: httpd 2.2 shipped `AllowOverride All`, and 2.4 changed it to `None`. That single line is behind a large share of "my rewrite rules stopped working after the upgrade" reports — the file is still there and still correct; the server has simply stopped reading it. ## Framing the cost honestly It is easy to overstate this. The stat calls hit the operating system's directory-entry cache after the first request, so the cost is a handful of cheap syscalls per hit, not disk seeks. On a low-traffic site it is invisible. What makes it worth caring about at scale is that it is paid on *every* request including cheap static ones, it scales with path depth, and — for any `.htaccess` that actually exists — it includes re-parsing a config fragment and, for mod_rewrite, re-compiling its regular expressions. The second cost is operational rather than measurable: rules in `.htaccess` are invisible to anyone reading the server config, are not covered by `apachectl configtest`, and a typo becomes a live 500 on the next request rather than a failed reload you catch before it ships. ## The decision that follows If you control the server config and can reload it, hoist the rules into a `<Directory>` block and set `AllowOverride None`. The directives are identical apart from per-directory path handling, and they are then parsed once, reviewable, and syntax-checked before they go live. Keep `.htaccess` where the delegation is the point: shared hosting, or an application whose deploy artifact legitimately carries its own routing rules and whose team has no way to reload httpd.