diff --git a/docs/manual/bind.html b/docs/manual/bind.html index e3023bfe57..75bacbb253 100644 --- a/docs/manual/bind.html +++ b/docs/manual/bind.html @@ -29,18 +29,21 @@ There are two directives used to restrict or specify which addresses and ports Apache listens to. -

BindAddress

+

BindAddress

Syntax: BindAddress [ * | IP-address | hostname ]
+>Syntax: BindAddress [ * | IP-address + | hostname ]
Port directive. Only one BindAddress should be used. -

Listen

+

Listen

-
  • BindAddress is used to restrict the server to listening to +
  • BindAddress is used to restrict the server to + listening to a single address, and can be used to permit multiple Apache servers on the same machine listening to different IP addresses. -
  • Listen can be used to make a single Apache server listen +
  • Listen can be used to make a single Apache server + listen to more than one address and/or port. -

    BindAddress

    +

    BindAddress

    Syntax: BindAddress [ * | IP-address | hostname ]
    +>Syntax: BindAddress [ * | IP-address + | hostname ]
    Port directive. Only one BindAddress should be used. -

    Listen

    +

    Listen

    -

    Overview

    +

    Overview

    As implemented in Apache 1.1.1 and earlier versions, the method Apache used to create PATH_INFO in the CGI environment was @@ -27,7 +27,7 @@ applications, the Apache 1.2 behavior is still compatible with the CGI/1.1 specification, and CGI scripts can be easily modified (see below). -

    The Problem

    +

    The Problem

    Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME environment variables by looking at the filename, not the URL. While @@ -46,7 +46,7 @@ SCRIPT_NAME to "/cgi-". Obviously, the latter is incorrect. In certain cases, this could even cause the server to crash.

    -

    The Solution

    +

    The Solution

    Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by looking directly at the URL, and determining how much of the URL is @@ -67,7 +67,7 @@ sort of information is not a recommended method, and a script making use of it "deserves" not to work. Apache 1.2b3 and later, however, do provide a workaround. -

    Compatibility with Previous Servers

    +

    Compatibility with Previous Servers

    It may be necessary for a script that was designed for earlier versions of Apache or other servers to need the information that the diff --git a/docs/manual/cgi_path.html.en b/docs/manual/cgi_path.html.en index 569ddbb343..2b7bd963b1 100644 --- a/docs/manual/cgi_path.html.en +++ b/docs/manual/cgi_path.html.en @@ -16,7 +16,7 @@

    -

    Overview

    +

    Overview

    As implemented in Apache 1.1.1 and earlier versions, the method Apache used to create PATH_INFO in the CGI environment was @@ -27,7 +27,7 @@ applications, the Apache 1.2 behavior is still compatible with the CGI/1.1 specification, and CGI scripts can be easily modified (see below). -

    The Problem

    +

    The Problem

    Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME environment variables by looking at the filename, not the URL. While @@ -46,7 +46,7 @@ SCRIPT_NAME to "/cgi-". Obviously, the latter is incorrect. In certain cases, this could even cause the server to crash.

    -

    The Solution

    +

    The Solution

    Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by looking directly at the URL, and determining how much of the URL is @@ -67,7 +67,7 @@ sort of information is not a recommended method, and a script making use of it "deserves" not to work. Apache 1.2b3 and later, however, do provide a workaround. -

    Compatibility with Previous Servers

    +

    Compatibility with Previous Servers

    It may be necessary for a script that was designed for earlier versions of Apache or other servers to need the information that the diff --git a/docs/manual/content-negotiation.html b/docs/manual/content-negotiation.html index 98e0190677..3f9d60ecf2 100644 --- a/docs/manual/content-negotiation.html +++ b/docs/manual/content-negotiation.html @@ -294,7 +294,8 @@ remains, move onto the next test.

  • Select the variants with the highest language quality factor
  • Select the variants with the best language match, using either the - order of languages on the LanguagePriority directive (if present), + order of languages on the LanguagePriority directive (if + present), else the order of languages on the Accept-Language header.
  • Select the variants with the highest 'level' media parameter @@ -330,7 +331,7 @@ and go to stage 3. -

    Fiddling with Quality Values

    +

    Fiddling with Quality Values

    Apache sometimes changes the quality values from what would be @@ -435,10 +436,11 @@ Examples:

    -Here some more examples of filenames together with valid and invalid hyperlinks: +Here some more examples of filenames together with valid and invalid +hyperlinks:

    - +
    diff --git a/docs/manual/content-negotiation.html.en b/docs/manual/content-negotiation.html.en index 98e0190677..3f9d60ecf2 100644 --- a/docs/manual/content-negotiation.html.en +++ b/docs/manual/content-negotiation.html.en @@ -294,7 +294,8 @@ remains, move onto the next test.
  • Select the variants with the highest language quality factor
  • Select the variants with the best language match, using either the - order of languages on the LanguagePriority directive (if present), + order of languages on the LanguagePriority directive (if + present), else the order of languages on the Accept-Language header.
  • Select the variants with the highest 'level' media parameter @@ -330,7 +331,7 @@ and go to stage 3. -

    Fiddling with Quality Values

    +

    Fiddling with Quality Values

    Apache sometimes changes the quality values from what would be @@ -435,10 +436,11 @@ Examples:

    -Here some more examples of filenames together with valid and invalid hyperlinks: +Here some more examples of filenames together with valid and invalid +hyperlinks:

    -
    • Filename Valid hyperlink
    +
    diff --git a/docs/manual/custom-error.html b/docs/manual/custom-error.html index 5e2a3a9475..c76f224e26 100644 --- a/docs/manual/custom-error.html +++ b/docs/manual/custom-error.html @@ -49,7 +49,8 @@

    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 + 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 @@ -70,18 +71,23 @@ 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. +

    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. None of these will be set if your ErrorDocument is an - external redirect (i.e. anything starting with a protocol name + external redirect (i.e., anything starting with a + scheme name like http:, even if it refers to the same host as the server).

    Configuration
    Use of "ErrorDocument" is enabled for .htaccess files when the - "FileInfo" override is allowed. + "FileInfo" override is + allowed.

    Here are some examples... @@ -126,7 +132,8 @@ ErrorDocument 401 /Subscription/how_to_subscribe.html

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

    @@ -146,6 +153,24 @@ Both the original URL and the URL being redirected to can be logged in the access log. +

    +If the ErrorDocument specifies a local redirect to a CGI script, the script +should include a "Status:" header field in its output +in order to ensure the propagation all the way back to the client +of the error condition that caused it to be invoked. For instance, a Perl +ErrorDocument script might include the following: +

    +
    +      :
+    print  "Content-type: text/html\n";
+    printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
+      :
+
    +

    +If the script is dedicated to handling a particular error condition, such as +404 Not Found, it can use the specific code and +error text instead. +

    diff --git a/docs/manual/custom-error.html.en b/docs/manual/custom-error.html.en index 5e2a3a9475..c76f224e26 100644 --- a/docs/manual/custom-error.html.en +++ b/docs/manual/custom-error.html.en @@ -49,7 +49,8 @@

    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 + 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 @@ -70,18 +71,23 @@ 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. +

    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. None of these will be set if your ErrorDocument is an - external redirect (i.e. anything starting with a protocol name + external redirect (i.e., anything starting with a + scheme name like http:, even if it refers to the same host as the server).

    Configuration
    Use of "ErrorDocument" is enabled for .htaccess files when the - "FileInfo" override is allowed. + "FileInfo" override is + allowed.

    Here are some examples... @@ -126,7 +132,8 @@ ErrorDocument 401 /Subscription/how_to_subscribe.html

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

    @@ -146,6 +153,24 @@ Both the original URL and the URL being redirected to can be logged in the access log. +

    +If the ErrorDocument specifies a local redirect to a CGI script, the script +should include a "Status:" header field in its output +in order to ensure the propagation all the way back to the client +of the error condition that caused it to be invoked. For instance, a Perl +ErrorDocument script might include the following: +

    +
    +      :
+    print  "Content-type: text/html\n";
+    printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
+      :
+
    +

    +If the script is dedicated to handling a particular error condition, such as +404 Not Found, it can use the specific code and +error text instead. +

    diff --git a/docs/manual/developer/API.html b/docs/manual/developer/API.html index 3918922588..1b59833024 100644 --- a/docs/manual/developer/API.html +++ b/docs/manual/developer/API.html @@ -43,9 +43,11 @@ coming up, and in what order:
  • A brief tour of the request_rec
  • Where request_rec structures come from -
  • Handling requests, declining, and returning error codes +
  • Handling requests, declining, and returning error + codes
  • Special considerations for response handlers -
  • Special considerations for authentication handlers +
  • Special considerations for authentication + handlers
  • Special considerations for logging handlers
  • Resource allocation and resource pools @@ -53,16 +55,17 @@ coming up, and in what order:
  • Per-directory configuration structures
  • Command handling -
  • Side notes --- per-server configuration, virtual servers, etc. +
  • Side notes --- per-server configuration, + virtual servers, etc.
    • -

    Basic concepts.

    +

    Basic concepts.

    We begin with an overview of the basic concepts behind the API, and how they are manifested in the code. -

    Handlers, Modules, and Requests

    +

    Handlers, Modules, and Requests

    Apache breaks down request handling into a series of steps, more or less the same way the Netscape server API does (although this API has @@ -116,7 +119,7 @@ The handlers themselves are functions of one argument (a request_rec structure. vide infra), which returns an integer, as above.

    -

    A brief tour of a module

    +

    A brief tour of a module

    At this point, we need to explain the structure of a module. Our candidate will be one of the messier ones, the CGI module --- this @@ -215,14 +218,14 @@ module cgi_module = { }; -

    How handlers work

    +

    How handlers work

    The sole argument to handlers is a request_rec structure. This structure describes a particular request which has been made to the server, on behalf of a client. In most cases, each connection to the client generates only one request_rec structure.

    -

    A brief tour of the request_rec

    +

    A brief tour of the request_rec

    The request_rec contains pointers to a resource pool which will be cleared when the server is finished handling the @@ -329,7 +332,7 @@ struct request_rec { -

    Where request_rec structures come from

    +

    Where request_rec structures come from

    Most request_rec structures are built by reading an HTTP request from a client, and filling in the fields. However, there are @@ -370,7 +373,8 @@ a few exceptions: function run_sub_request). -

    Handling requests, declining, and returning error codes

    +

    Handling requests, declining, and returning error + codes

    As discussed above, each handler, when invoked to handle a particular request_rec, has to return an int to @@ -389,7 +393,8 @@ the module should put a Location in the request's headers_out, to indicate where the client should be redirected to.

    -

    Special considerations for response handlers

    +

    Special considerations for response + handlers

    Handlers for most phases do their work by simply setting a few fields in the request_rec structure (or, in the case of access @@ -463,7 +468,8 @@ internally redirected should always return OK.

    (Invoking ap_internal_redirect from handlers which are not response handlers will lead to serious confusion). -

    Special considerations for authentication handlers

    +

    Special considerations for authentication + handlers

    Stuff that should be discussed here in detail: @@ -481,7 +487,7 @@ Stuff that should be discussed here in detail: to be sent back). -

    Special considerations for logging handlers

    +

    Special considerations for logging handlers

    When a request has internally redirected, there is the question of what to log. Apache handles this by bundling the entire chain of @@ -493,7 +499,7 @@ initial request from the client; note that the bytes_sent field will only be correct in the last request in the chain (the one for which a response was actually sent). -

    Resource allocation and resource pools

    +

    Resource allocation and resource pools

    One of the problems of writing and designing a server-pool server is that of preventing leakage, that is, allocating resources (memory, @@ -610,7 +616,7 @@ of the strings, as a unit; for instance: returns a pointer to 8 bytes worth of memory, initialized to "foo/bar".

    -

    Commonly-used pools in the Apache Web server

    +

    Commonly-used pools in the Apache Web server

    A pool is really defined by its lifetime more than anything else. There are some static pools in http_main which are passed to various @@ -633,7 +639,7 @@ non-http_main functions as arguments at opportune times. Here they are:

  • created at the beginning of a config "cycle"; exists until the server is terminated or restarts; passed to all config-time - routines, either via cmd->pool, or as the "pool *p" argument on + routines, either via cmd->pool, or as the "pool *p" argument on those which don't take pools
  • passed to the module init() functions @@ -652,8 +658,8 @@ non-http_main functions as arguments at opportune times. Here they are:
  • subpool of permanent_pool
  • created at the beginning of a config "cycle"; exists until the - end of config parsing; passed to config-time routines via - cmd->temp_pool. Somewhat of a "bastard child" because it isn't + end of config parsing; passed to config-time routines via + cmd->temp_pool. Somewhat of a "bastard child" because it isn't available everywhere. Used for temporary scratch space which may be needed by some config routines but which is deleted at the end of config. @@ -687,52 +693,54 @@ non-http_main functions as arguments at opportune times. Here they are:
  • cleared by the child before going into the accept() loop to receive a connection
    • -
  • used as connection->pool +
  • used as connection->pool
    • -
    r->pool +
    r->pool

    -For almost everything folks do, r->pool is the pool to use. But you +For almost everything folks do, r->pool is the pool to use. But you can see how other lifetimes, such as pchild, are useful to some modules... such as modules that need to open a database connection once per child, and wish to clean it up when the child dies.

    You can also see how some bugs have manifested themself, such as setting -connection->user to a value from r->pool -- in this case connection exists -for the lifetime of ptrans, which is longer than r->pool (especially if -r->pool is a subrequest!). So the correct thing to do is to allocate -from connection->pool. +connection->user to a value from r->pool -- in this case +connection exists +for the lifetime of ptrans, which is longer than r->pool (especially if +r->pool is a subrequest!). So the correct thing to do is to allocate +from connection->pool.

    And there was another interesting bug in mod_include/mod_cgi. You'll see -in those that they do this test to decide if they should use r->pool -or r->main->pool. In this case the resource that they are registering -for cleanup is a child process. If it were registered in r->pool, +in those that they do this test to decide if they should use r->pool +or r->main->pool. In this case the resource that they are registering +for cleanup is a child process. If it were registered in r->pool, then the code would wait() for the child when the subrequest finishes. With mod_include this could be any old #include, and the delay can be up to 3 seconds... and happened quite frequently. Instead the subprocess -is registered in r->main->pool which causes it to be cleaned up when +is registered in r->main->pool which causes it to be cleaned up when the entire request is done -- i.e., after the output has been sent to the client and logging has happened.

    -

    Tracking open files, etc.

    +

    Tracking open files, etc.

    As indicated above, resource pools are also used to track other sorts of resources besides memory. The most common are open files. The @@ -824,7 +832,7 @@ cleared. It is only when you are allocating many, many sub-requests for a single main request that you should seriously consider the ap_destroy... functions). -

    Configuration, commands and the like

    +

    Configuration, commands and the like

    One of the design goals for this server was to maintain external compatibility with the NCSA 1.3 server --- that is, to read the same @@ -873,7 +881,7 @@ for handling them. That is solved the same way it is solved wherever else similar problems come up, by tying those structures to the per-transaction resource pool.

    -

    Per-directory configuration structures

    +

    Per-directory configuration structures

    Let's look out how all of this plays out in mod_mime.c, which defines the file typing handler which emulates the NCSA server's @@ -966,7 +974,7 @@ consists solely of the state of the XBITHACK), and for those modules, you can just not declare one, and leave the corresponding structure slot in the module itself NULL.

    -

    Command handling

    +

    Command handling

    Now that we have these structures, we need to be able to figure out how to fill them. That involves processing the actual @@ -1105,7 +1113,8 @@ int find_ct(request_rec *r) -

    Side notes --- per-server configuration, virtual servers, etc.

    +

    Side notes --- per-server configuration, virtual + servers, etc.

    The basic ideas behind per-server module configuration are basically the same as those for per-directory configuration; there is a creation diff --git a/docs/manual/dns-caveats.html b/docs/manual/dns-caveats.html index 530573fc79..cbf8a57a9d 100644 --- a/docs/manual/dns-caveats.html +++ b/docs/manual/dns-caveats.html @@ -141,7 +141,7 @@ CGIs unless you use mod_env to control the environment. It's best to consult the man pages or FAQs for your OS. -

    Tips to Avoid these problems

    +

    Tips to Avoid these problems

    -

    Porting Notes

    +

    Porting Notes

    1. @@ -200,8 +200,8 @@

    -

    Document Storage Notes

    -

    Binary Files

    +

    Document Storage Notes

    +

    Binary Files

    All files with a Content-Type: which does not start with text/ are regarded as binary files @@ -217,7 +217,7 @@ (the -b switch is not supported in unix rcp's).

    -

    Text Documents

    +

    Text Documents

    The default assumption of the server is that Text Files (i.e., all files whose Content-Type: starts with @@ -225,13 +225,13 @@ set of the host, EBCDIC.

    -

    Server Side Included Documents

    +

    Server Side Included Documents

    SSI documents must currently be stored in EBCDIC only. No provision is made to convert it from ASCII before processing.

    -

    Apache Modules' Status

    +

    Apache Modules' Status

    Filename Valid hyperlink
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Module @@ -240,223 +240,223 @@
    http_core - + + http_core + +
    mod_access - + + mod_access + +
    mod_actions - ? + mod_actions + ?
    mod_alias - + + mod_alias + +
    mod_asis - ? + mod_asis + ?
    mod_auth - + + mod_auth + +
    mod_auth_anon - + + mod_auth_anon + +
    mod_auth_db - ? + mod_auth_db + ? with own libdb.a
    mod_auth_dbm - ? + mod_auth_dbm + ? with own libdb.a
    mod_autoindex - + + mod_autoindex + +
    mod_cern_meta - ? + mod_cern_meta + ?
    mod_cgi - + + mod_cgi + +
    mod_digest - - + mod_digest + - MD5 not ported yet
    mod_dir - + + mod_dir + +
    mod_dld - - + mod_dld + - no shared libs
    mod_env - + + mod_env + +
    mod_example - - + mod_example + - not tried yet
    mod_expires - + + mod_expires + +
    mod_headers - + + mod_headers + +
    mod_imap - + + mod_imap + +
    mod_include - + + mod_include + +
    mod_info - + + mod_info + +
    mod_log_agent - + + mod_log_agent + +
    mod_log_config - + + mod_log_config + +
    mod_log_referer - + + mod_log_referer + +
    mod_mime - + + mod_mime + +
    mod_mime_magic - - + mod_mime_magic + - not tried yet
    mod_negotiation - + + mod_negotiation + +
    mod_proxy - + + mod_proxy + +
    mod_rewrite - ? + mod_rewrite + ? untested
    mod_setenvif - + + mod_setenvif + +
    mod_speling - + + mod_speling + +
    mod_status - + + mod_status + +
    mod_unique_id - + + mod_unique_id + +
    mod_userdir - + + mod_userdir + +
    mod_usertrack - ? + mod_usertrack + ? untested
    -

    Third Party Modules' Status

    +

    Third Party Modules' Status

    - - - - diff --git a/docs/manual/handler.html b/docs/manual/handler.html index 638d740f8e..84cd97c06b 100644 --- a/docs/manual/handler.html +++ b/docs/manual/handler.html @@ -69,16 +69,18 @@ handlers in the standard distribution are as follows:

    -

    AddHandler

    +

    AddHandler

    Syntax: <AddHandler handler-name extension>
    +>Syntax: <AddHandler handler-name + extension>
    Context: server config, virtual host, directory, .htaccess
    +>Context: server config, virtual host, directory, + .htaccess
    -

    SetHandler

    +

    SetHandler

    -

    AddHandler

    +

    AddHandler

    Syntax: <AddHandler handler-name extension>
    +>Syntax: <AddHandler handler-name + extension>
    Context: server config, virtual host, directory, .htaccess
    +>Context: server config, virtual host, directory, + .htaccess
    -

    SetHandler

    +

    SetHandler

    <URL:http://www.apache.org/dist/contrib/modules/>. +parties with specific needs or functions are available at +<http://www.apache.org/dist/contrib/modules/>. There are instructions on that page for linking these modules into the core Apache code. diff --git a/docs/manual/install.html.en b/docs/manual/install.html.en index 077c4ef7c2..ad532557e1 100644 --- a/docs/manual/install.html.en +++ b/docs/manual/install.html.en @@ -110,8 +110,9 @@ directory of the Apache distribution. Change into this directory. 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/>. +parties with specific needs or functions are available at +<http://www.apache.org/dist/contrib/modules/>. There are instructions on that page for linking these modules into the core Apache code. diff --git a/docs/manual/invoking.html b/docs/manual/invoking.html index e7767cbbdf..df0a4d0445 100644 --- a/docs/manual/invoking.html +++ b/docs/manual/invoking.html @@ -46,13 +46,14 @@ use this mode to provide ordinary web service.
    -v
    Print the version of httpd and its build date, and then exit. -
    -V +
    -V
    Print the base version of httpd, its sub-version if defined, its build date, and a list of compile time settings which influence the -behavior and performance of the apache server (e.g., -D USE_MMAP_FILES), +behavior and performance of the apache server (e.g., +-DUSE_MMAP_FILES), then exit. -
    -h +
    -h
    Give a list of directives together with expected arguments and places where the directive is valid. (New in Apache 1.2) @@ -93,7 +94,8 @@ The filename may be overridden with the 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, +is set by the TypesConfig +directive, and is conf/mime.types by default.

    Log files

    @@ -119,15 +121,16 @@ 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 +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. +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 index e7767cbbdf..df0a4d0445 100644 --- a/docs/manual/invoking.html.en +++ b/docs/manual/invoking.html.en @@ -46,13 +46,14 @@ use this mode to provide ordinary web service.
    -v
    Print the version of httpd and its build date, and then exit. -
    -V +
    -V
    Print the base version of httpd, its sub-version if defined, its build date, and a list of compile time settings which influence the -behavior and performance of the apache server (e.g., -D USE_MMAP_FILES), +behavior and performance of the apache server (e.g., +-DUSE_MMAP_FILES), then exit. -
    -h +
    -h
    Give a list of directives together with expected arguments and places where the directive is valid. (New in Apache 1.2) @@ -93,7 +94,8 @@ The filename may be overridden with the 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, +is set by the TypesConfig +directive, and is conf/mime.types by default.

    Log files

    @@ -119,15 +121,16 @@ 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 +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. +TransferLog directive; +different transfer logs can be set for different +virtual hosts. diff --git a/docs/manual/location.html b/docs/manual/location.html index 7cf602541c..2dddd2ee2c 100644 --- a/docs/manual/location.html +++ b/docs/manual/location.html @@ -15,7 +15,7 @@

    Access Control by URL

    -

    The <Location> Directive

    +

    The <Location> Directive

  • A brief tour of the request_rec
  • Where request_rec structures come from -
  • Handling requests, declining, and returning error codes +
  • Handling requests, declining, and returning error + codes
  • Special considerations for response handlers -
  • Special considerations for authentication handlers +
  • Special considerations for authentication + handlers
  • Special considerations for logging handlers
  • Resource allocation and resource pools @@ -53,16 +55,17 @@ coming up, and in what order:
  • Per-directory configuration structures
  • Command handling -
  • Side notes --- per-server configuration, virtual servers, etc. +
  • Side notes --- per-server configuration, + virtual servers, etc.
    • -

    Basic concepts.

    +

    Basic concepts.

    We begin with an overview of the basic concepts behind the API, and how they are manifested in the code. -

    Handlers, Modules, and Requests

    +

    Handlers, Modules, and Requests

    Apache breaks down request handling into a series of steps, more or less the same way the Netscape server API does (although this API has @@ -116,7 +119,7 @@ The handlers themselves are functions of one argument (a request_rec structure. vide infra), which returns an integer, as above.

    -

    A brief tour of a module

    +

    A brief tour of a module

    At this point, we need to explain the structure of a module. Our candidate will be one of the messier ones, the CGI module --- this @@ -215,14 +218,14 @@ module cgi_module = { }; -

    How handlers work

    +

    How handlers work

    The sole argument to handlers is a request_rec structure. This structure describes a particular request which has been made to the server, on behalf of a client. In most cases, each connection to the client generates only one request_rec structure.

    -

    A brief tour of the request_rec

    +

    A brief tour of the request_rec

    The request_rec contains pointers to a resource pool which will be cleared when the server is finished handling the @@ -329,7 +332,7 @@ struct request_rec { -

    Where request_rec structures come from

    +

    Where request_rec structures come from

    Most request_rec structures are built by reading an HTTP request from a client, and filling in the fields. However, there are @@ -370,7 +373,8 @@ a few exceptions: function run_sub_request). -

    Handling requests, declining, and returning error codes

    +

    Handling requests, declining, and returning error + codes

    As discussed above, each handler, when invoked to handle a particular request_rec, has to return an int to @@ -389,7 +393,8 @@ the module should put a Location in the request's headers_out, to indicate where the client should be redirected to.

    -

    Special considerations for response handlers

    +

    Special considerations for response + handlers

    Handlers for most phases do their work by simply setting a few fields in the request_rec structure (or, in the case of access @@ -463,7 +468,8 @@ internally redirected should always return OK.

    (Invoking ap_internal_redirect from handlers which are not response handlers will lead to serious confusion). -

    Special considerations for authentication handlers

    +

    Special considerations for authentication + handlers

    Stuff that should be discussed here in detail: @@ -481,7 +487,7 @@ Stuff that should be discussed here in detail: to be sent back). -

    Special considerations for logging handlers

    +

    Special considerations for logging handlers

    When a request has internally redirected, there is the question of what to log. Apache handles this by bundling the entire chain of @@ -493,7 +499,7 @@ initial request from the client; note that the bytes_sent field will only be correct in the last request in the chain (the one for which a response was actually sent). -

    Resource allocation and resource pools

    +

    Resource allocation and resource pools

    One of the problems of writing and designing a server-pool server is that of preventing leakage, that is, allocating resources (memory, @@ -610,7 +616,7 @@ of the strings, as a unit; for instance: returns a pointer to 8 bytes worth of memory, initialized to "foo/bar".

    -

    Commonly-used pools in the Apache Web server

    +

    Commonly-used pools in the Apache Web server

    A pool is really defined by its lifetime more than anything else. There are some static pools in http_main which are passed to various @@ -633,7 +639,7 @@ non-http_main functions as arguments at opportune times. Here they are:

  • created at the beginning of a config "cycle"; exists until the server is terminated or restarts; passed to all config-time - routines, either via cmd->pool, or as the "pool *p" argument on + routines, either via cmd->pool, or as the "pool *p" argument on those which don't take pools
  • passed to the module init() functions @@ -652,8 +658,8 @@ non-http_main functions as arguments at opportune times. Here they are:
  • subpool of permanent_pool
  • created at the beginning of a config "cycle"; exists until the - end of config parsing; passed to config-time routines via - cmd->temp_pool. Somewhat of a "bastard child" because it isn't + end of config parsing; passed to config-time routines via + cmd->temp_pool. Somewhat of a "bastard child" because it isn't available everywhere. Used for temporary scratch space which may be needed by some config routines but which is deleted at the end of config. @@ -687,52 +693,54 @@ non-http_main functions as arguments at opportune times. Here they are:
  • cleared by the child before going into the accept() loop to receive a connection
    • -
  • used as connection->pool +
  • used as connection->pool
    • -
    r->pool +
    r->pool

    -For almost everything folks do, r->pool is the pool to use. But you +For almost everything folks do, r->pool is the pool to use. But you can see how other lifetimes, such as pchild, are useful to some modules... such as modules that need to open a database connection once per child, and wish to clean it up when the child dies.

    You can also see how some bugs have manifested themself, such as setting -connection->user to a value from r->pool -- in this case connection exists -for the lifetime of ptrans, which is longer than r->pool (especially if -r->pool is a subrequest!). So the correct thing to do is to allocate -from connection->pool. +connection->user to a value from r->pool -- in this case +connection exists +for the lifetime of ptrans, which is longer than r->pool (especially if +r->pool is a subrequest!). So the correct thing to do is to allocate +from connection->pool.

    And there was another interesting bug in mod_include/mod_cgi. You'll see -in those that they do this test to decide if they should use r->pool -or r->main->pool. In this case the resource that they are registering -for cleanup is a child process. If it were registered in r->pool, +in those that they do this test to decide if they should use r->pool +or r->main->pool. In this case the resource that they are registering +for cleanup is a child process. If it were registered in r->pool, then the code would wait() for the child when the subrequest finishes. With mod_include this could be any old #include, and the delay can be up to 3 seconds... and happened quite frequently. Instead the subprocess -is registered in r->main->pool which causes it to be cleaned up when +is registered in r->main->pool which causes it to be cleaned up when the entire request is done -- i.e., after the output has been sent to the client and logging has happened.

    -

    Tracking open files, etc.

    +

    Tracking open files, etc.

    As indicated above, resource pools are also used to track other sorts of resources besides memory. The most common are open files. The @@ -824,7 +832,7 @@ cleared. It is only when you are allocating many, many sub-requests for a single main request that you should seriously consider the ap_destroy... functions). -

    Configuration, commands and the like

    +

    Configuration, commands and the like

    One of the design goals for this server was to maintain external compatibility with the NCSA 1.3 server --- that is, to read the same @@ -873,7 +881,7 @@ for handling them. That is solved the same way it is solved wherever else similar problems come up, by tying those structures to the per-transaction resource pool.

    -

    Per-directory configuration structures

    +

    Per-directory configuration structures

    Let's look out how all of this plays out in mod_mime.c, which defines the file typing handler which emulates the NCSA server's @@ -966,7 +974,7 @@ consists solely of the state of the XBITHACK), and for those modules, you can just not declare one, and leave the corresponding structure slot in the module itself NULL.

    -

    Command handling

    +

    Command handling

    Now that we have these structures, we need to be able to figure out how to fill them. That involves processing the actual @@ -1105,7 +1113,8 @@ int find_ct(request_rec *r) -

    Side notes --- per-server configuration, virtual servers, etc.

    +

    Side notes --- per-server configuration, virtual + servers, etc.

    The basic ideas behind per-server module configuration are basically the same as those for per-directory configuration; there is a creation diff --git a/docs/manual/misc/FAQ.html b/docs/manual/misc/FAQ.html index a1c5783c4e..949c18844a 100644 --- a/docs/manual/misc/FAQ.html +++ b/docs/manual/misc/FAQ.html @@ -3,8 +3,7 @@ Apache Server Frequently Asked Questions - - +

    Apache Server Frequently Asked Questions

    - $Revision: 1.115 $ ($Date: 1998/05/20 11:12:42 $) + $Revision: 1.116 $ ($Date: 1998/05/20 14:22:39 $)

    The latest version of this FAQ is always available from the main @@ -1122,7 +1121,7 @@

    -
  • +
  • Why do my Java app[let]s give me plain text when I request an URL from an Apache server? diff --git a/docs/manual/misc/client_block_api.html b/docs/manual/misc/client_block_api.html index c346c4adb3..e70a8284fc 100644 --- a/docs/manual/misc/client_block_api.html +++ b/docs/manual/misc/client_block_api.html @@ -65,7 +65,8 @@ accomplished while remaining backwards-compatible.

    should proceed (to step 3). This step also sends a 100 Continue response to HTTP/1.1 clients, so should not be called until the module - is *definitely* ready to read content. (otherwise, the point of the + is *definitely* ready to read content. (otherwise, the + point of the 100 response is defeated). Never call this function more than once.
  • Finally, call ap_get_client_block in a loop. Pass it a diff --git a/docs/manual/misc/custom_errordocs.html b/docs/manual/misc/custom_errordocs.html index 261f1b86be..7eee41a125 100644 --- a/docs/manual/misc/custom_errordocs.html +++ b/docs/manual/misc/custom_errordocs.html @@ -37,7 +37,8 @@ to return error messages generated by the server in the client's native language.

    -By using XSSI, all customized messages +By using XSSI, all +customized messages can share a homogenous and consistent style and layout, and maintenance work (changing images, changing links) is kept to a minimum because all layout information can be kept in a single file.
    @@ -90,7 +91,9 @@ of as much server support as we can get:

  • By defining the MultiViews option, we enable the language selection of the most appropriate language alternative (content negotiation). -
  • By setting the LanguagePriority +
  • By setting the + LanguagePriority directive we define a set of default fallback languages in the situation where the client's browser did not express any preference at all.
  • By enabling Server Side Includes @@ -111,7 +114,8 @@ of as much server support as we can get: restricts these "special" settings to the error document directory and avoids an impact on any of the settings for the regular document tree.
  • For each of the error codes to be handled (see RFC2068 for an exact - description of each error code, or look at src/main/http_protocol.c + description of each error code, or look at + src/main/http_protocol.c if you wish to see apache's standard messages), an ErrorDocument in the aliased /errordocs directory is defined. @@ -212,7 +216,8 @@ For simplicity, the header file is simply called head.shtml because it contains server-parsed content but no language specific information. The footer file exists once for each language translation, plus a symlink for the default language.

    -Example: for english, french and german versions (default english)
    +Example: for English, French and German versions +(default english)
    foot.shtml.en,
    foot.shtml.fr,
    foot.shtml.de,
    @@ -228,15 +233,16 @@ See the listings below to see an actual HTML implementation of the discussed example. -

    Creating ErrorDocuments in different languages

    +

    Creating ErrorDocuments in different languages +

    After all this preparation work, little remains to be said about the actual documents. They all share a simple common structure: 
    -<!--#set var="title" value="error description title" -->
-<!--#include virtual="head" -->
+<!--#set var="title" value="error description title" -->
+<!--#include virtual="head" -->
    explanatory error text
-<!--#include virtual="foot" -->
+<!--#include virtual="foot" -->
    In the listings section, you can see an example of a [400 Bad Request] error document. Documents as simple as that @@ -283,26 +289,26 @@ almost nothing but the error text (with conditional additions). Starting with this example, you will find it easy to add more error documents, or to translate the error documents to different languages. 
    -<!--#set var="title" value="Bad Request"
---><!--#include virtual="head" --><P>
+<!--#set var="title" value="Bad Request"
+--><!--#include virtual="head" --><P>
    Your browser sent a request that this server could not understand:
    <BLOCKQUOTE>
-     <STRONG><!--#echo var="REQUEST_URI" --></STRONG>
+     <STRONG><!--#echo var="REQUEST_URI" --></STRONG>
    </BLOCKQUOTE>
    The request could not be understood by the server due to malformed
    syntax. The client should not repeat the request without
    modifications.
    </P>
    <P>
-   <!--#if expr="\"$HTTP_REFERER\" != \"\"" -->
+   <!--#if expr="\"$HTTP_REFERER\" != \"\"" -->
     Please inform the owner of
-    <A HREF="<!--#echo var="HTTP_REFERER" -->">the referring page</A> about 
+    <A HREF="<!--#echo var="HTTP_REFERER" -->">the referring page</A> about 
     the malformed link.
    <!--#else -->
     Please check your request for typing errors and retry.
    <!--#endif -->
    </P>
-<!--#include virtual="foot" -->
+<!--#include virtual="foot" -->
    Here is the complete head.shtml file (the funny line @@ -315,34 +321,34 @@ appears to support it (the latter requires server configuration lines of the form
    BrowserMatch "^Mozilla/[2-4]" anigif
    for browser types which support animated GIFs). 
    -<!--#if expr="\"$SERVER_NAME\" = /.*\.mycompany\.com/" 
---><!--#set var="IMG_CorpLogo"
-            value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif" 
---><!--#set var="ALT_CorpLogo" value="Powered by Linux!" 
+<!--#if expr="\"$SERVER_NAME\" = /.*\.mycompany\.com/" 
+--><!--#set var="IMG_CorpLogo"
+            value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif" 
+--><!--#set var="ALT_CorpLogo" value="Powered by Linux!" 
 --><!--#else
---><!--#set var="IMG_CorpLogo"
-            value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif" 
---><!--#set var="ALT_CorpLogo" value="Powered by Linux!" 
+--><!--#set var="IMG_CorpLogo"
+            value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif" 
+--><!--#set var="ALT_CorpLogo" value="Powered by Linux!" 
 --><!--#endif
---><!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif" 
---><!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/" 
---><!--#if expr="$anigif" 
---><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif" 
+--><!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif" 
+--><!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/" 
+--><!--#if expr="$anigif" 
+--><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif" 
 --><!--#else
---><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif" 
+--><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif" 
 --><!--#endif
---><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+--><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
 <HTML>
  <HEAD>
   <TITLE>
-   [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
+   [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
   </TITLE>
  </HEAD>
- <BODY BGCOLOR="white" BACKGROUND="<!--#echo var="IMG_BgImage" -->"><UL>
-  <H1 ALIGN="center">
-   [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
-   <IMG SRC="<!--#echo var="IMG_CorpLogo" -->"
-        ALT="<!--#echo var="ALT_CorpLogo" -->" ALIGN=right>
+ <BODY BGCOLOR="white" BACKGROUND="<!--#echo var="IMG_BgImage" -->"><UL>
+  <H1 ALIGN="center">
+   [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
+   <IMG SRC="<!--#echo var="IMG_CorpLogo" -->"
+        ALT="<!--#echo var="ALT_CorpLogo" -->" ALIGN=right>
   </H1>
   <HR><!-- ======================================================== -->
   <DIV>
@@ -352,22 +358,22 @@ for browser types which support animated GIFs).
 
   </DIV>
   <HR>
-  <DIV ALIGN="right"><SMALL><SUP>Local Server time:
-      <!--#echo var="DATE_LOCAL" -->
+  <DIV ALIGN="right"><SMALL><SUP>Local Server time:
+      <!--#echo var="DATE_LOCAL" -->
   </SUP></SMALL></DIV>
-  <DIV ALIGN="center">
-    <A HREF="<!--#echo var="DOC_Apache" -->">
-    <IMG SRC="<!--#echo var="IMG_Apache" -->" BORDER=0 ALIGN="bottom"
-         ALT="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></A><BR>
-    <SMALL><SUP><!--#set var="var"
-     value="Powered by $SERVER_SOFTWARE -- File last modified on $LAST_MODIFIED"
-    --><!--#echo var="var" --></SUP></SMALL>
+  <DIV ALIGN="center">
+    <A HREF="<!--#echo var="DOC_Apache" -->">
+    <IMG SRC="<!--#echo var="IMG_Apache" -->" BORDER=0 ALIGN="bottom"
+         ALT="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></A><BR>
+    <SMALL><SUP><!--#set var="var"
+     value="Powered by $SERVER_SOFTWARE -- File last modified on $LAST_MODIFIED"
+    --><!--#echo var="var" --></SUP></SMALL>
   </DIV>
   <ADDRESS>If the indicated error looks like a misconfiguration, please inform
-   <A HREF="mailto:<!--#echo var="SERVER_ADMIN" -->"
-      SUBJECT="Feedback about Error message [<!--#echo var="REDIRECT_STATUS" 
-        -->] <!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->">
-   <!--#echo var="SERVER_NAME" -->'s WebMaster</A>.
+   <A HREF="mailto:<!--#echo var="SERVER_ADMIN" -->"
+      SUBJECT="Feedback about Error message [<!--#echo var="REDIRECT_STATUS" 
+        -->] <!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->">
+   <!--#echo var="SERVER_NAME" -->'s WebMaster</A>.
   </ADDRESS>
  </UL></BODY>
 </HTML>
diff --git a/docs/manual/misc/fin_wait_2.html b/docs/manual/misc/fin_wait_2.html
index 135b8b06e0..f264bf24a0 100644
--- a/docs/manual/misc/fin_wait_2.html
+++ b/docs/manual/misc/fin_wait_2.html
@@ -154,7 +154,8 @@ violation of the RFC, but it is widely recognized as being necessary.
 The following systems are known to have a timeout:
 
    
 
      
-        
    • FreeBSD versions starting at 2.0 or possibly earlier.
+        
    • FreeBSD versions starting at
+            2.0 or possibly earlier.
         
    • NetBSD version 1.2(?)
         
    • OpenBSD all versions(?)
         
    • BSD/OS 2.1, with the
@@ -204,8 +205,8 @@ The following systems are known to not have a timeout:
 
    
 
    
 There is a
-
-patch available for adding a timeout to the FIN_WAIT_2 state; it
+patch available for adding a timeout to the FIN_WAIT_2 state; it
 was originally intended for BSD/OS, but should be adaptable to most
 systems using BSD networking code.  You need kernel source code to be
 able to use it.  If you do adapt it to work for any other systems,
diff --git a/docs/manual/misc/howto.html b/docs/manual/misc/howto.html
index 2eb207ad52..e2995c2473 100644
--- a/docs/manual/misc/howto.html
+++ b/docs/manual/misc/howto.html
@@ -1,7 +1,8 @@
 
 
 
-
+
 
 Apache HOWTO documentation
 
@@ -19,13 +20,15 @@
 
 How to:
 
    
 
 
    
-
    How to redirect an entire server or directory to a single URL
    
+
    How to redirect an entire server or directory to a
+single URL
    
 
 
    There are two chief ways to redirect all requests for an entire
 server to a single location: one which requires the use of
@@ -44,8 +47,9 @@ however, it may not be appropriate - for example, when the directory
 structure has changed after the move, and you simply want to direct people
 to the home page.
 
-
    The best option is to use the standard Apache module mod_rewrite.
-If that module is compiled in, the following lines:
+
    The best option is to use the standard Apache module
+mod_rewrite.
+If that module is compiled in, the following lines
 
 
    RewriteEngine On
 RewriteRule /.* http://www.apache.org/ [R]
@@ -56,10 +60,12 @@ what they gave in the original URL, they'll be sent to
 "http://www.apache.org".
 
 The second option is to set up a ScriptAlias pointing to
-a cgi script which outputs a 301 or 302 status and the location
+a cgi script which outputs a 301 or 302 status and the
+location
 of the other server.
    
 
-
    By using a cgi-script you can intercept various requests and
+
    By using a cgi-script you can intercept various requests
+and
 treat them specially, e.g. you might want to intercept POST
 requests, so that the client isn't redirected to a script on the other
 server which expects POST information (a redirect will lose the POST
@@ -68,7 +74,8 @@ want to compile mod_rewrite into your server.
 
 
    Here's how to redirect all requests to a script... In the server
 configuration file,
-
    ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script
    
+
    ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script
    
+
    
 
 and here's a simple perl script to redirect requests:
 
@@ -82,7 +89,7 @@ Location: http://www.some.where.else.com/\r\n\r\n";
 
 
    
 
-
    How to reset your log files
    
+
    How to reset your log files
    
 
 
    Sooner or later, you'll want to reset your log files (access_log and
 error_log) because they are too big, or full of old information you don't
@@ -98,7 +105,8 @@ logfile moved. This results in a new logfile being created which is just
 as big as the old one, but it now contains thousands (or millions) of null
 characters.
    
 
-
    The correct procedure is to move the logfile, then signal Apache to tell it to reopen the logfiles.
    
+
    The correct procedure is to move the logfile, then signal Apache to tell
+it to reopen the logfiles.
    
 
 
    Apache is signaled using the SIGHUP (-1) signal. e.g.
 
    
@@ -107,7 +115,8 @@ kill -1 `cat httpd.pid`
 
    
 
    
 
-
    Note: httpd.pid is a file containing the process id
+
    Note: httpd.pid is a file containing the
+process id
 of the Apache httpd daemon, Apache saves this in the same directory as the log
 files.
    
 
@@ -115,7 +124,7 @@ files.
    
 nightly or weekly basis.
    
 
    
 
-
    How to stop or restrict robots
    
+
    How to stop or restrict robots
    
 
 
    Ever wondered why so many clients are interested in a file called
 robots.txt which you don't have, and never did have?
    
@@ -147,7 +156,8 @@ stale by the time people find it in a search engine.
    
 
 
    If you decide to exclude robots completely, or just limit the areas
 in which they can roam, create a robots.txt file; refer
-to the robot information pages provided by Martijn Koster for the syntax.
    
+to the robot information pages provided by Martijn Koster for the syntax.
    
 
 
 
diff --git a/docs/manual/misc/known_client_problems.html b/docs/manual/misc/known_client_problems.html
index 729d88abe7..63336e8a65 100644
--- a/docs/manual/misc/known_client_problems.html
+++ b/docs/manual/misc/known_client_problems.html
@@ -40,7 +40,7 @@ The admin typically controls which are set, and for which clients, by using
 mod_browser.  Unless otherwise
 noted all of these workarounds exist in versions 1.2 and later.
 
-
    Trailing CRLF on POSTs
    
+
    Trailing CRLF on POSTs
    
 
 
    This is a legacy issue.  The CERN webserver required POST
 data to have an extra CRLF following it.  Thus many
@@ -49,7 +49,7 @@ is not included in the Content-Length of the request.
 Apache works around this problem by eating any empty lines which
 appear before a request.
 
-
    Broken keepalive
    
+
    Broken keepalive
    
 
 
    Various clients have had broken implementations of keepalive
 (persistent connections).  In particular the Windows versions of
@@ -66,13 +66,15 @@ strings just like Navigator.
 support keepalive when it is used on 301 or 302 (redirect)
 responses.  Unfortunately Apache's nokeepalive code
 prior to 1.2.2 would not work with HTTP/1.1 clients.  You must apply
-this
-patch to version 1.2.1.  Then add this to your config:
+this patch to version 1.2.1.  Then add this to your config:
 
    
 BrowserMatch "MSIE 4\.0b2;" nokeepalive
 
    
 
-
    Incorrect interpretation of HTTP/1.1 in response
    
+
    Incorrect interpretation of
+HTTP/1.1 in response
    
 
 
    To quote from section 3.1 of RFC1945:
 
    
@@ -112,7 +114,8 @@ workaround is still:
 BrowserMatch "RealPlayer 4.0" force-response-1.0
 
    
 
-
    Requests use HTTP/1.1 but responses must be in HTTP/1.0
    
+
    Requests use HTTP/1.1 but responses must be
+in HTTP/1.0
    
 
 
    MSIE 4.0b2 has this problem.  Its Java VM makes requests in HTTP/1.1
 format but the responses must be in HTTP/1.0 format (in particular, it
@@ -122,10 +125,11 @@ is to fool Apache into believing the request came in HTTP/1.0 format.
 BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0
 
    
 This workaround is available in 1.2.2, and in a
-patch
- against 1.2.1.
+patch against 1.2.1.
 
-
    Boundary problems with header parsing
    
+
    Boundary problems with header parsing
    
 
 
    All versions of Navigator from 2.0 through 4.0b2 (and possibly later)
 have a problem if the trailing CRLF of the response header starts at
@@ -135,7 +139,8 @@ on all responses.  The workaround is to detect when this condition would
 occur in a response and add extra padding to the header to push the
 trailing CRLF past offset 258 of the response.
 
-
    Multipart responses and Quoted Boundary Strings
    
+
    Multipart responses and Quoted Boundary
+Strings
    
 
 
    On multipart responses some clients will not accept quotes (")
 around the boundary string.  The MIME standard recommends that
@@ -144,7 +149,7 @@ on one of the examples in RFC2068, which does not include quotes.
 Apache does not include quotes on its boundary strings to workaround
 this problem.
 
-
    Byterange requests
    
+
    Byterange requests
    
 
 
    A byterange request is used when the client wishes to retrieve a
 portion of an object, not necessarily the entire object.  There
@@ -185,7 +190,8 @@ with MSIE 3 is actually due to the Acrobat plugin, not due to the browser.
 version 3.01 is used with it, it will not properly understand byteranges.
 The user must upgrade their Acrobat reader to 3.01.
 
-
    Set-Cookie header is unmergeable
    
+
    Set-Cookie header is
+unmergeable
    
 
 
    The HTTP specifications say that it is legal to merge headers with
 duplicate names into one (separated by semicolon).  Some browsers
@@ -194,7 +200,8 @@ that support Cookies don't like merged headers and prefer that each
 headers returned by a CGI, Apache will explicitly avoid merging any
 Set-Cookie headers.
 
-
    Expires headers and GIF89A animations
    
+
    Expires headers and GIF89A
+animations
    
 
 
    Navigator versions 2 through 4 will erroneously re-request
 GIF89A animations on each loop of the animation if the first
@@ -205,7 +212,8 @@ HREF="http://www.arctic.org/~dgaudet/patches/apache-1.2-gif89-expires-hack.patch
 and for 1.3.
 
-
    POST without Content-Length
    
+
    POST without
+Content-Length
    
 
 
    In certain situations Navigator 3.01 through 3.03 appear to incorrectly
 issue a POST without the request body.  There is no
@@ -216,7 +224,7 @@ There's also
 
 some information about the actual problem.
 
-
    JDK 1.2 betas lose parts of responses.
    
+
    JDK 1.2 betas lose parts of responses.
    
 
 
    The http client in the JDK1.2beta2 and beta3 will throw away the first part of
 the response body when both the headers and the first part of the body are sent
diff --git a/docs/manual/misc/perf-tuning.html b/docs/manual/misc/perf-tuning.html
index c36636967a..4cc53a9ad9 100644
--- a/docs/manual/misc/perf-tuning.html
+++ b/docs/manual/misc/perf-tuning.html
@@ -1,9 +1,16 @@
+
 
 
-Apache Performance Notes
+ Apache Performance Notes
 
-
-
+
+
 
    Apache Performance Notes
    
 
 
    Author: Dean Gaudet
@@ -215,8 +222,8 @@ connection.  The default KeepAliveTimeout of
 15 seconds attempts to minimize this effect.  The tradeoff
 here is between network bandwidth and server resources.
 In no event should you raise this above about 60 seconds, as
-
-most of the benefits are lost.
+most of the benefits are lost.
 
 
    Compile-Time Configuration Issues
    
 
@@ -278,7 +285,8 @@ requests.  All those blocked children will awaken and return from
 system and timing issues).
 They will all then fall down into the loop and try to accept
 the connection.  But only one will succeed (assuming there's still only
-one connection ready), the rest will be blocked in accept.
+one connection ready), the rest will be blocked in
+accept.
 This effectively locks those children into serving requests from that
 one socket and no other sockets, and they'll be stuck there until enough
 new requests appear on that socket to wake them all up.
@@ -327,7 +335,7 @@ the inner loop.  The loop looks like this (differences highlighted):
     }
    -The functions +The functions accept_mutex_on and accept_mutex_off implement a mutual exclusion semaphore. Only one child can have the mutex at any time. There are several choices for implementing these @@ -423,7 +431,9 @@ and then single-socket servers will not serialize at all.

    Lingering Close

    As discussed in -draft-ietf-http-connection-00.txt section 8, +draft-ietf-http-connection-00.txt section 8, in order for an HTTP server to reliably implement the protocol it needs to shutdown each direction of the communication independently (recall that a TCP connection is bi-directional, each half is independent @@ -648,7 +658,7 @@ properly implement the HTTP protocol. The second occurs because the Common Log Format dictates that the log record include a timestamp of the end of the request. A custom logging module could eliminate one of the calls. Or you can use a method which moves the time into shared memory, -see the patches section below. +see the patches section below.

    As described earlier, Rule STATUS=yes causes two gettimeofday calls and a call to times: @@ -783,28 +793,28 @@ munmap(0x400e3000, 6144) = 0 That's 19 system calls, of which 4 remain relatively easy to remove, but don't seem worth the effort. -

    Appendix: Patches Available

    +

    Appendix: Patches Available

    There are - -several performance patches available for 1.3. But they may + +several performance patches available for 1.3. But they may be slightly out of date by the time Apache 1.3.0 has been released, it shouldn't be difficult for someone with a little C knowledge to update them. In particular: -

    Appendix: The Pre-Forking Model

    @@ -846,11 +856,11 @@ depending on the operating system. implementations of threaded Apache, one using the 1.3 code base on DCE, and one using a custom user-level threads package and the 1.0 code base, neither are available publically. There is also an experimental port of -Apache 1.3 to -Netscape's Portable Run Time, which -is available +Apache 1.3 to +Netscape's Portable Run Time, which +is available (but you're encouraged to join the -new-httpd mailing list +new-httpd mailing list if you intend to use it). Part of our redesign for version 2.0 of Apache will include abstractions of the server model so that we diff --git a/docs/manual/misc/security_tips.html b/docs/manual/misc/security_tips.html index 0ec79e5f71..aa6106bf73 100644 --- a/docs/manual/misc/security_tips.html +++ b/docs/manual/misc/security_tips.html @@ -22,7 +22,7 @@ the suggestions will be general, others specific to Apache.
    -

    Permissions on ServerRoot Directories

    +

    Permissions on ServerRoot Directories

    In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits. @@ -81,7 +81,8 @@ directive.

    Non Script Aliased CGI

    -

    Allowing users to execute CGI scripts in any directory should only +

    Allowing users to execute CGI scripts in any directory +should only be considered if;

    1. You trust your users not to write scripts which will deliberately or @@ -93,7 +94,8 @@ make one more potential hole irrelevant.

      Script Alias'ed CGI

      -

      Limiting CGI to special directories gives the admin control over +

      Limiting CGI to special directories gives the admin +control over what goes into those directories. This is inevitably more secure than non script aliased CGI, but only if users with write access to the directories are trusted or the admin is willing to test each new CGI diff --git a/docs/manual/platform/perf-bsd44.html b/docs/manual/platform/perf-bsd44.html index 96536c266e..a209c7736d 100644 --- a/docs/manual/platform/perf-bsd44.html +++ b/docs/manual/platform/perf-bsd44.html @@ -17,7 +17,8 @@

      Running a High-Performance Web Server for BSD

      -Like other OS's, the listen queue is often the first limit hit. The +Like other OS's, the listen queue is often the first limit +hit. The following are comments from "Aaron Gifford <agifford@InfoWest.COM>" on how to fix this on BSDI 1.x, 2.x, and FreeBSD 2.0 (and earlier): @@ -167,7 +168,8 @@ value derived from maxusers proved sufficient for our load.

      Be aware that your system may not boot with a kernel that is configured -to use more resources than you have available system RAM. ALWAYS +to use more resources than you have available system RAM. +ALWAYS have a known bootable kernel available when tuning your system this way, and use the system tools beforehand to learn if you need to buy more memory before tuning. @@ -187,8 +189,8 @@ Finally, there's the hard limit of child processes configured in Apache.

      For versions of Apache later than 1.0.5 you'll need to change the -definition for HARD_SERVER_LIMIT in httpd.h and recompile -if you need to run more than the default 150 instances of httpd. +definition for HARD_SERVER_LIMIT in httpd.h and +recompile if you need to run more than the default 150 instances of httpd.

      @@ -228,8 +230,8 @@ often maxed out.

      More welcome!

      -If you have tips to contribute, send mail to brian@organic.com +If you have tips to contribute, send mail to +brian@organic.com diff --git a/docs/manual/platform/perf-dec.html b/docs/manual/platform/perf-dec.html index 67eed58ff1..32245e0fbc 100644 --- a/docs/manual/platform/perf-dec.html +++ b/docs/manual/platform/perf-dec.html @@ -50,7 +50,7 @@ From mogul@pa.dec.com (Jeffrey Mogul) Organization DEC Western Research Date 30 May 1996 00:50:25 GMT Newsgroups comp.unix.osf.osf1 -Message-ID <4oirch$bc8@usenet.pa.dec.com> +Message-ID <4oirch$bc8@usenet.pa.dec.com> Subject Re: Web Site Performance References 1 @@ -63,8 +63,10 @@ In article <skoogDs54BH.9pF@netcom.com> skoog@netcom.com (Jim Skoog) write >runing DEC UNIX 3.2C, which run DEC's seal firewall and behind >that Alpha 1000 and 2100 webservers. -Our experience (running such Web servers as altavista.digital.com -and www.digital.com) is that there is one important kernel tuning +Our experience (running such Web servers as altavista.digital.com +and www.digital.com) is that there is one important kernel tuning knob to adjust in order to get good performance on V3.2C. You need to patch the kernel global variable "somaxconn" (use dbx -k to do this) from its default value of 8 to something much larger. @@ -98,7 +100,8 @@ with no obvious performance bottlenecks at the millions-of-hits-per-day level. We have some Webstone performance results available at - http://www.digital.com/info/alphaserver/news/webff.html + http://www.digital.com/info/alphaserver/news/webff.html I'm not sure if these were done using V4.0 or an earlier version of Digital UNIX, although I suspect they were done using a test version of V4.0. @@ -113,7 +116,7 @@ From mogul@pa.dec.com (Jeffrey Mogul) Organization DEC Western Research Date 31 May 1996 21:01:01 GMT Newsgroups comp.unix.osf.osf1 -Message-ID <4onmmd$mmd@usenet.pa.dec.com> +Message-ID <4onmmd$mmd@usenet.pa.dec.com> Subject Digital UNIX V3.2C Internet tuning patch info ---------------------------------------------------------------------------- @@ -136,7 +139,8 @@ so the description of the various tuning parameters in this README file might be useful to people running V4.0 systems. This patch kit does not appear to be available (yet?) from - http://www.service.digital.com/html/patch_service.html + http://www.service.digital.com/html/patch_service.html so I guess you'll have to call Digital's Customer Support to get it. -Jeff @@ -251,7 +255,7 @@ TUNING V3.2C Feature V3.2C patch V4.0 - ======= ===== ===== ==== +======= ===== ===== ==== somaxconn X X X sominconn - X X sobacklog_hiwat - X - diff --git a/docs/manual/platform/unixware.html b/docs/manual/platform/unixware.html index 458104a9d0..a77a3b5cd4 100644 --- a/docs/manual/platform/unixware.html +++ b/docs/manual/platform/unixware.html @@ -46,7 +46,8 @@ in order for Apache to work correctly on UnixWare 2.1.x. See http://www.sco.com for UnixWare patch information.

      -NOTE: Unixware 2.1.2 and later already have patch ptf3123 included

      +NOTE: Unixware 2.1.2 and later already have patch ptf3123 +included

      In addition, make sure that USE_FCNTL_SERIALIZE_ACCEPT is defined (if not defined by Apache autoconfiguration). To reduce instances of connections diff --git a/docs/manual/platform/windows.html b/docs/manual/platform/windows.html index 9da3075dfa..a1499d8ff3 100644 --- a/docs/manual/platform/windows.html +++ b/docs/manual/platform/windows.html @@ -52,7 +52,7 @@ to help with development, or to track down bugs), see the section on

      -

      Requirements

      +

      Requirements

      Apache 1.3b6 requires the following:

      @@ -62,14 +62,14 @@ to help with development, or to track down bugs), see the section on requirements unknown) with a connection to a TCP/IP network. -

      * Apache may run with Windows NT 3.5.1, but +

      * Apache may run with Windows NT 3.5.1, but has not been tested.

      If running on Windows 95, using the "Winsock2" upgrade is recommended but may not be necessary. If running on NT 4.0, installing Service Pack 2 is recommended.

      -

      Downloading Apache for Windows

      +

      Downloading Apache for Windows

      Information on the latest version of Apache can be found on the Apache web server at .zip file containing the source code, to compile Apache yourself. -

      Installing Apache for Windows

      +

      Installing Apache for Windows

      Run the Apache .exe file you downloaded above. This will ask for: @@ -124,7 +124,7 @@ subdirectory htdocs. There are lots of other options which should be set before you start really using Apache. However to get started the files should work as installed. -

      Running Apache for Windows

      +

      Running Apache for Windows

      There are two ways you can run Apache: @@ -178,7 +178,7 @@ manual. If nothing happens or you get an error, look in the Once your basic installation is working, you should configure it properly by editing the files in the conf directory. -

      Configuring Apache for Windows

      +

      Configuring Apache for Windows

      Apache is configured by files in the conf directory. These are the same as files used to configure the Unix @@ -237,7 +237,7 @@ The main differences in Apache for Windows are: is available. -

      Running Apache for Windows from the Command Line

      +

      Running Apache for Windows from the Command Line

      The Start menu icons and the NT Service manager can provide an simple interafce for administering Apache. But in some cases it is easier to @@ -301,7 +301,7 @@ listed above. Again note that once Apache has read the given on the ServerRoot directive line instead of the -f or -d command line argument. -

      Compiling Apache for Windows

      +

      Compiling Apache for Windows

      Compiling Apache requires Microsoft Visual C++ 5.0 to be properly installed. It is easiest to compile with the command-line tools @@ -344,8 +344,10 @@ or -d command line argument.

      To install the files into the \Apache directory automatically, use one the following nmake commands (see above):

        -
      • nmake /f Makefile.nt installr INSTDIR=dir (for release build) -
      • nmake /f Makefile.nt installd INSTDIR=dir (for debug build) +
      • nmake /f Makefile.nt installr INSTDIR=dir + (for release build) +
      • nmake /f Makefile.nt installd INSTDIR=dir + (for debug build)
      The dir argument to INSTDIR gives the installation directory. The can @@ -354,12 +356,12 @@ be omitted if Apache is to be installed into \Apache.

      This will install the following:

        -
      • dir\Apache.exe - Apache executable -
      • dir\ApacheCore.dll - Main Apache shared library -
      • dir\modules\ApacheModule*.dll - Optional Apache +
      • dir\Apache.exe - Apache executable +
      • dir\ApacheCore.dll - Main Apache shared library +
      • dir\modules\ApacheModule*.dll - Optional Apache modules (7 files) -
      • dir\conf - Empty configuration directory -
      • dir\logs - Empty logging directory +
      • dir\conf - Empty configuration directory +
      • dir\logs - Empty logging directory

      If you do not have nmake, or wish to install in a different directory, diff --git a/docs/manual/sections.html b/docs/manual/sections.html index b9a5679100..a8e4756d92 100644 --- a/docs/manual/sections.html +++ b/docs/manual/sections.html @@ -57,10 +57,12 @@ The order of merging is:

      2. -
    2. <Files> and <FilesMatch> done simultaneously +
    3. <Files> and <FilesMatch> done + simultaneously
      4. -
    4. <Location> and <LocationMatch> done simultaneously +
    5. <Location> and <LocationMatch> done + simultaneously
    diff --git a/docs/manual/sections.html.en b/docs/manual/sections.html.en index b9a5679100..a8e4756d92 100644 --- a/docs/manual/sections.html.en +++ b/docs/manual/sections.html.en @@ -57,10 +57,12 @@ The order of merging is:
    • -
  • <Files> and <FilesMatch> done simultaneously +
  • <Files> and <FilesMatch> done + simultaneously
    • -
  • <Location> and <LocationMatch> done simultaneously +
  • <Location> and <LocationMatch> done + simultaneously
    • diff --git a/docs/manual/stopping.html b/docs/manual/stopping.html index 2b65aa8f1c..3d03d4df97 100644 --- a/docs/manual/stopping.html +++ b/docs/manual/stopping.html @@ -38,7 +38,7 @@ Modify those examples to match your ServerRoot and PidFile settings. -

    As of Apache 1.3 we provide a script src/support/apachectl +

    As of Apache 1.3 we provide a script src/support/apachectl which can be used to start, stop, and restart Apache. It may need a little customization for your system, see the comments at the top of the script. @@ -64,14 +64,15 @@ serving hits. will notice that the server statistics are set to zero when a HUP is sent. -

    Note: If your configuration file has errors in it when you issue a +

    Note: If your configuration file has errors in it when +you issue a restart then your parent will not restart, it will exit with an error. See below for a method of avoiding this.

    USR1 Signal: graceful restart

    -

    Note: prior to release 1.2b9 this code is quite unstable and -shouldn't be used at all. +

    Note: prior to release 1.2b9 this code is quite unstable +and shouldn't be used at all.

    The USR1 signal causes the parent process to advise the children to exit after their current request (or to exit immediately @@ -94,7 +95,8 @@ with the StartServers parameter.

    Users of the status module will notice that the server statistics -are not set to zero when a USR1 is sent. The code +are not set to zero when a USR1 is sent. The +code was written to both minimize the time in which the server is unable to serve new requests (they will be queued up by the operating system, so they're not lost in any event) and to respect your tuning parameters. In order @@ -113,7 +115,8 @@ old log. For example if most of your hits take less than 10 minutes to complete for users on low bandwidth links then you could wait 15 minutes before doing anything with the old log. -

    Note: If your configuration file has errors in it when you issue a +

    Note: If your configuration file has errors in it when +you issue a restart then your parent will not restart, it will exit with an error. In the case of graceful restarts it will also leave children running when it exits. (These are diff --git a/docs/manual/stopping.html.en b/docs/manual/stopping.html.en index 2b65aa8f1c..3d03d4df97 100644 --- a/docs/manual/stopping.html.en +++ b/docs/manual/stopping.html.en @@ -38,7 +38,7 @@ Modify those examples to match your ServerRoot and PidFile settings. -

    As of Apache 1.3 we provide a script src/support/apachectl +

    As of Apache 1.3 we provide a script src/support/apachectl which can be used to start, stop, and restart Apache. It may need a little customization for your system, see the comments at the top of the script. @@ -64,14 +64,15 @@ serving hits. will notice that the server statistics are set to zero when a HUP is sent. -

    Note: If your configuration file has errors in it when you issue a +

    Note: If your configuration file has errors in it when +you issue a restart then your parent will not restart, it will exit with an error. See below for a method of avoiding this.

    USR1 Signal: graceful restart

    -

    Note: prior to release 1.2b9 this code is quite unstable and -shouldn't be used at all. +

    Note: prior to release 1.2b9 this code is quite unstable +and shouldn't be used at all.

    The USR1 signal causes the parent process to advise the children to exit after their current request (or to exit immediately @@ -94,7 +95,8 @@ with the StartServers parameter.

    Users of the status module will notice that the server statistics -are not set to zero when a USR1 is sent. The code +are not set to zero when a USR1 is sent. The +code was written to both minimize the time in which the server is unable to serve new requests (they will be queued up by the operating system, so they're not lost in any event) and to respect your tuning parameters. In order @@ -113,7 +115,8 @@ old log. For example if most of your hits take less than 10 minutes to complete for users on low bandwidth links then you could wait 15 minutes before doing anything with the old log. -

    Note: If your configuration file has errors in it when you issue a +

    Note: If your configuration file has errors in it when +you issue a restart then your parent will not restart, it will exit with an error. In the case of graceful restarts it will also leave children running when it exits. (These are diff --git a/docs/manual/suexec.html b/docs/manual/suexec.html index ecdf0c3559..d005739b63 100644 --- a/docs/manual/suexec.html +++ b/docs/manual/suexec.html @@ -74,8 +74,8 @@ may have on your system and its level of security.

    Third, it is assumed that you are using an unmodified version of suEXEC code. All code for suEXEC has been carefully scrutinized and -tested by the developers as well as numerous beta testers. Every precaution has -been taken to ensure a simple yet solidly safe base of code. Altering this +tested by the developers as well as numerous beta testers. Every precaution +has been taken to ensure a simple yet solidly safe base of code. Altering this code can cause unexpected problems and new security risks. It is highly recommended you not alter the suEXEC code unless you are well versed in the particulars of security programming and are willing to @@ -124,124 +124,150 @@ user and group IDs under which the program is to execute. The wrapper then employs the following process to determine success or failure -- if any one of these conditions fail, the program logs the failure and exits with an error, otherwise it will continue: -

      -
    1. Was the wrapper called with the proper number of arguments? -
      - The wrapper will only execute if it is given the proper number of arguments. - The proper argument format is known to the Apache web server. If the wrapper - is not receiving the proper number of arguments, it is either being hacked, or - there is something wrong with the suEXEC portion of your Apache binary. -
      -
      2. -
    2. Is the user executing this wrapper a valid user of this system? -
      - This is to ensure that the user executing the wrapper is truly a user of the system. -
      -
      3. -
    3. Is this valid user allowed to run the wrapper? -
      - Is this user the user allowed to run this wrapper? Only one user (the Apache - user) is allowed to execute this program. -
      -
      4. -
    4. Does the target program have an unsafe hierarchical reference? -
      - Does the target program contain a leading '/' or have a '..' backreference? These - are not allowed; the target program must reside within the Apache webspace. -
      -
      5. -
    5. Is the target user name valid? -
      - Does the target user exist? -
      -
      6. -
    6. Is the target group name valid? -
      - Does the target group exist? -
      -
      7. -
    7. Is the target user NOT superuser? -
      - Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. -
      -
      8. -
    8. Is the target userid ABOVE the minimum ID number? -
      - The minimum user ID number is specified during configuration. This allows you - to set the lowest possible userid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" accounts. -
      -
      9. -
    9. Is the target group NOT the superuser group? -
      - Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs. -
      -
      10. -
    10. Is the target groupid ABOVE the minimum ID number? -
      - The minimum group ID number is specified during configuration. This allows you - to set the lowest possible groupid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" groups. -
      -
      11. -
    11. Can the wrapper successfully become the target user and group? -
      - Here is where the program becomes the target user and group via setuid and setgid - calls. The group access list is also initialized with all of the groups of which - the user is a member. -
      -
      12. -
    12. Does the directory in which the program resides exist? -
      - If it doesn't exist, it can't very well contain files. -
      -
      13. -
    13. Is the directory within the Apache webspace? -
      - If the request is for a regular portion of the server, is the requested directory - within the server's document root? If the request is for a UserDir, is the requested - directory within the user's document root? -
      -
      14. -
    14. Is the directory NOT writable by anyone else? -
      - We don't want to open up the directory to others; only the owner user may be able - to alter this directories contents. -
      -
      15. -
    15. Does the target program exist? -
      - If it doesn't exists, it can't very well be executed. -
      -
      16. -
    16. Is the target program NOT writable by anyone else? -
      - We don't want to give anyone other than the owner the ability to change the program. -
      -
      17. -
    17. Is the target program NOT setuid or setgid? -
      - We do not want to execute programs that will then change our UID/GID again. -
      -
      18. -
    18. Is the target user/group the same as the program's user/group? -
      - Is the user the owner of the file? -
      -
      19. -
    19. Can we successfully clean the process environment to ensure safe operations? -
      - suEXEC cleans the process' environment by establishing a safe execution PATH (defined - during configuration), as well as only passing through those variables whose names - are listed in the safe environment list (also created during configuration). -
      -
      20. -
    20. Can we successfully become the target program and execute? -
      - Here is where suEXEC ends and the target program begins. -
      -
      21. -
    +
      +
    1. Was the wrapper called with the proper number of + arguments? +
      + The wrapper will only execute if it is given the proper number of arguments. + The proper argument format is known to the Apache web server. If the + wrapper + is not receiving the proper number of arguments, it is either being hacked, + or + there is something wrong with the suEXEC portion of your Apache binary. +
      +
      2. +
    2. Is the user executing this wrapper a valid user of this + system? +
      + This is to ensure that the user executing the wrapper is truly a user of the + system. +
      +
      3. +
    3. Is this valid user allowed to run the wrapper? +
      + Is this user the user allowed to run this wrapper? Only one user (the + Apache user) is allowed to execute this program. +
      +
      4. +
    4. Does the target program have an unsafe hierarchical + reference? +
      + Does the target program contain a leading '/' or have a '..' backreference? + These are not allowed; the target program must reside within the Apache + webspace. +
      +
      5. +
    5. Is the target user name valid? +
      + Does the target user exist? +
      +
      6. +
    6. Is the target group name valid? +
      + Does the target group exist? +
      +
      7. +
    7. Is the target user NOT superuser? +
      + Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. +
      +
      8. +
    8. Is the target userid ABOVE the minimum ID + number? +
      + The minimum user ID number is specified during configuration. This allows + you + to set the lowest possible userid that will be allowed to execute CGI/SSI + programs. This is useful to block out "system" accounts. +
      +
      9. +
    9. Is the target group NOT the superuser group? +
      + Presently, suEXEC does not allow the 'root' group to execute CGI/SSI + programs. +
      +
      10. +
    10. Is the target groupid ABOVE the minimum ID + number? +
      + The minimum group ID number is specified during configuration. This allows + you + to set the lowest possible groupid that will be allowed to execute CGI/SSI + programs. This is useful to block out "system" groups. +
      +
      11. +
    11. Can the wrapper successfully become the target user and + group? +
      + Here is where the program becomes the target user and group via setuid and + setgid + calls. The group access list is also initialized with all of the groups + of which + the user is a member. +
      +
      12. +
    12. Does the directory in which the program resides exist? +
      + If it doesn't exist, it can't very well contain files. +
      +
      13. +
    13. Is the directory within the Apache webspace? +
      + If the request is for a regular portion of the server, is the requested + directory + within the server's document root? If the request is for a UserDir, is + the requested + directory within the user's document root? +
      +
      14. +
    14. Is the directory NOT writable by anyone else? +
      + We don't want to open up the directory to others; only the owner user + may be able + to alter this directories contents. +
      +
      15. +
    15. Does the target program exist? +
      + If it doesn't exists, it can't very well be executed. +
      +
      16. +
    16. Is the target program NOT writable by anyone + else? +
      + We don't want to give anyone other than the owner the ability to + change the program. +
      +
      17. +
    17. Is the target program NOT setuid or setgid? +
      + We do not want to execute programs that will then change our UID/GID again. +
      +
      18. +
    18. Is the target user/group the same as the program's + user/group? +
      + Is the user the owner of the file? +
      +
      19. +
    19. Can we successfully clean the process environment to + ensure safe operations? +
      + suEXEC cleans the process' environment by establishing a safe + execution PATH (defined + during configuration), as well as only passing through those + variables whose names + are listed in the safe environment list (also created during + configuration). +
      +
      20. +
    20. Can we successfully become the target program and + execute? +
      + Here is where suEXEC ends and the target program begins. +
      +
      21. +

    @@ -253,8 +279,9 @@ in mind.

    For more information as to how this security model can limit your possibilities -in regards to server configuration, as well as what security risks can be avoided -with a proper suEXEC setup, see the "Beware the Jabberwock" +in regards to server configuration, as well as what security risks can be +avoided with a proper suEXEC setup, see the +"Beware the Jabberwock" section of this document.

    @@ -393,7 +420,8 @@ user shell, do so now and execute the following commands.

    -chown root /usr/local/apache/sbin/suexec [ENTER]
    +chown root /usr/local/apache/sbin/suexec [ENTER] +
    chmod 4711 /usr/local/apache/sbin/suexec [ENTER]

    @@ -459,7 +487,9 @@ and the error_log for the server to see where you may have gone astray. BACK TO CONTENTS

    -

    Beware the Jabberwock: Warnings & Examples

    +

    +Beware the Jabberwock: Warnings & Examples +

    NOTE! This section may not be complete. For the latest revision of this section of the documentation, see the Apache Group's diff --git a/docs/manual/suexec.html.en b/docs/manual/suexec.html.en index ecdf0c3559..d005739b63 100644 --- a/docs/manual/suexec.html.en +++ b/docs/manual/suexec.html.en @@ -74,8 +74,8 @@ may have on your system and its level of security.

    Third, it is assumed that you are using an unmodified version of suEXEC code. All code for suEXEC has been carefully scrutinized and -tested by the developers as well as numerous beta testers. Every precaution has -been taken to ensure a simple yet solidly safe base of code. Altering this +tested by the developers as well as numerous beta testers. Every precaution +has been taken to ensure a simple yet solidly safe base of code. Altering this code can cause unexpected problems and new security risks. It is highly recommended you not alter the suEXEC code unless you are well versed in the particulars of security programming and are willing to @@ -124,124 +124,150 @@ user and group IDs under which the program is to execute. The wrapper then employs the following process to determine success or failure -- if any one of these conditions fail, the program logs the failure and exits with an error, otherwise it will continue: -

      -
    1. Was the wrapper called with the proper number of arguments? -
      - The wrapper will only execute if it is given the proper number of arguments. - The proper argument format is known to the Apache web server. If the wrapper - is not receiving the proper number of arguments, it is either being hacked, or - there is something wrong with the suEXEC portion of your Apache binary. -
      -
      2. -
    2. Is the user executing this wrapper a valid user of this system? -
      - This is to ensure that the user executing the wrapper is truly a user of the system. -
      -
      3. -
    3. Is this valid user allowed to run the wrapper? -
      - Is this user the user allowed to run this wrapper? Only one user (the Apache - user) is allowed to execute this program. -
      -
      4. -
    4. Does the target program have an unsafe hierarchical reference? -
      - Does the target program contain a leading '/' or have a '..' backreference? These - are not allowed; the target program must reside within the Apache webspace. -
      -
      5. -
    5. Is the target user name valid? -
      - Does the target user exist? -
      -
      6. -
    6. Is the target group name valid? -
      - Does the target group exist? -
      -
      7. -
    7. Is the target user NOT superuser? -
      - Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. -
      -
      8. -
    8. Is the target userid ABOVE the minimum ID number? -
      - The minimum user ID number is specified during configuration. This allows you - to set the lowest possible userid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" accounts. -
      -
      9. -
    9. Is the target group NOT the superuser group? -
      - Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs. -
      -
      10. -
    10. Is the target groupid ABOVE the minimum ID number? -
      - The minimum group ID number is specified during configuration. This allows you - to set the lowest possible groupid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" groups. -
      -
      11. -
    11. Can the wrapper successfully become the target user and group? -
      - Here is where the program becomes the target user and group via setuid and setgid - calls. The group access list is also initialized with all of the groups of which - the user is a member. -
      -
      12. -
    12. Does the directory in which the program resides exist? -
      - If it doesn't exist, it can't very well contain files. -
      -
      13. -
    13. Is the directory within the Apache webspace? -
      - If the request is for a regular portion of the server, is the requested directory - within the server's document root? If the request is for a UserDir, is the requested - directory within the user's document root? -
      -
      14. -
    14. Is the directory NOT writable by anyone else? -
      - We don't want to open up the directory to others; only the owner user may be able - to alter this directories contents. -
      -
      15. -
    15. Does the target program exist? -
      - If it doesn't exists, it can't very well be executed. -
      -
      16. -
    16. Is the target program NOT writable by anyone else? -
      - We don't want to give anyone other than the owner the ability to change the program. -
      -
      17. -
    17. Is the target program NOT setuid or setgid? -
      - We do not want to execute programs that will then change our UID/GID again. -
      -
      18. -
    18. Is the target user/group the same as the program's user/group? -
      - Is the user the owner of the file? -
      -
      19. -
    19. Can we successfully clean the process environment to ensure safe operations? -
      - suEXEC cleans the process' environment by establishing a safe execution PATH (defined - during configuration), as well as only passing through those variables whose names - are listed in the safe environment list (also created during configuration). -
      -
      20. -
    20. Can we successfully become the target program and execute? -
      - Here is where suEXEC ends and the target program begins. -
      -
      21. -
    +
      +
    1. Was the wrapper called with the proper number of + arguments? +
      + The wrapper will only execute if it is given the proper number of arguments. + The proper argument format is known to the Apache web server. If the + wrapper + is not receiving the proper number of arguments, it is either being hacked, + or + there is something wrong with the suEXEC portion of your Apache binary. +
      +
      2. +
    2. Is the user executing this wrapper a valid user of this + system? +
      + This is to ensure that the user executing the wrapper is truly a user of the + system. +
      +
      3. +
    3. Is this valid user allowed to run the wrapper? +
      + Is this user the user allowed to run this wrapper? Only one user (the + Apache user) is allowed to execute this program. +
      +
      4. +
    4. Does the target program have an unsafe hierarchical + reference? +
      + Does the target program contain a leading '/' or have a '..' backreference? + These are not allowed; the target program must reside within the Apache + webspace. +
      +
      5. +
    5. Is the target user name valid? +
      + Does the target user exist? +
      +
      6. +
    6. Is the target group name valid? +
      + Does the target group exist? +
      +
      7. +
    7. Is the target user NOT superuser? +
      + Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. +
      +
      8. +
    8. Is the target userid ABOVE the minimum ID + number? +
      + The minimum user ID number is specified during configuration. This allows + you + to set the lowest possible userid that will be allowed to execute CGI/SSI + programs. This is useful to block out "system" accounts. +
      +
      9. +
    9. Is the target group NOT the superuser group? +
      + Presently, suEXEC does not allow the 'root' group to execute CGI/SSI + programs. +
      +
      10. +
    10. Is the target groupid ABOVE the minimum ID + number? +
      + The minimum group ID number is specified during configuration. This allows + you + to set the lowest possible groupid that will be allowed to execute CGI/SSI + programs. This is useful to block out "system" groups. +
      +
      11. +
    11. Can the wrapper successfully become the target user and + group? +
      + Here is where the program becomes the target user and group via setuid and + setgid + calls. The group access list is also initialized with all of the groups + of which + the user is a member. +
      +
      12. +
    12. Does the directory in which the program resides exist? +
      + If it doesn't exist, it can't very well contain files. +
      +
      13. +
    13. Is the directory within the Apache webspace? +
      + If the request is for a regular portion of the server, is the requested + directory + within the server's document root? If the request is for a UserDir, is + the requested + directory within the user's document root? +
      +
      14. +
    14. Is the directory NOT writable by anyone else? +
      + We don't want to open up the directory to others; only the owner user + may be able + to alter this directories contents. +
      +
      15. +
    15. Does the target program exist? +
      + If it doesn't exists, it can't very well be executed. +
      +
      16. +
    16. Is the target program NOT writable by anyone + else? +
      + We don't want to give anyone other than the owner the ability to + change the program. +
      +
      17. +
    17. Is the target program NOT setuid or setgid? +
      + We do not want to execute programs that will then change our UID/GID again. +
      +
      18. +
    18. Is the target user/group the same as the program's + user/group? +
      + Is the user the owner of the file? +
      +
      19. +
    19. Can we successfully clean the process environment to + ensure safe operations? +
      + suEXEC cleans the process' environment by establishing a safe + execution PATH (defined + during configuration), as well as only passing through those + variables whose names + are listed in the safe environment list (also created during + configuration). +
      +
      20. +
    20. Can we successfully become the target program and + execute? +
      + Here is where suEXEC ends and the target program begins. +
      +
      21. +

    @@ -253,8 +279,9 @@ in mind.

    For more information as to how this security model can limit your possibilities -in regards to server configuration, as well as what security risks can be avoided -with a proper suEXEC setup, see the "Beware the Jabberwock" +in regards to server configuration, as well as what security risks can be +avoided with a proper suEXEC setup, see the +"Beware the Jabberwock" section of this document.

    @@ -393,7 +420,8 @@ user shell, do so now and execute the following commands.

    -chown root /usr/local/apache/sbin/suexec [ENTER]
    +chown root /usr/local/apache/sbin/suexec [ENTER] +
    chmod 4711 /usr/local/apache/sbin/suexec [ENTER]

    @@ -459,7 +487,9 @@ and the error_log for the server to see where you may have gone astray. BACK TO CONTENTS

    -

    Beware the Jabberwock: Warnings & Examples

    +

    +Beware the Jabberwock: Warnings & Examples +

    NOTE! This section may not be complete. For the latest revision of this section of the documentation, see the Apache Group's diff --git a/docs/manual/vhosts/details.html b/docs/manual/vhosts/details.html index 97ac6d824e..b7baf591d3 100644 --- a/docs/manual/vhosts/details.html +++ b/docs/manual/vhosts/details.html @@ -14,7 +14,8 @@

    An In-Depth Discussion of Virtual Host Matching

    -

    The virtual host code was completely rewritten in Apache 1.3. +

    The virtual host code was completely rewritten in +Apache 1.3. This document attempts to explain exactly what Apache does when deciding what virtual host to serve a hit from. With the help of the new NameVirtualHost @@ -120,9 +121,9 @@ first name in its VirtualHost directive.

    The complete list of names in the VirtualHost directive are treated just like a ServerAlias (but are not overridden by any -ServerAlias statement) if all names resolve to the same address set. -Note that subsequent Port statements for this vhost will not affect -the ports assigned in the address set. +ServerAlias statement) if all names resolve to the same address +set. Note that subsequent Port statements for this vhost will not +affect the ports assigned in the address set.

    During initialization a list for each IP address is generated an inserted into an hash table. If the IP address is @@ -144,9 +145,11 @@ the table is optimized for IP addresses which vary in the last octet. ResourceConfig, AccessConfig, Timeout, - KeepAliveTimeout, + KeepAliveTimeout, KeepAlive, - MaxKeepAliveRequests, + MaxKeepAliveRequests, or SendBufferSize directive then the respective value is @@ -219,17 +222,17 @@ file.

    The first vhost on this list (the first vhost in the config file with the specified IP address) has the highest priority and catches any request to an unknown server name or a request without a Host: -header. +header field. -

    If the client provided a Host: header the list is +

    If the client provided a Host: header field the list is searched for a matching vhost and the first hit on a ServerName or ServerAlias is taken and the request is served from -that vhost. A Host: header can contain a port number, but +that vhost. A Host: header field can contain a port number, but Apache always matches against the real port to which the client sent the request.

    If the client submitted a HTTP/1.0 request without Host: -header we don't know to what server the client tried to connect and +header field we don't know to what server the client tried to connect and any existing ServerPath is matched against the URI from the request. The first matching path on the list is used and the request is served from that vhost. @@ -282,7 +285,7 @@ taken to be a proxy request.

  • For security reasons the port number given in a Host: - header is never used during the matching process. Apache always + header field is never used during the matching process. Apache always uses the real port to which the client sent the request.

    @@ -290,7 +293,7 @@ taken to be a proxy request. another ServerPath directive that appears later in the configuration file, then the former will always be matched and the latter will never be matched. (That is assuming that no - Host header was available to disambiguate the two.) + Host: header field was available to disambiguate the two.)

  • If two IP-based vhosts have an address in common, the vhost appearing @@ -312,13 +315,13 @@ taken to be a proxy request. and port number to which the client connected is unspecified and does not match any other vhost (including a _default_ vhost). In other words the main_server only catches a request for an - unspecified address/port combination (unless there is a _default_ - vhost which matches that port). + unspecified address/port combination (unless there is a + _default_ vhost which matches that port).

  • A _default_ vhost or the main_server is never matched for a request with an unknown or missing Host: header - if the client connected to an address (and port) which is used + field if the client connected to an address (and port) which is used for name-based vhosts, e.g. in a NameVirtualHost directive.

    diff --git a/docs/manual/vhosts/details_1_2.html b/docs/manual/vhosts/details_1_2.html index 640de6d88d..e262cb3556 100644 --- a/docs/manual/vhosts/details_1_2.html +++ b/docs/manual/vhosts/details_1_2.html @@ -357,7 +357,7 @@ the virtual hosts). -

    What Works

    +

    What Works

    In addition to the tips on the DNS Issues page, here are some further tips: diff --git a/docs/manual/vhosts/host.html b/docs/manual/vhosts/host.html index 977a2eeb8c..0065e04861 100644 --- a/docs/manual/vhosts/host.html +++ b/docs/manual/vhosts/host.html @@ -135,8 +135,8 @@ workaround, albeit a slightly cumbersome one:

    To continue the www.apache.org example (Note: Apache's web server does not actually function in this manner), we might use the -new ServerPath directive in the www.apache.org virtual host, -for example: +new ServerPath directive in the www.apache.org +virtual host, for example: 

         ServerPath /apache
diff --git a/docs/manual/vhosts/index.html b/docs/manual/vhosts/index.html
index be02eaa4d7..b08ea16444 100644
--- a/docs/manual/vhosts/index.html
+++ b/docs/manual/vhosts/index.html
@@ -53,8 +53,8 @@ of virtual host support in Apache version 1.3 and later.
    
 
  • ServerPath
 
 
-
    Folks trying to debug their virtual host configuration may find the
-Apache -S command line switch useful.  It will dump out a
+
    Folks trying to debug their virtual host configuration may find the
+Apache -S command line switch useful.  It will dump out a
 description of how Apache parsed the configuration file.  Careful
 examination of the IP addresses and server names may help uncover
 configuration mistakes.
diff --git a/docs/manual/vhosts/index.html.en b/docs/manual/vhosts/index.html.en
index be02eaa4d7..b08ea16444 100644
--- a/docs/manual/vhosts/index.html.en
+++ b/docs/manual/vhosts/index.html.en
@@ -53,8 +53,8 @@ of virtual host support in Apache version 1.3 and later.
    
 
  • ServerPath
 
 
-
    Folks trying to debug their virtual host configuration may find the
-Apache -S command line switch useful.  It will dump out a
+
    Folks trying to debug their virtual host configuration may find the
+Apache -S command line switch useful.  It will dump out a
 description of how Apache parsed the configuration file.  Careful
 examination of the IP addresses and server names may help uncover
 configuration mistakes.
diff --git a/docs/manual/vhosts/name-based.html b/docs/manual/vhosts/name-based.html
index 3d0190ef95..1a86a32f70 100644
--- a/docs/manual/vhosts/name-based.html
+++ b/docs/manual/vhosts/name-based.html
@@ -64,9 +64,9 @@ all that is needed is to make sure that the name
 www.domain.tld points to the IP address
 111.22.33.44
    
 
-
    Note: When you specify an IP address in a NameVirtualHost
+
    Note: When you specify an IP address in a NameVirtualHost
 directive then requests to that IP address will only ever be served
-by matching <VirtualHost>s.  The "main server" will never
+by matching <VirtualHost>s.  The "main server" will never
 be served from the specified IP address.
 
 
    Additionally, many servers may wish to be accessible by more than
diff --git a/docs/manual/vhosts/name-based.html.en b/docs/manual/vhosts/name-based.html.en
index 3d0190ef95..1a86a32f70 100644
--- a/docs/manual/vhosts/name-based.html.en
+++ b/docs/manual/vhosts/name-based.html.en
@@ -64,9 +64,9 @@ all that is needed is to make sure that the name
 www.domain.tld points to the IP address
 111.22.33.44
    
 
-
    Note: When you specify an IP address in a NameVirtualHost
+
    Note: When you specify an IP address in a NameVirtualHost
 directive then requests to that IP address will only ever be served
-by matching <VirtualHost>s.  The "main server" will never
+by matching <VirtualHost>s.  The "main server" will never
 be served from the specified IP address.
 
 
    Additionally, many servers may wish to be accessible by more than
diff --git a/docs/manual/vhosts/vhosts-in-depth.html b/docs/manual/vhosts/vhosts-in-depth.html
index 640de6d88d..e262cb3556 100644
--- a/docs/manual/vhosts/vhosts-in-depth.html
+++ b/docs/manual/vhosts/vhosts-in-depth.html
@@ -357,7 +357,7 @@ the virtual hosts).
 
 
 
-
    What Works
    
+
    What Works
    
 
 
    In addition to the tips on the DNS
 Issues page, here are some further tips:
diff --git a/docs/manual/vhosts/virtual-host.html b/docs/manual/vhosts/virtual-host.html
index 11457f647f..fd3dcb2181 100644
--- a/docs/manual/vhosts/virtual-host.html
+++ b/docs/manual/vhosts/virtual-host.html
@@ -83,9 +83,10 @@ Use a single daemon when:
 
    Setting up multiple daemons
    
 Create a separate httpd installation for each virtual host.
 For each installation, use the
-BindAddress directive in the configuration
+BindAddress directive in the
+configuration
 file to select which IP address (or virtual host) that daemon services.
-e.g.
+E.g.,
 
    BindAddress www.smallco.com
    
 This hostname can also be given as an IP address.
 
@@ -99,7 +100,7 @@ The VirtualHost directive in the
 ErrorLog and
 TransferLog configuration
 directives to different values for each virtual host.
-e.g.
+E.g.,
 
    
 <VirtualHost www.smallco.com>
    
 ServerAdmin webmaster@mail.smallco.com
    
@@ -185,7 +186,8 @@ for the root process. This will exhibit itself as errors in the error log like
 
      
 
    1. Have a csh script wrapper around httpd which sets the
 "rlimit" to some large number, like 512.
-
    2. Edit http_main.c to add calls to setrlimit() from main(), along the lines of
+
    3. Edit http_main.c to add calls to setrlimit() from main(), along the lines
+of
 
               struct rlimit rlp;
    • Module @@ -465,26 +465,28 @@
    mod_jserv - - + mod_jserv + - JAVA still being ported.
    mod_php - - + mod_php + - not ported yet
    mod_put - ? + mod_put + ? untested
    mod_session - - + mod_session + - untested