.htaccess
.htaccess file lets you apply Apache configuration to a specific folder just by placing a plain text file inside it -- no access to the main server config needed, which is why shared hosting relies on it so heavily.In this page:
What .htaccess Is For
On shared hosting, customers typically can't edit httpd.conf -- they don't have server access at all, just an FTP/SFTP connection to their own files. A .htaccess file dropped into any directory lets them set redirects, custom error pages, access rules, and rewrite rules for that directory (and its subdirectories) without needing anything more.
It Only Works If AllowOverride Says So
A .htaccess file does nothing on its own -- Apache only reads it if the enclosing <Directory> in the main config has AllowOverride set to something other than None for that context. AllowOverride All lets it override anything; more specific values like AllowOverride FileInfo AuthConfig restrict which categories of directive it's allowed to touch.
.htaccess support question is "why isn't my .htaccess doing anything" -- and the answer is almost always AllowOverride None on that directory.Common Uses
The classic use is URL rewriting for clean URLs (covered fully in the mod_rewrite and URL Rewriting lessons), plus custom error pages (ErrorDocument 404 /404.html), password-protecting a directory with AuthType Basic, redirecting old URLs to new ones, and setting caching headers for static assets.
The Performance Cost
Because .htaccess files can live in any directory and its subdirectories, Apache has to check for one on essentially every single request, walking up the directory tree each time. If you control the server directly, putting the equivalent rules straight into a <Directory> block in the main config (or a VirtualHost) is faster, since Apache only has to parse that once at startup, not on every request.
Inheritance and Precedence
.htaccess rules apply to the directory they're in and everything below it, and a .htaccess file in a subdirectory is layered on top of (and can override) one further up the tree -- the same nesting behavior as <Directory> blocks in the main config, just distributed across the filesystem instead of one file.
Example: A typical .htaccess file
# .htaccess in the site's document root
# Custom error page
ErrorDocument 404 /404.html
# Redirect an old URL to a new one
Redirect 301 /old-page.html /new-page.html
# Prevent this folder's contents from being listed
Options -Indexes
{# Flagged by hand after confirming a runner can't handle this example
(a shell command / go.mod file stored as a TopicExample, a language
feature the configured runner version doesn't support, or output
that blows a runner's sandbox limit) -- see TopicExample.norun.
Never render the run button for these, regardless of language,
since it would just fail at execute_code (or worse, hang the
Judge0 queue on a submission that can never finish cleanly). #}
- Adding rules to .htaccess and being confused when nothing happens, without checking that AllowOverride actually permits it for that directory.
- Using .htaccess for performance-sensitive, server-wide rules when you have full access to httpd.conf -- every request pays the cost of Apache re-checking for .htaccess files up the directory tree.
- A syntax error in .htaccess (unlike a syntax error in the main config) can produce a 500 Internal Server Error on every request to that directory immediately, with no configtest step to catch it first.
- httpd.conf (and the files it Includes) is Apache's central configuration, setting things like the port to Listen on and the DocumentRoot, and should always be checked with
configtestbefore reloading. - Virtual Hosts let one Apache server host multiple independent sites, matched by the Host header the browser sends, while Directory blocks and .htaccess apply rules -- access control, Options, rewrite rules -- to specific folders, with .htaccess as the option for when you can't edit the main config directly.
Chapter Quiz — Complete all 4 topics to unlock
0/4 topics done
Complete these topics first: