An Apache rewrite rule that worked in the main server configuration stops matching after you move it into an .htaccess file: `RewriteRule ^/products/(.*)$ /catalog/$1 [L]` now never fires. Why, and what is RewriteBase for?

## Two contexts, two things being matched mod_rewrite rules can live in the server or virtual host configuration, or in per-directory context: an `.htaccess` file or a `<Directory>` block. The directives look identical. What the pattern is matched against does not. In **server context**, mod_rewrite runs early, during URL-to-filename translation, and the rule matches the URL path exactly as it appeared in the request: `/products/widget`, leading slash and all. In **per-directory context**, mod_rewrite runs later — after httpd has already worked out which directory the request maps into. By then the directory prefix is redundant, so mod_rewrite removes it, along with the leading slash. In `/var/www/html/products/.htaccess`, with a document root of `/var/www/html`, a request for `/products/widget` is matched against the string `widget`. That is the entire explanation for the reported symptom. `^/products/(.*)$` demands a leading slash the string does not have, and demands a prefix that has already been removed. It matches nothing, and mod_rewrite reports nothing, because a rule that does not match is not an error. The rule is simply inert. ```apache # /var/www/html/products/.htaccess RewriteEngine On # Never matches: the leading slash and the prefix are gone by now. # RewriteRule ^/products/(.*)$ /catalog/$1 [L] # Matches: the pattern sees "widget" for a request to /products/widget. RewriteRule ^(.*)$ /catalog/$1 [L] ``` A related consequence: because per-directory rules run after translation, they are working with a URL that has already been mapped to a file. This is why `%{REQUEST_FILENAME}` is meaningful in `.htaccess` guards and why the `-f` and `-d` tests are the idiomatic way to say "only rewrite if there is no real file here". ## What RewriteBase actually does The stripped prefix has to come back at some point, because the substitution has to name something the server can map. mod_rewrite handles this by prepending a base to any substitution that is *relative* — one that does not begin with a slash or a scheme. When you do not set `RewriteBase`, httpd derives that base from the physical directory's path relative to the document root. For an ordinary tree that is right, and you never need the directive. It becomes wrong when the URL path and the filesystem path are not the same string: - The directory is reached through an `Alias`, so `/shop/` on the URL side is `/srv/apps/shop/` on disk. - The tree is symlinked into the document root from elsewhere. - The application is mounted under a path prefix that does not correspond to a real directory of that name. In those cases a relative substitution expands against a base that does not exist as a URL, and the result is a 404, or the internal path leaking into a redirect — the classic symptom of the server's filesystem layout appearing in the browser's address bar. ```apache # /srv/apps/shop/.htaccess, reachable at https://example.com/shop/ RewriteEngine On RewriteBase /shop/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^ index.php [L] ``` Here the substitution `index.php` is relative, so it becomes `/shop/index.php`. Without the `RewriteBase`, mod_rewrite would try to build the base from `/srv/apps/shop/` and get something that is not a URL on this site at all. The sidestep is worth knowing: write substitutions as absolute URL paths (`/shop/index.php`) and `RewriteBase` becomes unnecessary, because nothing needs a base prepended. Many teams standardise on that precisely to remove a class of subtle breakage. `RewriteBase` earns its place when the same rule set must be droppable into different mount points, where a relative substitution plus one declared base is genuinely more portable than absolute paths edited per deployment. ## The other per-directory prerequisites Two more things must be true before per-directory rules run at all, and both produce "my rules do nothing" reports of their own: - **`AllowOverride` must permit `FileInfo`** for that tree, or httpd never reads the file — or, if it reads it and the directive is not permitted, fails the request with 500 and logs the directive as not allowed. - **`Options FollowSymLinks` (or `SymLinksIfOwnerMatch`) must be enabled.** With both off, mod_rewrite refuses to run per-directory rules and logs that the `RewriteRule` directive is forbidden because those options are off. The reason is security: a per-directory rewrite can point at a path outside the tree, and the symlink options are the existing control for that class of escape. Finally, rewrite configuration is not inherited the way most directives are. If a child directory has its own `.htaccess` with `RewriteEngine On`, the parent's per-directory rules do not apply to it unless you ask, with `RewriteOptions Inherit` (or `InheritBefore`). A rule that "stops working in one subdirectory only" is very often this. ## How to debug it in practice Do not guess at the matched string — read it. httpd 2.4 removed `RewriteLog`; you raise `LogLevel` to a trace level instead, and the error log then prints, per rule, the string mod_rewrite matched against and what it substituted. Seeing `widget` where you expected `/products/widget` ends the argument in one line, and it is the fastest route through every per-directory surprise in this topic.