- -There are two directives used to restrict or specify which addresses -and ports Apache listens to. - -
BindAddress *- -Makes the server listen to just the specified address. If the argument -is *, the server listens to all addresses. The port listened to -is set with the Port directive. Only one BindAddress -should be used. - -
none- -Listen can be used instead of BindAddress and -Port. It tells the server to accept incoming requests on the -specified port or address-and-port combination. If the first format is -used, with a port number only, the server listens to the given port on -all interfaces, instead of the port given by the Port -directive. If an IP address is given as well as a port, the server -will listen on the given port and interface.
Multiple Listen -directives may be used to specify a number of addresses and ports to -listen to. The server will respond to requests from any of the listed -addresses and ports.
- -For example, to make the server accept connections on both port -80 and port 8000, use: -
- Listen 80 - Listen 8000 -- -To make the server accept connections on two specified -interfaces and port numbers, use -
- Listen 192.170.2.1:80 - Listen 192.170.2.5:8000 -- -
As implemented in Apache 1.1.1 and earlier versions, the method -Apache used to create PATH_INFO in the CGI environment was -counterintuitive, and could result in crashes in certain cases. In -Apache 1.2 and beyond, this behavior has changed. Although this -results in some compatibility problems with certain legacy CGI -applications, the Apache 1.2 behavior is still compatible with the -CGI/1.1 specification, and CGI scripts can be easily modified (see below). - -
Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME -environment variables by looking at the filename, not the URL. While -this resulted in the correct values in many cases, when the filesystem -path was overloaded to contain path information, it could result in -errant behavior. For example, if the following appeared in a config -file: -
- Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph --
In this case, user.cgi is the CGI script, the "/ralph"
-is information to be passed onto the CGI. If this configuration was in
-place, and a request came for "/cgi-ralph/script/", the
-code would set PATH_INFO to "/ralph/script", and
-SCRIPT_NAME to "/cgi-". Obviously, the latter is
-incorrect. In certain cases, this could even cause the server to
-crash.
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
-client-modifiable, and setting PATH_INFO to it. To use the above
-example, PATH_INFO would be set to "/script", and
-SCRIPT_NAME to "/cgi-ralph". This makes sense and results
-in no server behavior problems. It also permits the script to be
-guaranteed that
-"http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO"
-will always be an accessible URL that points to the current script,
-something which was not necessarily true with previous versions of
-Apache.
-
-
However, the "/ralph"
-information from the Alias directive is lost. This is
-unfortunate, but we feel that using the filesystem to pass along this
-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.
-
-
It may be necessary for a script that was designed for earlier -versions of Apache or other servers to need the information that the -old PATH_INFO variable provided. For this purpose, Apache 1.2 (1.2b3 -and later) sets an additional variable, FILEPATH_INFO. This -environment variable contains the value that PATH_INFO would have had -with Apache 1.1.1.
- -A script that wishes to work with both Apache 1.2 and earlier -versions can simply test for the existence of FILEPATH_INFO, and use -it if available. Otherwise, it can use PATH_INFO. For example, in -Perl, one might use: -
- $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
-
-
-By doing this, a script can work with all servers supporting the -CGI/1.1 specification, including all versions of Apache.
- - - - - diff --git a/docs/manual/content-negotiation.html.en b/docs/manual/content-negotiation.html.en deleted file mode 100644 index 2aa06eb32fb..00000000000 --- a/docs/manual/content-negotiation.html.en +++ /dev/null @@ -1,426 +0,0 @@ - - - -- -Content negotiation is provided by the -mod_negotiation module, -which is compiled in by default. - -
- Accept-Language: fr -- -Note that this preference will only be applied when there is a choice -of representations and they vary by language. -
- -As an example of a more complex request, this browser has been -configured to accept French and English, but prefer French, and to -accept various media types, preferring HTML over plain text or other -text types, and preferring GIF or JPEG over other media types, but also -allowing any other media type as a last resort: - -
- Accept-Language: fr; q=1.0, en; q=0.5 - Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, - image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1 -- -Apache 1.2 supports 'server driven' content negotiation, as defined in -the HTTP/1.1 specification. It fully supports the Accept, -Accept-Language, Accept-Charset and Accept-Encoding request headers. -
- -The terms used in content negotiation are: a resource is an -item which can be requested of a server, which might be selected as -the result of a content negotiation algorithm. If a resource is -available in several formats, these are called representations -or variants. The ways in which the variants for a particular -resource vary are called the dimensions of negotiation. - -
*.var file) which
- names the files containing the variants explicitly
- type-map (or, for backwards-compatibility with
-older Apache configurations, the mime type
-application/x-type-map). Note that to use this feature,
-you've got to have a SetHandler some place which defines a
-file suffix as type-map; this is best done with a
-- - AddHandler type-map var - --in
srm.conf. See comments in the sample config files for
-details. - -Type map files have an entry for each available variant; these entries -consist of contiguous RFC822-format header lines. Entries for -different variants are separated by blank lines. Blank lines are -illegal within an entry. It is conventional to begin a map file with -an entry for the combined entity as a whole (although this -is not required, and if present will be ignored). An example -map file is: -
- - URI: foo - - URI: foo.en.html - Content-type: text/html - Content-language: en - - URI: foo.fr.de.html - Content-type: text/html; charset=iso-8859-2 - Content-language: fr, de -- -If the variants have different source qualities, that may be indicated -by the "qs" parameter to the media type, as in this picture (available -as jpeg, gif, or ASCII-art): -
- URI: foo - - URI: foo.jpeg - Content-type: image/jpeg; qs=0.8 - - URI: foo.gif - Content-type: image/gif; qs=0.5 - - URI: foo.txt - Content-type: text/plain; qs=0.01 - --
- -qs values can vary between 0.000 and 1.000. Note that any variant with -a qs value of 0.000 will never be chosen. Variants with no 'qs' -parameter value are given a qs factor of 1.0.
- -The full list of headers recognized is: - -
URI:
- Content-type:
- image/gif, text/plain, or
- text/html; level=3.
- Content-language:
- en for English,
- kr for Korean, etc.).
- Content-encoding:
- x-compress, or x-gzip, as appropriate.
- Content-length:
- Options directive within a <Directory>,
-<Location> or <Files>
-section in access.conf, or (if AllowOverride
-is properly set) in .htaccess files. Note that
-Options All does not set MultiViews; you
-have to ask for it by name. (Fixing this is a one-line change to
-http_core.h).
-
-
-
-The effect of MultiViews is as follows: if the server
-receives a request for /some/dir/foo, if
-/some/dir has MultiViews enabled, and
-/some/dir/foo does not exist, then the server reads the
-directory looking for files named foo.*, and effectively fakes up a
-type map which names all those files, assigning them the same media
-types and content-encodings it would have if the client had asked for
-one of them by name. It then chooses the best match to the client's
-requirements, and forwards them along.
-
-
-
-This applies to searches for the file named by the
-DirectoryIndex directive, if the server is trying to
-index a directory; if the configuration files specify
-
- - DirectoryIndex index - -then the server will arbitrate between
index.html
-and index.html3 if both are present. If neither are
-present, and index.cgi is there, the server will run it.
-
-- -If one of the files found when reading the directive is a CGI script, -it's not obvious what should happen. The code gives that case -special treatment --- if the request was a POST, or a GET with -QUERY_ARGS or PATH_INFO, the script is given an extremely high quality -rating, and generally invoked; otherwise it is given an extremely low -quality rating, which generally causes one of the other views (if any) -to be retrieved. - -
- -In some circumstances, Apache can 'fiddle' the quality factor of a -particular dimension to achieve a better result. The ways Apache can -fiddle quality factors is explained in more detail below. - -
| Dimension - | Notes - |
|---|---|
| Media Type - | Browser indicates preferences on Accept: header. Each item -can have an associated quality factor. Variant description can also -have a quality factor. - |
| Language - | Browser indicates preferences on Accept-Language: header. Each -item -can have a quality factor. Variants can be associated with none, one -or more languages. - |
| Encoding - | Browser indicates preference with Accept-Encoding: header. - |
| Charset - | Browser indicates preference with Accept-Charset: header. Variants -can indicate a charset as a parameter of the media type. - |
- -
LanguagePriority directive (if present),
- else the order of languages on the Accept-Language header.
-
-- -
- Accept: image/*, */* -- -would indicate that any type starting "image/" is acceptable, -as is any other type (so the first "image/*" is redundant). Some -browsers routinely send wildcards in addition to explicit types they -can handle. For example: -
- Accept: text/html, text/plain, image/gif, image/jpeg, */* -- -The intention of this is to indicate that the explicitly -listed types are preferred, but if a different representation is -available, that is ok too. However under the basic algorithm, as given -above, the */* wildcard has exactly equal preference to all the other -types, so they are not being preferred. The browser should really have -sent a request with a lower quality (preference) value for *.*, such -as: -
- Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01 -- -The explicit types have no quality factor, so they default to a -preference of 1.0 (the highest). The wildcard */* is given -a low preference of 0.01, so other types will only be returned if -no variant matches an explicitly listed type. -
- -If the Accept: header contains no q factors at all, Apache sets -the q value of "*/*", if present, to 0.01 to emulate the desired -behavior. It also sets the q value of wildcards of the format -"type/*" to 0.02 (so these are preferred over matches against -"*/*". If any media type on the Accept: header contains a q factor, -these special values are not applied, so requests from browsers -which send the correct information to start with work as expected. - -
- -The reason for setting this language quality factor for -variant with no language to a very low value is to allow -for a default variant which can be supplied if none of the -other variants match the browser's language preferences. - -For example, consider the situation with three variants: - -
- -For requests which come from a HTTP/1.0 compliant client (either a -browser or a cache), the directive CacheNegotiatedDocs can be -used to allow caching of responses which were subject to negotiation. -This directive can be given in the server config or virtual host, and -takes no arguments. It has no effect on requests from HTTP/1.1 -clients. - - - - diff --git a/docs/manual/custom-error.html b/docs/manual/custom-error.html index 3f04af058b0..3165ec044e6 100644 --- a/docs/manual/custom-error.html +++ b/docs/manual/custom-error.html @@ -29,9 +29,9 @@ response, then this response can be replaced with either some friendlier text or by a redirection to another URL (local or external). - +
- +
Customizable responses can be defined to be activated in the - event of a server detected error or problem. - -
e.g. if a script crashes and produces a "500 Server Error" - response, then this response can be replaced with either some - friendlier text or by a redirection to another URL (local or - external). - -
- -
- -
Redirecting to another URL can be useful, but only if some information - can be passed which can then be used to explain and/or log the error/problem - more clearly. - -
To achieve this, Apache will define new CGI-like environment - variables, e.g. - -
-REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg
-REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712)
-REDIRECT_PATH=.:/bin:/usr/local/bin:/etc
-REDIRECT_QUERY_STRING=
-REDIRECT_REMOTE_ADDR=121.345.78.123
-REDIRECT_REMOTE_HOST=ooh.ahhh.com
-REDIRECT_SERVER_NAME=crash.bang.edu
-REDIRECT_SERVER_PORT=80
-REDIRECT_SERVER_SOFTWARE=Apache/0.8.15
-REDIRECT_URL=/cgi-bin/buggy.pl
- 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.
- None of these will be set if your ErrorDocument is an
- external redirect (i.e. anything starting with a protocol name
- like http:, even if it refers to the same host as the
- server).
- -
Here are some examples... - -
-ErrorDocument 500 /cgi-bin/crash-recover
-ErrorDocument 500 "Sorry, our script crashed. Oh dear
-ErrorDocument 500 http://xxx/
-ErrorDocument 404 /Lame_excuses/not_found.html
-ErrorDocument 401 /Subscription/how_to_subscribe.html
- The syntax is, - -
ErrorDocument
-<3-digit-code> action
-
-
where the action can be, - -
- -
- -
- -
REDIRECT_. REDIRECT_ environment
-variables are created from the CGI environment variables which existed
-prior to the redirect, they are renamed with a REDIRECT_
-prefix, i.e. HTTP_USER_AGENT becomes
-REDIRECT_HTTP_USER_AGENT. In addition to these new
-variables, Apache will define REDIRECT_URL and
-REDIRECT_STATUS to help the script trace its origin.
-Both the original URL and the URL being redirected to can be logged in
-the access log.
-
-- -A few notes on general pedagogical style here. In the interest of -conciseness, all structure declarations here are incomplete --- the -real ones have more slots that I'm not telling you about. For the -most part, these are reserved to one component of the server core or -another, and should be altered by modules with caution. However, in -some cases, they really are things I just haven't gotten around to -yet. Welcome to the bleeding edge.
- -Finally, here's an outline, to give you some bare idea of what's -coming up, and in what order: - -
SetEnv, which don't really fit well elsewhere.
- OK.
- DECLINED. In this case, the
- server behaves in all respects as if the handler simply hadn't
- been there.
- */* (i.e., a
-wildcard MIME type specification). However, wildcard handlers are
-only invoked if the server has already tried and failed to find a more
-specific response handler for the MIME type of the requested object
-(either none existed, or they all declined).
-
-The handlers themselves are functions of one argument (a
-request_rec structure. vide infra), which returns an
-integer, as above.
- -
ScriptAlias config file
-command. It's actually a great deal more complicated than most
-modules, but if we're going to have only one example, it might as well
-be the one with its fingers in every place.
-
-Let's begin with handlers. In order to handle the CGI scripts, the
-module declares a response handler for them. Because of
-ScriptAlias, it also has handlers for the name
-translation phase (to recognize ScriptAliased URIs), the
-type-checking phase (any ScriptAliased request is typed
-as a CGI script).
-
-The module needs to maintain some per (virtual)
-server information, namely, the ScriptAliases in effect;
-the module structure therefore contains pointers to a functions which
-builds these structures, and to another which combines two of them (in
-case the main server and a virtual server both have
-ScriptAliases declared).
-
-Finally, this module contains code to handle the
-ScriptAlias command itself. This particular module only
-declares one command, but there could be more, so modules have
-command tables which declare their commands, and describe
-where they are permitted, and how they are to be invoked.
-
-A final note on the declared types of the arguments of some of these
-commands: a pool is a pointer to a resource pool
-structure; these are used by the server to keep track of the memory
-which has been allocated, files opened, etc., either to service a
-particular request, or to handle the process of configuring itself.
-That way, when the request is over (or, for the configuration pool,
-when the server is restarting), the memory can be freed, and the files
-closed, en masse, without anyone having to write explicit code to
-track them all down and dispose of them. Also, a
-cmd_parms structure contains various information about
-the config file being read, and other status information, which is
-sometimes of use to the function which processes a config-file command
-(such as ScriptAlias).
-
-With no further ado, the module itself:
-
-
-/* Declarations of handlers. */
-
-int translate_scriptalias (request_rec *);
-int type_scriptalias (request_rec *);
-int cgi_handler (request_rec *);
-
-/* Subsidiary dispatch table for response-phase handlers, by MIME type */
-
-handler_rec cgi_handlers[] = {
-{ "application/x-httpd-cgi", cgi_handler },
-{ NULL }
-};
-
-/* Declarations of routines to manipulate the module's configuration
- * info. Note that these are returned, and passed in, as void *'s;
- * the server core keeps track of them, but it doesn't, and can't,
- * know their internal structure.
- */
-
-void *make_cgi_server_config (pool *);
-void *merge_cgi_server_config (pool *, void *, void *);
-
-/* Declarations of routines to handle config-file commands */
-
-extern char *script_alias(cmd_parms *, void *per_dir_config, char *fake,
- char *real);
-
-command_rec cgi_cmds[] = {
-{ "ScriptAlias", script_alias, NULL, RSRC_CONF, TAKE2,
- "a fakename and a realname"},
-{ NULL }
-};
-
-module cgi_module = {
- STANDARD_MODULE_STUFF,
- NULL, /* initializer */
- NULL, /* dir config creator */
- NULL, /* dir merger --- default is to override */
- make_cgi_server_config, /* server config */
- merge_cgi_server_config, /* merge server config */
- cgi_cmds, /* command table */
- cgi_handlers, /* handlers */
- translate_scriptalias, /* filename translation */
- NULL, /* check_user_id */
- NULL, /* check auth */
- NULL, /* check access */
- type_scriptalias, /* type_checker */
- NULL, /* fixups */
- NULL, /* logger */
- NULL /* header parser */
-};
-
-
-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.- -
request_recrequest_rec contains pointers to a resource pool
-which will be cleared when the server is finished handling the
-request; to structures containing per-server and per-connection
-information, and most importantly, information on the request itself.- -The most important such information is a small set of character -strings describing attributes of the object being requested, including -its URI, filename, content-type and content-encoding (these being filled -in by the translation and type-check handlers which handle the -request, respectively).
-
-Other commonly used data items are tables giving the MIME headers on
-the client's original request, MIME headers to be sent back with the
-response (which modules can add to at will), and environment variables
-for any subprocesses which are spawned off in the course of servicing
-the request. These tables are manipulated using the
-table_get and table_set routines.
-
- Note that the Content-type header value cannot be - set by module content-handlers using the table_*() - routines. Rather, it is set by pointing the content_type - field in the request_rec structure to an appropriate - string. E.g., --Finally, there are pointers to two data structures which, in turn, -point to per-module configuration structures. Specifically, these -hold pointers to the data structures which the module has built to -describe the way it has been configured to operate in a given -directory (via- r->content_type = "text/html"; --
.htaccess files or
-<Directory> sections), for private data it has
-built in the course of servicing the request (so modules' handlers for
-one phase can pass `notes' to their handlers for other phases). There
-is another such configuration vector in the server_rec
-data structure pointed to by the request_rec, which
-contains per (virtual) server configuration data.- -Here is an abridged declaration, giving the fields most commonly used:
- -
-struct request_rec {
-
- pool *pool;
- conn_rec *connection;
- server_rec *server;
-
- /* What object is being requested */
-
- char *uri;
- char *filename;
- char *path_info;
- char *args; /* QUERY_ARGS, if any */
- struct stat finfo; /* Set by server core;
- * st_mode set to zero if no such file */
-
- char *content_type;
- char *content_encoding;
-
- /* MIME header environments, in and out. Also, an array containing
- * environment variables to be passed to subprocesses, so people can
- * write modules to add to that environment.
- *
- * The difference between headers_out and err_headers_out is that
- * the latter are printed even on error, and persist across internal
- * redirects (so the headers printed for ErrorDocument handlers will
- * have them).
- */
-
- table *headers_in;
- table *headers_out;
- table *err_headers_out;
- table *subprocess_env;
-
- /* Info about the request itself... */
-
- int header_only; /* HEAD request, as opposed to GET */
- char *protocol; /* Protocol, as given to us, or HTTP/0.9 */
- char *method; /* GET, HEAD, POST, etc. */
- int method_number; /* M_GET, M_POST, etc. */
-
- /* Info for logging */
-
- char *the_request;
- int bytes_sent;
-
- /* A flag which modules can set, to indicate that the data being
- * returned is volatile, and clients should be told not to cache it.
- */
-
- int no_cache;
-
- /* Various other config info which may change with .htaccess files
- * These are config vectors, with one void* pointer for each module
- * (the thing pointed to being the module's business).
- */
-
- void *per_dir_config; /* Options set in config files, etc. */
- void *request_config; /* Notes on *this* request */
-
-};
-
-
-
-request_rec structures are built by reading an HTTP
-request from a client, and filling in the fields. However, there are
-a few exceptions:
-
-*.var file), or a CGI script which returned a
- local `Location:', then the resource which the user requested
- is going to be ultimately located by some URI other than what
- the client originally supplied. In this case, the server does
- an internal redirect, constructing a new
- request_rec for the new URI, and processing it
- almost exactly as if the client had requested the new URI
- directly. - -
ErrorDocument is in scope, the same internal
- redirect machinery comes into play.- -
-
- Such handlers can construct a sub-request, using the
- functions sub_req_lookup_file and
- sub_req_lookup_uri; this constructs a new
- request_rec structure and processes it as you
- would expect, up to but not including the point of actually
- sending a response. (These functions skip over the access
- checks if the sub-request is for a file in the same directory
- as the original request).
-
- (Server-side includes work by building sub-requests and then
- actually invoking the response handler for them, via the
- function run_sub_request).
-
request_rec, has to return an int to
-indicate what happened. That can either be
-
-REDIRECT, then
-the module should put a Location in the request's
-headers_out, to indicate where the client should be
-redirected to. - -
request_rec structure (or, in the case of access
-checkers, simply by returning the correct error code). However,
-response handlers have to actually send a request back to the client.
-
-They should begin by sending an HTTP response header, using the
-function send_http_header. (You don't have to do
-anything special to skip sending the header for HTTP/0.9 requests; the
-function figures out on its own that it shouldn't do anything). If
-the request is marked header_only, that's all they should
-do; they should return after that, without attempting any further
-output.
-
-Otherwise, they should produce a request body which responds to the
-client as appropriate. The primitives for this are rputc
-and rprintf, for internally generated output, and
-send_fd, to copy the contents of some FILE *
-straight to the client.
-
-At this point, you should more or less understand the following piece
-of code, which is the handler which handles GET requests
-which have no more specific handler; it also shows how conditional
-GETs can be handled, if it's desirable to do so in a
-particular response handler --- set_last_modified checks
-against the If-modified-since value supplied by the
-client, if any, and returns an appropriate code (which will, if
-nonzero, be USE_LOCAL_COPY). No similar considerations apply for
-set_content_length, but it returns an error code for
-symmetry.
- -
-int default_handler (request_rec *r)
-{
- int errstatus;
- FILE *f;
-
- if (r->method_number != M_GET) return DECLINED;
- if (r->finfo.st_mode == 0) return NOT_FOUND;
-
- if ((errstatus = set_content_length (r, r->finfo.st_size))
- || (errstatus = set_last_modified (r, r->finfo.st_mtime)))
- return errstatus;
-
- f = fopen (r->filename, "r");
-
- if (f == NULL) {
- log_reason("file permissions deny server access",
- r->filename, r);
- return FORBIDDEN;
- }
-
- register_timeout ("send", r);
- send_http_header (r);
-
- if (!r->header_only) send_fd (f, r);
- pfclose (r->pool, f);
- return OK;
-}
-
-
-Finally, if all of this is too much of a challenge, there are a few
-ways out of it. First off, as shown above, a response handler which
-has not yet produced any output can simply return an error code, in
-which case the server will automatically produce an error response.
-Secondly, it can punt to some other handler by invoking
-internal_redirect, which is how the internal redirection
-machinery discussed above is invoked. A response handler which has
-internally redirected should always return OK.
-
-(Invoking internal_redirect from handlers which are
-not response handlers will lead to serious confusion).
-
-
auth_type,
- auth_name, and requires.
- get_basic_auth_pw,
- which sets the connection->user structure field
- automatically, and note_basic_auth_failure, which
- arranges for the proper WWW-Authenticate: header
- to be sent back).
-request_rec structures which are
-threaded through the r->prev and r->next
-pointers. The request_rec which is passed to the logging
-handlers in such cases is the one which was originally built for the
-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).
-
-- -The way this works is as follows: the memory which is allocated, file -opened, etc., to deal with a particular request are tied to a -resource pool which is allocated for the request. The pool -is a data structure which itself tracks the resources in question.
- -When the request has been processed, the pool is cleared. At -that point, all the memory associated with it is released for reuse, -all files associated with it are closed, and any other clean-up -functions which are associated with the pool are run. When this is -over, we can be confident that all the resource tied to the pool have -been released, and that none of them have leaked.
- -Server restarts, and allocation of memory and resources for per-server -configuration, are handled in a similar way. There is a -configuration pool, which keeps track of resources which were -allocated while reading the server configuration files, and handling -the commands therein (for instance, the memory that was allocated for -per-server module configuration, log files and other files that were -opened, and so forth). When the server restarts, and has to reread -the configuration files, the configuration pool is cleared, and so the -memory and file descriptors which were taken up by reading them the -last time are made available for reuse.
-
-It should be noted that use of the pool machinery isn't generally
-obligatory, except for situations like logging handlers, where you
-really need to register cleanups to make sure that the log file gets
-closed when the server restarts (this is most easily done by using the
-function pfopen, which also
-arranges for the underlying file descriptor to be closed before any
-child processes, such as for CGI scripts, are execed), or
-in case you are using the timeout machinery (which isn't yet even
-documented here). However, there are two benefits to using it:
-resources allocated to a pool never leak (even if you allocate a
-scratch string, and just forget about it); also, for memory
-allocation, palloc is generally faster than
-malloc.
- -We begin here by describing how memory is allocated to pools, and then -discuss how other resources are tracked by the resource pool -machinery. - -
palloc, which takes two arguments, one being a pointer to
-a resource pool structure, and the other being the amount of memory to
-allocate (in chars). Within handlers for handling
-requests, the most common way of getting a resource pool structure is
-by looking at the pool slot of the relevant
-request_rec; hence the repeated appearance of the
-following idiom in module code:
-
-
-int my_handler(request_rec *r)
-{
- struct my_structure *foo;
- ...
-
- foo = (foo *)palloc (r->pool, sizeof(my_structure));
-}
-
-
-Note that there is no pfree ---
-palloced memory is freed only when the associated
-resource pool is cleared. This means that palloc does not
-have to do as much accounting as malloc(); all it does in
-the typical case is to round up the size, bump a pointer, and do a
-range check.
-
-(It also raises the possibility that heavy use of palloc
-could cause a server process to grow excessively large. There are
-two ways to deal with this, which are dealt with below; briefly, you
-can use malloc, and try to be sure that all of the memory
-gets explicitly freed, or you can allocate a sub-pool of
-the main pool, allocate your memory in the sub-pool, and clear it out
-periodically. The latter technique is discussed in the section on
-sub-pools below, and is used in the directory-indexing code, in order
-to avoid excessive storage allocation when listing directories with
-thousands of files).
-
-
pcalloc has the same
-interface as palloc, but clears out the memory it
-allocates before it returns it. The function pstrdup
-takes a resource pool and a char * as arguments, and
-allocates memory for a copy of the string the pointer points to,
-returning a pointer to the copy. Finally pstrcat is a
-varargs-style function, which takes a pointer to a resource pool, and
-at least two char * arguments, the last of which must be
-NULL. It allocates enough memory to fit copies of each
-of the strings, as a unit; for instance:
-
-- pstrcat (r->pool, "foo", "/", "bar", NULL); -- -returns a pointer to 8 bytes worth of memory, initialized to -
"foo/bar".
-
-pfopen, which
-takes a resource pool and two strings as arguments; the strings are
-the same as the typical arguments to fopen, e.g.,
-
-
- ...
- FILE *f = pfopen (r->pool, r->filename, "r");
-
- if (f == NULL) { ... } else { ... }
-
-
-There is also a popenf routine, which parallels the
-lower-level open system call. Both of these routines
-arrange for the file to be closed when the resource pool in question
-is cleared.
-
-Unlike the case for memory, there are functions to close
-files allocated with pfopen, and popenf,
-namely pfclose and pclosef. (This is
-because, on many systems, the number of files which a single process
-can have open is quite limited). It is important to use these
-functions to close files allocated with pfopen and
-popenf, since to do otherwise could cause fatal errors on
-systems such as Linux, which react badly if the same
-FILE* is closed more than once.
-
-(Using the close functions is not mandatory, since the
-file will eventually be closed regardless, but you should consider it
-in cases where your module is opening, or could open, a lot of files).
-
-
spawn_process.
-
-palloc() and the
-associated primitives may result in undesirably profligate resource
-allocation. You can deal with such a case by creating a
-sub-pool, allocating within the sub-pool rather than the main
-pool, and clearing or destroying the sub-pool, which releases the
-resources which were associated with it. (This really is a
-rare situation; the only case in which it comes up in the standard
-module set is in case of listing directories, and then only with
-very large directories. Unnecessary use of the primitives
-discussed here can hair up your code quite a bit, with very little
-gain).
-
-The primitive for creating a sub-pool is make_sub_pool,
-which takes another pool (the parent pool) as an argument. When the
-main pool is cleared, the sub-pool will be destroyed. The sub-pool
-may also be cleared or destroyed at any time, by calling the functions
-clear_pool and destroy_pool, respectively.
-(The difference is that clear_pool frees resources
-associated with the pool, while destroy_pool also
-deallocates the pool itself. In the former case, you can allocate new
-resources within the pool, and clear it again, and so forth; in the
-latter case, it is simply gone).
-
-One final note --- sub-requests have their own resource pools, which
-are sub-pools of the resource pool for the main request. The polite
-way to reclaim the resources associated with a sub request which you
-have allocated (using the sub_req_lookup_... functions)
-is destroy_sub_request, which frees the resource pool.
-Before calling this function, be sure to copy anything that you care
-about which might be allocated in the sub-request's resource pool into
-someplace a little less volatile (for instance, the filename in its
-request_rec structure).
-
-(Again, under most circumstances, you shouldn't feel obliged to call
-this function; only 2K of memory or so are allocated for a typical sub
-request, and it will be freed anyway when the main request pool is
-cleared. It is only when you are allocating many, many sub-requests
-for a single main request that you should seriously consider the
-destroy... functions).
-
-
-
-However, just giving the modules command tables is not enough to
-divorce them completely from the server core. The server has to
-remember the commands in order to act on them later. That involves
-maintaining data which is private to the modules, and which can be
-either per-server, or per-directory. Most things are per-directory,
-including in particular access control and authorization information,
-but also information on how to determine file types from suffixes,
-which can be modified by AddType and
-DefaultType directives, and so forth. In general, the
-governing philosophy is that anything which can be made
-configurable by directory should be; per-server information is
-generally used in the standard set of modules for information like
-Aliases and Redirects which come into play
-before the request is tied to a particular place in the underlying
-file system.
-
-Another requirement for emulating the NCSA server is being able to
-handle the per-directory configuration files, generally called
-.htaccess files, though even in the NCSA server they can
-contain directives which have nothing at all to do with access
-control. Accordingly, after URI -> filename translation, but before
-performing any other phase, the server walks down the directory
-hierarchy of the underlying filesystem, following the translated
-pathname, to read any .htaccess files which might be
-present. The information which is read in then has to be
-merged with the applicable information from the server's own
-config files (either from the <Directory> sections
-in access.conf, or from defaults in
-srm.conf, which actually behaves for most purposes almost
-exactly like <Directory />).
-
-Finally, after having served a request which involved reading
-.htaccess files, we need to discard the storage allocated
-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.
- -
mod_mime.c,
-which defines the file typing handler which emulates the NCSA server's
-behavior of determining file types from suffixes. What we'll be
-looking at, here, is the code which implements the
-AddType and AddEncoding commands. These
-commands can appear in .htaccess files, so they must be
-handled in the module's private per-directory data, which in fact,
-consists of two separate tables for MIME types and
-encoding information, and is declared as follows:
-
-
-typedef struct {
- table *forced_types; /* Additional AddTyped stuff */
- table *encoding_types; /* Added with AddEncoding... */
-} mime_dir_config;
-
-
-When the server is reading a configuration file, or
-<Directory> section, which includes one of the MIME
-module's commands, it needs to create a mime_dir_config
-structure, so those commands have something to act on. It does this
-by invoking the function it finds in the module's `create per-dir
-config slot', with two arguments: the name of the directory to which
-this configuration information applies (or NULL for
-srm.conf), and a pointer to a resource pool in which the
-allocation should happen.
-
-(If we are reading a .htaccess file, that resource pool
-is the per-request resource pool for the request; otherwise it is a
-resource pool which is used for configuration data, and cleared on
-restarts. Either way, it is important for the structure being created
-to vanish when the pool is cleared, by registering a cleanup on the
-pool if necessary).
-
-For the MIME module, the per-dir config creation function just
-pallocs the structure above, and a creates a couple of
-tables to fill it. That looks like this:
-
-
-void *create_mime_dir_config (pool *p, char *dummy)
-{
- mime_dir_config *new =
- (mime_dir_config *) palloc (p, sizeof(mime_dir_config));
-
- new->forced_types = make_table (p, 4);
- new->encoding_types = make_table (p, 4);
-
- return new;
-}
-
-
-Now, suppose we've just read in a .htaccess file. We
-already have the per-directory configuration structure for the next
-directory up in the hierarchy. If the .htaccess file we
-just read in didn't have any AddType or
-AddEncoding commands, its per-directory config structure
-for the MIME module is still valid, and we can just use it.
-Otherwise, we need to merge the two structures somehow. - -To do that, the server invokes the module's per-directory config merge -function, if one is present. That function takes three arguments: -the two structures being merged, and a resource pool in which to -allocate the result. For the MIME module, all that needs to be done -is overlay the tables from the new per-directory config structure with -those from the parent: - -
-void *merge_mime_dir_configs (pool *p, void *parent_dirv, void *subdirv)
-{
- mime_dir_config *parent_dir = (mime_dir_config *)parent_dirv;
- mime_dir_config *subdir = (mime_dir_config *)subdirv;
- mime_dir_config *new =
- (mime_dir_config *)palloc (p, sizeof(mime_dir_config));
-
- new->forced_types = overlay_tables (p, subdir->forced_types,
- parent_dir->forced_types);
- new->encoding_types = overlay_tables (p, subdir->encoding_types,
- parent_dir->encoding_types);
-
- return new;
-}
-
-
-As a note --- if there is no per-directory merge function present, the
-server will just use the subdirectory's configuration info, and ignore
-the parent's. For some modules, that works just fine (e.g., for the
-includes module, whose per-directory configuration information
-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.- -
AddType and AddEncoding commands. To find
-commands, the server looks in the module's command table.
-That table contains information on how many arguments the commands
-take, and in what formats, where it is permitted, and so forth. That
-information is sufficient to allow the server to invoke most
-command-handling functions with pre-parsed arguments. Without further
-ado, let's look at the AddType command handler, which
-looks like this (the AddEncoding command looks basically
-the same, and won't be shown here):
-
-
-char *add_type(cmd_parms *cmd, mime_dir_config *m, char *ct, char *ext)
-{
- if (*ext == '.') ++ext;
- table_set (m->forced_types, ext, ct);
- return NULL;
-}
-
-
-This command handler is unusually simple. As you can see, it takes
-four arguments, two of which are pre-parsed arguments, the third being
-the per-directory configuration structure for the module in question,
-and the fourth being a pointer to a cmd_parms structure.
-That structure contains a bunch of arguments which are frequently of
-use to some, but not all, commands, including a resource pool (from
-which memory can be allocated, and to which cleanups should be tied),
-and the (virtual) server being configured, from which the module's
-per-server configuration data can be obtained if required.
-
-Another way in which this particular command handler is unusually
-simple is that there are no error conditions which it can encounter.
-If there were, it could return an error message instead of
-NULL; this causes an error to be printed out on the
-server's stderr, followed by a quick exit, if it is in
-the main config files; for a .htaccess file, the syntax
-error is logged in the server error log (along with an indication of
-where it came from), and the request is bounced with a server error
-response (HTTP error status, code 500).
- -The MIME module's command table has entries for these commands, which -look like this: - -
-command_rec mime_cmds[] = {
-{ "AddType", add_type, NULL, OR_FILEINFO, TAKE2,
- "a mime type followed by a file extension" },
-{ "AddEncoding", add_encoding, NULL, OR_FILEINFO, TAKE2,
- "an encoding (e.g., gzip), followed by a file extension" },
-{ NULL }
-};
-
-
-The entries in these tables are:
-
-(void *) pointer, which is passed in the
- cmd_parms structure to the command handler ---
- this is useful in case many similar commands are handled by the
- same function.
- AllowOverride
- option, and an additional mask bit, RSRC_CONF,
- indicating that the command may appear in the server's own
- config files, but not in any .htaccess
- file.
- TAKE2 indicates two pre-parsed arguments. Other
- options are TAKE1, which indicates one pre-parsed
- argument, FLAG, which indicates that the argument
- should be On or Off, and is passed in
- as a boolean flag, RAW_ARGS, which causes the
- server to give the command the raw, unparsed arguments
- (everything but the command name itself). There is also
- ITERATE, which means that the handler looks the
- same as TAKE1, but that if multiple arguments are
- present, it should be called multiple times, and finally
- ITERATE2, which indicates that the command handler
- looks like a TAKE2, but if more arguments are
- present, then it should be called multiple times, holding the
- first argument constant.
- NULL).
-request_rec's per-directory configuration vector by using
-the get_module_config function.
-
-
-int find_ct(request_rec *r)
-{
- int i;
- char *fn = pstrdup (r->pool, r->filename);
- mime_dir_config *conf = (mime_dir_config *)
- get_module_config(r->per_dir_config, &mime_module);
- char *type;
-
- if (S_ISDIR(r->finfo.st_mode)) {
- r->content_type = DIR_MAGIC_TYPE;
- return OK;
- }
-
- if((i=rind(fn,'.')) < 0) return DECLINED;
- ++i;
-
- if ((type = table_get (conf->encoding_types, &fn[i])))
- {
- r->content_encoding = type;
-
- /* go back to previous extension to try to use it as a type */
-
- fn[i-1] = '\0';
- if((i=rind(fn,'.')) < 0) return OK;
- ++i;
- }
-
- if ((type = table_get (conf->forced_types, &fn[i])))
- {
- r->content_type = type;
- }
-
- return OK;
-}
-
-
-
-
-
-The only substantial difference is that when a command needs to
-configure the per-server private module data, it needs to go to the
-cmd_parms data to get at it. Here's an example, from the
-alias module, which also indicates how a syntax error can be returned
-(note that the per-directory configuration argument to the command
-handler is declared as a dummy, since the module doesn't actually have
-per-directory config data):
-
-
-char *add_redirect(cmd_parms *cmd, void *dummy, char *f, char *url)
-{
- server_rec *s = cmd->server;
- alias_server_conf *conf = (alias_server_conf *)
- get_module_config(s->module_config,&alias_module);
- alias_entry *new = push_array (conf->redirects);
-
- if (!is_url (url)) return "Redirect to non-URL";
-
- new->fake = f; new->real = url;
- return NULL;
-}
-
-
-
diff --git a/docs/manual/handler.html.en b/docs/manual/handler.html.en
deleted file mode 100644
index 80592161123..00000000000
--- a/docs/manual/handler.html.en
+++ /dev/null
@@ -1,141 +0,0 @@
-
-
-
-A "handler" is an internal Apache representation of the action to be -performed when a file is called. Generally, files have implicit -handlers, based on the file type. Normally, all files are simply -served by the server, but certain file typed are "handled" -separately. For example, you may use a type of -"application/x-httpd-cgi" to invoke CGI scripts.
- -Apache 1.1 adds the additional ability to use handlers -explicitly. Either based on filename extensions or on location, these -handlers are unrelated to file type. This is advantageous both because -it is a more elegant solution, but it also allows for both a type -and a handler to be associated with a file.
- -Handlers can either be built into the server or to a module, or -they can be added with the Action directive. The built-in -handlers in the standard distribution are as follows:
- -- -
AddHandler maps the filename extension extension to the
-handler handler-name. For example, to activate CGI scripts
-with the file extension ".cgi", you might use:
-
- AddHandler cgi-script cgi -- -
Once that has been put into your srm.conf or httpd.conf file, any
-file ending with ".cgi" will be treated as a CGI
-program.
When placed into an .htaccess file or a
-<Directory> or <Location> section,
-this directive forces all matching files to be parsed through the
-handler given by handler-name. For example, if you had a
-directory you wanted to be parsed entirely as imagemap rule files,
-regardless of extension, you might put the following into an
-.htaccess file in that directory:
-
- SetHandler imap-file --
Another example: if you wanted to have the server display a status
-report whenever a URL of http://servername/status was
-called, you might put the following into access.conf:
-
- <Location /status> - SetHandler server-status - </Location> -- -
In order to implement the handler features, an addition has been
-made to the Apache API that you may wish to
-make use of. Specifically, a new record has been added to the
-request_rec structure:
- char *handler --
If you wish to have your module engage a handler, you need only to
-set r->handler to the name of the handler at any time
-prior to the invoke_handler stage of the
-request. Handlers are implemented as they were before, albeit using
-the handler name instead of a content type. While it is not
-necessary, the naming convention for handlers is to use a
-dash-separated word, with no slashes, so as to not invade the media
-type name-space.
If you wish to download and install an earlier version of Apache please -read Compiling and Installing Apache 1.1.
- -UnixWare users will want to consult build notes -for various UnixWare versions before compiling. - -- -If you downloaded a binary distribution, skip to Installing Apache. Otherwise read the next section -for how to compile the server. - -
-
-All configuration of Apache is performed in the src
-directory of the Apache distribution. Change into this directory.
-
-
Configuration file. Uncomment lines corresponding to
- those optional modules you wish to include (among the Module lines
- at the bottom of the file), or add new lines corresponding to
- additional modules you have downloaded or written. (See API.html for preliminary docs on how to
- write Apache modules). Advanced users can comment out some of the
- default modules if they are sure they will not need them (be careful
- though, since many of the default modules are vital for the correct
- operation and security of the server).
-
-
- You should also read the instructions in the Configuration
- file to see if you need to set any of the Rule lines.
-
-
-
Configure script as given below. However
- if this fails or you have any special requirements (e.g. to include
- an additional library required by an optional module) you might need
- to edit one or more of the following options in the
- Configuration file:
- EXTRA_CFLAGS, LIBS, LFLAGS, INCLUDES.
-
-
- Run the Configure script:
-
-- - (*: Depending on Configuration and your system, Configure - make not print these lines. That's OK).- % Configure - Using 'Configuration' as config file - + configured for <whatever> platform - + setting C compiler to <whatever> * - + setting C compiler optimization-level to <whatever> * - % --
- - This generates a Makefile for use in stage 3. It also creates a - Makefile in the support directory, for compilation of the optional - support programs. -
-
- (If you want to maintain multiple configurations, you can give a
- option to Configure to tell it to read an alternative
- Configuration file, such as Configure -file
- Configuration.ai).
-
- -
make.
-httpd in the
-src directory. A binary distribution of Apache will
-supply this file.
-
-The next step is to install the program and configure it. Apache is
-designed to be configured and run from the same set of directories
-where it is compiled. If you want to run it from somewhere else, make
-a directory and copy the conf, logs and
-icons directories into it.
-
-The next step is to edit the configuration files for the server. This
-consists of setting up various directives in up to three
-central configuration files. By default, these files are located in
-the conf directory and are called srm.conf,
-access.conf and httpd.conf. To help you get
-started there are same files in the conf directory of the
-distribution, called srm.conf-dist,
-access.conf-dist and httpd.conf-dist. Copy
-or rename these files to the names without the -dist.
-Then edit each of the files. Read the comments in each file carefully.
-Failure to setup these files correctly could lead to your server not
-working or being insecure. You should also have an additional file in
-the conf directory called mime.types. This
-file usually does not need editing.
-
-
-
-First edit httpd.conf. This sets up general attributes
-about the server: the port number, the user it runs as, etc. Next
-edit the srm.conf file; this sets up the root of the
-document tree, special functions like server-parsed HTML or internal
-imagemap parsing, etc. Finally, edit the access.conf
-file to at least set the base cases of access.
-
-
-
-In addition to these three files, the server behavior can be configured
-on a directory-by-directory basis by using .htaccess
-files in directories accessed by the server.
-
-
httpd. This will look for
-httpd.conf in the location compiled into the code (by
-default /usr/locale/etc/httpd/conf/httpd.conf). If
-this file is somewhere else, you can give the real
-location with the -f argument. For example:
-
-- /usr/local/etc/apache/src/httpd -f /usr/local/etc/apache/conf/httpd.conf -- -If all goes well this will return to the command prompt almost -immediately. This indicates that the server is now up and running. If -anything goes wrong during the initialization of the server you will -see an error message on the screen. - -If the server started ok, you can now use your browser to -connect to the server and read the documentation. If you are running -the browser on the same machine as the server and using the default -port of 80, a suitable URL to enter into your browser is - -
- http://localhost/ -- -
- -Note that when the server starts it will create a number of -child processes to handle the requests. If you started Apache -as the root user, the parent process will continue to run as root -while the children will change to the user as given in the httpd.conf -file. - -
-
-If when you run httpd it complained about being unable to
-"bind" to an address, then either some other process is already using
-the port you have configured Apache to use, or you are running httpd
-as a normal user but trying to use port below 1024 (such as the
-default port 80).
-
-
-
-If the server is not running, read the error message displayed
-when you run httpd. You should also check the server
-error_log for additional information (with the default configuration,
-this will be located in the file error_log in the
-logs directory).
-
-
-
-If you want your server to continue running after a system reboot, you
-should add a call to httpd to your system startup files
-(typically rc.local or a file in an
-rc.N directory). This will start Apache as root.
-Before doing this ensure that your server is properly configured
-for security and access restrictions.
-
-
-
-To stop Apache send the parent process a TERM signal. The PID of this
-process is written to the file httpd.pid in the
-logs directory (unless configured otherwise). Do not
-attempt to kill the child processes because they will be renewed by
-the parent. A typical command to stop the server is:
-
-
- kill -TERM `cat /usr/local/etc/apache/logs/httpd.pid` -- -
- -For more information about Apache command line options, configuration -and log files, see Starting Apache. For a -reference guide to all Apache directives supported by the distributed -modules, see the Apache directives. - -
httpd server which is compiled
-and configured as above, Apache includes a number of support programs.
-These are not compiled by default. The support programs are in the
-support directory of the distribution. To compile
-the support programs, change into this directory and type
-- make -- - - - diff --git a/docs/manual/invoking.html.en b/docs/manual/invoking.html.en deleted file mode 100644 index 62e6a41af9a..00000000000 --- a/docs/manual/invoking.html.en +++ /dev/null @@ -1,124 +0,0 @@ - - - -
httpd program is usually run as a daemon which executes
-continuously, handling requests. It is possible to invoke Apache by
-the Internet daemon inetd each time a connection to the HTTP
-service is made (use the
-ServerType directive)
-but this is not recommended.
-
--d serverroot
-/usr/local/etc/httpd.
-
--f config
-/, then it is taken to be a
-path relative to the ServerRoot. The
-default is conf/httpd.conf.
-
--X
--v
--h
--l
--?
--d command line flag.
-
-Conventionally, the files are:
-conf/httpd.conf
--f command line flag.
-
-conf/srm.conf
-conf/access.conf
-
-The server also reads a file containing mime document types; the filename
-is set by the TypesConfig directive,
-and is conf/mime.types by default.
-
-
logs/httpd.pid. This filename can be changed with the
-PidFile directive. The process-id is for
-use by the administrator in restarting and terminating the daemon;
-A HUP or USR1 signal causes the daemon to re-read its configuration files and
-a TERM signal causes it to die gracefully. For more information
-see the Stopping and Restarting page.
--If the process dies (or is killed) abnormally, then it will be necessary to -kill the children httpd processes. - -
logs/error_log
-by default. The filename can be set using the
-ErrorLog directive; different error logs can
-be set for different virtual hosts.
-
-logs/access_log by default. The filename can be set using a
-TransferLog directive; different
-transfer logs can be set for different virtual
-hosts.
-
-
-
-
diff --git a/docs/manual/misc/FAQ.html b/docs/manual/misc/FAQ.html
index 94d257d6614..330582ffdc6 100644
--- a/docs/manual/misc/FAQ.html
+++ b/docs/manual/misc/FAQ.html
@@ -15,7 +15,7 @@
- $Revision: 1.63 $ ($Date: 1997/06/04 11:42:55 $) + $Revision: 1.63.2.14 $ ($Date: 1997/08/03 08:47:57 $)
The latest version of this FAQ is always available from the main @@ -35,6 +35,11 @@ + + + + +
@@ -51,8 +56,8 @@ - - + + @@ -61,17 +66,19 @@ - - - - - + + + + + + +
struct iovec" when compiling under Linux?-
To address the concerns of a group of WWW providers and part-time httpd programmers that httpd didn't behave as they wanted it to behave. - Apache is an entirely volunteer effort, completely funded by its + Apache is an entirely volunteer effort, completely funded by its members, not by commercial sales. -
@@ -273,7 +342,7 @@ How thoroughly tested is Apache?
- Apache is run on over 400,000 Internet servers (as of April 1997). It has + Apache is run on over 500,000 Internet servers (as of July 1997). It has been tested thoroughly by both developers and users. The Apache Group maintains rigorous standards before releasing new versions of their server, and our server runs without a hitch on over one third of all @@ -380,10 +449,10 @@
Apache tries to be helpful when it encounters a problem. In many
cases, it will provide some details by writing one or messages to
- the server error log. Sometimes this is enough for you to diagnose
+ the server error log. Sometimes this is enough for you to diagnose
& fix the problem yourself (such as file permissions or the like).
- The default location of the error log is
- /usr/local/etc/httpd/logs/error_log, but see the
+ The default location of the error log is
+ /usr/local/etc/httpd/logs/error_log, but see the
ErrorLog
@@ -446,16 +515,12 @@
dump, please include a backtrace (if possible). As an example,
-
-
+
-
-
# cd ServerRoot
+ # dbx httpd core
+ (dbx) where
+ (Substitute the appropriate locations for your @@ -477,7 +542,7 @@ NCSA httpd 1.4 and NCSA httpd 1.5.
- NCSA httpd appears to be moving toward adding experimental features + NCSA httpd appears to be moving toward adding experimental features which are not generally required at the moment. Some of the experiments will succeed while others will inevitably be dropped. The Apache philosophy is to add what's needed as and when it is needed. @@ -515,6 +580,7 @@ >AddHandler directive.
+
The server will then recognize that all files in that location (and its logical descendants) that end in ".cgi" are script files, not documents. +
+ In some situations it can be not conform to your local policy to actually + allow all files named "*.cgi" to be executable. + Perhaps all you want is to enable a particular file in a normal directory to + be executable. This can be alternatively accomplished + via + mod_rewrite + and the following steps: +
++
+
RewriteEngine on
+
+ RewriteBase /~foo/bar/
+
+ RewriteRule ^quux\.cgi$ - [T=application/x-httpd-cgi]
+
It means just what it says: the server was expecting a complete set of
HTTP headers (one or more followed by a blank line), and didn't get
- them. The most common cause of this (aside from people not
- outputting the required headers at all) a result of an interaction
- with perl's output buffering. To make perl flush its buffers
- after each output statement, insert the following statements before your
- first print or write statement:
+ them.
-
-
+ The most common cause of this problem is the script dying before
+ sending the complete set of headers, or possibly any at all, to the
+ server. To see if this is the case, try running the script standalone
+ from an interactive session, rather than as a script under the server.
+ If you get error messages, this is almost certainly the cause of the
+ "premature end of script headers" message.
-
-
- This is generally only necessary when you are calling external
- programs from your script that send output to stdout.
+ The second most common cause of this (aside from people not
+ outputting the required headers at all) is a result of an interaction
+ with Perl's output buffering. To make Perl flush its buffers
+ after each output statement, insert the following statements around
+ the print or write statements that send your
+ HTTP headers:
+
+
{
+ local ($oldbar) = $|;
+ $cfh = select (STDOUT);
+ $| = 1;
+ #
+ # print your HTTP headers here
+ #
+ $| = $oldbar;
+ select ($cfh);
+ }
+
+ This is generally only necessary when you are calling external
+ programs from your script that send output to stdout, or if there will
+ be a long delay between the time the headers are sent and the actual
+ content starts being emitted. To maximize performance, you should
+ turn buffer-flushing back off (with $| = 0 or the
+ equivalent) after the statements that send the headers, as displayed
+ above.
+
If your script isn't written in Perl, do the equivalent thing for
- whatever language you are using (e.g., for C, call
+ whatever language you are using (e.g., for C, call
fflush() after writing the headers).
To enable SSI processing, you need to @@ -695,8 +826,12 @@ Does or will Apache act as a Proxy server?
- Apache version 1.1 and above comes with a proxy module. If compiled - in, this will make Apache act as a caching-proxy server. + Apache version 1.1 and above comes with a + proxy module. + If compiled + in, this will make Apache act as a caching-proxy server.
"Multiviews" is the general name given to the Apache server's ability to provide language-specific document variants in - response to a request. This is documented quite thoroughly in the + response to a request. This is documented quite thoroughly in the
- You are probably running into resource limitations in your
- operating system. The most common limitation is the
- per-process limit on file descriptors,
- which is almost always the cause of problems seen when adding
- virtual hosts. Apache often does not give an intuitive error
- message because it is normally some library routine (such as
- gethostbyname()) which needs file descriptors and
- doesn't complain intelligibly when it can't get them.
+ You are probably running into resource limitations in your
+ operating system. The most common limitation is the
+ per-process limit on file descriptors,
+ which is almost always the cause of problems seen when adding
+ virtual hosts. Apache often does not give an intuitive error
+ message because it is normally some library routine (such as
+ gethostbyname()) which needs file descriptors and
+ doesn't complain intelligibly when it can't get them.
Each log file requires a file descriptor, which means that if you are using separate access and error logs for each virtual host, each - virtual host needs two file descriptors. Each + virtual host needs two file descriptors. Each Listen - directive also needs a file descriptor. + directive also needs a file descriptor.
Typical values for <n> that we've seen are in @@ -760,16 +895,17 @@ Listen - directives. If there are no other servers running on the machine - and all of them are running on the same port, you normally don't - need any Listen directives at all. + directives. If there are no other servers running on the machine + on the same port then you normally don't + need any Listen directives at all. By default Apache listens to + all addresses on port 80. -
Since this is an operating-system limitation, there's not much else available in the way of solutions.
++ As of 1.2.1 we have made attempts to work around various limitations + involving running with many descriptors. + More information is available. +
+ On versions of FreeBSD before 3.0, the FD_SETSIZE define + defaults to 256. This means that you will have trouble usefully using + more than 256 file descriptors in Apache. This can be increased, but + doing so can be tricky. + + If you are using a version prior to 2.2, you need to recompile your + kernel with a larger FD_SETSIZE. This can be done by adding a + line such as: +
+options FD_SETSIZE nnn
+ + To your kernel config file. Starting at version 2.2, this is no + longer necessary. +
++ If you are using a version of 2.1-stable from after 1997/03/10 or + 2.2 or 3.0-current from before 1997/06/28, there is a limit in + the resolver library that prevents it from using more file descriptors + than what FD_SETSIZE is set to when libc is compiled. To increase + this, you have to recompile libc with a higher FD_SETSIZE. +
++ In FreeBSD 3.0, the default FD_SETSIZE has been increased to + 1024 and the above limitation in the resolver library + has been removed. +
++ After you deal with the appropriate changes above, you can increase + the setting of FD_SETSIZE at Apache compilation time + by adding "-DFD_SETSIZE=nnn" to the + EXTRA_CFLAGS line in your Configuration + file. +
+
-
-
+
-
-
<Limit GET>
:
+
- Change that to <Limit GET POST> and the problem
+ Change that to <Limit GET POST> and the problem
will probably go away.
ErrorDocument 401 work?
- You need to use it with a URL in the form "/foo/bar" and not one - with a method and hostname such as "http://host/foo/bar". See the + You need to use it with a URL in the form + "/foo/bar" and not one with a method and + hostname such as "http://host/foo/bar". See the ErrorDocument @@ -908,7 +1093,7 @@
Apache does not send automatically send a cookie on every
- response, unless you have re-compiled it with the
+ response, unless you have re-compiled it with the
mod_cookies
@@ -917,11 +1102,11 @@
This module may help track users, and uses cookies to do this. If
you are not using the data generated by mod_cookies, do
not compile it into Apache. Note that in 1.2 this module was renamed
- to the more correct name
+ to the more correct name
mod_usertrack,
- and cookies
+ and cookies
have to be specifically enabled with the
-
BrowserMatch Java/1.0 force-response-1.0
+ BrowserMatch Java1.0 force-response-1.0
+
+ BrowserMatch JDK/1.0 force-response-1.0
This message almost always indicates that the client disconnected
before Apache reached the point of calling setsockopt()
@@ -1045,6 +1232,20 @@
+ This is a normal message and nothing about which to be alarmed. It simply + means that the client canceled the connection before it had been + completely set up - such as by the end-user pressing the "Stop" + button. People's patience being what it is, sites with response-time + problems or slow network links may experiences this more than + high-capacity ones or those with large pipes to the network. +
+As an example how you might handle the former (in a Perl script):
-
-
- - if ($0 =~ m:/*nph-:) {
-
-
- $HTTP_headers =
- "HTTP/1.1 200 OK\015\012";
-
-
- $HTTP_headers .=
- "Connection: close\015\012";
-
-
- printf ($HTTP_headers);
-
- };
-
-
-
+ +
if ($0 =~ m:^(.*/)*nph-[^/]*$:) {
+
+
+ $HTTP_headers =
+ "HTTP/1.1 200 OK\015\012";
+
+
+ $HTTP_headers .=
+ "Connection: close\015\012";
+
+
+ print $HTTP_headers;
+
+ }
+ and then follow with your normal non-nph headers.
@@ -1105,16 +1306,18 @@struct iovec" when
+ compiling under Linux?
This is a conflict between your C library includes and your kernel includes. You need to make sure that the versions of both are matched properly. There are two workarounds, either one will solve the problem:
+
struct iovec from your C
- library includes. It is located in /usr/include/sys/uio.h.
+ library includes. It is located in /usr/include/sys/uio.h.
Or,
-DNO_WRITEV to the EXTRA_CFLAGS
@@ -1122,6 +1325,7 @@
This hurts performance and should only be used as a last resort.
- In Apache version 1.2 (beginning with 1.2b8), the error log message
+ In Apache version 1.2, the error log message
about dumped core includes the directory where the dump file should be
located. However, many Unixes do not allow a process that has
- called setuid() to dump core for security reasons;
- the typical Apache setup has the server started as root to bind to
- port 80, after which it changes UIDs to a non-privileged user to
+ called setuid() to dump core for security reasons;
+ the typical Apache setup has the server started as root to bind to
+ port 80, after which it changes UIDs to a non-privileged user to
serve requests.
@@ -1183,10 +1387,12 @@ this by adding the -DMAXIMUM_DNS clause to the EXTRA_CFLAGS definition in your Configuration file. For example: +
EXTRA_CFLAGS=-DMAXIMUM_DNS
This will cause Apache to be very paranoid about making sure a particular host address is really assigned to the name it @@ -1207,8 +1413,8 @@ encryption technology. If Apache included SSL in the base package, its distribution would involve all sorts of legal and bureaucratic issues, and it would no longer be freely available. Also, some of - the technology required to talk to current clients using SSL is - patented by RSA Data Security, + the technology required to talk to current clients using SSL is + patented by RSA Data Security, who restricts its use without a license.
@@ -1227,9 +1433,9 @@ >Apache and Secure Transactions.
@@ -1259,10 +1465,12 @@
AddType audio/x-midi .mid .midi .kar
Note that this may break browsers that do recognize the audio/midi MIME type unless they're prepared to also @@ -1275,7 +1483,7 @@
If the server won't compile on your system, it is probably due to one of the following causes: @@ -1304,7 +1512,7 @@ the operating system.
- The Java Development Kit (JDK) libraries versions 1.0.2 and 1.1 do not
- correctly interpret the "HTTP/1.1" response
- header that Apache 1.2 sends. Instead, if they don't see an exact
- match for "HTTP/1.0", they assume the headers
- are part of the document content.
+ If you have installed BIND-8
+ then this is normally due to a conflict between your include files
+ and your libraries. BIND-8 installs its include files and libraries
+ /usr/local/include/ and /usr/local/lib/, while
+ the resolver that comes with your system is probably installed in
+ /usr/include/ and /usr/lib/. If
+ your system uses the header files in /usr/local/include/
+ before those in /usr/include/ but you do not use the new
+ resolver library, then the two versions will conflict.
+
+ To resolve this, you can either make sure you use the include files
+ and libraries that came with your system or make sure to use the
+ new include files and libraries. Adding -lbind to the
+ EXTRA_LDFLAGS line in your Configuration
+ file, then re-running Configure, should resolve the
+ problem. (Apache versions 1.2.* and earlier use
+ EXTRA_LFLAGS instead.)
- This is a known problem, and it has been reported to Sun's JavaSoft - unit. In the meantime, Apache 1.2 servers can work around this by - adding the following lines to their configuration files: + Note:As of BIND 8.1.1, the bind libraries and files are + installed under /usr/local/bind by default, so you + should not run into this problem. Should you want to use the bind + resolvers you'll have to add the following to the respective lines:
+
EXTRA_CFLAGS=-I/usr/local/bind/include
+
+ EXTRA_LDFLAGS=-L/usr/local/bind/lib
+
+ EXTRA_LIBS=-lbind
+ When you access a directory without a trailing "/", Apache needs + to send what is called a redirect to the client to tell it to + add the trailing slash. If it did not do so, relative URLs would + not work properly. When it sends the redirect, it needs to know + the name of the server so that it can include it in the redirect. + There are two ways for Apache to find this out; either it can guess, + or you can tell it. If your DNS is configured correctly, it can + normally guess without any problems. If it is not, however, then + you need to tell it. +
++ Add a ServerName directive + to the config file to tell it what the domain name of the server is. +
++ There are several ways to do this; some of the more popular + ones are to use the mod_auth, + mod_auth_db, or + mod_auth_dbm modules. +
++ For an explanation on how to implement these restrictions, see + Apache Week's + articles on + Using User Authentication + or + DBM User Authentication. +
++ This variable is set and thus available in SSI or CGI scripts if and + only if the requested document was protected by access + authentication. For an explanation on how to implement these restrictions, + see + Apache Week's + articles on + Using User Authentication + or + DBM User Authentication. +
++ Hint: When using a CGI script to receive the data of a HTML FORM + notice that protecting the document containing the FORM is not + sufficient to provide REMOTE_USER to the CGI script. You have + to protect the CGI script, too. Or alternatively only the CGI script (then + authentication happens only after filling out the form). +
+
+ Use the Satisfy directive,
+ in particular the Satisfy Any directive, to require
+ that only one of the access restrictions be met. For example,
+ adding the following configuration to a .htaccess
+ or server configuration file would restrict access to people who
+ either are accessing the site from a host under domain.com or
+ who can supply a valid username and password:
+
+
deny from all
+
+ allow from .domain.com
+
+ AuthType Basic
+
+ AuthUserFile /usr/local/etc/httpd/conf/htpasswd.users
+
+ AuthName special directory
+
+ require valid-user
+
+ satisfy any
+ + See the user authentication + question and the mod_access + module for details on how the above directives work. +
++ The + mod_info + module allows you to use a Web browser to see how your server is + configured. Among the information it displays is the list modules and + their configuration directives. The "current" values for + the directives are not necessarily those of the running server; they + are extracted from the configuration files themselves at the time of + the request. If the files have been changed since the server was last + reloaded, the display will will not match the values actively in use. + If the files and the path to the files are not readable by the user as + which the server is running (see the + User + directive), then mod_info cannot read them in order to + list their values. An entry will be made in the error log in + this event, however. +
+
+ Your kernel has been built without SysV IPC support. You will have to
+ rebuild the kernel with that support enabled (it's under the
+ "General Setup" submenu). Documentation for
+ kernel building is beyond the scope of this FAQ; you should consult
+ the
+ Kernel HOWTO,
+ or the documentation provided with your distribution, or a
+ Linux newsgroup/mailing list.
+ As a last-resort workaround, you can
+ comment out the #define HAVE_SHMGET definition in the
+ LINUX section of
+ src/conf.h and rebuild the server. This will produce
+ a server which is slower and less reliable.
+
+ Under normal circumstances, the Apache access control modules will + pass unrecognized user IDs on to the next access control module in + line. Only if the user ID is recognized and the password is validated + (or not) will it give the usual success or "authentication + failed" messages. +
++ However, if the last access module in line 'declines' the validation + request (because it has never heard of the user ID or because it is not + configured), the http_request handler will give one of + the following, confusing, errors: +
++ This does not mean that you have to add an + 'AuthUserFile /dev/null' line as some magazines suggest! +
++ The solution is to ensure that at least the last module is authoritative + and CONFIGURED. By default, mod_auth is + authoritative and will give an OK/Denied, but only if it is configured + with the proper AuthUserFile. Likewise, if a valid group + is required. (Remember that the modules are processed in the reverse + order from that in which they appear in your compile-time + Configuration file.) +
++ A typical situation for this error is when you are using the + mod_auth_dbm, mod_auth_msql, + mod_auth_mysql, mod_auth_anon or + mod_auth_cookie modules on their own. These are by + default not authoritative, and this will pass the + buck on to the (non-existent) next authentication module when the + user ID is not in their respective database. Just add the appropriate + 'XXXAuthoritative yes' line to the configuration. +
++ In general it is a good idea (though not terribly efficient) to have the + file-based mod_auth a module of last resort. This allows + you to access the web server with a few special passwords even if the + databases are down or corrupted. This does cost a + file open/seek/close for each request in a protected area. +
++ Some organizations feel very strongly about keeping the authentication + information on a different machine than the webserver. With the + mod_auth_msql, mod_auth_mysql, and other SQL + modules connecting to (R)DBMses this is quite possible. Just configure + an explicit host to contact. +
++ Be aware that with mSQL and Oracle, opening and closing these database + connections is very expensive and time consuming. You might want to + look at the code in the auth_* modules and play with the + compile time flags to alleviate this somewhat, if your RDBMS licences + allow for it. +
++ You have probably configured the Host by specifying a FQHN, + and thus the libmsql will use a full blown tcp/ip socket to talk to + the database, rather than a fast internal device. The + libmsql, the mSQL FAQ, and the mod_auth_msql + documentation warn you about this. If you have to use different + hosts, check out the mod_auth_msql code for + some compile time flags which might - or might not - suit you. +
++ There is a collection of + Practical Solutions for URL-Manipulation + where you can + find all typical solutions the author of + mod_rewrite + currently knows of. If you have more + interesting rulesets which solve particular problems not currently covered in + this document, send it to + Ralf S. Engelschall + for inclusion. The + other webmasters will thank you for avoiding the reinvention of the wheel. +
++ There is an article from + Ralf S. Engelschall + about URL-manipulations based on + mod_rewrite + in the "iX Multiuser Multitasking Magazin" issue #12/96. The + german (original) version + can be read online at + http://www.heise.de/ix/artikel/9612149/, + the English (translated) version can be found at + http://www.heise.de/ix/artikel/E/9612149/. +
++ Hmmm... there are a lot of reasons. First, mod_rewrite itself is a powerful + module which can help you in really all aspects of URL rewriting, so + it can be no trivial module per definition. To accomplish its hard job it + uses software leverage and makes use of a powerful regular expression + library by Henry Spencer which is an integral part of Apache since its + version 1.2. And regular expressions itself can be difficult to newbies, + while providing the most flexible power to the advanced hacker. +
++ On the other hand mod_rewrite has to work inside the Apache API environment + and needs to do some tricks to fit there. For instance the Apache API as of + 1.x really was not designed for URL rewriting at the .htaccess + level of processing. Or the problem of multiple rewrites in sequence, which + is also not handled by the API per design. To provide this features + mod_rewrite has to do some special (but API compliant!) handling which leads + to difficult processing inside the Apache kernel. While the user usually + doesn't see anything of this processing, it can be difficult to find + problems when some of your RewriteRules seem not to work. +
++ Use "RewriteLog somefile" and + "RewriteLogLevel 9" and have a precise look at the + steps the rewriting engine performs. This is really the only one and best + way to debug your rewriting configuration. +
++ If the rule starts with /somedir/... make sure that really no + /somedir exists on the filesystem if you don't want to lead the + URL to match this directory, i.e. there must be no root directory named + somedir on the filesystem. Because if there is such a + directory, the URL will not get prefixed with DocumentRoot. This behaviour + looks ugly, but is really important for some other aspects of URL + rewriting. +
++ You can't! The reason is: First, case translations for arbitrary length URLs + cannot be done via regex patterns and corresponding substitutions. One need + a per-character pattern like sed/Perl tr|..|..| feature. Second, just + making URLs always upper or lower case will not resolve the complete problem + of case-INSENSITIVE URLs, because actually the URLs had to be rewritten to + the correct case-variant residing on the filesystem because in later + processing Apache needs to access the file. And Unix filesystem is always + case-SENSITIVE. +
+
+ But there is a module named mod_speling.c (yes, it is named
+ this way!) out there on the net. Try this one.
+
+ Because you have to enable the engine for every virtual host explicitly due + to security concerns. Just add a "RewriteEngine on" to your + virtual host configuration parts. +
++ There is only one ugly solution: You have to surround the complete flag + argument by quotation marks ("[E=...]"). Notice: The argument + to quote here is not the argument to the E-flag, it is the argument of the + Apache config file parser, i.e. the third argument of the RewriteRule here. + So you have to write "[E=any text with whitespaces]". +
++ The Common Gateway Interface (CGI) specification currently lives in at + least two versions: +
++
AuthGroupFile-specified group file
+AuthGroupFile-specified group file
format allows commas between user names - Apache does not.AddType only accepts one file extension per line, without
-any dots (.) in the extension, and does not take full filenames.
-If you need multiple extensions per type, use multiple lines, e.g.
-
-AddType application/foo foo
-AddType application/foo bar
-.foo and .bar to application/foo
-- - +
If you follow the NCSA guidelines for setting up access restrictions
based on client domain, you may well have added entries for,
@@ -62,7 +51,7 @@ To map .foo and .bar to application/foo
AuthUserFile requires a full pathname. In earlier
versions of NCSA httpd and Apache, you could use a filename
relative to the .htaccess file. This could be a major security hole,
- as it made it trivially easy to make a ".htpass" file in the a
+ as it made it trivially easy to make a ".htpass" file in the a
directory easily accessible by the world. We recommend you store
your passwords outside your document tree.
@@ -89,18 +78,32 @@ To map .foo and .bar to application/foo
-
-
+
.asis files: Apache 0.6.5 did not require a Status header;
it added one automatically if the .asis file contained a Location header.
@@ -111,7 +114,19 @@ it added one automatically if the .asis file contained a Location header.
files if the last line does not have a trailing newline. This affects
configuration files (httpd.conf, access.conf and srm.conf), and
htpasswd and htgroup files.
-
+ <VirtualHost> treats all addresses as
+ "optional" (i.e. the server should continue booting if it can't resolve
+ the address). Whereas in NCSA the default is to fail booting unless
+ an added optional keyword is included.
+
+ OnDeny use
+ ErrorDocument
+ instead.
+
A descriptor, also commonly called a file handle is
+an object that a program uses to read or write an open file, or open
+network socket, or a variety of other devices. It is represented
+by an integer, and you may be familiar with stdin,
+stdout, and stderr which are descriptors 0,
+1, and 2 respectively.
+Apache needs a descriptor for each log file, plus one for each
+network socket that it listens on, plus a handful of others. Libraries
+that Apache uses may also require descriptors. Normal programs don't
+open up many descriptors at all, and so there are some latent problems
+that you may experience should you start running Apache with many
+descriptors (i.e. with many virtual hosts).
+
+
The operating system enforces a limit on the number of descriptors +that a program can have open at a time. There are typically three limits +involved here. One is a kernel limitation, depending on your operating +system you will either be able to tune the number of descriptors available +to higher numbers (this is frequently called FD_SETSIZE). Or you +may be stuck with a (relatively) low amount. The second limit is called +the hard resource limit, and it is sometimes set by root in an +obscure operating system file, but frequently is the same as the kernel +limit. The third limit is called the soft +resource limit. The soft limit is always less than or equal to +the hard limit. For example, the hard limit may be 1024, but the soft +limit only 64. Any user can raise their soft limit up to the hard limit. +Root can raise the hard limit up to the system maximum limit. The soft +limit is the actual limit that is used when enforcing the maximum number +of files a process can have open. + +
To summarize: + +
+ #open files <= soft limit <= hard limit <= kernel limit +
You control the hard and soft limits using the limit (csh)
+or ulimit (sh) directives. See the respective man pages
+for more information. For example you can probably use
+ulimit -n unlimited to raise your soft limit up to the
+hard limit. You should include this command in a shell script which
+starts your webserver.
+
+
Unfortunately, it's not always this simple. As mentioned above, +you will probably run into some system limitations that will need to be +worked around somehow. Work was done in version 1.2.1 to improve the +situation somewhat. Here is a partial list of systems and workarounds +(assuming you are using 1.2.1 or later): + +
-DFD_SETSIZE=nnn to
+ EXTRA_CFLAGS (where nnn is the number of descriptors
+ you wish to support, keep it less than the hard limit). But it
+ will run into trouble if more than approximately 240 Listen
+ directives are used. This may be cured by rebuilding your kernel
+ with a higher FD_SETSIZE.
+ + +
FD_SETSIZE and rebuild. But the extra
+ Listen limitation doesn't exist.
+ + +
+ +
-DHIGH_SLACK_LINE=256 added to
+ EXTRA_CFLAGS. You will be limited to approximately
+ 240 error logs if you do this.
+ + +
+ +
+ +
In addition to the problems described above there are problems with +many libraries that Apache uses. The most common example is the bind +DNS resolver library that is used by pretty much every unix, which +fails if it ends up with a descriptor above 256. We suspect there +are other libraries that similar limitations. So the code as of 1.2.1 +takes a defensive stance and tries to save descriptors less than 16 +for use while processing each request. This is called the low +slack line. + +
Note that this shouldn't waste descriptors. If you really are pushing +the limits and Apache can't get a descriptor above 16 when it wants +it, it will settle for one below 16. + +
In extreme situations you may want to lower the low slack line,
+but you shouldn't ever need to. For example, lowering it can
+increase the limits 240 described above under Solaris and BSDI 2.0.
+But you'll play a delicate balancing game with the descriptors needed
+to serve a request. Should you want to play this game, the compile
+time parameter is LOW_SLACK_LINE and there's a tiny
+bit of documentation in the header file httpd.h.
+
+
Finally, if you suspect that all this slack stuff is causing you
+problems, you can disable it. Add -DNO_SLACK to
+EXTRA_CFLAGS and rebuild. But please report it to
+our Bug
+Report Page so that
+we can investigate.
+
+
+