In Apache HTTP Server 2.0, the module system has been changed to allow modules to be chained together or combined in new and interesting ways. Common Gateway Interface (CGI) scripts, for example, can generate server-parsed HTML documents which can then be processed by
mod_include. This opens up a tremendous number of possibilities with regards to how modules can be combined to achieve a specific goal.
The way this works is that each request is served by exactly one handler module followed by zero or more filter modules.
Under Apache HTTP Server 1.3, for example, a Perl script would be handled in its entirety by the Perl module (
mod_perl). Under Apache HTTP Server 2.0, the request is initially handled by the core module — which serves static files — and is then filtered by
Exactly how to use this, and all other new features of Apache HTTP Server 2.0, is beyond the scope of this document; however, the change has ramifications if the
PATH_INFO directive is used for a document which is handled by a module that is now implemented as a filter, as each contains trailing path information after the true file name. The core module, which initially handles the request, does not by default understand
PATH_INFO and returns
404 Not Found errors for requests that contain such information. As an alternative, use the
AcceptPathInfo directive to coerce the core module into accepting requests with
The following is an example of this directive:
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
In Apache HTTP Server 2.0, the
mod_suexec module uses the
SuexecUserGroup directive, rather than the
Group directives, which is used for configuring virtual hosts. The
Group directives can still be used in general, but are deprecated for configuring virtual hosts.
For example, the following is a sample Apache HTTP Server 1.3 directive:
To migrate this setting to Apache HTTP Server 2.0, use the following structure:
SuexecUserGroup someone somegroup