Don't Panic — Apache HTTP Server

Almost nobody adopts Apache any more; it gets inherited. A configuration written years ago, extended twice, documented never, currently serving something the organisation would notice losing. So the skill worth acquiring is archaeology: knowing which setting wins, which module is quietly loaded, and how to prove what the server will do before restarting it.

Underneath, there is startlingly little server. Connection handling and coordination are all the core does. Everything anyone would call a feature — TLS, rewriting, authentication, proxying, compression — arrives as a module hooking a defined stage of the request, and the individual configuration lines, called directives, decide which modules act on which requests.

That is why one installation can serve files, run applications and forward traffic to other servers at once, and equally why its characteristic failure is combination rather than error. httpd -M lists what is genuinely loaded, which beats reading any single file.

One module is special. Exactly one multi-processing module is active, and it decides how work is accepted and dispatched: prefork uses separate processes with no threads, worker puts threads inside processes, event adds asynchronous handling of some connection work.

That is an architectural choice rather than a speed switch, and it is where the largest inherited win usually hides. Apache's own documentation is blunt that under prefork the HTTP/2 module handles one request at a time per connection, and that prefork is chosen today only for processing engines that would crash if threaded — meaning PHP running inside the server. Moving off it is often the biggest available improvement, and it stalls for years because nobody owns it.

Then the containers, the configuration blocks that scope a rule to part of the server. <Directory> and <Files> match things on disk. <Location> matches URL space whether or not a file exists there. <VirtualHost> selects a site. Protect files with the disk-based ones, because a URL can arrive at a file by more than one route, so a <Location> restriction alone may protect nothing.

Here is the fact that surprises people and keeps surprising them. No file on disk contains the configuration that applies to a request. Policy is assembled at request time from the main config, the matched virtual host, the containers above, any per-directory overrides, and each module's own merge order.

So a change process where somebody reads a diff and nods is theatre: the diff is real, the conclusion drawn from it is a guess. The parsed virtual-host dump from apachectl -S, and a traced request against the running server, are the only honest evidence.

Two habits follow. Run apachectl configtest before every reload, and apply with apachectl graceful so requests already in flight finish. And count the per-directory .htaccess override files under the served directories: zero means central policy is real and reviewable, hundreds means access control is editable by anyone who can write a file there.

Look up directives and control commands on the Cheatsheet, and let the Intro give scope merging and the request path the room they need. Field Notes is about the staffing bill nobody budgets for.

Don't Panic — Apache HTTP Server

Relevant careers