||Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix|
|News||Web servers||Recommended Books||Recommended Links||.htaccess file||mod rewrite||Troubleshooting|
|Modules||mod rewrite||mod_security||Apache .htaccess file||Using deny directive in apache .htaccess||Referrer Spam||Apache Security|
|Installation||Startup and shutdown||Perl HTTP Logs Processing Scripts||Apache authentication and authorization using LDAP||Server Side Includes (SSI)|
|HTTP Return Codes||Using Apache 1.3 with Cygwin||Compiling Apache 1.3 on AIX||Compiling Apache 2.2.8 on AIX||Content management||Cheap Web hosting with SSH access||Web site monitoring|
|Sysadmin Horror Stories||The Corporate Jungles Of Cubonia||Communication Skills and Basic Competencies Courses for Programmmer's Wives||Ten Commandments of the IT Slackers Society||Humor||Random Findings||Etc|
The Apache Web Server was originally created in 1995. It was based on the earlier NCSA server, written by the National Center for Supercomputing Applications (which also developed the Mosaic browser, predecessor to most of today's browsers, with a direct line to Netscape and Mozilla).
Apache runs as a permanent background task: a daemon (UNIX) or service (Windows). Start-up is a slow and expensive operation, so for an operational server, it is usual for Apache to start at system boot and remain permanently up. Early versions of Apache had documented support for an inetd mode (run from a generic superserver for every incoming request), but this mode was never appropriate for operational use.
The first applications development framework were dominated by Perl, under both CGI and mod_perl. Application developers concentrated on Perl, because mod_perl presented the first really useful and easy-to-use API. The Java Servlet API and numerous other scripting languages, including the current market leader PHP, soon followed.
The native API is much improved and the APR library is a separate entity. This helps programmers overcome most of the drawbacks of C programming—in particular, the problems of cross-platform programming and resource management. Working with Apache 2, C programmers can expect levels of productivity more commonly associated with higher-level and scripting languages.
A new extension architecture enables development of a whole new class of applications, as well as far cleaner implementations of existing modules and applications. This book will discuss in detail how to take advantage of this extension architecture.
A new core architecture makes Apache 2 a truly cross-platform server. The operating system layer has itself become a module (the MPM), enabling it to be separately tuned for each operating system. Whereas Apache 1 was a UNIX application that was ported with many limitations to other platforms, Apache 2 is truly cross-platform and is not tied to UNIX features, some of which perform poorly on, for example, Windows or Netware. The introduction of threaded MPMs also improves scalability on UNIX in many applications.
The downside of Apache 2 is that the API is not backward compatible with Apache 1.3, so many third-party modules and applications have been slow to upgrade to version 2.
file consists of directives in plain text configuration files. The main configuration
file is usually called
httpd.conf. The location of this file
is set at compile-time, but may be overridden with the
line flag. Some sites also have
historical reasons. In addition, other configuration files may be added
Include directive. Any directive may be placed in any of these
configuration files. Changes to the main configuration files are only recognized
by Apache when it is started or restarted.
Starting with Apache 1.3.13 any configuration file can actually be a directory, Apache will enter that directory and parse any files (and subdirectories) found there as configuration files. One possible use for this would be to add VirtualHosts by creating small configuration files for each host, and placing them in such a configuration directory. Thus, you can add or remove VirtualHosts without editing any files at all, simply adding or deleting them. This makes automating such processes much easier.
The server also reads a file containing mime document types; the filename
is set by the
TypesConfig directive, and is
mime.types by default.
Apache configuration files contain one directive per line. The back-slash "\" may be used as the last character on a line to indicate that the directive continues onto the next line. There must be no other characters or white space between the back-slash and the end of the line.
Directives in the configuration files are case-insensitive, but arguments to directives are often case sensitive. Lines which begin with the hash character "#" are considered comments, and are ignored. Comments may not be included on a line after a configuration directive. Blank lines and white space occurring before a directive are ignored, so you may indent directives for clarity.
You can check your configuration files for syntax errors without starting
the server by using
apachectl configtest or the
command line option.
Apache is a modular server. This implies that only the most basic functionality is included in the core server. Extended features are available through modules which can be loaded into Apache. By default, a base set of modules is included in the server at compile-time. If the server is compiled to use dynamically loaded modules, then modules can be compiled separately and added at any time using the LoadModule directive. Otherwise, Apache must be recompiled to add or remove modules. Configuration directives may be included conditional on a presence of a particular module by enclosing them in an <IfModule> block.
To see which modules are currently compiled into the server, you can
-l command line option.
Directives placed in the main configuration files apply to the entire
server. If you wish to change the configuration for only a part of the server,
you can scope your directives by placing them in
<LocationMatch> sections. These sections limit the application
of the directives which they enclose to particular filesystem locations
or URLs. They can also be nested, allowing for very fine grained configuration.
Apache has the capability to serve many different websites simultaneously.
This is called
Hosting. Directives can also be scoped by placing them inside
<VirtualHost> sections, so that they will only apply to requests
for a particular website.
Although most directives can be placed in any of these sections, some directives do not make sense in some contexts. For example, directives controlling process creation can only be placed in the main server context. To find which directives can be placed in which sections, check the Context of the directive. For further information, we provide details on How Directory, Location and Files sections work.
Apache allows for decentralized management of configuration via special
files placed inside the web tree. The special files are usually called
.htaccess, but any name can be specified in the
AccessFileName directive. Directives placed in
files apply to the directory where you place the file, and all sub-directories.
.htaccess files follow the same syntax as the main configuration
.htaccess files are read on every request, changes
made in these files take immediate effect.
To find which directives can be placed in
Context of the directive. The server administrator further controls
what directives may be placed in
.htaccess files by configuring
AllowOverride directive in the main configuration files.
For more information on
.htaccess files, see Ken Coar's
Using .htaccess Files with Apache, or the
.htaccess tutorial in the Apache docs.