Apache - basic control and behaviour

From Helpful
Jump to navigation Jump to search

Related to web development, lower level hosting, and such: (See also the webdev category)

Lower levels

Server stuff:

Higher levels

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

service commands

  • Start
  • Stop
  • Graceful restart
    • idea: minimize downtime while reloading config and re-opening log files, by
      • first doinga configtest - don't move on if that fails(verify)
      • then doing apachectl -k graceful, which sends SIGUSR1
    • also, it only advises children to stop after their current requests; each is replaced as soon as they stop (verify).
    • It's possible for there to be a short time in which no new connections are served
    • things that are not strictly apache children (processes started for/by dynamic scripting and such) may stall for relatively long (consider e.g. keepalive)
  • basic/hard restart
    • first does a configtest
    • does apachectl -k restart, which sends SIGHUP

Not all startup/init scripts are set up the same way. For example, some interpret restart as graceful restart, others as a hard restart.


phases and handlers

Apache does things in phases - see e.g. this image (from here).

Phases are steps that handle single concepts. Each phase consists usually of one, but possibly multiple handlers. Apache's defaults are usually 'do nothing' (e.g. for authentication) or are very simple things such as returning a file from the file system. In the case of serving files, the phases involved are roughly:

  • Translating the request URI into a file location
  • Read file and send out ('main' phase)
  • Logging the request

Phases and handlers are essentially a transformation chain. Seen another way it is a tree in which the first-deep nodes are phases (their names) and the second level are handlers. Each of the (again, possibly multiple) handlers can ask apache to skip further handlers in the same phase.

Note that authentication may be abbreviated as AuthN (or auth), while authorization is often abbreviated as AuthZ. This is where the separate phases come from. In dynamic systems it's common to do the authorization yourself, and often the authentication as well. Authentication is useful in that the user/password exchange is supported by all serious user agents, and thereby standardized.

All handling (virtual directories, url rewriting, module handling) fit into this model somehow, usually in a single handler, and in some complex setups involving multiple handlers and/or multiple phases (the magical mod_rewrite sits in two phases, for example).