This module provides SSL v2/v3 and TLS v1 support for the Apache +HTTP Server. It was contributed by Ralf S. Engeschall based on his +mod_ssl project and originally derived from work by Ben Laurie.
+ +This module relies on OpenSSL +to provide the cryptography engine.
+ +Further details, discussion, and examples are provided in the +SSL documentation.
+This module provides a lot of SSL information as additional environment +variables to the SSI and CGI namespace. The generated variables are listed in +the table below. For backward compatibility the information can +be made available under different names, too. Look in the Compatibility chapter for details on the +compatibility variables.
+ +
+
|
When %{varname}x''
+eXtension format function which can be used to expand any variables
+provided by any module, especially those provided by mod_ssl which can
+you find in the above table.
+For backward compatibility there is additionally a special
+``%{name}c'' cryptography format function
+provided. Information about this function is provided in the Compatibility chapter.
+Example:
+
+When Apache starts up it has to read the various Certificate (see
+
builtin
+ + This is the default where an interactive terminal dialog occurs at startup + time just before Apache detaches from the terminal. Here the administrator + has to manually enter the Pass Phrase for each encrypted Private Key file. + Because a lot of SSL-enabled virtual hosts can be configured, the + following reuse-scheme is used to minimize the dialog: When a Private Key + file is encrypted, all known Pass Phrases (at the beginning there are + none, of course) are tried. If one of those known Pass Phrases succeeds no + dialog pops up for this particular Private Key file. If none succeeded, + another Pass Phrase is queried on the terminal and remembered for the next + round (where it perhaps can be reused).
++ This scheme allows mod_ssl to be maximally flexible (because for N encrypted + Private Key files you can use N different Pass Phrases - but then + you have to enter all of them, of course) while minimizing the terminal + dialog (i.e. when you use a single Pass Phrase for all N Private Key files + this Pass Phrase is queried only once).
exec:/path/to/program
+
+ Here an external program is configured which is called at startup for each
+ encrypted Private Key file. It is called with two arguments (the first is
+ of the form ``servername:portnumber'', the second is either
+ ``RSA'' or ``DSA''), which indicate for which
+ server and algorithm it has to print the corresponding Pass Phrase to
+ stdout. The intent is that this external program first runs
+ security checks to make sure that the system is not compromised by an
+ attacker, and only when these checks were passed successfully it provides
+ the Pass Phrase.
+ Both these security checks, and the way the Pass Phrase is determined, can
+ be as complex as you like. Mod_ssl just defines the interface: an
+ executable program which provides the Pass Phrase on stdout.
+ Nothing more or less! So, if you're really paranoid about security, here
+ is your interface. Anything else has to be left as an exercise to the
+ administrator, because local security requirements are so different.
+ The reuse-algorithm above is used here, too. In other words: The external + program is called only once per unique Pass Phrase.
+Example:
++This configures the SSL engine's semaphore (aka. lock) which is used for mutual +exclusion of operations which have to be done in a synchronized way between the +pre-forked Apache server processes. This directive can only be used in the +global server context because it's only useful to have one global mutex.
++The following Mutex types are available:
+none
+ + This is the default where no Mutex is used at all. Use it at your own + risk. But because currently the Mutex is mainly used for synchronizing + write access to the SSL Session Cache you can live without it as long + as you accept a sometimes garbled Session Cache. So it's not recommended + to leave this the default. Instead configure a real Mutex.
file:/path/to/mutex
+
+ This is the portable and (under Unix) always provided Mutex variant where
+ a physical (lock-)file is used as the Mutex. Always use a local disk
+ filesystem for /path/to/mutex and never a file residing on a
+ NFS- or AFS-filesystem. Note: Internally, the Process ID (PID) of the
+ Apache parent process is automatically appended to
+ /path/to/mutex to make it unique, so you don't have to worry
+ about conflicts yourself. Notice that this type of mutex is not available
+ under the Win32 environment. There you have to use the semaphore
+ mutex.
sem
+ + This is the most elegant but also most non-portable Mutex variant where a + SysV IPC Semaphore (under Unix) and a Windows Mutex (under Win32) is used + when possible. It is only available when the underlying platform + supports it.
+This configures one or more sources for seeding the Pseudo Random Number
+Generator (PRNG) in OpenSSL at startup time (context is
+startup) and/or just before a new SSL connection is established
+(context is connect). This directive can only be used
+in the global server context because the PRNG is a global facility.
+The following source variants are available:
+builtin
+ This is the always available builtin seeding source. It's usage + consumes minimum CPU cycles under runtime and hence can be always used + without drawbacks. The source used for seeding the PRNG contains of the + current time, the current process id and (when applicable) a randomly + choosen 1KB extract of the inter-process scoreboard structure of Apache. + The drawback is that this is not really a strong source and at startup + time (where the scoreboard is still not available) this source just + produces a few bytes of entropy. So you should always, at least for the + startup, use an additional seeding source.
file:/path/to/source
+
+ This variant uses an external file /path/to/source as the
+ source for seeding the PRNG. When bytes is specified, only the
+ first bytes number of bytes of the file form the entropy (and
+ bytes is given to /path/to/source as the first
+ argument). When bytes is not specified the whole file forms the
+ entropy (and 0 is given to /path/to/source as
+ the first argument). Use this especially at startup time, for instance
+ with an available /dev/random and/or
+ /dev/urandom devices (which usually exist on modern Unix
+ derivates like FreeBSD and Linux).
+ But be careful: Usually /dev/random provides only as
+ much entropy data as it actually has, i.e. when you request 512 bytes of
+ entropy, but the device currently has only 100 bytes available two things
+ can happen: On some platforms you receive only the 100 bytes while on
+ other platforms the read blocks until enough bytes are available (which
+ can take a long time). Here using an existing /dev/urandom is
+ better, because it never blocks and actually gives the amount of requested
+ data. The drawback is just that the quality of the received data may not
+ be the best.
+ On some platforms like FreeBSD one can even control how the entropy is
+ actually generated, i.e. by which system interrupts. More details one can
+ find under rndcontrol(8) on those platforms. Alternatively, when
+ your system lacks such a random device, you can use tool
+ like EGD
+ (Entropy Gathering Daemon) and run it's client program with the
+ exec:/path/to/program/ variant (see below) or use
+ egd:/path/to/egd-socket (see below).
exec:/path/to/program
+
+ This variant uses an external executable
+ /path/to/program as the source for seeding the
+ PRNG. When bytes is specified, only the first
+ bytes number of bytes of its stdout contents
+ form the entropy. When bytes is not specified, the
+ entirety of the data produced on stdout form the
+ entropy. Use this only at startup time when you need a very strong
+ seeding with the help of an external program (for instance as in
+ the example above with the truerand utility you can
+ find in the mod_ssl distribution which is based on the AT&T
+ truerand library). Using this in the connection context
+ slows down the server too dramatically, of course. So usually you
+ should avoid using external programs in that context.
egd:/path/to/egd-socket (Unix only)
+ + This variant uses the Unix domain socket of the + external Entropy Gathering Daemon (EGD) (see http://www.lothar.com/tech + /crypto/) to seed the PRNG. Use this if no random device exists + on your platform.
+This configures the storage type of the global/inter-process SSL Session +Cache. This cache is an optional facility which speeds up parallel request +processing. For requests to the same server process (via HTTP keep-alive), +OpenSSL already caches the SSL session information locally. But because modern +clients request inlined images and other data via parallel requests (usually +up to four parallel requests are common) those requests are served by +different pre-forked server processes. Here an inter-process cache +helps to avoid unneccessary session handshakes.
++The following two storage types are currently supported:
+none
+ + This is the default and just disables the global/inter-process Session + Cache. There is no drawback in functionality, but a noticeable speed + penalty can be observed.
dbm:/path/to/datafile
+ + This makes use of a DBM hashfile on the local disk to synchronize the + local OpenSSL memory caches of the server processes. The slight increase + in I/O on the server results in a visible request speedup for your + clients, so this type of storage is generally recommended.
shm:/path/to/datafile[(size)]
+
+ This makes use of a high-performance hash table (approx. size bytes
+ in size) inside a shared memory segment in RAM (established via
+ /path/to/datafile) to synchronize the local OpenSSL memory
+ caches of the server processes. This storage type is not available on all
+ platforms. See the mod_ssl INSTALL document for details on
+ how to build Apache+EAPI with shared memory support.
+This directive sets the timeout in seconds for the information stored in the +global/inter-process SSL Session Cache and the OpenSSL internal memory cache. +It can be set as low as 15 for testing, but should be set to higher +values like 300 in real life.
+
+This directive toggles the usage of the SSL/TLS Protocol Engine. This
+is usually used inside a
+This directive can be used to control the SSL protocol flavors mod_ssl should +use when establishing its server environment. Clients then can only connect +with one of the provided protocols.
++The available (case-insensitive) protocols are:
+SSLv2
+ + This is the Secure Sockets Layer (SSL) protocol, version 2.0. It is the + original SSL protocol as designed by Netscape Corporation.
SSLv3
+ + This is the Secure Sockets Layer (SSL) protocol, version 3.0. It is the + successor to SSLv2 and the currently (as of February 1999) de-facto + standardized SSL protocol from Netscape Corporation. It's supported by + almost all popular browsers.
TLSv1
+ + This is the Transport Layer Security (TLS) protocol, version 1.0. It is the + successor to SSLv3 and currently (as of February 1999) still under + construction by the Internet Engineering Task Force (IETF). It's still + not supported by any popular browsers.
All
+
+ This is a shortcut for ``+SSLv2 +SSLv3 +TLSv1'' and a
+ convinient way for enabling all protocols except one when used in
+ combination with the minus sign on a protocol as the example above
+ shows.
+This complex directive uses a colon-separated cipher-spec string +consisting of OpenSSL cipher specifications to configure the Cipher Suite the +client is permitted to negotiate in the SSL handshake phase. Notice that this +directive can be used both in per-server and per-directory context. In +per-server context it applies to the standard SSL handshake when a connection +is established. In per-directory context it forces a SSL renegotation with the +reconfigured Cipher Suite after the HTTP request was read but before the HTTP +response is sent.
++An SSL cipher specification in cipher-spec is composed of 4 major +attributes plus a few extra minor ones:
+An SSL cipher can also be an export cipher and is either a SSLv2 or SSLv3/TLSv1 +cipher (here TLSv1 is equivalent to SSLv3). To specify which ciphers to use, +one can either specify all the Ciphers, one at a time, or use aliases to +specify the preference and order for the ciphers (see Table +1).
+ +
+
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
+Now where this becomes interesting is that these can be put together
+to specify the order and ciphers you wish to use. To speed this up
+there are also aliases (SSLv2, SSLv3, TLSv1, EXP, LOW, MEDIUM,
+HIGH) for certain groups of ciphers. These tags can be joined
+together with prefixes to form the cipher-spec. Available
+prefixes are:
+: add ciphers to list and pull them to current location in list-: remove cipher from list (can be added later again)!: kill cipher from list completely (can not be added later again)A simpler way to look at all of this is to use the ``openssl ciphers
+-v'' command which provides a nice way to successively create the
+correct cipher-spec string. The default cipher-spec string
+is ``ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'' which
+means the following: first, remove from consideration any ciphers that do not
+authenticate, i.e. for SSL only the Anonymous Diffie-Hellman ciphers. Next,
+use ciphers using RC4 and RSA. Next include the high, medium and then the low
+security ciphers. Finally pull all SSLv2 and export ciphers to the
+end of the list.
+$ openssl ciphers -v 'ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP' +NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1 +NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5 +EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 +... ... ... ... ... +EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export +EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export +EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export ++
The complete list of particular RSA & DH ciphers for SSL is given in Table 2.
+
+
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
+This directive points to the PEM-encoded Certificate file for the server and +optionally also to the corresponding RSA or DSA Private Key file for it +(contained in the same file). If the contained Private Key is encrypted the +Pass Phrase dialog is forced at startup time. This directive can be used up to +two times (referencing different filenames) when both a RSA and a DSA based +server certificate is used in parallel.
+
+This directive points to the PEM-encoded Private Key file for the
+server. If the Private Key is not combined with the Certificate in the
+
+This directive sets the optional all-in-one file where you can +assemble the certificates of Certification Authorities (CA) which form the +certificate chain of the server certificate. This starts with the issuing CA +certificate of of the server certificate and can range up to the root CA +certificate. Such a file is simply the concatenation of the various +PEM-encoded CA Certificate files, usually in certificate chain order.
+
+This should be used alternatively and/or additionally to
+But be careful: Providing the certificate chain works only if you are using a +single (either RSA or DSA) based server certificate. If you are +using a coupled RSA+DSA certificate pair, this will work only if actually both +certificates use the same certificate chain. Else the browsers will be +confused in this situation.
++This directive sets the directory where you keep the Certificates of +Certification Authorities (CAs) whose clients you deal with. These are used to +verify the client certificate on Client Authentication.
+
+The files in this directory have to be PEM-encoded and are accessed through
+hash filenames. So usually you can't just place the Certificate files
+there: you also have to create symbolic links named
+hash-value.N. And you should always make sure this directory
+contains the appropriate symbolic links. Use the Makefile which
+comes with mod_ssl to accomplish this task.
+This directive sets the all-in-one file where you can assemble the
+Certificates of Certification Authorities (CA) whose clients you deal
+with. These are used for Client Authentication. Such a file is simply the
+concatenation of the various PEM-encoded Certificate files, in order of
+preference. This can be used alternatively and/or additionally to
+
+This directive sets the directory where you keep the Certificate Revocation +Lists (CRL) of Certification Authorities (CAs) whose clients you deal with. +These are used to revoke the client certificate on Client Authentication.
+
+The files in this directory have to be PEM-encoded and are accessed through
+hash filenames. So usually you have not only to place the CRL files there.
+Additionally you have to create symbolic links named
+hash-value.rN. And you should always make sure this directory
+contains the appropriate symbolic links. Use the Makefile which
+comes with
+This directive sets the all-in-one file where you can
+assemble the Certificate Revocation Lists (CRL) of Certification
+Authorities (CA) whose clients you deal with. These are used
+for Client Authentication. Such a file is simply the concatenation of
+the various PEM-encoded CRL files, in order of preference. This can be
+used alternatively and/or additionally to
+This directive sets the Certificate verification level for the Client +Authentication. Notice that this directive can be used both in per-server and +per-directory context. In per-server context it applies to the client +authentication process used in the standard SSL handshake when a connection is +established. In per-directory context it forces a SSL renegotation with the +reconfigured client verification level after the HTTP request was read but +before the HTTP response is sent.
++The following levels are available for level:
+In practice only levels none and +require are really interesting, because level +optional doesn't work with all browsers and level +optional_no_ca is actually against the idea of +authentication (but can be used to establish SSL test pages, etc.)
++This directive sets how deeply mod_ssl should verify before deciding that the +clients don't have a valid certificate. Notice that this directive can be +used both in per-server and per-directory context. In per-server context it +applies to the client authentication process used in the standard SSL +handshake when a connection is established. In per-directory context it forces +a SSL renegotation with the reconfigured client verification depth after the +HTTP request was read but before the HTTP response is sent.
+
+The depth actually is the maximum number of intermediate certificate issuers,
+i.e. the number of CA certificates which are max allowed to be followed while
+verifying the client certificate. A depth of 0 means that self-signed client
+certificates are accepted only, the default depth of 1 means the client
+certificate can be self-signed or has to be signed by a CA which is directly
+known to the server (i.e. the CA's certificate is under
+
+This directive sets the name of the dedicated SSL protocol engine logfile.
+Error type messages are additionally duplicated to the general Apache error
+log file (directive ErrorLog). Put this somewhere where it cannot
+be used for symlink attacks on a real server (i.e. somewhere where only root
+can write). If the file-path does not begin with a slash
+('/') then it is assumed to be relative to the Server
+Root. If file-path begins with a bar ('|') then the
+following string is assumed to be a path to an executable program to which a
+reliable pipe can be established. The directive should occur only once per
+virtual server config.
+This directive sets the verbosity degree of the dedicated SSL protocol engine +logfile. The level is one of the following (in ascending order where +higher levels include lower levels):
+noneerror'' are still written to the general Apache error
+ logfile.
+errorwarninfotracedebug
+This directive can be used to control various run-time options on a
+per-directory basis. Normally, if multiple SSLOptions
+could apply to a directory, then the most specific one is taken
+completely; the options are not merged. However if all the
+options on the SSLOptions directive are preceded by a
+plus (+) or minus (-) symbol, the options
+are merged. Any options preceded by a + are added to the
+options currently in force, and any options preceded by a
+- are removed from the options currently in force.
+The available options are:
+StdEnvVars
+ + When this option is enabled, the standard set of SSL related CGI/SSI + environment variables are created. This per default is disabled for + performance reasons, because the information extraction step is a + rather expensive operation. So one usually enables this option for + CGI and SSI requests only.
+CompatEnvVars
+ + When this option is enabled, additional CGI/SSI environment variables are + created for backward compatibility to other Apache SSL solutions. Look in + the Compatibility chapter for details + on the particular variables generated.
+ExportCertData
+
+ When this option is enabled, additional CGI/SSI environment variables are
+ created: SSL_SERVER_CERT, SSL_CLIENT_CERT and
+ SSL_CLIENT_CERT_CHAINn (with n = 0,1,2,..).
+ These contain the PEM-encoded X.509 Certificates of server and client for
+ the current HTTPS connection and can be used by CGI scripts for deeper
+ Certificate checking. Additionally all other certificates of the client
+ certificate chain are provided, too. This bloats up the environment a
+ little bit which is why you have to use this option to enable it on
+ demand.
FakeBasicAuth
+
+ When this option is enabled, the Subject Distinguished Name (DN) of the
+ Client X509 Certificate is translated into a HTTP Basic Authorization
+ username. This means that the standard Apache authentication methods can
+ be used for access control. The user name is just the Subject of the
+ Client's X509 Certificate (can be determined by running OpenSSL's
+ openssl x509 command: openssl x509 -noout -subject -in
+ certificate.crt). Note that no password is
+ obtained from the user. Every entry in the user file needs this password:
+ ``xxj31ZMTZzkVA'', which is the DES-encrypted version of the
+ word `password''. Those who live under MD5-based encryption
+ (for instance under FreeBSD or BSD/OS, etc.) should use the following MD5
+ hash of the same word: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''.
StrictRequire
+
+ This forces forbidden access when SSLRequireSSL or
+ SSLRequire successfully decided that access should be
+ forbidden. Usually the default is that in the case where a ``Satisfy
+ any'' directive is used, and other access restrictions are passed,
+ denial of access due to SSLRequireSSL or
+ SSLRequire is overridden (because that's how the Apache
+ Satisfy mechanism should work.) But for strict access restriction
+ you can use SSLRequireSSL and/or SSLRequire in
+ combination with an ``SSLOptions +StrictRequire''. Then an
+ additional ``Satisfy Any'' has no chance once mod_ssl has
+ decided to deny access.
OptRenegotiate
+ + This enables optimized SSL connection renegotiation handling when SSL + directives are used in per-directory context. By default a strict + scheme is enabled where every per-directory reconfiguration of + SSL parameters causes a full SSL renegotiation handshake. When this + option is used mod_ssl tries to avoid unnecessary handshakes by doing more + granular (but still safe) parameter checks. Nevertheless these granular + checks sometimes maybe not what the user expects, so enable this on a + per-directory basis only, please.
++This directive forbids access unless HTTP over SSL (i.e. HTTPS) is enabled for +the current connection. This is very handy inside the SSL-enabled virtual +host or directories for defending against configuration errors that expose +stuff that should be protected. When this directive is present all requests +are denied which are not using SSL.
++This directive specifies a general access requirement which has to be +fulfilled in order to allow access. It's a very powerful directive because the +requirement specification is an arbitrarily complex boolean expression +containing any number of access checks.
++The expression must match the following syntax (given as a BNF +grammar notation):
+
+
+expr ::= "true" | "false"
+ | "!" expr
+ | expr "&&" expr
+ | expr "||" expr
+ | "(" expr ")"
+ | comp
+
+comp ::= word "==" word | word "eq" word
+ | word "!=" word | word "ne" word
+ | word "<" word | word "lt" word
+ | word "<=" word | word "le" word
+ | word ">" word | word "gt" word
+ | word ">=" word | word "ge" word
+ | word "in" "{" wordlist "}"
+ | word "=~" regex
+ | word "!~" regex
+
+wordlist ::= word
+ | wordlist "," word
+
+word ::= digit
+ | cstring
+ | variable
+ | function
+
+digit ::= [0-9]+
+cstring ::= "..."
+variable ::= "%{" varname "}"
+function ::= funcname "(" funcargs ")"
+
+
+while for varname any variable from Table 3 can be used. Finally for
+funcname the following functions are available:
file(filename)
+ + This function takes one string argument and expands to the contents of the + file. This is especially useful for matching this contents against a + regular expression, etc.
+Notice that expression is first parsed into an internal machine +representation and then evaluated in a second step. Actually, in Global and +Per-Server Class context expression is parsed at startup time and +at runtime only the machine representation is executed. For Per-Directory +context this is different: here expression has to be parsed and +immediately executed for every request.
+
+
|
This Multi-Processing Module (MPM) implements a hybrid + multi-process, multi-threaded web server. A fixed number of + processes create threads to handle requests. Fluctuations in + load are handled by increasing or decreasing the number of + threads in each process.
+ +A single control process launches the number of child processes
+ indicated by the StartThreads directive. The individual threads then
+ listen for connections and serve them when they arrive.
Apache always tries to maintain a pool of spare or
+ idle server threads, which stand ready to serve incoming
+ requests. In this way, clients do not need to wait for new
+ threads to be created. For each child process, Apache assesses
+ the number of idle threads and creates or destroys threads to
+ keep this number within the boundaries specified by
+ MinSpareThreads and MaxSpareThreads.
+ Since this process is very self-regulating, it is rarely
+ necessary to modify these directives from their default values.
+ The maximum number of clients that may be served simultaneously
+ is determined by multiplying the number of server processes
+ that will be created (NumServers) by the maximum
+ number of threads created in each process
+ (MaxThreadsPerChild).
While the parent process is usually started as root under
+ Unix in order to bind to port 80, the child processes and
+ threads are launched by Apache as a less-privileged user. The
+ User and Group directives are used to
+ set the privileges of the Apache child processes. The child
+ processes must be able to read all the content that will be
+ served, but should have as few privileges beyond that as
+ possible. In addition, unless suexec is used, these directives also
+ set the privileges which will be inherited by CGI scripts.
MaxRequestsPerChild controls how frequently the
+ server recycles processes by killing old ones and launching new
+ ones.
See also: Setting which addresses and + ports Apache uses.
+ +In addition it adds the extra ability to specify that + specific processes should serve requests under different + userids. These processes can then be associated with specific + virtual hosts.
+ +Tie a virtual host to a specific child process. Requests addressed to +the virtual host where this directive appears will be served by the process +running with the specified user and group id.
+Specify a user id and group id for a specific child process. The number of +children if set by the NumServers +directive. For example, the default value for NumServers is 5 and that means +children ids 1,2,3,4 and 5 are available for assigment. If a child does not +have an associated ChildPerUserID, it inherits the User and Group settings from the main server
+This Multi-Processing Module (MPM) is the default for most + unix-like operating systems. It implements a hybrid + multi-process multi-threaded server. Each process has a fixed + number of threads. The server adjusts to handle load by + increasing or decreasing the number of processes.
+ +A single control process is responsible for launching child
+ processes. Each child process creates a fixed number of threads
+ as specified in the ThreadsPerChild directive. The
+ individual threads then listen for connections and serve them
+ when they arrive.
Apache always tries to maintain a pool of spare or
+ idle server threads, which stand ready to serve incoming
+ requests. In this way, clients do not need to wait for a new
+ threads or processes to be created before their requests can be
+ served. Apache assesses the total number of idle threads in all
+ processes, and forks or kills processes to keep this number
+ within the boundaries specified by MinSpareThreads
+ and MaxSpareThreads. Since this process is very
+ self-regulating, it is rarely necessary to modify these
+ directives from their default values. The maximum number of
+ clients that may be served simultaneously is determined by
+ multiplying the maximum number of server processes that will be
+ created (MaxClients) by the number of threads
+ created in each process (ThreadsPerChild).
While the parent process is usually started as root under
+ Unix in order to bind to port 80, the child processes and
+ threads are launched by Apache as a less-privileged user. The
+ User and Group directives are used to
+ set the privileges of the Apache child processes. The child
+ processes must be able to read all the content that will be
+ served, but should have as few privileges beyond that as
+ possible. In addition, unless suexec is used, these directives also
+ set the privileges which will be inherited by CGI scripts.
MaxRequestsPerChild controls how frequently the
+ server recycles processes by killing old ones and launching new
+ ones.