An Apache site whose .htaccess routes everything to a front controller starts returning 500s, and the error log reports that the request exceeded the limit of 10 internal redirects. What causes that loop, and how do you write the rule so it cannot happen?

## Why an internal rewrite comes back around A rewrite in the server configuration happens during URL-to-filename translation and is essentially done once it produces a path. A rewrite in per-directory context cannot work that way, because the substitution may map into a *different* directory — one with its own `.htaccess`, its own access control, its own rules. httpd's answer is to treat the result as an **internal redirect**: it discards the current mapping and re-runs the whole mapping phase with the new URI. That re-run includes reading and applying `.htaccess` again — including the file that just performed the rewrite. So the ruleset is offered its own output. `[L]` does not prevent this. "Last" means "stop evaluating further rules *in this pass*". It is a within-ruleset control, not a within-request one. This is the single most common misunderstanding in the topic, and it is why adding more `[L]` flags to a looping config never helps. ## The classic looping rule ```apache # /var/www/html/.htaccess — loops RewriteEngine On RewriteRule ^ index.php [L] ``` Pass 1: URI `/anything` → `/index.php`. Internal redirect. Pass 2: URI `/index.php` still matches `^` → `/index.php`. Internal redirect. Pass 3, 4, 5… identical. httpd increments a recursion counter on each internal redirect and compares it with `LimitInternalRecursion`, whose default is 10. When the count is exceeded it aborts the request with 500 and logs that the request exceeded the limit of 10 internal redirects due to a probable configuration error. Two details matter for diagnosis. First, the client sees a plain 500 — nothing about the loop travels on the wire, unlike a browser-visible redirect loop, so this is an error-log problem, not a devtools problem. Second, raising `LimitInternalRecursion` does not fix anything; it makes the server do ten times the work before returning the same 500. Treat the limit as a smoke detector, not a dial. ## Guards that actually terminate The rule must stop matching once it has done its job. The idiomatic form tests the mapped filename: ```apache RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^ index.php [L] ``` On the first pass `/anything` maps to a path with no file behind it, both conditions hold, and the rewrite happens. On the second pass `%{REQUEST_FILENAME}` is the real `/var/www/html/index.php`, the `-f` test succeeds, `!-f` fails, and the rule does not fire. The recursion terminates after exactly one internal redirect. As a bonus, the same guard is what stops the front controller from swallowing requests for real static assets. An explicit exclusion works too and is clearer when the target is not a file test: ```apache RewriteCond %{REQUEST_URI} !^/index\.php$ RewriteRule ^ index.php [L] ``` And since httpd 2.3.9 there is `[END]`: ```apache RewriteRule ^ index.php [END] ``` `[END]` stops the current pass *and* prevents any further per-directory rewriting of this request in later passes. It is the direct answer to "I want L to mean what everybody thinks L means". Use it deliberately, though: it also stops rules in *other* directories from applying, which is occasionally load-bearing. ## Loops that are not this loop Several neighbouring failures produce similar-looking symptoms and want different fixes: - **A browser-visible redirect loop.** If the rule carries `[R]`, the recursion happens in the client instead: the browser reports too many redirects, and each hop is visible in devtools or `curl -IL`. Usual causes are a rule that redirects to a URL still matching its own pattern, or two layers — an edge proxy and Apache — each trying to canonicalise scheme or trailing slash in opposite directions. - **Rules resurrected by inheritance.** A parent `.htaccess` plus `RewriteOptions InheritBefore` in a child can reintroduce a rule you thought you had scoped away, producing a loop only in one subtree. - **A rewrite target that is itself rewritten elsewhere.** Directory A rewrites into directory B, whose own `.htaccess` rewrites back. Each hop is legitimate in isolation; the cycle only exists across files, which is exactly what makes it hard to see by reading one of them. ## Debugging procedure Raise the error log level to a trace level — httpd 2.4 dropped the old `RewriteLog` directive in favour of `LogLevel` — and replay one request. The trace prints each pass, the string matched, the conditions evaluated and the substitution produced, so a loop appears as the same substitution repeating with an incrementing internal-redirect count. That transcript tells you which rule fires on the *second* pass, which is the rule that needs the guard. Reading the config alone rarely does, because the bug is not in any single rule — it is in the rule's relationship to its own output. Finally, prevention: put the `-f`/`-d` guards on every front-controller rule as a matter of house style, and prefer hoisting the ruleset into a `<Directory>` block in server config, where a mistake is caught by a config test before it ever reaches a request.