++ +There are two directives used to restrict or specify which addresses +and ports Apache listens to. + +
BindAddress *+ +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. + +
none+ +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 ++ +
+
+
+
+
+
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 @@
+
+
++ +There are two directives used to restrict or specify which addresses +and ports Apache listens to. + +
BindAddress *+ +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. + +
none+ +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 ++ +
+
+
+
+
+
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 @@
+
+
+
+
+
+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: + +
*.var file) names the files
+ containing the variants explicitly
+ 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:
+ Content-type:
+ image/gif, text/plain, or
+ text/html; level=3.
+ Content-language:
+ en for English,
+ kr for Korean, etc.).
+ Content-encoding:
+ x-compress, or gzip, as appropriate.
+ Content-length:
+ 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).
+
+
+
+
+
+
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 @@
+
+
+
+
+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: + +
*.var file) names the files
+ containing the variants explicitly
+ 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:
+ Content-type:
+ image/gif, text/plain, or
+ text/html; level=3.
+ Content-language:
+ en for English,
+ kr for Korean, etc.).
+ Content-encoding:
+ x-compress, or gzip, as appropriate.
+ Content-length:
+ 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).
+
+
+
+
+
+
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 @@
+
+
+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).
+
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
+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.
+ +
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
+
+ErrorDocument
+<3-digit-code> action
+ +where the action can be, +
%s.
+Note: the (") prefix isn't displayed.
+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.
+
+ +
+ +
+
REDIRECT_.REDIRECT_URL and REDIRECT_STATUS to help the script
+trace its origin.+
+
+
+
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 @@
+
+
+
+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).
+
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
+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.
+ +
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
+
+ErrorDocument
+<3-digit-code> action
+ +where the action can be, +
%s.
+Note: the (") prefix isn't displayed.
+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.
+
+ +
+ +
+
REDIRECT_.REDIRECT_URL and REDIRECT_STATUS to help the script
+trace its origin.+
+
+
+
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 @@
+
+
+
+
+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:
+ ++ +
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.
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> ++ +
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.
+
+
+
+
+
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 @@
+
+
+
+
+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:
+ ++ +
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.
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> ++ +
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.
+
+
+
+
+
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 @@
+
+
+
+
+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: +
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:
++Note that DBM auth has to be explicitly configured in, if you want +it; just uncomment the corresponding line. +
+% Configure
+Using 'Configuration' as config file
+%
+% Configure -file Configuration.ai
+Using alternate config file Configuration.ai
+%+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. +
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
+
+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.
+
+
+
+
+
+
+
+
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 @@
+
+
+
+
+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: +
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:
++Note that DBM auth has to be explicitly configured in, if you want +it; just uncomment the corresponding line. +
+% Configure
+Using 'Configuration' as config file
+%
+% Configure -file Configuration.ai
+Using alternate config file Configuration.ai
+%+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. +
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
+
+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.
+
+
+
+
+
+
+
+
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 @@
+
+
+
+
+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.
+
+-d serverroot
+/usr/local/etc/httpd.
+
+-f config
+/, then it is taken to be a
+path relative to the ServerRoot. The
+default is conf/httpd.conf.
+
+-X
+-v
+-?
+-d command line flag.
+
+Conventionally, the files are:
+conf/httpd.conf
+-f command line flag.
+
+conf/srm.conf
+conf/acces.conf
+
+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.
+
+
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. + +
logs/error_log
+by default. The filename can be set using the
+ErrorLog directive; different error logs can
+be set for different virtual hosts.
+
+logs/access_log by default. The filename can be set using a
+TransferLog directive; different
+transfer logs can be set for different virtual
+hosts.
+
+
+
+
+
+
+
+
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 @@
+
+
+
+
+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.
+
+-d serverroot
+/usr/local/etc/httpd.
+
+-f config
+/, then it is taken to be a
+path relative to the ServerRoot. The
+default is conf/httpd.conf.
+
+-X
+-v
+-?
+-d command line flag.
+
+Conventionally, the files are:
+conf/httpd.conf
+-f command line flag.
+
+conf/srm.conf
+conf/acces.conf
+
+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.
+
+
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. + +
logs/error_log
+by default. The filename can be set using the
+ErrorLog directive; different error logs can
+be set for different virtual hosts.
+
+logs/access_log by default. The filename can be set using a
+TransferLog directive; different
+transfer logs can be set for different virtual
+hosts.
+
+
+
+
+
+
+
+
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 @@
+
+
+
+
+<Location> DirectiveThe <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> +
+
+
+
+
+
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 @@
+
+
++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 + +