Tech Tip of the Day: mod_rewrite & AllowOverride
Recently, an upgrade of the OS on the commavee server resulted in the blog post URLs failure to resolve. Earlier blog posts, with the date-and-post title formatted URL, were now unresolvable. This meant that every post in the search engines (and even the site itself) resulted in a 404 Not found error. It took a bit of investigation, but the solution was straight-forward.
Background
For reasons unrelated to the blog itself, the operating system was upgraded. This was a major operation that changed virtually *everything* on the server, from the kernel outward. Among the many packages that were upgraded was Apache, which previously had been at a very stable 1.3.33 for a very long time.
I have blogged about this already, so I will stay focused here on the singular issue of the blog URLs. When Apache was upgraded to 2.0, it brought in a completely new conf file. No big deal; I have dealt with conf files for years, and long ago began using conf.d files for site configuration. My main httpd.conf file could be pretty basic as long as I had this line somewhere in it:
Include conf.d/*.conf
This allows me to create custom configurations and drop them into the server as needed. So, I had grown to pay little attention to the actual httpd.conf file itself, whose basic configuration hadn’t changed for several years.
It did change with the upgrade, of course. Apache, by default, configures / (DocumentRoot as a result) with very limited permissions. You, as the server admin, must specifically allow actions against your server by configuring them. One of the typical mechanisms for allowing actions in your server directories is the AllowOverride directive. By applying the AllowOverride to a directory definition in your conf file, you instruct the server on how to handle override requests for that directory.
If AllowOverride is set to None, no overrides are allowed ever. This means that directory-level access controls and behaviors, as implemented in a directory-specific .htaccess file, will never be executed. That’s exactly what was occuring now with the blog post URLs – the mod_rewrite rule that made the URLs easily readable – was implemented in an .htaccess file that was now *never* going to be executed, because Apache’s default rule for that directory was set to allow no overrides.
Solution
Passing the parameter ‘All’ to the AllowOverride directive and restarting Apache resolved this issue. The old blog post URLs worked again, because the mod_rewrite rule in the .htaccess file was now being executed.
Here’s the code snippet:
<Directory>
Options FollowSymLinks
AllowOverride All
</Directory>
Tags: freepository, apache, mod_rewrite, tech tip
Popularity: 6% [?]