What’s the point of the default .htaccess?

That’s a very insightful and detailed analysis of the default WordPress .htaccess rules! You’ve hit on some common points of confusion and raised excellent questions about their apparent utility. Let’s break down each of your observations to clarify the “point” of these rules, especially in the context of how WordPress and similar PHP applications function.

Here’s an explanation for each rule you’ve listed:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

1. RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

• Your Observation: “This is pointless, since the variable isn’t exported with a SetEnv, and isn’t used in this .htaccess.”
• The Point: You are correct that this variable isn’t used within the .htaccess file itself, nor is it explicitly exported with SetEnv. However, its purpose is crucial for PHP applications, especially when PHP is running as a CGI or FastCGI module (which is common on shared hosting).
  • Apache and Authorization Headers: By default, Apache might strip the Authorization header when passing requests to CGI/FastCGI processes for security reasons.
  • PHP’s Need: Many applications, including WordPress (especially for its REST API), rely on the Authorization header for authentication (e.g., Basic Auth, Bearer tokens).
  • How it Works: This RewriteRule explicitly captures the Authorization header and sets it as an internal Apache environment variable named HTTP_AUTHORIZATION. PHP, when configured correctly, can then access this variable via $_SERVER['HTTP_AUTHORIZATION']. Without this rule, the Authorization header might not be available to the PHP script, breaking authentication for certain requests. So, it’s not pointless; it’s a necessary workaround for a common server configuration issue.

2. RewriteRule ^index\.php$ - [L]

• Your Observation: “If you ask for index.php that’s exactly what you get.”
• The Point: This rule is a critical optimization and loop prevention mechanism.
  • Preventing Infinite Loops: The subsequent rule (RewriteRule . /index.php [L]) is designed to rewrite other URLs to index.php. If a request for index.php itself were to fall through to that rule, it could potentially be rewritten to index.php again, leading to an infinite rewrite loop.
  • Efficiency: By explicitly saying “if the request is already index.php, stop processing rewrite rules ([L] flag),” Apache avoids unnecessary processing and ensures that direct requests for index.php are served immediately without going through the rewrite engine’s logic for non-existent files.

3. RewriteCond %{REQUEST_FILENAME} !-f and RewriteCond %{REQUEST_FILENAME} !-d followed by RewriteRule . /index.php [L]

• Your Observation: “If you ask for something that isn’t a file or a directory, you instead get index.php. Or, to be more precise, you would get index.php, if the . had been correctly entered as .*. Again pointless, as your Apache setup will already have a 404 response, which is arguably better than going to your home page.”
• The Point (The Core of “Pretty Permalinks”): This is the most fundamental part of how WordPress (and many other modern PHP frameworks like Laravel, Symfony, etc.) achieves “pretty URLs” and operates as a “front controller.”
  • RewriteCond Explained:
    • RewriteCond %{REQUEST_FILENAME} !-f: This condition checks if the requested URI (e.g., /my-awesome-post) does not correspond to an existing physical file on the server.
    • RewriteCond %{REQUEST_FILENAME} !-d: This condition checks if the requested URI does not correspond to an existing physical directory on the server.
  • RewriteRule . /index.php [L] Explained:
    • Regex .: In the context of these preceding RewriteCond directives, the . (which matches any single character except newline) effectively acts as a catch-all. If the request is not for an existing file or directory, then any remaining request path will match this rule. It doesn’t need to be .* because the conditions have already filtered out the “real” files and directories. The [L] flag ensures no further rules are processed after this rewrite.
    • The “Front Controller” Pattern: This is the crucial part. When you request example.com/my-awesome-post, there isn’t a physical file named my-awesome-post on your server. Instead of Apache serving a 404 error, these rules intercept the request. They say: “If this isn’t a real file or directory, then internally rewrite the request to index.php.”
    • How WordPress Uses It: index.php then becomes the single entry point for all dynamic requests. When index.php is executed, WordPress inspects the original request URI (/my-awesome-post in this example), queries its database to find the post associated with that “slug,” and then dynamically generates the content for that post.
  • Why not a 404? If Apache simply returned a 404, WordPress would never get a chance to process the request for my-awesome-post. The entire concept of “pretty permalinks” (e.g., example.com/category/post-title) relies on this internal rewriting to a central PHP script that then dispatches the request to the correct content handler. It’s not about going to the “home page” (though index.php is often the home page), but about letting the application handle the routing for dynamic content.

4. WordPress’s Inability to Write .htaccess

• Your Observation: “If your site is locked down, you don’t get the ‘default’ .htaccess anyway, because WordPress can’t write it, and complains about it. Which doesn’t stop anything from working. And I don’t imagine anyone here would allow PHP code to write to their .htaccess files anyway.”
• The Point:
  • Why WordPress Complains: WordPress does complain because it needs to write these rules for permalinks to function correctly. If it can’t write them, your permalinks will either default to the “ugly” ?p=123 format or, if you try to use custom permalink structures, those custom URLs simply won’t work (they’ll likely result in 404s from Apache, not WordPress).
  • “Doesn’t Stop Anything From Working”: This suggests one of two things:
    1. You are using the “Plain” permalink structure (?p=123), which doesn’t require .htaccess rewrite rules.
    2. Your server’s main configuration (e.g., httpd.conf or a virtual host file) already includes similar rewrite rules that apply to your WordPress installation, effectively making the .htaccess redundant for this specific function. This is a common setup on some managed hosting environments.
  • PHP Writing to .htaccess: While some administrators prefer manual control for security and stability, it is an extremely common and accepted practice for CMSs like WordPress, Joomla, Drupal, etc., to write to .htaccess. It simplifies the configuration of permalinks, caching rules, security directives, and other features, making it much easier for non-technical users to set up and manage their sites without needing direct server access. The alternative would be manual configuration of httpd.conf, which requires server-level permissions and restarts, making it impractical for most shared hosting users.

Conclusion

You haven’t missed anything in your detailed observation of the rules themselves. The “point” of the default .htaccess (specifically the WordPress version) isn’t immediately obvious without understanding the underlying architecture of how modern PHP applications handle URLs and requests.

It’s not about modifying URLs in the browser’s address bar, but about internally routing requests to a central application file (index.php) that then takes over the responsibility of parsing the URL, fetching content, and serving the correct dynamic page. The other rules are crucial for ensuring this process is secure, efficient, and compatible with various server environments.