From 2ada5933c85b2ca45770c2df27e2d292667f36c4 Mon Sep 17 00:00:00 2001 From: paul Date: Mon, 18 Nov 1996 19:51:08 +0000 Subject: New manual setup. This is the current docs for all versions of the server merged into a single manual. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@76987 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/LICENSE | 51 ++++++++ docs/manual/bind.html | 103 +++++++++++++++ docs/manual/bind.html.en | 103 +++++++++++++++ docs/manual/content-negotiation.html | 216 ++++++++++++++++++++++++++++++++ docs/manual/content-negotiation.html.en | 216 ++++++++++++++++++++++++++++++++ docs/manual/custom-error.html | 109 ++++++++++++++++ docs/manual/custom-error.html.en | 109 ++++++++++++++++ docs/manual/handler.html | 138 ++++++++++++++++++++ docs/manual/handler.html.en | 138 ++++++++++++++++++++ docs/manual/install.html | 109 ++++++++++++++++ docs/manual/install.html.en | 109 ++++++++++++++++ docs/manual/invoking.html | 108 ++++++++++++++++ docs/manual/invoking.html.en | 108 ++++++++++++++++ docs/manual/location.html | 58 +++++++++ docs/manual/process-model.html | 50 ++++++++ 15 files changed, 1725 insertions(+) create mode 100644 docs/manual/LICENSE create mode 100644 docs/manual/bind.html create mode 100644 docs/manual/bind.html.en create mode 100644 docs/manual/content-negotiation.html create mode 100644 docs/manual/content-negotiation.html.en create mode 100644 docs/manual/custom-error.html create mode 100644 docs/manual/custom-error.html.en create mode 100644 docs/manual/handler.html create mode 100644 docs/manual/handler.html.en create mode 100644 docs/manual/install.html create mode 100644 docs/manual/install.html.en create mode 100644 docs/manual/invoking.html create mode 100644 docs/manual/invoking.html.en create mode 100644 docs/manual/location.html create mode 100644 docs/manual/process-model.html diff --git a/docs/manual/LICENSE b/docs/manual/LICENSE new file mode 100644 index 0000000000..0d3053a52e --- /dev/null +++ b/docs/manual/LICENSE @@ -0,0 +1,51 @@ + +Apache httpd license + ==================== + + +This is the license for the Apache Server. It covers all the +files which come in this distribution, and should never be removed. + +The "Apache Group" has based this server, called "Apache", on +public domain code distributed under the name "NCSA httpd 1.3". + +NCSA httpd 1.3 was placed in the public domain by the National Center +for Supercomputing Applications at the University of Illinois +at Urbana-Champaign. + +As requested by NCSA we acknowledge, + + "Portions developed at the National Center for Supercomputing + Applications at the University of Illinois at Urbana-Champaign." + +Copyright on the sections of code added by the "Apache Group" belong +to the "Apache Group" and/or the original authors. The "Apache Group" and +authors hereby grant permission for their code, along with the +public domain NCSA code, to be distributed under the "Apache" name. + +Reuse of "Apache Group" code outside of the Apache distribution should +be acknowledged with the following quoted text, to be included with any new +work; + + "Portions developed by the "Apache Group", taken with permission + from the Apache Server http://www.hyperreal.com/apache/ " + + +Permission is hereby granted to anyone to redistribute Apache under +the "Apache" name. We do not grant permission for the resale of Apache, but +we do grant permission for vendors to bundle Apache free with other software, +or to charge a reasonable price for redistribution, provided it is made +clear that Apache is free. Permission is also granted for vendors to +sell support for for Apache. We explicitly forbid the redistribution of +Apache under any other name. + +The "Apache Group" makes no promises to support "Apache". Users and +sellers of Apache support, and users of "Apache Group" code, should be +aware that they use "Apache" or portions of the "Apache Group" code at +their own risk. While every effort has been made to ensure that "Apache" +is robust and safe to use, we will not accept responsibility for any +damage caused, or loss of data or income which results from its use. + + + +Apache httpd server (c) 1995 The Apache Group. diff --git a/docs/manual/bind.html b/docs/manual/bind.html new file mode 100644 index 0000000000..777f79650f --- /dev/null +++ b/docs/manual/bind.html @@ -0,0 +1,103 @@ + +Setting which addresses and ports Apache uses + + + +

Setting which addresses and ports Apache uses

+ +
+ +When Apache starts, it connects to some port and address on the +local machine and waits for incoming requests. By default, it +listens to all addresses on the machine, and to the port +as specified by the Port directive in the server configuration. +However, it can be told to listen to more the one port, or to listen +to only selected addresses, or a combination. This is often combined +with the Virtual Host feature which determines how Apache +responds to different IP addresses, hostnames and ports.

+ +There are two directives used to restrict or specify which addresses +and ports Apache listens to. + +

+ +

BindAddress

+Syntax: BindAddress [ * | IP-address | hostname ]
+Default: BindAddress *
+Context: server config
+Status: Core

+ +Makes the server listen to just the specified address. If the argument +is *, the server listens to all addresses. The port listened to +is set with the Port directive. Only one BindAddress +should be used. + +

Listen

+Syntax: Listen [ port | IP-address:port ]
+Default: none
+Context: server config
+Status: Core

+ +Listen can be used instead of BindAddress and +Port. It tells the server to accept incoming requests on the +specified port or address-and-port combination. If the first format is +used, with a port number only, the server listens to the given port on +all interfaces, instead of the port given by the Port +directive. If an IP address is given as well as a port, the server +will listen on the given port and interface.

Multiple Listen +directives may be used to specify a number of addresses and ports to +listen to. The server will respond to requests from any of the listed +addresses and ports.

+ +For example, to make the server accept connections on both port +80 and port 8000, use: +

+   Listen 80
+   Listen 8000
+
+ +To make the server accept connections on two specified +interfaces and port numbers, use +
+   Listen 192.170.2.1:80
+   Listen 192.170.2.5:8000
+
+ +

How this works with Virtual Hosts

+ +BindAddress and Listen do not implement Virtual Hosts. They tell the +main server what addresses and ports to listen to. If no +<VirtualHost> directives are used, the server will behave the +same for all accepted requests. However, <VirtualHost> can be +used to specify a different behavour for one or more of the addresses +and ports. To implement a VirtualHost, the server must first be told +to listen to the address and port to be used. Then a +<VirtualHost> section should be created for a specified address +and port to set the behaviour of this virtual host. Note that if the +<VirtualHost> is set for an address and port that the server is +not listening to, it cannot be accessed. + +

See also

+ +See also the documentation on +Virtual Hosts, +Non-IP virtual hosts, +BindAddress directive, +Port directive +and +<VirtualHost> section. + + +
+Home +Index + + + + diff --git a/docs/manual/bind.html.en b/docs/manual/bind.html.en new file mode 100644 index 0000000000..777f79650f --- /dev/null +++ b/docs/manual/bind.html.en @@ -0,0 +1,103 @@ + +Setting which addresses and ports Apache uses + + + +

Setting which addresses and ports Apache uses

+ +
+ +When Apache starts, it connects to some port and address on the +local machine and waits for incoming requests. By default, it +listens to all addresses on the machine, and to the port +as specified by the Port directive in the server configuration. +However, it can be told to listen to more the one port, or to listen +to only selected addresses, or a combination. This is often combined +with the Virtual Host feature which determines how Apache +responds to different IP addresses, hostnames and ports.

+ +There are two directives used to restrict or specify which addresses +and ports Apache listens to. + +

+ +

BindAddress

+Syntax: BindAddress [ * | IP-address | hostname ]
+Default: BindAddress *
+Context: server config
+Status: Core

+ +Makes the server listen to just the specified address. If the argument +is *, the server listens to all addresses. The port listened to +is set with the Port directive. Only one BindAddress +should be used. + +

Listen

+Syntax: Listen [ port | IP-address:port ]
+Default: none
+Context: server config
+Status: Core

+ +Listen can be used instead of BindAddress and +Port. It tells the server to accept incoming requests on the +specified port or address-and-port combination. If the first format is +used, with a port number only, the server listens to the given port on +all interfaces, instead of the port given by the Port +directive. If an IP address is given as well as a port, the server +will listen on the given port and interface.

Multiple Listen +directives may be used to specify a number of addresses and ports to +listen to. The server will respond to requests from any of the listed +addresses and ports.

+ +For example, to make the server accept connections on both port +80 and port 8000, use: +

+   Listen 80
+   Listen 8000
+
+ +To make the server accept connections on two specified +interfaces and port numbers, use +
+   Listen 192.170.2.1:80
+   Listen 192.170.2.5:8000
+
+ +

How this works with Virtual Hosts

+ +BindAddress and Listen do not implement Virtual Hosts. They tell the +main server what addresses and ports to listen to. If no +<VirtualHost> directives are used, the server will behave the +same for all accepted requests. However, <VirtualHost> can be +used to specify a different behavour for one or more of the addresses +and ports. To implement a VirtualHost, the server must first be told +to listen to the address and port to be used. Then a +<VirtualHost> section should be created for a specified address +and port to set the behaviour of this virtual host. Note that if the +<VirtualHost> is set for an address and port that the server is +not listening to, it cannot be accessed. + +

See also

+ +See also the documentation on +Virtual Hosts, +Non-IP virtual hosts, +BindAddress directive, +Port directive +and +<VirtualHost> section. + + +
+Home +Index + + + + diff --git a/docs/manual/content-negotiation.html b/docs/manual/content-negotiation.html new file mode 100644 index 0000000000..20825f3661 --- /dev/null +++ b/docs/manual/content-negotiation.html @@ -0,0 +1,216 @@ + + +Apache server Content arbitration: MultiViews and *.var files + + + + +

Content Arbitration: MultiViews and *.var files

+ +The HTTP standard allows clients (i.e., browsers like Mosaic or +Netscape) to specify what data formats they are prepared to accept. +The intention is that when information is available in multiple +variants (e.g., in different data formats), servers can use this +information to decide which variant to send. This feature has been +supported in the CERN server for a while, and while it is not yet +supported in the NCSA server, it is likely to assume a new importance +in light of the emergence of HTML3 capable browsers.

+ +The Apache module mod_negotiation handles +content negotiation in two different ways; special treatment for the +pseudo-mime-type application/x-type-map, and the +MultiViews per-directory Option (which can be set in srm.conf, or in +.htaccess files, as usual). These features are alternate user +interfaces to what amounts to the same piece of code (in the new file +http_mime_db.c) which implements the content negotiation +portion of the HTTP protocol.

+ +Each of these features allows one of several files to satisfy a +request, based on what the client says it's willing to accept; the +differences are in the way the files are identified: + +

+ +Apache also supports a new pseudo-MIME type, +text/x-server-parsed-html3, which is treated as text/html;level=3 +for purposes of content negotiation, and as server-side-included HTML +elsewhere. + +

Type maps (*.var files)

+ +A type map is a document which is typed by the server (using its +normal suffix-based mechanisms) as +application/x-type-map. Note that to use this feature, +you've got to have an AddType some place which defines a +file suffix as application/x-type-map; the easiest thing +may be to stick a +
+
+  AddType application/x-type-map var
+
+
+in srm.conf. See comments in the sample config files for +details.

+ +Type map files have an entry for each available variant; these entries +consist of contiguous RFC822-format header lines. Entries for +different variants are separated by blank lines. Blank lines are +illegal within an entry. It is conventional to begin a map file with +an entry for the combined entity as a whole, e.g., +

+
+  URI: foo; vary="type,language"
+
+  URI: foo.en.html
+  Content-type: text/html; level=2
+  Content-language: en
+
+  URI: foo.fr.html
+  Content-type: text/html; level=2
+  Content-language: fr
+
+
+If the variants have different qualities, that may be indicated by the +"qs" parameter, as in this picture (available as jpeg, gif, or ASCII-art): +
+
+  URI: foo; vary="type,language"
+
+  URI: foo.jpeg
+  Content-type: image/jpeg; qs=0.8
+
+  URI: foo.gif
+  Content-type: image/gif; qs=0.5
+
+  URI: foo.txt
+  Content-type: text/plain; qs=0.01
+
+

+ +The full list of headers recognized is: + +

+
URI: +
uri of the file containing the variant (of the given media + type, encoded with the given content encoding). These are + interpreted as URLs relative to the map file; they must be on + the same server (!), and they must refer to files to which the + client would be granted access if they were to be requested + directly. +
Content-type: +
media type --- level may be specified, along with "qs". These + are often referred to as MIME types; typical media types are + image/gif, text/plain, or + text/html; level=3. +
Content-language: +
The language of the variant, specified as an internet standard + language code (e.g., en for English, + kr for Korean, etc.). +
Content-encoding: +
If the file is compressed, or otherwise encoded, rather than + containing the actual raw data, this says how that was done. + For compressed files (the only case where this generally comes + up), content encoding should be + x-compress, or gzip, as appropriate. +
Content-length: +
The size of the file. Clients can ask to receive a given media + type only if the variant isn't too big; specifying a content + length in the map allows the server to compare against these + thresholds without checking the actual file. +
+ +

Multiviews

+ +This is a per-directory option, meaning it can be set with an +Options directive within a <Directory> +section in access.conf, or (if AllowOverride +is properly set) in .htaccess files. Note that +Options All does not set MultiViews; you +have to ask for it by name. (Fixing this is a one-line change to +httpd.h). + +

+ +The effect of MultiViews is as follows: if the server +receives a request for /some/dir/foo, if +/some/dir has MultiViews enabled, and +/some/dir/foo does *not* exist, then the server reads the +directory looking for files named foo.*, and effectively fakes up a +type map which names all those files, assigning them the same media +types and content-encodings it would have if the client had asked for +one of them by name. It then chooses the best match to the client's +requirements, and forwards them along. + +

+ +This applies to searches for the file named by the +DirectoryIndex directive, if the server is trying to +index a directory; if the configuration files specify +

+
+  DirectoryIndex index
+
+
then the server will arbitrate between index.html +and index.html3 if both are present. If neither are +present, and index.cgi is there, the server will run it. + +

+ +If one of the files found by the globbing is a CGI script, it's not +obvious what should happen. My code gives that case gets special +treatment --- if the request was a POST, or a GET with QUERY_ARGS or +PATH_INFO, the script is given an extremely high quality rating, and +generally invoked; otherwise it is given an extremely low quality +rating, which generally causes one of the other views (if any) to be +retrieved. This is the only jiggering of quality ratings done by the +MultiViews code; aside from that, all Qualities in the synthesized +type maps are 1.0. + +

+ +New as of 0.8: Documents in multiple languages can also be resolved through the use +of the AddLanguage and LanguagePriority +directives: + +

+AddLanguage en .en
+AddLanguage fr .fr
+AddLanguage de .de
+AddLanguage da .da
+AddLanguage el .el
+AddLanguage it .it
+
+# LanguagePriority allows you to give precedence to some languages
+# in case of a tie during content negotiation.
+# Just list the languages in decreasing order of preference.
+
+LanguagePriority en fr de
+
+ +Here, a request for "foo.html" matched against "foo.html.en" and +"foo.html.fr" would return an French document to a browser that +indicated a preference for French, or an English document otherwise. +In fact, a request for "foo" matched against "foo.html.en", +"foo.html.fr", "foo.ps.en", "foo.pdf.de", and "foo.txt.it" would do +just what you expect - treat those suffices as a database and compare +the request to it, returning the best match. The languages and data +types share the same suffix name space. + +

+ +Note that this machinery only comes into play if the file which the +user attempted to retrieve does not exist by that name; if it +does, it is simply retrieved as usual. (So, someone who actually asks +for foo.jpeg, as opposed to foo, never gets +foo.gif). + +

+Home +Index + + diff --git a/docs/manual/content-negotiation.html.en b/docs/manual/content-negotiation.html.en new file mode 100644 index 0000000000..20825f3661 --- /dev/null +++ b/docs/manual/content-negotiation.html.en @@ -0,0 +1,216 @@ + + +Apache server Content arbitration: MultiViews and *.var files + + + + +

Content Arbitration: MultiViews and *.var files

+ +The HTTP standard allows clients (i.e., browsers like Mosaic or +Netscape) to specify what data formats they are prepared to accept. +The intention is that when information is available in multiple +variants (e.g., in different data formats), servers can use this +information to decide which variant to send. This feature has been +supported in the CERN server for a while, and while it is not yet +supported in the NCSA server, it is likely to assume a new importance +in light of the emergence of HTML3 capable browsers.

+ +The Apache module mod_negotiation handles +content negotiation in two different ways; special treatment for the +pseudo-mime-type application/x-type-map, and the +MultiViews per-directory Option (which can be set in srm.conf, or in +.htaccess files, as usual). These features are alternate user +interfaces to what amounts to the same piece of code (in the new file +http_mime_db.c) which implements the content negotiation +portion of the HTTP protocol.

+ +Each of these features allows one of several files to satisfy a +request, based on what the client says it's willing to accept; the +differences are in the way the files are identified: + +

+ +Apache also supports a new pseudo-MIME type, +text/x-server-parsed-html3, which is treated as text/html;level=3 +for purposes of content negotiation, and as server-side-included HTML +elsewhere. + +

Type maps (*.var files)

+ +A type map is a document which is typed by the server (using its +normal suffix-based mechanisms) as +application/x-type-map. Note that to use this feature, +you've got to have an AddType some place which defines a +file suffix as application/x-type-map; the easiest thing +may be to stick a +
+
+  AddType application/x-type-map var
+
+
+in srm.conf. See comments in the sample config files for +details.

+ +Type map files have an entry for each available variant; these entries +consist of contiguous RFC822-format header lines. Entries for +different variants are separated by blank lines. Blank lines are +illegal within an entry. It is conventional to begin a map file with +an entry for the combined entity as a whole, e.g., +

+
+  URI: foo; vary="type,language"
+
+  URI: foo.en.html
+  Content-type: text/html; level=2
+  Content-language: en
+
+  URI: foo.fr.html
+  Content-type: text/html; level=2
+  Content-language: fr
+
+
+If the variants have different qualities, that may be indicated by the +"qs" parameter, as in this picture (available as jpeg, gif, or ASCII-art): +
+
+  URI: foo; vary="type,language"
+
+  URI: foo.jpeg
+  Content-type: image/jpeg; qs=0.8
+
+  URI: foo.gif
+  Content-type: image/gif; qs=0.5
+
+  URI: foo.txt
+  Content-type: text/plain; qs=0.01
+
+

+ +The full list of headers recognized is: + +

+
URI: +
uri of the file containing the variant (of the given media + type, encoded with the given content encoding). These are + interpreted as URLs relative to the map file; they must be on + the same server (!), and they must refer to files to which the + client would be granted access if they were to be requested + directly. +
Content-type: +
media type --- level may be specified, along with "qs". These + are often referred to as MIME types; typical media types are + image/gif, text/plain, or + text/html; level=3. +
Content-language: +
The language of the variant, specified as an internet standard + language code (e.g., en for English, + kr for Korean, etc.). +
Content-encoding: +
If the file is compressed, or otherwise encoded, rather than + containing the actual raw data, this says how that was done. + For compressed files (the only case where this generally comes + up), content encoding should be + x-compress, or gzip, as appropriate. +
Content-length: +
The size of the file. Clients can ask to receive a given media + type only if the variant isn't too big; specifying a content + length in the map allows the server to compare against these + thresholds without checking the actual file. +
+ +

Multiviews

+ +This is a per-directory option, meaning it can be set with an +Options directive within a <Directory> +section in access.conf, or (if AllowOverride +is properly set) in .htaccess files. Note that +Options All does not set MultiViews; you +have to ask for it by name. (Fixing this is a one-line change to +httpd.h). + +

+ +The effect of MultiViews is as follows: if the server +receives a request for /some/dir/foo, if +/some/dir has MultiViews enabled, and +/some/dir/foo does *not* exist, then the server reads the +directory looking for files named foo.*, and effectively fakes up a +type map which names all those files, assigning them the same media +types and content-encodings it would have if the client had asked for +one of them by name. It then chooses the best match to the client's +requirements, and forwards them along. + +

+ +This applies to searches for the file named by the +DirectoryIndex directive, if the server is trying to +index a directory; if the configuration files specify +

+
+  DirectoryIndex index
+
+
then the server will arbitrate between index.html +and index.html3 if both are present. If neither are +present, and index.cgi is there, the server will run it. + +

+ +If one of the files found by the globbing is a CGI script, it's not +obvious what should happen. My code gives that case gets special +treatment --- if the request was a POST, or a GET with QUERY_ARGS or +PATH_INFO, the script is given an extremely high quality rating, and +generally invoked; otherwise it is given an extremely low quality +rating, which generally causes one of the other views (if any) to be +retrieved. This is the only jiggering of quality ratings done by the +MultiViews code; aside from that, all Qualities in the synthesized +type maps are 1.0. + +

+ +New as of 0.8: Documents in multiple languages can also be resolved through the use +of the AddLanguage and LanguagePriority +directives: + +

+AddLanguage en .en
+AddLanguage fr .fr
+AddLanguage de .de
+AddLanguage da .da
+AddLanguage el .el
+AddLanguage it .it
+
+# LanguagePriority allows you to give precedence to some languages
+# in case of a tie during content negotiation.
+# Just list the languages in decreasing order of preference.
+
+LanguagePriority en fr de
+
+ +Here, a request for "foo.html" matched against "foo.html.en" and +"foo.html.fr" would return an French document to a browser that +indicated a preference for French, or an English document otherwise. +In fact, a request for "foo" matched against "foo.html.en", +"foo.html.fr", "foo.ps.en", "foo.pdf.de", and "foo.txt.it" would do +just what you expect - treat those suffices as a database and compare +the request to it, returning the best match. The languages and data +types share the same suffix name space. + +

+ +Note that this machinery only comes into play if the file which the +user attempted to retrieve does not exist by that name; if it +does, it is simply retrieved as usual. (So, someone who actually asks +for foo.jpeg, as opposed to foo, never gets +foo.gif). + +

+Home +Index + + diff --git a/docs/manual/custom-error.html b/docs/manual/custom-error.html new file mode 100644 index 0000000000..31c955a2c4 --- /dev/null +++ b/docs/manual/custom-error.html @@ -0,0 +1,109 @@ + + +Ccustom error responses + + + + +

Custom error responses

+
+
Purpose +
Additional functionality. Allows webmasters to configure the response of +Apache to some error or problem.
+

Customizable responses can be defined to be activated in the event of a +server detected error or problem.
+e.g. if a script crashes and produces a "500 Server Error" response, then +this response can be replaced with either some friendlier text or by a +redirection to another URL (local or external). +

Old behavior +
NCSA httpd 1.3 would return some boring old error/problem message which +would often be meaningless to the user, and would provide no means of logging +the symptoms which caused it.

+
New behavior +
The server can be asked to; +
    +
  1. Display some other text, instead of the NCSA hard coded messages, or +
  2. redirect to a local URL, or +
  3. redirect to an external URL. +
+

Redirecting to another URL can be useful, but only if some information +can be passed which can then be used to explain and/or log the error/problem +more clearly.
To achieve this, Apache will define new CGI-like environment +variables, e.g. +

+REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg
+REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712)
+REDIRECT_PATH=.:/bin:/usr/local/bin:/etc
+REDIRECT_QUERY_STRING=
+REDIRECT_REMOTE_ADDR=121.345.78.123
+REDIRECT_REMOTE_HOST=ooh.ahhh.com
+REDIRECT_SERVER_NAME=crash.bang.edu
+REDIRECT_SERVER_PORT=80
+REDIRECT_SERVER_SOFTWARE=Apache/0.8.15
+REDIRECT_URL=/cgi-bin/buggy.pl
+
+ +note the REDIRECT_ prefix.

+ +At least REDIRECT_URL and REDIRECT_QUERY_STRING will +be passed to the new URL (assuming it's a cgi-script or a cgi-include). The +other variables will exist only if they existed prior to the error/problem.

+ +

Configuration +
file: server configuration
+

Here are some examples... +

+ErrorDocument 500 /cgi-bin/crash-recover
+ErrorDocument 500 "Sorry, our script crashed because %s. Oh dear
+ErrorDocument 500 http://xxx/
+ErrorDocument 404 /Lame_excuses/not_found.html
+ErrorDocument 401 /Subscription/how_to_subscribe.html +
+The syntax is,

+ErrorDocument +<3-digit-code> action

+ +where the action can be, +

    +
  1. Text to be displayed.
    Prefix the text with a quote ("). Whatever +follows the quote is displayed. If the error/problem produced any additional +information, it can be specified using %s. +Note: the (") prefix isn't displayed. +
  2. An external URL to redirect to. +
  3. A local URL to redirect to. +
+

ErrorDocument definitions are sensitive to a +SIGHUP, so you can change any of the definitions or add new ones +prior to sending a SIGHUP (kill -1) signal. +

+

+ +

Custom error responses and redirects

+
+
Purpose +
Apache's behaviour to redirected URLs has been modified so that additional +environment variables are available to a script/server-include.

+ +

Old behaviour +
Standard CGI vars were made available to a script which has been +redirected to. No indication of where the redirection came from was provided. +

+

New behaviour +
A new batch of environment variables will be initialized for use by a +script which has been redirected to.
+Each new variable will have the prefix REDIRECT_.
+REDIRECT_ environment variables are created from the CGI environment +variables which existed prior to the redirect, they are renamed with a +REDIRECT_ prefix, i.e. HTTP_USER_AGENT -> REDIRECT_HTTP_USER_AGENT.
+In addition to these new variables, Apache will define +REDIRECT_URL and REDIRECT_STATUS to help the script +trace its origin.
+Logging: both the original URL and the URL being redirected to, will +now be logged correctly in the access log.

+

+

+ +Home +Index + + diff --git a/docs/manual/custom-error.html.en b/docs/manual/custom-error.html.en new file mode 100644 index 0000000000..31c955a2c4 --- /dev/null +++ b/docs/manual/custom-error.html.en @@ -0,0 +1,109 @@ + + +Ccustom error responses + + + + +

Custom error responses

+
+
Purpose +
Additional functionality. Allows webmasters to configure the response of +Apache to some error or problem.
+

Customizable responses can be defined to be activated in the event of a +server detected error or problem.
+e.g. if a script crashes and produces a "500 Server Error" response, then +this response can be replaced with either some friendlier text or by a +redirection to another URL (local or external). +

Old behavior +
NCSA httpd 1.3 would return some boring old error/problem message which +would often be meaningless to the user, and would provide no means of logging +the symptoms which caused it.

+
New behavior +
The server can be asked to; +
    +
  1. Display some other text, instead of the NCSA hard coded messages, or +
  2. redirect to a local URL, or +
  3. redirect to an external URL. +
+

Redirecting to another URL can be useful, but only if some information +can be passed which can then be used to explain and/or log the error/problem +more clearly.
To achieve this, Apache will define new CGI-like environment +variables, e.g. +

+REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg
+REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712)
+REDIRECT_PATH=.:/bin:/usr/local/bin:/etc
+REDIRECT_QUERY_STRING=
+REDIRECT_REMOTE_ADDR=121.345.78.123
+REDIRECT_REMOTE_HOST=ooh.ahhh.com
+REDIRECT_SERVER_NAME=crash.bang.edu
+REDIRECT_SERVER_PORT=80
+REDIRECT_SERVER_SOFTWARE=Apache/0.8.15
+REDIRECT_URL=/cgi-bin/buggy.pl
+
+ +note the REDIRECT_ prefix.

+ +At least REDIRECT_URL and REDIRECT_QUERY_STRING will +be passed to the new URL (assuming it's a cgi-script or a cgi-include). The +other variables will exist only if they existed prior to the error/problem.

+ +

Configuration +
file: server configuration
+

Here are some examples... +

+ErrorDocument 500 /cgi-bin/crash-recover
+ErrorDocument 500 "Sorry, our script crashed because %s. Oh dear
+ErrorDocument 500 http://xxx/
+ErrorDocument 404 /Lame_excuses/not_found.html
+ErrorDocument 401 /Subscription/how_to_subscribe.html +
+The syntax is,

+ErrorDocument +<3-digit-code> action

+ +where the action can be, +

    +
  1. Text to be displayed.
    Prefix the text with a quote ("). Whatever +follows the quote is displayed. If the error/problem produced any additional +information, it can be specified using %s. +Note: the (") prefix isn't displayed. +
  2. An external URL to redirect to. +
  3. A local URL to redirect to. +
+

ErrorDocument definitions are sensitive to a +SIGHUP, so you can change any of the definitions or add new ones +prior to sending a SIGHUP (kill -1) signal. +

+

+ +

Custom error responses and redirects

+
+
Purpose +
Apache's behaviour to redirected URLs has been modified so that additional +environment variables are available to a script/server-include.

+ +

Old behaviour +
Standard CGI vars were made available to a script which has been +redirected to. No indication of where the redirection came from was provided. +

+

New behaviour +
A new batch of environment variables will be initialized for use by a +script which has been redirected to.
+Each new variable will have the prefix REDIRECT_.
+REDIRECT_ environment variables are created from the CGI environment +variables which existed prior to the redirect, they are renamed with a +REDIRECT_ prefix, i.e. HTTP_USER_AGENT -> REDIRECT_HTTP_USER_AGENT.
+In addition to these new variables, Apache will define +REDIRECT_URL and REDIRECT_STATUS to help the script +trace its origin.
+Logging: both the original URL and the URL being redirected to, will +now be logged correctly in the access log.

+

+

+ +Home +Index + + diff --git a/docs/manual/handler.html b/docs/manual/handler.html new file mode 100644 index 0000000000..4472b3165d --- /dev/null +++ b/docs/manual/handler.html @@ -0,0 +1,138 @@ + + + +Apache's Handler Use + + + + +

Apache's Handler Use

+ +

What is a Handler

+ +

A "handler" is an internal Apache representation of the action to be +performed when a file is called. Generally, files have implicit +handlers, based on the file type. Normally, all files are simply +served by the server, but certain file typed are "handled" +seperately. For example, you may use a type of +"application/x-httpd-cgi" to invoke CGI scripts.

+ +

Apache 1.1 adds the additional ability to use handlers +explicitly. Either based on filename extensions or on location, these +handlers are unrelated to file type. This is advantageous both because +it is a more elegant solution, but it also allows for both a type +and a handler to be associated with a file.

+ +

Handlers can either be built into the server or to a module, or +they can be added with the Action directive. The built-in +handlers in the standard distribution are as follows:

+ + + +

+ +

Directives

+ + +
+ +

AddHandler

+ +Syntax: <AddHandler handler-name extention>
+Context: server config, virtual host, directory, .htaccess
+Status: Base
+Module: mod_mime + +

AddHandler maps the filename extension extension to the +handler handler-name. For example, to activate CGI scripts +with the file extension ".cgi", you might use: +

+    AddHandler cgi-script cgi
+
+ +

Once that has been put into your srm.conf or httpd.conf file, any +file ending with ".cgi" will be treated as a CGI +program.

+ +
+ +

SetHandler

+ +Syntax: <SetHandler handler-name>
+Context: directory, .htaccess
+Status: Base
+Module: mod_mime + +

When placed into an .htaccess file or a +<Directory> or <Location section, +this directive forces all matching files to be parsed through the +handler given by handler-name. For example, if you had a +directory you wanted to be parsed entirely as imagemap rule files, +regardless of extension, you might put the following into an +.htaccess file in that directory: +

+    SetHandler imap-file
+
+

Another example: if you wanted to have the server display a status +report whenever a URL of http://servername/status was +called, you might put the following into access.conf: +

+    <Location /status>
+    SetHandler server-status
+    </Location>
+
+ +

+ +

Programmer's Note

+ +

In order to implement the handler features, an addition has been +made to the Apache API that you may wish to +make use of. Specifically, a new record has been added to the +request_rec structure:

+
+    char *handler
+
+

If you wish to have your module engage a handler, you need only to +set r->handler to the name of the handler at any time +prior to the invoke_handler stage of the +request. Handlers are implemented as they were before, albiet using +the handler name instead of a content type. While it is not +neccessary, the naming convention for handlers is to use a +dash-seperated word, with no slashes, so as to not invade the media +type namespace.

+ +
+ +Home +Index + + + + diff --git a/docs/manual/handler.html.en b/docs/manual/handler.html.en new file mode 100644 index 0000000000..4472b3165d --- /dev/null +++ b/docs/manual/handler.html.en @@ -0,0 +1,138 @@ + + + +Apache's Handler Use + + + + +

Apache's Handler Use

+ +

What is a Handler

+ +

A "handler" is an internal Apache representation of the action to be +performed when a file is called. Generally, files have implicit +handlers, based on the file type. Normally, all files are simply +served by the server, but certain file typed are "handled" +seperately. For example, you may use a type of +"application/x-httpd-cgi" to invoke CGI scripts.

+ +

Apache 1.1 adds the additional ability to use handlers +explicitly. Either based on filename extensions or on location, these +handlers are unrelated to file type. This is advantageous both because +it is a more elegant solution, but it also allows for both a type +and a handler to be associated with a file.

+ +

Handlers can either be built into the server or to a module, or +they can be added with the Action directive. The built-in +handlers in the standard distribution are as follows:

+ + + +

+ +

Directives

+ + +
+ +

AddHandler

+ +Syntax: <AddHandler handler-name extention>
+Context: server config, virtual host, directory, .htaccess
+Status: Base
+Module: mod_mime + +

AddHandler maps the filename extension extension to the +handler handler-name. For example, to activate CGI scripts +with the file extension ".cgi", you might use: +

+    AddHandler cgi-script cgi
+
+ +

Once that has been put into your srm.conf or httpd.conf file, any +file ending with ".cgi" will be treated as a CGI +program.

+ +
+ +

SetHandler

+ +Syntax: <SetHandler handler-name>
+Context: directory, .htaccess
+Status: Base
+Module: mod_mime + +

When placed into an .htaccess file or a +<Directory> or <Location section, +this directive forces all matching files to be parsed through the +handler given by handler-name. For example, if you had a +directory you wanted to be parsed entirely as imagemap rule files, +regardless of extension, you might put the following into an +.htaccess file in that directory: +

+    SetHandler imap-file
+
+

Another example: if you wanted to have the server display a status +report whenever a URL of http://servername/status was +called, you might put the following into access.conf: +

+    <Location /status>
+    SetHandler server-status
+    </Location>
+
+ +

+ +

Programmer's Note

+ +

In order to implement the handler features, an addition has been +made to the Apache API that you may wish to +make use of. Specifically, a new record has been added to the +request_rec structure:

+
+    char *handler
+
+

If you wish to have your module engage a handler, you need only to +set r->handler to the name of the handler at any time +prior to the invoke_handler stage of the +request. Handlers are implemented as they were before, albiet using +the handler name instead of a content type. While it is not +neccessary, the naming convention for handlers is to use a +dash-seperated word, with no slashes, so as to not invade the media +type namespace.

+ +
+ +Home +Index + + + + diff --git a/docs/manual/install.html b/docs/manual/install.html new file mode 100644 index 0000000000..dd53b73a2e --- /dev/null +++ b/docs/manual/install.html @@ -0,0 +1,109 @@ + + + + +Compiling and Installing Apache + + + + + +

Compiling and Installing Apache

+

Downloading Apache

+Information on the latest version of Apache can be found on the Apache +web server at http://www.apache.org/. This will list the current release, +any more recent beta-test release, together with details of mirror +web and anonymous ftp sites. + +

Compiling Apache

+This release of Apache supports the notion of `optional modules'. +However, the server has to know which modules are compiled into it, in +order for those modules to be effective; this requires generation of a +short bit of code (`modules.c') which simply has a list of them. +

+If you are satisfied with our standard module set, and expect to +continue to be satisfied with it, then you can just edit the stock +Makefile and compile as you have been doing previously. If you +would +like to select optional modules, however, you need to run the +configuration script. +

+To do this: +

    +
  1. Edit the file `Configuration'. This contains the per-machine +config settings of the Makefile, and also an additional section at +the bottom which lists the modules which have been compiled in, and +also names the files containing them. You will need to: +
      +
    1. Select a compiler and compilation options as appropriate to +your machine. +
    2. Uncomment lines corresponding to those optional modules you wish +to include (among the Module lines at the bottom of the file) +or add new lines corresponding to custom modules you have written. +

      +Note that DBM auth has to be explicitly configured in, if you want +it; just uncomment the corresponding line. +

    +
  2. Run the `Configure' script: +
    +% Configure
    +Using 'Configuration' as config file
    +%
    + +This generates new versions of the Makefile and of modules.c. If +you want to maintain multiple configurations, you can say, e.g., +
    +% Configure -file Configuration.ai
    +Using alternate config file Configuration.ai
    +%
    + +
  3. Type `make'. +

    +The modules we place in the Apache distribution are the ones we have +tested and are used regularly by various members of the Apache +development group. Additional modules contributed by members or third +parties with specific needs or functions are available at +<URL:http://www.apache.org/dist/contrib/modules/>. There are instructions on that page for +linking these modules into the core Apache code. +

+ +

Installing Apache

+After compilation, you will have a binary called `httpd' in the +src/ directory. A binary distribution of Apache will supply this +file. +

+The next step is to edit the configuration files for the server. In +the subdirectory called `conf' you should find distribution versions +of the three configuration files: srm.conf-dist, +access.conf-dist and httpd.conf-dist. Copy them to +srm.conf, access.conf and httpd.conf +respectively. +

+First edit httpd.conf. This sets up general attributes about the +server; the port number, the user it runs as, etc. Next edit the +srm.conf file; this sets up the root of the document tree, +special functions like server-parsed HTML or internal imagemap parsing, etc. +Finally, edit the access.conf file to at least set the base cases +of access. +

+Finally, make a call to httpd, with a -f to the full path to the +httpd.conf file. I.e., the common case: +

+ /usr/local/etc/apache/src/httpd -f /usr/local/etc/apache/conf/httpd.conf +
+The server should be now running. +

+By default the srm.conf and access.conf files are +located by name; to specifically call them by other names, use the +AccessConfig and +ResourceConfig directives in +httpd.conf. + + +

+Home +Index + + + + diff --git a/docs/manual/install.html.en b/docs/manual/install.html.en new file mode 100644 index 0000000000..dd53b73a2e --- /dev/null +++ b/docs/manual/install.html.en @@ -0,0 +1,109 @@ + + + + +Compiling and Installing Apache + + + + + +

Compiling and Installing Apache

+

Downloading Apache

+Information on the latest version of Apache can be found on the Apache +web server at http://www.apache.org/. This will list the current release, +any more recent beta-test release, together with details of mirror +web and anonymous ftp sites. + +

Compiling Apache

+This release of Apache supports the notion of `optional modules'. +However, the server has to know which modules are compiled into it, in +order for those modules to be effective; this requires generation of a +short bit of code (`modules.c') which simply has a list of them. +

+If you are satisfied with our standard module set, and expect to +continue to be satisfied with it, then you can just edit the stock +Makefile and compile as you have been doing previously. If you +would +like to select optional modules, however, you need to run the +configuration script. +

+To do this: +

    +
  1. Edit the file `Configuration'. This contains the per-machine +config settings of the Makefile, and also an additional section at +the bottom which lists the modules which have been compiled in, and +also names the files containing them. You will need to: +
      +
    1. Select a compiler and compilation options as appropriate to +your machine. +
    2. Uncomment lines corresponding to those optional modules you wish +to include (among the Module lines at the bottom of the file) +or add new lines corresponding to custom modules you have written. +

      +Note that DBM auth has to be explicitly configured in, if you want +it; just uncomment the corresponding line. +

    +
  2. Run the `Configure' script: +
    +% Configure
    +Using 'Configuration' as config file
    +%
    + +This generates new versions of the Makefile and of modules.c. If +you want to maintain multiple configurations, you can say, e.g., +
    +% Configure -file Configuration.ai
    +Using alternate config file Configuration.ai
    +%
    + +
  3. Type `make'. +

    +The modules we place in the Apache distribution are the ones we have +tested and are used regularly by various members of the Apache +development group. Additional modules contributed by members or third +parties with specific needs or functions are available at +<URL:http://www.apache.org/dist/contrib/modules/>. There are instructions on that page for +linking these modules into the core Apache code. +

+ +

Installing Apache

+After compilation, you will have a binary called `httpd' in the +src/ directory. A binary distribution of Apache will supply this +file. +

+The next step is to edit the configuration files for the server. In +the subdirectory called `conf' you should find distribution versions +of the three configuration files: srm.conf-dist, +access.conf-dist and httpd.conf-dist. Copy them to +srm.conf, access.conf and httpd.conf +respectively. +

+First edit httpd.conf. This sets up general attributes about the +server; the port number, the user it runs as, etc. Next edit the +srm.conf file; this sets up the root of the document tree, +special functions like server-parsed HTML or internal imagemap parsing, etc. +Finally, edit the access.conf file to at least set the base cases +of access. +

+Finally, make a call to httpd, with a -f to the full path to the +httpd.conf file. I.e., the common case: +

+ /usr/local/etc/apache/src/httpd -f /usr/local/etc/apache/conf/httpd.conf +
+The server should be now running. +

+By default the srm.conf and access.conf files are +located by name; to specifically call them by other names, use the +AccessConfig and +ResourceConfig directives in +httpd.conf. + + +

+Home +Index + + + + diff --git a/docs/manual/invoking.html b/docs/manual/invoking.html new file mode 100644 index 0000000000..f00b68e459 --- /dev/null +++ b/docs/manual/invoking.html @@ -0,0 +1,108 @@ + + + + +Starting Apache + + + + + +

Starting Apache

+

Invoking Apache

+The httpd program is either invoked by the Internet +daemon inetd each time a connection to the HTTP service is made, +or alternatively it may run as a daemon which executes continuously, handling +requests. Whatever method is chosen, the +ServerType directive must be set +to tell the server how it is to run. + +

Command line options

+The following options are recognised on the httpd command line: +
+
-d serverroot +
Set the initial value for the +ServerRoot variable to +serverroot. This can be overridden by the ServerRoot command in the +configuration file. The default is /usr/local/etc/httpd. + +
-f config +
Execute the commands in the file config on startup. If +config does not begin with a /, then it is taken to be a +path relative to the ServerRoot. The +default is conf/httpd.conf. + +
-X +
Run in single-process mode, for internal debugging purposes only; the +daemon does not detach from the terminal or fork any children. Do NOT +use this mode to provide ordinary web service. + +
-v +
Print the version of httpd, and then exit. + +
-? +
Print a list of the httpd options, and then exit. +
+ +

Configuration files

+The server will read three files for configuration directives. Any directive +may appear in any of these files. The the names of these files are taken +to be relative to the server root; this is set by the +ServerRoot directive, or the +-d command line flag. + +Conventionally, the files are: +
+
conf/httpd.conf +
Contains directives that control the operation of the server daemon. +The filename may be overridden with the -f command line flag. + +
conf/srm.conf +
Contains directives that control the specification of documents that +the server can provide to clients. The filename may be overridden with +the ResourceConfig directive. + +
conf/acces.conf +
Contains directives that control access to documents. +The filename may be overridden with the +AccessConfig directive. +
+However, these conventions need not be adhered to. +

+The server also reads a file containing mime document types; the filename +is set by the TypesConfig directive, +and is conf/mime.types by default. + +

Log files

+

pid file

+On daemon startup, it saves the process id of the parent httpd process to +the file logs/httpd.pid. This filename can be changed with the +PidFile directive. The process-id is for +use by the administrator in restarting and terminating the daemon; +A HUP signal causes the daemon to re-read its configuration files and +a TERM signal causes it to die gracefully. +

+If the process dies (or is killed) abnormally, then it will be necessary to +kill the children httpd processes. + +

Error log

+The server will log error messages to a log file, logs/error_log +by default. The filename can be set using the +ErrorLog directive; different error logs can +be set for different virtual hosts. + +

Transfer log

+The server will typically log each request to a transfer file, +logs/access_log by default. The filename can be set using a +TransferLog directive; different +transfer logs can be set for different virtual +hosts. + + +
+Home +Index + + + + diff --git a/docs/manual/invoking.html.en b/docs/manual/invoking.html.en new file mode 100644 index 0000000000..f00b68e459 --- /dev/null +++ b/docs/manual/invoking.html.en @@ -0,0 +1,108 @@ + + + + +Starting Apache + + + + + +

Starting Apache

+

Invoking Apache

+The httpd program is either invoked by the Internet +daemon inetd each time a connection to the HTTP service is made, +or alternatively it may run as a daemon which executes continuously, handling +requests. Whatever method is chosen, the +ServerType directive must be set +to tell the server how it is to run. + +

Command line options

+The following options are recognised on the httpd command line: +
+
-d serverroot +
Set the initial value for the +ServerRoot variable to +serverroot. This can be overridden by the ServerRoot command in the +configuration file. The default is /usr/local/etc/httpd. + +
-f config +
Execute the commands in the file config on startup. If +config does not begin with a /, then it is taken to be a +path relative to the ServerRoot. The +default is conf/httpd.conf. + +
-X +
Run in single-process mode, for internal debugging purposes only; the +daemon does not detach from the terminal or fork any children. Do NOT +use this mode to provide ordinary web service. + +
-v +
Print the version of httpd, and then exit. + +
-? +
Print a list of the httpd options, and then exit. +
+ +

Configuration files

+The server will read three files for configuration directives. Any directive +may appear in any of these files. The the names of these files are taken +to be relative to the server root; this is set by the +ServerRoot directive, or the +-d command line flag. + +Conventionally, the files are: +
+
conf/httpd.conf +
Contains directives that control the operation of the server daemon. +The filename may be overridden with the -f command line flag. + +
conf/srm.conf +
Contains directives that control the specification of documents that +the server can provide to clients. The filename may be overridden with +the ResourceConfig directive. + +
conf/acces.conf +
Contains directives that control access to documents. +The filename may be overridden with the +AccessConfig directive. +
+However, these conventions need not be adhered to. +

+The server also reads a file containing mime document types; the filename +is set by the TypesConfig directive, +and is conf/mime.types by default. + +

Log files

+

pid file

+On daemon startup, it saves the process id of the parent httpd process to +the file logs/httpd.pid. This filename can be changed with the +PidFile directive. The process-id is for +use by the administrator in restarting and terminating the daemon; +A HUP signal causes the daemon to re-read its configuration files and +a TERM signal causes it to die gracefully. +

+If the process dies (or is killed) abnormally, then it will be necessary to +kill the children httpd processes. + +

Error log

+The server will log error messages to a log file, logs/error_log +by default. The filename can be set using the +ErrorLog directive; different error logs can +be set for different virtual hosts. + +

Transfer log

+The server will typically log each request to a transfer file, +logs/access_log by default. The filename can be set using a +TransferLog directive; different +transfer logs can be set for different virtual +hosts. + + +
+Home +Index + + + + diff --git a/docs/manual/location.html b/docs/manual/location.html new file mode 100644 index 0000000000..a1f4c9ea3f --- /dev/null +++ b/docs/manual/location.html @@ -0,0 +1,58 @@ + + + +Access Control by URL + + + + +

Access Control by URL

+ +

The <Location> Directive

+ +Syntax: <Location URL prefix>
+Context: server config, virtual host
+Status: core
+ +

The <Location> directive provides for access control by +URL. It is comprable to the <Directory> directive, and +should be matched with a </Location> directive. Directives that +apply to the URL given should be listen +within. <Location> sections are processed in the +order they appear in the configuration file, after the +<Directory> sections and .htaccess files are +read.

+ +

Note that, due to the way HTTP functions, URL prefix +should, save for proxy requests, be of the form /path/, +and should not include the http://servername. It doesn't +neccessarily have to protect a directory (it can be an individual +file, or a number of files), and can include wildcards. In a wildcard +string, `?' matches any single character, and `*' matches any +sequences of characters. + +

This functionality is especially useful when combined with the +SetHandler +directive. For example, to enable status requests, but allow them only +from browsers at foo.com, you might use: + +

+    <Location /status>
+    SetHandler server-status
+    
+    order deny,allow
+    deny from all
+    allow from .foo.com
+    
+    </Location>
+
+ +

+ +Home +Index + + + + diff --git a/docs/manual/process-model.html b/docs/manual/process-model.html new file mode 100644 index 0000000000..f2c22f9ccc --- /dev/null +++ b/docs/manual/process-model.html @@ -0,0 +1,50 @@ + +Server Pool Management with MinSpareServers and MaxSpareServers + + + +

Server Pool Management with MinSpareServers and MaxSpareServers

+ +
+

+We found that many people were using values for "MaxServers" either +too high or too low, and were hanging themselves on it. The model we +adopted is still based on long-lived minimal-forking processes, but +instead of specifying one number of persistant processes, the +webmaster specifies a maximum and minimum number of processes to be +"spare" - every couple of seconds the parent checks the actual number +of spare servers and adjusts accordingly. This should keep the number +of servers concurrently running relatively low while still ensuring +minimal forking. + +

+ +We renamed the current StartServers to MinSpareServers, created +separate StartServers parameter which means what it says, and renamed +MaxServers to MaxSpareServers (though the old name still works, for +NCSA 1.4 back-combatibility). The old names were generally regarded +as too confusing. + +

+ +The defaults for each variable are: + +

+MinSpareServers		5
+MaxSpareServers		10
+StartServers		10
+
+ +There is a compile-time limit of 150 absolute maximum number of +simultaneous children that will be allowed, which can be overruled by +"MaxClients", though we don't recommend changing that number unless + +
    +
  1. You know you have the server resources to handle more +
  2. You use the machine for other purposes and must limit the amount of memory +Apache uses +
+ + + + -- cgit v1.2.3