It Worked!
If you can see this, it means that the installation of the Apache software on this system was successful. You may now add content to this directory and replace this page.
If you are seeing this instead of the content you expected, please contact the administrator of the site involved. If you send mail about this to the authors of the Apache software, who almost certainly have nothing to do with this site, your message will be ignored.
The Apache documentation has been included with this distribution.
You are free to use the image below on an Apache-powered web server. Thanks for using Apache!
![[APACHE DOCUMENTATION]](images/sub.gif)
Apache HTTP Server Version 1.2
Setting which addresses and ports Apache uses
When Apache starts, it connects to some port and address on the local machine and waits for incoming requests. By default, it listens to all addresses on the machine, and to the port as specified by the Port directive in the server configuration. However, it can be told to listen to more the one port, or to listen to only selected addresses, or a combination. This is often combined with the Virtual Host feature which determines how Apache responds to different IP addresses, hostnames and ports.
There are two directives used to restrict or specify which addresses and ports Apache listens to.
- BindAddress 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 to more than one address and/or port.
BindAddress
Syntax: BindAddress [ * | IP-address | hostname ]Default:
BindAddress *Context: server config
Status: Core
Makes the server listen to just the specified address. If the argument is *, the server listens to all addresses. The port listened to is set with the Port directive. Only one BindAddress should be used.
Listen
Syntax: Listen [ port | IP-address:port ]Default:
noneContext: server config
Status: Core
Listen can be used instead of BindAddress and Port. It tells the server to accept incoming requests on the specified port or address-and-port combination. If the first format is used, with a port number only, the server listens to the given port on all interfaces, instead of the port given by the Port directive. If an IP address is given as well as a port, the server will listen on the given port and interface.
Multiple Listen directives may be used to specify a number of addresses and ports to listen to. The server will respond to requests from any of the listed addresses and ports.
For example, to make the server accept connections on both port 80 and port 8000, use:
Listen 80 Listen 8000To make the server accept connections on two specified interfaces and port numbers, use
Listen 192.170.2.1:80 Listen 192.170.2.5:8000
How this works with Virtual Hosts
BindAddress and Listen do not implement Virtual Hosts. They tell the main server what addresses and ports to listen to. If no <VirtualHost> directives are used, the server will behave the same for all accepted requests. However, <VirtualHost> can be used to specify a different behavior for one or more of the addresses and ports. To implement a VirtualHost, the server must first be told to listen to the address and port to be used. Then a <VirtualHost> section should be created for a specified address and port to set the behavior of this virtual host. Note that if the <VirtualHost> is set for an address and port that the server is not listening to, it cannot be accessed.See also
See also the documentation on Virtual Hosts, Non-IP virtual hosts, BindAddress directive, Port directive, DNS Issues and <VirtualHost> section.Apache HTTP Server Version 1.2
0707010000fb21000081a400000064000000640000000134b16bd200000f63000000200000001b00000000000000000000002200000004reloc/htdocs/manual/cgi_path.html
Apache HTTP Server Version 1.2
PATH_INFO Changes in the CGI Environment
Overview
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).
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 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.
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
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.
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 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.
Apache HTTP Server Version 1.2
0707010000fb22000081a400000064000000640000000134b16bd200004254000000200000001b00000000000000000000002d00000004reloc/htdocs/manual/content-negotiation.html
Apache HTTP Server Version 1.2
Content Negotiation
Apache's support for content negotiation has been updated to meet the HTTP/1.1 specification. It can choose the best representation of a resource based on the browser-supplied preferences for media type, languages, character set and encoding. It is also implements a couple of features to give more intelligent handling of requests from browsers which send incomplete negotiation information.Content negotiation is provided by the mod_negotiation module, which is compiled in by default.
About Content Negotiation
A resource may be available in several different representations. For example, it might be available in different languages or different media types, or a combination. One way of selecting the most appropriate choice is to give the user an index page, and let them select. However it is often possible for the server to choose automatically. This works because browsers can send as part of each request information about what representations they prefer. For example, a browser could indicate that it would like to see information in French, if possible, else English will do. Browsers indicate their preferences by headers in the request. To request only French representations, the browser would sendAccept-Language: frNote 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.
Negotiation in Apache
In order to negotiate a resource, the server needs to be given information about each of the variants. This is done in one of two ways:- Using a type map (i.e., a
*.varfile) which names the files containing the variants explicitly - Or using a 'MultiViews' search, where the server does an implicit filename pattern match, and chooses from among the results.
Using a type-map file
A type map is a document which is associated with the handler namedtype-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 varin
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, deIf 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: - uri of the file containing the variant (of the given media type, encoded with the given content encoding). These are interpreted as URLs relative to the map file; they must be on the same server (!), and they must refer to files to which the client would be granted access if they were to be requested directly.
-
Content-type: - media type --- charset, level and "qs" parameters may be given. These
are often referred to as MIME types; typical media types are
image/gif,text/plain, ortext/html; level=3. -
Content-language: - The languages of the variant, specified as an Internet standard
language code (e.g.,
enfor English,krfor Korean, etc.). -
Content-encoding: - If the file is compressed, or otherwise encoded, rather than
containing the actual raw data, this says how that was done.
For compressed files (the only case where this generally comes
up), content encoding should be
x-compress, orx-gzip, as appropriate. -
Content-length: - The size of the file. Clients can ask to receive a given media type only if the variant isn't too big; specifying a content length in the map allows the server to compare against these thresholds without checking the actual file.
Multiviews
This is a per-directory option, meaning it can be set with anOptions 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 indexthen 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.
The Negotiation Algorithm
After Apache has obtained a list of the variants for a given resource, either from a type-map file or from the filenames in the directory, it applies a algorithm to decide on the 'best' variant to return, if any. To do this it calculates a quality value for each variant in each of the dimensions of variance. It is not necessary to know any of the details of how negotiation actually takes place in order to use Apache's content negotiation features. However the rest of this document explains in detail the algorithm used for those interested.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.
Dimensions of Negotiation
| 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. |
Apache Negotiation Algorithm
Apache uses an algorithm to select the 'best' variant (if any) to return to the browser. This algorithm is not configurable. It operates like this:
- Firstly, for each dimension of the negotiation, the appropriate Accept header is checked and a quality assigned to this each variant. If the Accept header for any dimension means that this variant is not acceptable, eliminate it. If no variants remain, go to step 4.
- Select the 'best' variant by a process of elimination. Each of
the following tests is applied in order. Any variants not selected at
each stage are eliminated. After each test, if only one variant
remains, it is selected as the best match. If more than one variant
remains, move onto the next test.
- Multiply the quality factor from the Accept header with the quality-of-source factor for this variant's media type, and select the variants with the highest value
- 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
LanguagePrioritydirective (if present), else the order of languages on the Accept-Language header. - Select the variants with the highest 'level' media parameter (used to give the version of text/html media types).
- Select only unencoded variants, if there is a mix of encoded and non-encoded variants. If either all variants are encoded or all variants are not encoded, select all.
- Select only variants with acceptable charset media parameters, as given on the Accept-Charset header line. Charset ISO-8859-1 is always acceptable. Variants not associated with a particular charset are assumed to be in ISO-8859-1.
- Select the variants with the smallest content length
- Select the first variant of those remaining (this will be either the first listed in the type-map file, or the first read from the directory) and go to stage 3.
- The algorithm has now selected one 'best' variant, so return it as the response. The HTTP response header Vary is set to indicate the dimensions of negotiation (browsers and caches can use this information when caching the resource). End.
- To get here means no variant was selected (because non are acceptable to the browser). Return a 406 status (meaning "No acceptable representation") with a response body consisting of an HTML document listing the available variants. Also set the HTTP Vary header to indicate the dimensions of variance.
Fiddling with Quality Values
Apache sometimes changes the quality values from what would be expected by a strict interpretation of the algorithm above. This is to get a better result from the algorithm for browsers which do not send full or accurate information. Some of the most popular browsers send Accept header information which would otherwise result in the selection of the wrong variant in many cases. If a browser sends full and correct information these fiddles will not be applied.
Media Types and Wildcards
The Accept: request header indicates preferences for media types. It can also include 'wildcard' media types, such as "image/*" or "*/*" where the * matches any string. So a request including: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.01The 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.
Variants with no Language
If some of the variants for a particular resource have a language attribute, and some do not, those variants with no language are given a very low language quality factor of 0.001.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:
- foo.en.html, language en
- foo.fr.html, language en
- foo.html, no language
Note on Caching
When a cache stores a document, it associates it with the request URL. The next time that URL is requested, the cache can use the stored document, provided it is still within date. But if the resource is subject to content negotiation at the server, this would result in only the first requested variant being cached, and subsequent cache hits could return the wrong response. To prevent this, Apache normally marks all responses that are returned after content negotiation as non-cacheable by HTTP/1.0 clients. Apache also supports the HTTP/1.1 protocol features to allow caching of negotiated responses.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.
Apache HTTP Server Version 1.2
0707010000fb23000081a400000064000000640000000134b16bd20000132d000000200000001b00000000000000000000002600000004reloc/htdocs/manual/custom-error.html
Apache HTTP Server Version 1.2
Custom error responses
- Purpose
- Additional functionality. Allows webmasters to configure the response of
Apache to some error or problem.
Customizable responses can be defined to be activated in the event of a server detected error or problem.
e.g. if a script crashes and produces a "500 Server Error" response, then this response can be replaced with either some friendlier text or by a redirection to another URL (local or external).
- Old behavior
- NCSA httpd 1.3 would return some boring old error/problem message
which would often be meaningless to the user, and would provide no
means of logging the symptoms which caused it.
- New behavior
- The server can be asked to;
- Display some other text, instead of the NCSA hard coded messages, or
- redirect to a local URL, or
- redirect to an external URL.
Redirecting to another URL can be useful, but only if some information can be passed which can then be used to explain and/or log the error/problem more clearly.
To achieve this, Apache will define new CGI-like environment variables, e.g.
REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg
REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712)
REDIRECT_PATH=.:/bin:/usr/local/bin:/etc
REDIRECT_QUERY_STRING=
REDIRECT_REMOTE_ADDR=121.345.78.123
REDIRECT_REMOTE_HOST=ooh.ahhh.com
REDIRECT_SERVER_NAME=crash.bang.edu
REDIRECT_SERVER_PORT=80
REDIRECT_SERVER_SOFTWARE=Apache/0.8.15
REDIRECT_URL=/cgi-bin/buggy.pl
note the
REDIRECT_prefix.At least
REDIRECT_URLandREDIRECT_QUERY_STRINGwill 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 likehttp:, 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.
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.htmlThe syntax is,
ErrorDocument<3-digit-code> actionwhere the action can be,
- Text to be displayed. Prefix the text with a quote ("). Whatever follows the quote is displayed. Note: the (") prefix isn't displayed.
- An external URL to redirect to.
- A local URL to redirect to.
Custom error responses and redirects
- Purpose
- Apache's behavior to redirected URLs has been modified so that additional
environment variables are available to a script/server-include.
- 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.
- New behavior
-
A new batch of environment variables will be initialized for use by a
script which has been redirected to. Each new variable will have the
prefix
REDIRECT_.REDIRECT_environment variables are created from the CGI environment variables which existed prior to the redirect, they are renamed with aREDIRECT_prefix, i.e.HTTP_USER_AGENTbecomesREDIRECT_HTTP_USER_AGENT. In addition to these new variables, Apache will defineREDIRECT_URLandREDIRECT_STATUSto help the script trace its origin. Both the original URL and the URL being redirected to can be logged in the access log.
Apache HTTP Server Version 1.2
0707010000fb24000081a400000064000000640000000134b16bd200002277000000200000001b00000000000000000000002500000004reloc/htdocs/manual/dns-caveats.html
Apache HTTP Server Version 1.2
Issues Regarding DNS and Apache
This page could be summarized with the statement: don't require Apache to use DNS for any parsing of the configuration files. If Apache has to use DNS to parse the configuration files then your server may be subject to reliability problems (it might not boot), or denial and theft of service attacks (including users able to steal hits from other users).
A Simple Example
Consider this configuration snippet:
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
In order for Apache to function properly it absolutely needs
to have two pieces of information about each virtual host: the
ServerName
and at least one IP address that the server
responds to. This example does not include the IP address, so Apache
must use DNS to find the address of www.abc.dom. If for
some reason DNS is not available at the time your server is parsing its
config file, then this virtual host will not be configured. It
won't be able to respond to any hits to this virtual host (prior to
Apache version 1.2 the server would not even boot).
Suppose that www.abc.dom has address 10.0.0.1. Then
consider this configuration snippet:
<VirtualHost 10.0.0.1>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Now Apache needs to use reverse DNS to find the ServerName
for this virtualhost. If that reverse lookup fails then it will partially
disable the virtualhost (prior to Apache version 1.2 the server would not
even boot). If the virtual host is name-based then it will effectively
be totally disabled, but if it is IP-based then it will mostly work.
However if Apache should ever have to generate a full URL for the server
which includes the server name then it will fail to generate a valid URL.
Here is a snippet that avoids both of these problems.
<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Denial of Service
There are (at least) two forms that denial of service can come in.
If you are running a version of Apache prior to version 1.2 then your
server will not even boot if one of the two DNS lookups mentioned above
fails for any of your virtual hosts. In some cases this DNS lookup may
not even be under your control. For example, if abc.dom
is one of your customers and they control their own DNS then they
can force your (pre-1.2) server to fail while booting simply by deleting the
www.abc.dom record.
Another form is far more insidious. Consider this configuration snippet:
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
<VirtualHost www.def.dom>
ServerAdmin webguy@def.dom
DocumentRoot /www/def
</VirtualHost>
Suppose that you've assigned 10.0.0.1 to www.abc.dom and
10.0.0.2 to www.def.dom. Furthermore, suppose that
def.com has control of their own DNS. With this config
you have put def.com into a position where they can steal
all traffic destined to abc.com. To do so, all they have to
do is set www.def.dom to 10.0.0.1.
Since they control their own DNS you can't stop them from pointing the
www.def.com record wherever they wish.
Requests coming in to 10.0.0.1 (including all those where users typed
in URLs of the form http://www.abc.dom/whatever) will all be
served by the def.com virtual host. To better understand why
this happens requires a more in-depth discussion of how Apache matches
up incoming requests with the virtual host that will serve it. A rough
document describing this is available.
The "main server" Address
The addition of non-IP-based virtual host
support in Apache 1.1 requires Apache to know the IP address(es) of
the host that httpd is running on. To get this address it uses either
the global ServerName (if present) or calls the C function
gethostname (which should return the same as typing
"hostname" at the command prompt). Then it performs a DNS lookup on
this address. At present there is no way to avoid this lookup.
If you fear that this lookup might fail because your DNS server is down
then you can insert the hostname in /etc/hosts (where you
probably already have it so that the machine can boot properly). Then
ensure that your machine is configured to use /etc/hosts
in the event that DNS fails. Depending on what OS you are using this
might be accomplished by editing /etc/resolv.conf, or maybe
/etc/nsswitch.conf.
If your server doesn't have to perform DNS for any other reason
then you might be able to get away with running Apache with the
HOSTRESORDER environment variable set to "local". This all
depends on what OS and resolver libraries you are using. It also affects
CGIs unless you use mod_env
to control the environment. It's best to consult the man pages or FAQs
for your OS.
The _default_ Address
Any address that happens to go to your webserver which doesn't match
the IP address of any of the webservers will be served from the "main" or
"default" server configurations. The "main" server configuration consists
of all those definitions appearing outside of any VirtualHost section.
You may want instead to define a <VirtualHost _default_:*>
which returns 403 or 404 for all hits. (The trailing :*
makes it apply to all ports, which is just a safety measure should you
begin using multiple Listen
directives.)
Tips to Avoid these problems
- use IP addresses in
<VirtualHost> - use IP addresses in
Listen - use IP addresses in
BindAddress - ensure all virtual hosts have an explicit
ServerName - create a
<VirtualHost _default_:*>server that has no pages to serve
Appendix: Future Directions
The situation regarding DNS is highly undesirable. For Apache 1.2 we've attempted to make the server at least continue booting in the event of failed DNS, but it might not be the best we can do. In any event requiring the use of explicit IP addresses in configuration files is highly undesirable in today's Internet where renumbering is a necessity.
A possible work around to the theft of service attack described above would be to perform a reverse DNS lookup on the ip address returned by the forward lookup and compare the two names. In the event of a mismatch the virtualhost would be disabled. This would require reverse DNS to be configured properly (which is something that most admins are familiar with because of the common use of "double-reverse" DNS lookups by FTP servers and TCP wrappers).
In any event it doesn't seem possible to reliably boot a virtual-hosted web server when DNS has failed unless IP addresses are used. Partial solutions such as disabling portions of the configuration might be worse than not booting at all depending on what the webserver is supposed to accomplish.
As HTTP/1.1 is deployed and browsers and proxies start issuing the
Host header it will become possible to avoid the use of
IP-based virtual hosts entirely. In this event a webserver has no requirement
to do DNS lookups during configuration. But as of March 1997 these
features have not been deployed widely enough to be put into use on
critical webservers.
Apache HTTP Server Version 1.2
0707010000fb25000081a400000064000000640000000134b16bd200000663000000200000001b00000000000000000000001d00000004reloc/htdocs/manual/env.html
Apache HTTP Server Version 1.2
Special Purpose Environment Variables
Interoperability problems have led to the introduction of mechanisms to modify the way Apache behaves when talking to particular clients. To make these mechanisms as flexible as possible, they are invoked by defining environment variables, typically with BrowserMatch, though SetEnv and PassEnv could also be used, for example.
nokeepalive
This disables KeepAlive when set. Because of problems with Netscape 2.x and KeepAlive, we recommend the following directive be used:
BrowserMatch Mozilla/2 nokeepalive
force-response-1.0
This forces an HTTP/1.0 response when set. It was originally implemented as a result of a problem with AOL's proxies. Some clients may not behave correctly when given an HTTP/1.1 response, and this can be used to interoperate with them.Apache HTTP Server Version 1.2
0707010000fb26000081a400000064000000640000000134b16bd20000007a000000200000001b00000000000000000000002000000004reloc/htdocs/manual/footer.html Apache HTTP Server Version 1.2
0707010000fb27000081a400000064000000640000000134b16bd200001379000000200000001b00000000000000000000002100000004reloc/htdocs/manual/handler.html
Apache HTTP Server Version 1.2
Apache's Handler Use
What is a Handler
A "handler" is an internal Apache representation of the action to be performed when a file is called. Generally, files have implicit handlers, based on the file type. Normally, all files are simply served by the server, but certain file typed are "handled" 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:
- send-as-is: Send file with HTTP headers as is. (mod_asis)
- cgi-script: Treat the file as a CGI script. (mod_cgi)
- imap-file: Imagemap rule file. (mod_imap)
- server-info: Get the server's configuration information (mod_info)
- server-parsed: Parse for server-side includes (mod_include)
- server-status: Get the server's status report (mod_status)
- type-map: Parse as a type map file for content negotiation (mod_negotiation)
Directives
AddHandler
Syntax: <AddHandler handler-name extension>Context: server config, virtual host, directory, .htaccess
Status: Base
Module: mod_mime
AddHandler maps the filename extension extension to the
handler handler-name. For example, to activate CGI scripts
with the file extension ".cgi", you might use:
AddHandler cgi-script cgi
Once that has been put into your srm.conf or httpd.conf file, any
file ending with ".cgi" will be treated as a CGI
program.
SetHandler
Syntax: <SetHandler handler-name>Context: directory, .htaccess
Status: Base
Module: mod_mime
When placed into an .htaccess file or a
<Directory> or <Location> section,
this directive forces all matching files to be parsed through the
handler given by handler-name. For example, if you had a
directory you wanted to be parsed entirely as imagemap rule files,
regardless of extension, you might put the following into an
.htaccess file in that directory:
SetHandler imap-file
Another example: if you wanted to have the server display a status
report whenever a URL of http://servername/status was
called, you might put the following into access.conf:
<Location /status>
SetHandler server-status
</Location>
Programmer's Note
In order to implement the handler features, an addition has been
made to the Apache API that you may wish to
make use of. Specifically, a new record has been added to the
request_rec structure:
char *handler
If you wish to have your module engage a handler, you need only to
set r->handler to the name of the handler at any time
prior to the invoke_handler stage of the
request. Handlers are implemented as they were before, 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.
Apache HTTP Server Version 1.2
0707010000fb28000081a400000064000000640000000134b16bd200000083000000200000001b00000000000000000000002000000004reloc/htdocs/manual/header.html
Apache HTTP Server Version 1.2
Apache HTTP Server Version 1.2
Apache non-IP Virtual Hosts
See Also: Virtual Host SupportWhat is a Virtual Host
The "Virtual Host" refers to the practice of maintaining more than
one server on one machine, as differentiated by their apparent
hostname. For example, it is often desirable for companies sharing a
web server to have their own domains, with web servers accessible as
www.company1.com and www.company2.com,
without requiring the user to know any extra path information.
Apache was one of the first servers to support virtual hosts right
out of the box, but since the base HTTP (HyperText
Transport Protocol) standard does not allow any method for the server
to determine the hostname it is being addressed as, Apache's virtual
host support has required a separate IP address for each
server. Documentation on using this approach (which still works very
well) is available.
While the approach described above works, with the available IP
address space growing smaller, and the number of domains increasing,
it is not the most elegant solution, and is hard to implement on some
machines. The HTTP/1.1 protocol contains a method for the
server to identify what name it is being addressed as. Apache 1.1 and
later support this approach as well as the traditional
IP-address-per-hostname method.
The benefits of using the new virtual host support is a practically unlimited number of servers, ease of configuration and use, and requires no additional hardware or software. The main disadvantage is that the user's browser must support this part of the protocol. The latest versions of many browsers (including Netscape Navigator 2.0 and later) do, but many browsers, especially older ones, do not. This can cause problems, although a possible solution is addressed below.
Using non-IP Virtual Hosts
Using the new virtual hosts is quite easy, and superficially looks
like the old method. You simply add to one of the Apache configuration
files (most likely httpd.conf or srm.conf)
code similar to the following:
<VirtualHost www.apache.org>
ServerName www.apache.org
DocumentRoot /usr/web/apache
</VirtualHost>
Of course, any additional directives can (and should) be placed
into the <VirtualHost> section. To make this work,
all that is needed is to make sure that the www.apache.org
DNS entry points to the same IP address as the main
server. Optionally, you could simply use that IP address in the
<VirtualHost> entry.
Additionally, many servers may wish to be accessible by more than
one name. For example, the Apache server might want to be accessible
as apache.org, or ftp.apache.org, assuming
the IP addresses pointed to the same server. In fact, one might want it
so that all addresses at apache.org were picked up by the
server. This is possible with the ServerAlias
directive, placed inside the <VirtualHost> section. For
example:
ServerAlias apache.org *.apache.org
Note that you can use * and ? as wild-card
characters.
You also might need ServerAlias if you are serving local users who
do not always include the domain name. For example, if local users are
familiar with typing "www" or "www.physics" then you will need to add
ServerAlias www www.physics. It isn't possible for the
server to know what domain the client uses for their name resolution
because the client doesn't provide that information in the request.
Security Considerations
Apache allows all virtual hosts to be made accessible via theHost: header through all IP interfaces, even those which
are configured to use different IP interfaces. For example, if the
configuration for www.foo.com contained a virtual host
section for www.bar.com, and www.bar.com was
a separate IP interface, such that
non-Host:-header-supporting browsers can use it, as
before with Apache 1.0. If a request is made to
www.foo.com and the request includes the header
Host: www.bar.com, a page from www.bar.com
will be sent.
This is a security concern if you are controlling access to a
particular server based on IP-layer controls, such as from within a
firewall or router. Let's say www.bar.com in the above
example was instead an intra-net server called
private.foo.com, and the router used by foo.com only let
internal users access private.foo.com. Obviously,
Host: header functionality now allows someone who has
access to www.foo.com to get
private.foo.com, if they send a Host:
private.foo.com header. It is important to note that this
condition exists only if you only implement this policy at the IP
layer - all security controls used by Apache (i.e., allow, deny from, etc.) are consistently
respected.
Compatibility with Older Browsers
As mentioned earlier, a majority of browsers do not send the required data for the new virtual hosts to work properly. These browsers will always be sent to the main server's pages. There is a 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:
ServerPath /apache
What does this mean? It means that a request for any file beginning
with "/apache" will be looked for in the Apache
docs. This means that the pages can be accessed as
http://www.apache.org/apache/ for all browsers, although
new browsers can also access it as
http://www.apache.org/.
In order to make this work, put a link on your main server's page
to http://www.apache.org/apache/ (Note: Do not use
http://www.apache.org/ - this would create an endless
loop). Then, in the virtual host's pages, be sure to use either purely
relative links (e.g. "file.html" or
"../icons/image.gif" or links containing the prefacing
/apache/
(e.g. "http://www.apache.org/apache/file.html" or
"/apache/docs/1.1/index.html").
This requires a bit of
discipline, but adherence to these guidelines will, for the most part,
ensure that your pages will work with all browsers, new and old. When
a new browser contacts http://www.apache.org/, they will
be directly taken to the Apache pages. Older browsers will be able to
click on the link from the main server, go to
http://www.apache.org/apache/, and then access the
pages.
Apache HTTP Server Version 1.2
07070100012774000041ed00000064000000640000000234e8a36c00000000000000200000001b00000000000000000000001b00000004reloc/htdocs/manual/images 07070100012775000081a400000064000000640000000132941fac000005b9000000200000001b00000000000000000000002400000004reloc/htdocs/manual/images/home.gif GIF87ad QQ = ] C
ss ` 9 zz i > 00 + 77 " E YY ^ > * E% ? , 11 E c m - E 3 ? / T $$ 3?% ^ ? ? 22
(! ? 8TT 2 ? w b }t . %% { J Nc ! ii :: / E d ? P ?
6&& \\ o , E HH cc ~n U ػ _ # P > ' ;; qq ? 6 & E 4 E& * 50 '' ]] 6 < ] dd
, & r kk ?, ?$ ?" ? 7 ? : rr @
d b h
@S c v a %M S// JJ ^ , d @ H*\ȰBa"Jhн
*LL YI氤ɓ
[|BIM pнѡCۓ'an s(C/QTaIiR2 ؤзf<< !r8d8pǬK7:T. &JE Nǐ#KL2 h2kޜYH7ˠMH8V0m0 aB; ad?sd8Rs.+_ QK ~d J 7<6 WGU *0L1a#(/ 83 eh 0"#nOs$ )썵Р._GȾC< 2p_Q28V.r 0W1$BB!9%no^UEh'pUj^q(#* `$ 0S0i ^j8XZ%. ?_1 ; 0707010000fb2a000081a400000064000000640000000134b16bd200000907000000200000001b00000000000000000000001f00000004reloc/htdocs/manual/index.html
Apache HTTP Server Version 1.2
Apache User's Guide
Release Notes
Apache Reference Manual
- Search the master manual pages for key words
- Compiling and Installing Apache
- Starting Apache
- Stopping or Restarting Apache
- Apache run-time configuration directives
- Apache modules
- Apache's handler use
- Special purpose environment variables
- Highly generalized API to server functionality
- Using SetUserID Execution for CGI
Other Notes
- Frequently Asked Questions list
- How do I? documentation
- Security tips
- Performance hints for heavily loaded web servers.
- Discussion of the FIN_WAIT_2 problem
- Java's 1.0.2 virtual machine and HTTP/1.1
Apache HTTP Server Version 1.2
0707010000fb2b000081a400000064000000640000000134b16bd300002564000000200000001b00000000000000000000002100000004reloc/htdocs/manual/install.html
Apache HTTP Server Version 1.2
Compiling and Installing Apache 1.2
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.Downloading Apache
Information on the latest version of Apache can be found on the Apache web server at http://www.apache.org/. This will list the current release, any more recent beta-test release, together with details of mirror web and anonymous ftp sites.If you downloaded a binary distribution, skip to Installing Apache. Otherwise read the next section for how to compile the server.
Compiling Apache
Compiling Apache consists of three steps: Firstly select which Apache modules you want to include into the server. Secondly create a configuration for your operating system. Thirdly compile the executable.
All configuration of Apache is performed in the src
directory of the Apache distribution. Change into this directory.
-
Select modules to compile into Apache in the
Configurationfile. 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
Configurationfile to see if you need to set any of theRulelines. -
Configure Apache for your operating system. Normally you can just
type run the
Configurescript 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 theConfigurationfile:EXTRA_CFLAGS, LIBS, LFLAGS, INCLUDES.Run the
Configurescript:
(*: 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
Configureto tell it to read an alternative Configuration file, such asConfigure -file Configuration.ai). -
Type
make.
Installing Apache
You will have a binary file calledhttpd 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.
Starting and Stopping the Server
To start the server, simply runhttpd. 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.
Compiling Support Programs
In addition to the mainhttpd 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
Apache HTTP Server Version 1.2
0707010000fb2c000081a400000064000000640000000134b16bd300001272000000200000001b00000000000000000000002500000004reloc/htdocs/manual/install_1_1.html
Apache HTTP Server Version 1.2
Compiling and Installing Apache
Downloading Apache
Information on the latest version of Apache can be found on the Apache web server at http://www.apache.org/. This will list the current release, any more recent beta-test release, together with details of mirror web and anonymous ftp sites.
UnixWare users will want to consult build notes for various UnixWare versions before compiling.Compiling Apache
This release of Apache supports the notion of `optional modules'. However, the server has to know which modules are compiled into it, in order for those modules to be effective; this requires generation of a short bit of code (`modules.c') which simply has a list of them.
If you are satisfied with our standard module set, and expect to
continue to be satisfied with it, then you can just edit the stock
Makefile and compile as you have been doing previously. If you
would
like to select optional modules, however, you need to run the
configuration script.
To do this:
- Edit the file `
Configuration'. This contains the per-machine config settings of the Makefile, and also an additional section at the bottom which lists the modules which have been compiled in, and also names the files containing them. You will need to:- Select a compiler and compilation options as appropriate to your machine.
- Uncomment lines corresponding to those optional modules you wish
to include (among the Module lines at the bottom of the file)
or add new lines corresponding to custom modules you have written.
Note that DBM auth has to be explicitly configured in, if you want it; just uncomment the corresponding line.
- Run the `Configure' script:
This generates new versions of the Makefile and of modules.c. If you want to maintain multiple configurations, you can say, e.g.,% Configure
Using 'Configuration' as config file
%% Configure -file Configuration.ai
Using alternate config file Configuration.ai
% - Type `make'.
The modules we place in the Apache distribution are the ones we have tested and are used regularly by various members of the Apache development group. Additional modules contributed by members or third parties with specific needs or functions are available at <URL:http://www.apache.org/dist/contrib/modules/>. There are instructions on that page for linking these modules into the core Apache code.
Installing Apache
After compilation, you will have a binary called `httpd' in thesrc/ directory. A binary distribution of Apache will supply this
file.
The next step is to edit the configuration files for the server. In
the subdirectory called `conf' you should find distribution versions
of the three configuration files: srm.conf-dist,
access.conf-dist and httpd.conf-dist. Copy them to
srm.conf, access.conf and httpd.conf
respectively.
First edit httpd.conf. This sets up general attributes about the
server; the port number, the user it runs as, etc. Next edit the
srm.conf file; this sets up the root of the document tree,
special functions like server-parsed HTML or internal imagemap parsing, etc.
Finally, edit the access.conf file to at least set the base cases
of access.
Finally, make a call to httpd, with a -f to the full path to the httpd.conf file. I.e., the common case:
/usr/local/etc/apache/src/httpd -f /usr/local/etc/apache/conf/httpd.conf
By default the srm.conf and access.conf files are
located by name; to specifically call them by other names, use the
AccessConfig and
ResourceConfig directives in
httpd.conf.
Apache HTTP Server Version 1.2
0707010000fb2d000081a400000064000000640000000134b16bd30000145f000000200000001b00000000000000000000002200000004reloc/htdocs/manual/invoking.html
Apache HTTP Server Version 1.2
Starting Apache
Invoking Apache
Thehttpd 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.
Command line options
The following options are recognized on the httpd command line:-dserverroot- Set the initial value for the
ServerRoot variable to
serverroot. This can be overridden by the ServerRoot command in the
configuration file. The default is
/usr/local/etc/httpd. -fconfig- Execute the commands in the file config on startup. If
config does not begin with a
/, then it is taken to be a path relative to the ServerRoot. The default isconf/httpd.conf. -X- Run in single-process mode, for internal debugging purposes only; the daemon does not detach from the terminal or fork any children. Do NOT use this mode to provide ordinary web service.
-v- Print the version of httpd, and then exit.
-h- Give a list of directives together with expected arguments and places where the directive is valid. (New in Apache 1.2)
-l- Give a list of all modules compiled into the server.
-?- Print a list of the httpd options, and then exit.
Configuration files
The server will read three files for configuration directives. Any directive may appear in any of these files. The the names of these files are taken to be relative to the server root; this is set by the ServerRoot directive, or the-d command line flag.
Conventionally, the files are:
conf/httpd.conf- Contains directives that control the operation of the server daemon.
The filename may be overridden with the
-fcommand line flag. conf/srm.conf- Contains directives that control the specification of documents that the server can provide to clients. The filename may be overridden with the ResourceConfig directive.
conf/access.conf- Contains directives that control access to documents. The filename may be overridden with the AccessConfig directive.
The server also reads a file containing mime document types; the filename
is set by the TypesConfig directive,
and is conf/mime.types by default.
Log files
security warning
Anyone who can write to the directory where Apache is writing a log file can almost certainly gain access to the uid that the server is started as, which is normally root. Do NOT give people write access to the directory the logs are stored in without being aware of the consequences; see the security tips document for details.pid file
On daemon startup, it saves the process id of the parent httpd process to the filelogs/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.
Error log
The server will log error messages to a log file,logs/error_log
by default. The filename can be set using the
ErrorLog directive; different error logs can
be set for different virtual hosts.
Transfer log
The server will typically log each request to a transfer file,logs/access_log by default. The filename can be set using a
TransferLog directive; different
transfer logs can be set for different virtual
hosts.
Apache HTTP Server Version 1.2
0707010000fb2e000081a400000064000000640000000134b16bd300000c61000000200000001b00000000000000000000002300000004reloc/htdocs/manual/keepalive.html
Apache HTTP Server Version 1.2
Apache Keep-Alive Support
What is Keep-Alive?
The Keep-Alive extension to HTTP, as defined by theHTTP/1.1 draft, allows persistent connections. These
long-lived HTTP sessions allow multiple requests to be send over the
same TCP connection, and in some cases have been shown to result in an
almost 50% speedup in latency times for HTML documents with lots of
images.
Enabling Keep-Alive Support
Apache 1.1 comes with Keep-Alive support on by default, however there are some directives you can use to modify Apache's behavior:Note: Apache 1.2 uses a different syntax for the KeepAlive directive.
KeepAlive
Syntax: KeepAlive max-requestsDefault:
KeepAlive 5Context: server config
Status: Core
This directive enables Keep-Alive support. Set max-requests
to the maximum number of requests you want Apache to entertain per
connection. A limit is imposed to prevent a client from hogging your
server resources. Set this to 0 to disable support.
KeepAliveTimeout
Syntax: KeepAliveTimeout secondsDefault:
KeepAliveTimeout 15Context: server config
Status: Core
The number of seconds Apache will wait for a subsequent request before
closing the connection. Once a request has been received, the timeout
value specified by the Timeout directive
applies.
When Keep-Alive Is Used
In order for Keep-Alive support to be used, first the browser must support it. Many current browsers, including Netscape Navigator 2.0, and Spyglass Mosaic-based browsers (including Microsoft Internet Explorer) do. Note, however, that some Windows 95-based browsers misbehave with Keep-Alive-supporting servers; they may occasionally hang on a connect. This has been observed with several Windows browsers, and occurs when connecting to any Keep-Alive server, not just Apache. Netscape 3.0b5 and later versions are known to work around this problem.However, Keep-Alive support only is active with files where the length is known beforehand. This means that most CGI scripts, server-side included files and directory listings will not use the Keep-Alive protocol. While this should be completely transparent to the end user, it is something the web-master may want to keep in mind.
Apache HTTP Server Version 1.2
0707010000fb2f000081a400000064000000640000000134b16bd300000866000000200000001b00000000000000000000002200000004reloc/htdocs/manual/location.html
Apache HTTP Server Version 1.2
Access Control by URL
The <Location> Directive
Syntax: <Location URL prefix>Context: server config, virtual host
Status: core
The <Location> directive provides for access control by
URL. It is comparable to the <Directory> directive, and
should be matched with a </Location> directive. Directives that
apply to the URL given should be listen
within. <Location> sections are processed in the
order they appear in the configuration file, after the
<Directory> sections and .htaccess files are
read.
Note that, due to the way HTTP functions, URL prefix
should, save for proxy requests, be of the form /path/,
and should not include the http://servername. It doesn't
necessarily have to protect a directory (it can be an individual
file, or a number of files), and can include wild-cards. In a wild-card
string, `?' matches any single character, and `*' matches any
sequences of characters.
This functionality is especially useful when combined with the
SetHandler
directive. For example, to enable status requests, but allow them only
from browsers at foo.com, you might use:
<Location /status>
SetHandler server-status
order deny,allow
deny from all
allow from .foo.com
</Location>
Apache HTTP Server Version 1.2
0707010000fb30000081a400000064000000640000000134b16bd30000086b000000200000001b00000000000000000000002600000004reloc/htdocs/manual/man-template.html
Apache HTTP Server Version 1.2
Module mod_foobar
Add this file as a link in modules.htmlThis module is contained in the
mod_foobar.c file, and
is/is not compiled in by default. It provides for
the foobar feature. Any document with the mime type
foo/bar will be processed by this module.
Add the magic mime type to the list in magic_types.html
Summary
General module documentation here.Directives
Add these directives to the list in directives.html
ADirective
Syntax: ADirective some argsDefault:
ADirective default valueContext: context-list
context-list is where this directive can appear; allowed: server config, virtual host, directory, .htaccessOverride: override
required if the directive is allowed in .htaccess files; the AllowOverride option that allows the directive.Status: status
Core if in core apache, Base if in one of the standard modules, Extension if in an extension module (not compiled in by default) or ExperimentalModule: mod_foobar
The ADirective directive does something.
Apache HTTP Server Version 1.2
07070100012778000041ed00000064000000640000000234e8a36c00000000000000200000001b00000000000000000000001900000004reloc/htdocs/manual/misc 07070100012779000081a400000064000000640000000134b16bd70000ae2f000000200000001b00000000000000000000002200000004reloc/htdocs/manual/misc/API.html
![[APACHE DOCUMENTATION]](../images/sub.gif)
Apache HTTP Server Version 1.2
Apache API notes
These are some notes on the Apache API and the data structures you have to deal with, etc. They are not yet nearly complete, but hopefully, they will help you get your bearings. Keep in mind that the API is still subject to change as we gain experience with it. (See the TODO file for what might be coming). However, it will be easy to adapt modules to any changes that are made. (We have more modules to adapt than you do).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:
- Basic concepts.
- How handlers work
- Resource allocation and resource pools
- Configuration, commands and the like
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
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 a few more stages than NetSite does, as hooks for stuff I thought might be useful in the future). These are:- URI -> Filename translation
- Auth ID checking [is the user who they say they are?]
- Auth access checking [is the user authorized here?]
- Access checking other than auth
- Determining MIME type of the object requested
- `Fixups' --- there aren't any of these yet, but the phase is
intended as a hook for possible extensions like
SetEnv, which don't really fit well elsewhere. - Actually sending a response back to the client.
- Logging the request
- Handle the request, and indicate that it has done so
by returning the magic constant
OK. - Decline to handle the request, by returning the magic
integer constant
DECLINED. In this case, the server behaves in all respects as if the handler simply hadn't been there. - Signal an error, by returning one of the HTTP error codes. This terminates normal handling of the request, although an ErrorDocument may be invoked to try to mop up, and it will be logged in any case.
*/* (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.
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 handles both CGI scripts and theScriptAlias 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 */
};
How handlers work
The sole argument to handlers is arequest_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
The request_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 (viar->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 */
};
Where request_rec structures come from
Mostrequest_rec structures are built by reading an HTTP
request from a client, and filling in the fields. However, there are
a few exceptions:
- If the request is to an imagemap, a type map (i.e., a
*.varfile), 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 newrequest_recfor the new URI, and processing it almost exactly as if the client had requested the new URI directly. - If some handler signaled an error, and an
ErrorDocumentis in scope, the same internal redirect machinery comes into play. - Finally, a handler occasionally needs to investigate `what
would happen if' some other request were run. For instance,
the directory indexing module needs to know what MIME type
would be assigned to a request for each directory entry, in
order to figure out what icon to use.
Such handlers can construct a sub-request, using the functions
sub_req_lookup_fileandsub_req_lookup_uri; this constructs a newrequest_recstructure 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).
Handling requests, declining, and returning error codes
As discussed above, each handler, when invoked to handle a particularrequest_rec, has to return an int to
indicate what happened. That can either be
- OK --- the request was handled successfully. This may or may not terminate the phase.
- DECLINED --- no erroneous condition exists, but the module declines to handle the phase; the server tries to find another.
- an HTTP error code, which aborts handling of the request.
REDIRECT, then
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
Handlers for most phases do their work by simply setting a few fields in therequest_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).
Special considerations for authentication handlers
Stuff that should be discussed here in detail:- Authentication-phase handlers not invoked unless auth is configured for the directory.
- Common auth configuration stored in the core per-dir
configuration; it has accessors
auth_type,auth_name, andrequires. - Common routines, to handle the protocol end of things, at least
for HTTP basic authentication (
get_basic_auth_pw, which sets theconnection->userstructure field automatically, andnote_basic_auth_failure, which arranges for the properWWW-Authenticate:header to be sent back).
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 redirects into a list ofrequest_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).
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, open files, etc.), without subsequently releasing them. The resource pool machinery is designed to make it easy to prevent this from happening, by allowing resource to be allocated in such a way that they are automatically released when the server is done with them.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.
Allocation of memory in pools
Memory is allocated to pools by calling the functionpalloc, 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).
Allocating initialized memory
There are functions which allocate initialized memory, and are frequently useful. The functionpcalloc 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".
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 routine which is typically used for this ispfopen, 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).
Other sorts of resources --- cleanup functions
More text goes here. Describe the the cleanup primitives in terms of which the file stuff is implemented; also,spawn_process.
Fine control --- creating and dealing with sub-pools, with a note on sub-requests
On rare occasions, too-free use ofpalloc() 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).
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 configuration files, to process all the directives therein correctly, and in general to be a drop-in replacement for NCSA. On the other hand, another design goal was to move as much of the server's functionality into modules which have as little as possible to do with the monolithic server core. The only way to reconcile these goals is to move the handling of most commands from the central server into the modules.
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.
Per-directory configuration structures
Let's look out how all of this plays out inmod_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.
Command handling
Now that we have these structures, we need to be able to figure out how to fill them. That involves processing the actualAddType 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:
- The name of the command
- The function which handles it
- a
(void *)pointer, which is passed in thecmd_parmsstructure to the command handler --- this is useful in case many similar commands are handled by the same function. - A bit mask indicating where the command may appear. There are
mask bits corresponding to each
AllowOverrideoption, and an additional mask bit,RSRC_CONF, indicating that the command may appear in the server's own config files, but not in any.htaccessfile. - A flag indicating how many arguments the command handler wants
pre-parsed, and how they should be passed in.
TAKE2indicates two pre-parsed arguments. Other options areTAKE1, which indicates one pre-parsed argument,FLAG, which indicates that the argument should beOnorOff, 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 alsoITERATE, which means that the handler looks the same asTAKE1, but that if multiple arguments are present, it should be called multiple times, and finallyITERATE2, which indicates that the command handler looks like aTAKE2, but if more arguments are present, then it should be called multiple times, holding the first argument constant. - Finally, we have a string which describes the arguments that
should be present. If the arguments in the actual config file
are not as required, this string will be used to help give a
more specific error message. (You can safely leave this
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;
}
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 function and a merge function, the latter being invoked where a virtual server has partially overridden the base server configuration, and a combined structure must be computed. (As with per-directory configuration, the default if no merge function is specified, and a module is configured in some virtual server, is that the base configuration is simply ignored).
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;
}
Apache HTTP Server Version 1.2
0707010001277a000081a400000064000000640000000134b16bd700012a5c000000200000001b00000000000000000000002200000004reloc/htdocs/manual/misc/FAQ.html
Apache HTTP Server Version 1.2
Apache Server Frequently Asked Questions
$Revision: 1.63.2.16 $ ($Date: 1997/11/02 00:19:21 $)
The latest version of this FAQ is always available from the main Apache web site, at <http://www.apache.org/docs/misc/FAQ>.
If you are reading a text-only version of this FAQ, you may find numbers enclosed in brackets (such as "[12]"). These refer to the list of reference URLs to be found at the end of the document. These references do not appear, and are not needed, for the hypertext version.
The Questions
- Background
- What is Apache?
- Why was Apache created?
- How does The Apache Group's work relate to other servers?
- Why the name "Apache"?
- OK, so how does Apache compare to other servers?
- How thoroughly tested is Apache?
- What are the future plans for Apache?
- Whom do I contact for support?
- Is there any more information on Apache?
- Where can I get Apache?
- Technical Questions
- "Why can't I ...? Why won't ... work?" What to do in case of problems
- How compatible is Apache with my existing NCSA 1.3 setup?
- How do I enable CGI execution in directories other than the ScriptAlias?
- What does it mean when my CGIs fail with "Premature end of script headers"?
- How do I enable SSI (parsed HTML)?
- Why don't my parsed files get cached?
- How can I have my script output parsed?
- Does or will Apache act as a Proxy server?
- What are "multiviews"?
- Why can't I run more than <n> virtual hosts?
- Can I increase FD_SETSIZE on FreeBSD?
- Why do I keep getting "access denied" for form POST requests?
- Can I use my /etc/passwd file for Web page authentication?
- Why doesn't my
ErrorDocument 401work? - Why do I get "setgid: Invalid argument" at startup?
- Why does Apache send a cookie on every response?
- Why don't my cookies work, I even compiled in mod_cookies?
- Why do my Java app[let]s give me plain text when I request an URL from an Apache server?
- Why can't I publish to my Apache server using PUT on Netscape Gold and other programs?
- Why isn't FastCGI included with Apache any more?
- Why am I getting "httpd: could not set socket option TCP_NODELAY" in my error log?
- Why am I getting "connection reset by peer" in my error log?
- How can I get my script's output without Apache buffering it?
- Why do I get complaints about redefinition
of "
struct iovec" when compiling under Linux? - The errorlog says Apache dumped core, but where's the dump file?
- Why isn't restricting access by host or domain name working correctly?
- Why doesn't Apache include SSL?
- Why do I get core dumps under HPUX using HP's ANSI C compiler?
- How do I get Apache to send a MIDI file so the browser can play it?
- Why won't Apache compile with my system's cc?
- How do I add browsers and referrers to my logs?
- Why do I get an error about an undefined reference to "__inet_ntoa" or other __inet_* symbols?
- Why does accessing directories only work when I include the trailing "/" (e.g., http://foo.domain.com/~user/) but not when I omit it (e.g., http://foo.domain.com/~user)?
- How do I set up Apache to require a username and password to access certain documents?
- Why is the environment variable REMOTE_USER not set?
- How do I set up Apache to allow access to certain documents only if a site is either a local site or the user supplies a password and username?
- Why doesn't mod_info list any directives?
- When I run it under Linux I get "shmget: function not found", what should I do?
- Why does my authentication give me a server error?
- Do I have to keep the (mSQL) authentication information on the same machine?
- Why is my mSQL authentication terribly slow?
- Where can I find mod_rewrite rulesets which already solve particular URL-related problems?
- Where can I find any published information about URL-manipulations and mod_rewrite?
- Why is mod_rewrite so difficult to learn and seems so complicated?
- What can I do if my RewriteRules don't work as expected?
- Why don't some of my URLs get prefixed with DocumentRoot when using mod_rewrite?
- How can I make all my URLs case-insensitive with mod_rewrite?
- Why are RewriteRules in my VirtualHost parts ignored?
- How can I use strings with whitespaces in RewriteRule's ENV flag?
- Where can I find the "CGI specification"?
The Answers
Background
-
What is Apache?
Apache was originally based on code and ideas found in the most popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It has since evolved into a far superior system which can rival (and probably surpass) almost any other UNIX based HTTP server in terms of functionality, efficiency and speed.
Since it began, it has been completely rewritten, and includes many new features. Apache is, as of January 1997, the most popular WWW server on the Internet, according to the Netcraft Survey.
-
Why was Apache created?
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 members, not by commercial sales.
-
How does The Apache Group's work relate to other
server efforts, such as NCSA's?
We, of course, owe a great debt to NCSA and their programmers for making the server Apache was based on. We now, however, have our own server, and our project is mostly our own. The Apache Project is an entirely independent venture.
-
Why the name "Apache"?
A cute name which stuck. Apache is "A PAtCHy server". It was based on some existing code and a series of "patch files".
-
OK, so how does Apache compare to other servers?
For an independent assessment, see Web Compare's comparison chart.
Apache has been shown to be substantially faster than many other free servers. Although certain commercial servers have claimed to surpass Apache's speed (it has not been demonstrated that any of these "benchmarks" are a good way of measuring WWW server speed at any rate), we feel that it is better to have a mostly-fast free server than an extremely-fast server that costs thousands of dollars. Apache is run on sites that get millions of hits per day, and they have experienced no performance difficulties.
-
How thoroughly tested is Apache?
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 WWW servers available on the Internet. When bugs do show up, we release patches and new versions as soon as they are available.
The Apache project's web site includes a page with a partial list of sites running Apache.
-
What are the future plans for Apache?
- to continue as a public domain HTTP server,
- to keep up with advances in HTTP protocol and web developments in general,
- to collect suggestions for fixes/improvements from its users,
- to respond to needs of large volume providers as well as occasional users.
-
Whom do I contact for support?
There is no official support for Apache. None of the developers want to be swamped by a flood of trivial questions that can be resolved elsewhere. Bug reports and suggestions should be sent via the bug report page. Other questions should be directed to the comp.infosystems.www.servers.unix newsgroup, where some of the Apache team lurk, in the company of many other httpd gurus who should be able to help.
Commercial support for Apache is, however, available from a number of third parties.
-
Is there any more information available on
Apache?
Indeed there is. See the main Apache web site. There is also a regular electronic publication called Apache Week available. Links to relevant Apache Week articles are included below where appropriate.
-
Where can I get Apache?
You can find out how to download the source for Apache at the project's main web page.
Technical Questions
-
"Why can't I ...? Why won't ... work?" What to
do in case of problems
If you are having trouble with your Apache server software, you should take the following steps:
- Check the errorlog!
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 & 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 ErrorLog directive in your config files for the location on your server.
- Check the
FAQ!
The latest version of the Apache Frequently-Asked Questions list can always be found at the main Apache web site.
- Check the Apache bug database
Most problems that get reported to The Apache Group are recorded in the bug database. Please check the existing reports, open and closed, before adding one. If you find that your issue has already been reported, please don't add a "me, too" report. If the original report isn't closed yet, we suggest that you check it periodically. You might also consider contacting the original submitter, because there may be an email exchange going on about the issue that isn't getting recorded in the database.
- Ask in the comp.infosystems.www.servers.unix
USENET newsgroup
A lot of common problems never make it to the bug database because there's already high Q&A traffic about them in the comp.infosystems.www.servers.unix newsgroup. Many Apache users, and some of the developers, can be found roaming its virtual halls, so it is suggested that you seek wisdom there. The chances are good that you'll get a faster answer there than from the bug database, even if you don't see your question already posted.
- If all else fails, report the problem in the bug
database
If you've gone through those steps above that are appropriate and have obtained no relief, then please do let The Apache Group know about the problem by logging a bug report.
If your problem involves the server crashing and generating a core dump, please include a backtrace (if possible). As an example,
# cd ServerRoot
# dbx httpd core
(dbx) where
(Substitute the appropriate locations for your ServerRoot and your httpd and core files. You may have to use
gdbinstead ofdbx.)
- Check the errorlog!
-
How compatible is Apache with my existing NCSA 1.3
setup?
Apache attempts to offer all the features and configuration options of NCSA httpd 1.3, as well as many of the additional features found in NCSA httpd 1.4 and NCSA httpd 1.5.
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.
Friendly interaction between Apache and NCSA developers should ensure that fundamental feature enhancements stay consistent between the two servers for the foreseeable future.
-
How do I enable CGI execution in directories other than
the ScriptAlias?
Apache recognizes all files in a directory named as a ScriptAlias as being eligible for execution rather than processing as normal documents. This applies regardless of the file name, so scripts in a ScriptAlias directory don't need to be named "*.cgi" or "*.pl" or whatever. In other words, all files in a ScriptAlias directory are scripts, as far as Apache is concerned.
To persuade Apache to execute scripts in other locations, such as in directories where normal documents may also live, you must tell it how to recognize them - and also that it's okay to execute them. For this, you need to use something like the AddHandler directive.
- In an appropriate section of your server configuration files, add
a line such as
AddHandler cgi-script .cgi
The server will then recognize that all files in that location (and its logical descendants) that end in ".cgi" are script files, not documents.
- Make sure that the directory location is covered by an Options declaration that includes the ExecCGI option.
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:
- Locally add to the corresponding .htaccess file a ruleset
similar to this one:
RewriteEngine on
RewriteBase /~foo/bar/
RewriteRule ^quux\.cgi$ - [T=application/x-httpd-cgi]
- Make sure that the directory location is covered by an Options declaration that includes the ExecCGI and FollowSymLinks option.
- In an appropriate section of your server configuration files, add
a line such as
-
What does it mean when my CGIs fail with
"Premature end of script headers"?
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 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.
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
printorwritestatements 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
$| = 0or 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
fflush()after writing the headers).
-
How do I enable SSI (parsed HTML)?
SSI (an acronym for Server-Side Include) directives allow static HTML documents to be enhanced at run-time (e.g., when delivered to a client by Apache). The format of SSI directives is covered in the mod_include manual; suffice it to say that Apache supports not only SSI but xSSI (eXtended SSI) directives.
Processing a document at run-time is called parsing it; hence the term "parsed HTML" sometimes used for documents that contain SSI instructions. Parsing tends to be extremely resource-consumptive, and is not enabled by default. It can also interfere with the cachability of your documents, which can put a further load on your server. (see the next question for more information about this.)
To enable SSI processing, you need to
- Build your server with the mod_include module. This is normally compiled in by default.
- Make sure your server configuration files have an Options directive which permits Includes.
- Make sure that the directory where you want the SSI documents to
live is covered by the "server-parsed" content handler,
either explicitly or in some ancestral location. That can be done
with the following
AddHandler
directive:
AddHandler server-parsed .shtml
For additional information, see the Apache Week article on Using Server Side Includes.
-
Why don't my parsed files get cached?
Since the server is performing run-time processing of your SSI directives, which may change the content shipped to the client, it can't know at the time it starts parsing what the final size of the result will be, or whether the parsed result will always be the same. This means that it can't generate Content-Length or Last-Modified headers. Caches commonly work by comparing the Last-Modified of what's in the cache with that being delivered by the server. Since the server isn't sending that header for a parsed document, whatever's doing the caching can't tell whether the document has changed or not - and so fetches it again to be on the safe side.
You can work around this in some cases by causing an Expires header to be generated. (See the mod_expires documentation for more details.) Another possibility is to use the XBitHack Full mechanism, which tells Apache to send (under certain circumstances detailed in the XBitHack directive description) a Last-Modified header based upon the last modification time of the file being parsed. Note that this may actually be lying to the client if the parsed file doesn't change but the SSI-inserted content does; if the included content changes often, this can result in stale copies being cached.
-
How can I have my script output parsed?
So you want to include SSI directives in the output from your CGI script, but can't figure out how to do it? The short answer is "you can't." This is potentially a security liability and, more importantly, it can not be cleanly implemented under the current server API. The best workaround is for your script itself to do what the SSIs would be doing. After all, it's generating the rest of the content.
This is a feature The Apache Group hopes to add in the next major release after 1.2.
-
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.
-
What are "multiviews"?
"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 content negotiation description page. In addition, Apache Week carried an article on this subject entitled "Content Negotiation Explained".
-
Why can't I run more than <n>
virtual hosts?
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 Listen directive also needs a file descriptor.
Typical values for <n> that we've seen are in the neighborhood of 128 or 250. When the server bumps into the file descriptor limit, it may dump core with a SIGSEGV, it might just hang, or it may limp along and you'll see (possibly meaningful) errors in the error log. One common problem that occurs when you run into a file descriptor limit is that CGI scripts stop being executed properly.
As to what you can do about this:
- Reduce the number of Listen 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.
- Reduce the number of log files. You can use mod_log_config to log all requests to a single log file while including the name of the virtual host in the log file. You can then write a script to split the logfile into separate files later if necessary.
- Increase the number of file descriptors available to the server
(see your system's documentation on the
limitorulimitcommands). For some systems, information on how to do this is available in the performance hints page. There is a specific note for FreeBSD below. - "Don't do that" - try to run with fewer virtual hosts
- Spread your operation across multiple server processes (using Listen for example, but see the first point) and/or ports.
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.
-
Can I increase FD_SETSIZE on FreeBSD?
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.
-
Why do I keep getting "access denied" for form POST
requests?
The most common cause of this is a <Limit> section that only names the GET method. Look in your configuration files for something that resembles the following and would affect the location where the POST-handling script resides:
<Limit GET>
:
Change that to
<Limit GET POST>and the problem will probably go away.
-
Can I use my /etc/passwd file
for Web page authentication?
Yes, you can - but it's a very bad idea. Here are some of the reasons:
- The Web technology provides no governors on how often or how rapidly password (authentication failure) retries can be made. That means that someone can hammer away at your system's root password using the Web, using a dictionary or similar mass attack, just as fast as the wire and your server can handle the requests. Most operating systems these days include attack detection (such as n failed passwords for the same account within m seconds) and evasion (breaking the connection, disabling the account under attack, disabling all logins from that source, et cetera), but the Web does not.
- An account under attack isn't notified (unless the server is heavily modified); there's no "You have 19483 login failures" message when the legitimate owner logs in.
- Without an exhaustive and error-prone examination of the server logs, you can't tell whether an account has been compromised. Detecting that an attack has occurred, or is in progress, is fairly obvious, though - if you look at the logs.
- Web authentication passwords (at least for Basic authentication) generally fly across the wire, and through intermediate proxy systems, in what amounts to plain text. "O'er the net we go/Caching all the way;/O what fun it is to surf/Giving my password away!"
- Since HTTP is stateless, information about the authentication is transmitted each and every time a request is made to the server. Essentially, the client caches it after the first successful access, and transmits it without asking for all subsequent requests to the same server.
- It's relatively trivial for someone on your system to put up a page that will steal the cached password from a client's cache without them knowing. Can you say "password grabber"?
If you still want to do this in light of the above disadvantages, the method is left as an exercise for the reader. It'll void your Apache warranty, though, and you'll lose all accumulated UNIX guru points.
-
Why doesn't my
ErrorDocument 401work?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 documentation for details. This was incorrectly documented in the past.
-
Why do I get "setgid: Invalid
argument" at startup?
Your Group directive (probably in conf/httpd.conf) needs to name a group that actually exists in the /etc/group file (or your system's equivalent).
-
Why does Apache send a cookie on every response?
Apache does not send automatically send a cookie on every response, unless you have re-compiled it with the mod_cookies module. This module was distributed with Apache prior to 1.2. 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 mod_usertrack, and cookies have to be specifically enabled with the CookieTracking directive.
-
Why don't my cookies work, I even compiled in
mod_cookies?
Firstly, you do not need to compile in mod_cookies in order for your scripts to work (see the previous question for more about mod_cookies). Apache passes on your Set-Cookie header fine, with or without this module. If cookies do not work it will be because your script does not work properly or your browser does not use cookies or is not set-up to accept them.
-
Why do my Java app[let]s give me plain text when I request
an URL from an Apache server?
As of version 1.2, Apache is an HTTP/1.1 (HyperText Transfer Protocol version 1.1) server. This fact is reflected in the protocol version that's included in the response headers sent to a client when processing a request. Unfortunately, low-level Web access classes included in the Java Development Kit (JDK) version 1.0.2 expect to see the version string "HTTP/1.0" and do not correctly interpret the "HTTP/1.1" value Apache is sending (this part of the response is a declaration of what the server can do rather than a declaration of the dialect of the response). The result is that the JDK methods do not correctly parse the headers, and include them with the document content by mistake.
This is definitely a bug in the JDK 1.0.2 foundation classes from Sun, and it has been fixed in version 1.1. However, the classes in question are part of the virtual machine environment, which means they're part of the Web browser (if Java-enabled) or the Java environment on the client system - so even if you develop your classes with a recent JDK, the eventual users might encounter the problem. The classes involved are replaceable by vendors implementing the Java virtual machine environment, and so even those that are based upon the 1.0.2 version may not have this problem.
In the meantime, a workaround is to tell Apache to "fake" an HTTP/1.0 response to requests that come from the JDK methods; this can be done by including a line such as the following in your server configuration files:
BrowserMatch Java1.0 force-response-1.0
BrowserMatch JDK/1.0 force-response-1.0
More information about this issue can be found in the Java and HTTP/1.1 page at the Apache web site.
-
Why can't I publish to my Apache server using PUT on
Netscape Gold and other programs?
Because you need to install and configure a script to handle the uploaded files. This script is often called a "PUT" handler. There are several available, but they may have security problems. Using FTP uploads may be easier and more secure, at least for now. For more information, see the Apache Week article Publishing Pages with PUT.
-
Why isn't FastCGI included with Apache any more?
The simple answer is that it was becoming too difficult to keep the version being included with Apache synchronized with the master copy at the FastCGI web site. When a new version of Apache was released, the version of the FastCGI module included with it would soon be out of date.
You can still obtain the FastCGI module for Apache from the master FastCGI web site.
-
Why am I getting "httpd: could not set socket
option TCP_NODELAY" in my error log?
This message almost always indicates that the client disconnected before Apache reached the point of calling
setsockopt()for the connection. It shouldn't occur for more than about 1% of the requests your server handles, and it's advisory only in any case.
-
Why am I getting "connection reset by
peer" in my error log?
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.
-
How can I get my script's output without Apache buffering
it?
In order to improve network performance, Apache buffers script output into relatively large chunks. If you have a script that sends information in bursts (such as partial-done messages in a multi-commit database transaction, perhaps), the client will not necessarily get the output as the script is generating it.
To avoid this, Apache recognizes scripts whose names begin with "nph-" as non-parsed-header scripts. That is, Apache won't buffer their output, but connect it directly to the socket going back to the client.
While this will probably do what you want, there are some disadvantages to it:
- YOU (the script) are responsible for generating ALL of the HTTP headers, and no longer just the "Content-type" or "Location" headers
- Unless your script generates its output carefully, you will see a performance penalty as excessive numbers of packets go back and forth
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";
print $HTTP_headers;
}
and then follow with your normal non-nph headers.
-
Why do I get complaints about redefinition
of "
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:
- Remove the definition of
struct iovecfrom your C library includes. It is located in/usr/include/sys/uio.h. Or, - Add
-DNO_WRITEVto theEXTRA_CFLAGSline in your Configuration and reconfigure/rebuild. This hurts performance and should only be used as a last resort.
- Remove the definition of
-
The errorlog says Apache dumped core, but where's the dump
file?
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 serve requests.Dealing with this is extremely operating system-specific, and may require rebuilding your system kernel. Consult your operating system documentation or vendor for more information about whether your system does this and how to bypass it. If there is a documented way of bypassing it, it is recommended that you bypass it only for the httpd server process if possible.
The canonical location for Apache's core-dump files is the ServerRoot directory.
-
Why isn't restricting access by host or domain name
working correctly?
Two of the most common causes of this are:
- An error, inconsistency, or unexpected mapping in the DNS
registration
This happens frequently: your configuration restricts access to Host.FooBar.Com, but you can't get in from that host. The usual reason for this is that Host.FooBar.Com is actually an alias for another name, and when Apache performs the address-to-name lookup it's getting the real name, not Host.FooBar.Com. You can verify this by checking the reverse lookup yourself. The easiest way to work around it is to specify the correct host name in your configuration. - Inadequate checking and verification in your
configuration of Apache
If you intend to perform access checking and restriction based upon the client's host or domain name, you really need to configure Apache to double-check the origin information it's supplied. You do 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 claims to be. Note that this can incur a significant performance penalty, however, because of all the name resolution requests being sent to a nameserver.
- An error, inconsistency, or unexpected mapping in the DNS
registration
-
Why doesn't Apache include SSL?
SSL (Secure Socket Layer) data transport requires encryption, and many governments have restrictions upon the import, export, and use of 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, who restricts its use without a license.
Some SSL implementations of Apache are available, however; see the "related projects" page at the main Apache web site.
You can find out more about this topic in the Apache Week article about Apache and Secure Transactions.
-
Why do I get core dumps under HPUX using HP's ANSI
C compiler?
We have had numerous reports of Apache dumping core when compiled with HP's ANSI C compiler using optimization. Disabling the compiler optimization has fixed these problems.
-
How do I get Apache to send a MIDI file so the browser can
play it?
Even though the registered MIME type for MIDI files is audio/midi, some browsers are not set up to recognize it as such; instead, they look for audio/x-midi. There are two things you can do to address this:
- Configure your browser to treat documents of type audio/midi correctly. This is the type that Apache sends by default. This may not be workable, however, if you have many client installations to change, or if some or many of the clients are not under your control.
- Instruct Apache to send a different Content-type
header for these files by adding the following line to your server's
configuration files:
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 handle audio/x-midi the same way.
-
Why won't Apache compile with my system's
cc?
If the server won't compile on your system, it is probably due to one of the following causes:
- The Configure script doesn't recognize your system
environment.
This might be either because it's completely unknown or because the specific environment (include files, OS version, et cetera) isn't explicitly handled. If this happens, you may need to port the server to your OS yourself. - Your system's C compiler is garbage.
Some operating systems include a default C compiler that is either not ANSI C-compliant or suffers from other deficiencies. The usual recommendation in cases like this is to acquire, install, and use gcc. - Your include files may be confused.
In some cases, we have found that a compiler installation or system upgrade has left the C header files in an inconsistent state. Make sure that your include directory tree is in sync with the compiler and the operating system. - Your operating system or compiler may be out of
revision.
Software vendors (including those that develop operating systems) issue new releases for a reason; sometimes to add functionality, but more often to fix bugs that have been discovered. Try upgrading your compiler and/or your operating system.
The Apache Group tests the ability to build the server on many different platforms. Unfortunately, we can't test all of the OS platforms there are. If you have verified that none of the above issues is the cause of your problem, and it hasn't been reported before, please submit a problem report. Be sure to include complete details, such as the compiler & OS versions and exact error messages.
- The Configure script doesn't recognize your system
environment.
-
How do I add browsers and referrers to my logs?
Apache provides a couple of different ways of doing this. The recommended method is to compile the mod_log_config module into your configuration and use the CustomLog directive.
You can either log the additional information in files other than your normal transfer log, or you can add them to the records already being written. For example:
CustomLog logs/access_log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\""This will add the values of the User-agent: and Referer: headers, which indicate the client and the referring page, respectively, to the end of each line in the access log.
You may want to check out the Apache Week article entitled: "Gathering Visitor Information: Customising Your Logfiles".
-
Why do I get an error about an undefined reference to
"__inet_ntoa" or other
__inet_* symbols?
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
-lbindto theEXTRA_LDFLAGSline in your Configuration file, then re-running Configure, should resolve the problem. (Apache versions 1.2.* and earlier useEXTRA_LFLAGSinstead.)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
-
Why does accessing directories only work when I include
the trailing "/"
(e.g., http://foo.domain.com/~user/)
but not when I omit it
(e.g., http://foo.domain.com/~user)?
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.
-
How do I set up Apache to require a username and
password to access certain documents?
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.
-
Why is the environment variable
REMOTE_USER not set?
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).
-
How do I set up Apache to allow access to certain
documents only if a site is either a local site or
the user supplies a password and username?
Use the Satisfy directive, in particular the
Satisfy Anydirective, 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.
-
Why doesn't mod_info list any directives?
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.
-
When I run it under Linux I get "shmget:
function not found", what should I do?
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_SHMGETdefinition in the LINUX section of src/conf.h and rebuild the server. This will produce a server which is slower and less reliable.
-
Why does my authentication give me a server error?
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:
- check access
- check user. No user file?
- check access. No groups file?
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.
-
Do I have to keep the (mSQL) authentication information
on the same machine?
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.
-
Why is my mSQL authentication terribly slow?
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.
-
Where can I find mod_rewrite rulesets which already solve
particular URL-related problems?
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.
-
Where can I find any published information about URL-manipulations and
mod_rewrite?
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/.
-
Why is mod_rewrite so difficult to learn and seems so
complicated?
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.
-
What can I do if my RewriteRules don't work as expected?
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.
- Why don't some of my URLs
get prefixed with DocumentRoot when using mod_rewrite?
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.
-
How can I make all my URLs case-insensitive with mod_rewrite?
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.
-
Why are RewriteRules in my VirtualHost parts ignored?
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.
-
How can I use strings with whitespaces in RewriteRule's ENV
flag?
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]".
- Where can I find the "CGI
specification"?
The Common Gateway Interface (CGI) specification currently lives in at least two versions:
- At the original NCSA site <http://hoohoo.ncsa.uiuc.edu/cgi/interface.html>. This version hasn't been updated since 1995, and there have been some efforts to update it and replace it with
- The most current version, which is struggling to become an Internet RFC, found at <http://www.ast.cam.ac.uk/~drtr/cgi-spec.html>.
Apache HTTP Server Version 1.2
0707010001277b000081a400000064000000640000000134b16bd700000d81000000200000001b00000000000000000000002f00000004reloc/htdocs/manual/misc/client_block_api.html
Apache HTTP Server Version 1.2
Reading Client Input in Apache 1.2
Apache 1.1 and earlier let modules handle POST and PUT requests by
themselves. The module would, on its own, determine whether the
request had an entity, how many bytes it was, and then called a
function (read_client_block) to get the data.
However, HTTP/1.1 requires several things of POST and PUT request handlers that did not fit into this module, and all existing modules have to be rewritten. The API calls for handling this have been further abstracted, so that future HTTP protocol changes can be accomplished while remaining backwards-compatible.
The New API Functions
int setup_client_block (request_rec *, int read_policy); int should_client_block (request_rec *); long get_client_block (request_rec *, char *buffer, int buffer_size);
- Call
setup_client_block()near the beginning of the request handler. This will set up all the necessary properties, and will return either OK, or an error code. If the latter, the module should return that error code. The second parameter selects the policy to apply if the request message indicates a body, and how a chunked transfer-coding should be interpreted. Choose one ofREQUEST_NO_BODY Send 413 error if message has any body REQUEST_CHUNKED_ERROR Send 411 error if body without Content-Length REQUEST_CHUNKED_DECHUNK If chunked, remove the chunks for me. REQUEST_CHUNKED_PASS Pass the chunks to me without removal.In order to use the last two options, the caller MUST provide a buffer large enough to hold a chunk-size line, including any extensions. - When you are ready to possibly accept input, call
should_client_block(). This will tell the module whether or not to read input. If it is 0, the module should assume that the input is of a non-entity type (e.g. a GET request). A nonzero response indicates that the module 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 100 response is defeated). Never call this function more than once. - Finally, call
get_client_blockin a loop. Pass it a buffer and its size. It will put data into the buffer (not necessarily the full buffer, in the case of chunked inputs), and return the length of the input block. When it is done reading, it will return 0 if EOF, or -1 if there was an error.
As an example, please look at the code in
mod_cgi.c. This is properly written to the new API
guidelines.
Apache HTTP Server Version 1.2
0707010001277d000081a400000064000000640000000134b16bd7000013d1000000200000001b00000000000000000000002b00000004reloc/htdocs/manual/misc/compat_notes.html
Apache HTTP Server Version 1.2
Compatibility Notes with NCSA's Server
While Apache 0.8.x and beyond are for the most part a drop-in replacement for NCSA's httpd and earlier versions of Apache, there are a couple gotcha's to watch out for. These are mostly due to the fact that the parser for config and access control files was rewritten from scratch, so certain liberties the earlier servers took may not be available here. These are all easily fixable. If you know of other non-fatal problems that belong here, let us know.
Please also check the known bugs page.
- The basic mod_auth
AuthGroupFile-specified group file format allows commas between user names - Apache does not.
- added 12/1/96 If you follow the NCSA guidelines for setting up access restrictions based on client domain, you may well have added entries for,
AuthType, AuthName, AuthUserFileorAuthGroupFile. None of these are needed (or appropriate) for restricting access based on client domain.When Apache sees
AuthTypeit (reasonably) assumes you are using some authorization type based on username and password.Please remove
AuthType, it's unnecessary even for NCSA.AuthUserFilerequires 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 directory easily accessible by the world. We recommend you store your passwords outside your document tree.OldScriptAliasis no longer supported.exec cgi=""produces reasonable malformed header responses when used to invoke non-CGI scripts.
The NCSA code ignores the missing header. (bad idea)
Solution: write CGI to the CGI spec or useexec cmd=""instead.We might add
virtualsupport toexec cmdto make up for this difference.- <Limit> silliness - in the old Apache 0.6.5, a
directive of <Limit GET> would also restrict POST methods - Apache 0.8.8's new
core is correct in not presuming a limit on a GET is the same limit on a POST,
so if you are relying on that behavior you need to change your access configurations
to reflect that.
- Icons for FancyIndexing broken - well, no, they're not broken,
we've just upgraded the
icons from flat .xbm files to pretty and much smaller .gif files, courtesy of
Kevin Hughes at
EIT.
If you are using the same srm.conf from an old distribution, make sure
you add the new
AddIcon,
AddIconByType,
and
DefaultIcon
directives.
- Under IRIX, the "Group" directive in httpd.conf needs to be a
valid group name
(i.e., "nogroup") not the numeric group ID. The distribution
httpd.conf, and earlier ones, had the default Group be "#-1", which
was causing silent exits at startup.
.asisfiles: Apache 0.6.5 did not require a Status header; it added one automatically if the .asis file contained a Location header. 0.8.14 requires a Status header.- Apache versions before 1.2b1 will ignore the last line of configuration 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.
- Apache does not permit commas delimiting the methods in <Limit>.
- Apache's
<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 addedoptionalkeyword is included. - Apache does not implement
OnDenyuseErrorDocumentinstead.
Apache HTTP Server Version 1.2
0707010001277e000081a400000064000000640000000134b16bd700001cc5000000200000001b00000000000000000000002a00000004reloc/htdocs/manual/misc/descriptors.html
Apache HTTP Server Version 1.2
Descriptors and Apache
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):
- BSDI 2.0
- Under BSDI 2.0 you can build Apache to support more descriptors
by adding
-DFD_SETSIZE=nnntoEXTRA_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. - FreeBSD 2.2, BSDI 2.1+
- Similar to the BSDI 2.0 case, you should define
FD_SETSIZEand rebuild. But the extra Listen limitation doesn't exist. - Linux
- By default Linux has a kernel maximum of 256 open descriptors
per process. There are several patches available for the
2.0.x series which raise this to 1024 and beyond, and you
can find them in the "unofficial patches" section of the Linux Information HQ.
None of these patches are perfect, and an entirely different
approach is likely to be taken during the 2.1.x development.
Applying these patches will raise the FD_SETSIZE used to compile
all programs, and unless you rebuild all your libraries you should
avoid running any other program with a soft descriptor limit above
256. As of this writing the patches available for increasing
the number of descriptors do not take this into account. On a
dedicated webserver you probably won't run into trouble.
- Solaris through 2.5.1
- Solaris has a kernel hard limit of 1024 (may be lower in earlier
versions). But it has a limitation that files using
the stdio library cannot have a descriptor above 255.
Apache uses the stdio library for the ErrorLog directive.
When you have more than approximately 110 virtual hosts
(with an error log and an access log each) you will need to
build Apache with
-DHIGH_SLACK_LINE=256added toEXTRA_CFLAGS. You will be limited to approximately 240 error logs if you do this. - AIX
- AIX version 3.2?? appears to have a hard limit of 128 descriptors.
End of story. Version 4.1.5 has a hard limit of 2000.
- Others
- If you have details on another operating system, please submit
it through our Bug
Report Page.
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.
Apache HTTP Server Version 1.2
0707010001277f000081a400000064000000640000000134b16bd700003e65000000200000001b00000000000000000000002900000004reloc/htdocs/manual/misc/fin_wait_2.html
Apache HTTP Server Version 1.2
Connections in the FIN_WAIT_2 state and Apache
What is the FIN_WAIT_2 state?
Starting with the Apache 1.2 betas, people are reporting many more connections in the FIN_WAIT_2 state (as reported bynetstat) than they saw using older versions. When the server closes a TCP connection, it sends a packet with the FIN bit sent to the client, which then responds with a packet with the ACK bit set. The client then sends a packet with the FIN bit set to the server, which responds with an ACK and the connection is closed. The state that the connection is in during the period between when the server gets the ACK from the client and the server gets the FIN from the client is known as FIN_WAIT_2. See the TCP RFC for the technical details of the state transitions.The FIN_WAIT_2 state is somewhat unusual in that there is no timeout defined in the standard for it. This means that on many operating systems, a connection in the FIN_WAIT_2 state will stay around until the system is rebooted. If the system does not have a timeout and too many FIN_WAIT_2 connections build up, it can fill up the space allocated for storing information about the connections and crash the kernel. The connections in FIN_WAIT_2 do not tie up an httpd process.
But why does it happen?
There are several reasons for it happening, and not all of them are fully understood by the Apache team yet. What is known follows.Buggy clients and persistent connections
Several clients have a bug which pops up when dealing with persistent connections (aka keepalives). When the connection is idle and the server closes the connection (based on the KeepAliveTimeout), the client is programmed so that the client does not send back a FIN and ACK to the server. This means that the connection stays in the FIN_WAIT_2 state until one of the following happens:- The client opens a new connection to the same or a different site, which causes it to fully close the older connection on that socket.
- The user exits the client, which on some (most?) clients causes the OS to fully shutdown the connection.
- The FIN_WAIT_2 times out, on servers that have a timeout for this state.
If you are lucky, this means that the buggy client will fully close the connection and release the resources on your server. However, there are some cases where the socket is never fully closed, such as a dialup client disconnecting from their provider before closing the client. In addition, a client might sit idle for days without making another connection, and thus may hold its end of the socket open for days even though it has no further use for it. This is a bug in the browser or in its operating system's TCP implementation.
The clients on which this problem has been verified to exist:
- Mozilla/3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386)
- Mozilla/2.02 (X11; I; FreeBSD 2.1.5-RELEASE i386)
- Mozilla/3.01Gold (X11; I; SunOS 5.5 sun4m)
- MSIE 3.01 on the Macintosh
- MSIE 3.01 on Windows 95
This does not appear to be a problem on:
- Mozilla/3.01 (Win95; I)
It is expected that many other clients have the same problem. What a client should do is periodically check its open socket(s) to see if they have been closed by the server, and close their side of the connection if the server has closed. This check need only occur once every few seconds, and may even be detected by a OS signal on some systems (e.g., Win95 and NT clients have this capability, but they seem to be ignoring it).
Apache cannot avoid these FIN_WAIT_2 states unless it disables persistent connections for the buggy clients, just like we recommend doing for Navigator 2.x clients due to other bugs. However, non-persistent connections increase the total number of connections needed per client and slow retrieval of an image-laden web page. Since non-persistent connections have their own resource consumptions and a short waiting period after each closure, a busy server may need persistence in order to best serve its clients.
As far as we know, the client-caused FIN_WAIT_2 problem is present for all servers that support persistent connections, including Apache 1.1.x and 1.2.
Something in Apache may be broken
While the above bug is a problem, it is not the whole problem. Some users have observed no FIN_WAIT_2 problems with Apache 1.1.x, but with 1.2b enough connections build up in the FIN_WAIT_2 state to crash their server. We have not yet identified why this would occur and welcome additional test input.One possible (and most likely) source for additional FIN_WAIT_2 states is a function called
lingering_close()which was added between 1.1 and 1.2. This function is necessary for the proper handling of persistent connections and any request which includes content in the message body (e.g., PUTs and POSTs). What it does is read any data sent by the client for a certain time after the server closes the connection. The exact reasons for doing this are somewhat complicated, but involve what happens if the client is making a request at the same time the server sends a response and closes the connection. Without lingering, the client might be forced to reset its TCP input buffer before it has a chance to read the server's response, and thus understand why the connection has closed. See the appendix for more details.We have not yet tracked down the exact reason why
lingering_close()causes problems. Its code has been thoroughly reviewed and extensively updated in 1.2b6. It is possible that there is some problem in the BSD TCP stack which is causing the observed problems. It is also possible that we fixed it in 1.2b6. Unfortunately, we have not been able to replicate the problem on our test servers.- What can I do about it?
There are several possible workarounds to the problem, some of
which work better than others.
Add a timeout for FIN_WAIT_2
The obvious workaround is to simply have a timeout for the FIN_WAIT_2 state. This is not specified by the RFC, and could be claimed to be a 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.
- NetBSD version 1.2(?)
- OpenBSD all versions(?)
- BSD/OS 2.1, with the K210-027 patch installed.
- Solaris as of around version
2.2. The timeout can be tuned by using
nddto modifytcp_fin_wait_2_flush_interval, but the default should be appropriate for most servers and improper tuning can have negative impacts. - SCO TCP/IP Release 1.2.1 can be modified to have a timeout by following SCO's instructions.
- Linux 2.0.x and earlier(?)
- HP-UX 10.x defaults to
terminating connections in the FIN_WAIT_2 state after the
normal keepalive timeouts. This does not
refer to the persistent connection or HTTP keepalive
timeouts, but the
SO_LINGERsocket option which is enabled by Apache. This parameter can be adjusted by usingnettuneto modify parameters such astcp_keepstartandtcp_keepstop. In later revisions, there is an explicit timer for connections in FIN_WAIT_2 that can be modified; contact HP support for details. - SGI IRIX can be patched to support a timeout. For IRIX 5.3, 6.2, and 6.3, use patches 1654, 1703 and 1778 respectively. If you have trouble locating these patches, please contact your SGI support channel for help.
- NCR's MP RAS Unix 2.xx and 3.xx both have FIN_WAIT_2 timeouts. In 2.xx it is non-tunable at 600 seconds, while in 3.xx it defaults to 600 seconds and is calculated based on the tunable "max keep alive probes" (default of 8) multiplied by the "keep alive interval" (default 75 seconds).
- Squent's ptx/TCP/IP for DYNIX/ptx has had a FIN_WAIT_2 timeout since around release 4.1 in mid-1994.
The following systems are known to not have a timeout:
- SunOS 4.x does not and almost certainly never will have one because it as at the very end of its development cycle for Sun. If you have kernel source should be easy to patch.
There is a 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, please drop me a note at marc@apache.org.
Compile without using
It is possible to compile Apache 1.2 without using thelingering_close()lingering_close()function. This will result in that section of code being similar to that which was in 1.1. If you do this, be aware that it can cause problems with PUTs, POSTs and persistent connections, especially if the client uses pipelining. That said, it is no worse than on 1.1, and we understand that keeping your server running is quite important.To compile without the
lingering_close()function, add-DNO_LINGCLOSEto the end of theEXTRA_CFLAGSline in yourConfigurationfile, rerunConfigureand rebuild the server.Use
On most systems, there is an option calledSO_LINGERas an alternative tolingering_close()SO_LINGERthat can be set withsetsockopt(2). It does something very similar tolingering_close(), except that it is broken on many systems so that it causes far more problems thanlingering_close. On some systems, it could possibly work better so it may be worth a try if you have no other alternatives.To try it, add
-DUSE_SO_LINGER -DNO_LINGCLOSEto the end of theEXTRA_CFLAGSline in yourConfigurationfile, rerunConfigureand rebuild the server.NOTE: Attempting to use
SO_LINGERandlingering_close()at the same time is very likely to do very bad things, so don't.Increase the amount of memory used for storing connection state
- BSD based networking code:
- BSD stores network data, such as connection states,
in something called an mbuf. When you get so many connections
that the kernel does not have enough mbufs to put them all in, your
kernel will likely crash. You can reduce the effects of the problem
by increasing the number of mbufs that are available; this will not
prevent the problem, it will just make the server go longer before
crashing.
The exact way to increase them may depend on your OS; look for some reference to the number of "mbufs" or "mbuf clusters". On many systems, this can be done by adding the line
NMBCLUSTERS="n", wherenis the number of mbuf clusters you want to your kernel config file and rebuilding your kernel.
Disable KeepAlive
If you are unable to do any of the above then you should, as a last resort, disable KeepAlive. Edit your httpd.conf and change "KeepAlive On" to "KeepAlive Off".
- Feedback
If you have any information to add to this page, please contact me at
marc@apache.org.
- Appendix
Below is a message from Roy Fielding, one of the authors of HTTP/1.1.
Why the lingering close functionality is necessary with HTTP
The need for a server to linger on a socket after a close is noted a couple times in the HTTP specs, but not explained. This explanation is based on discussions between myself, Henrik Frystyk, Robert S. Thau, Dave Raggett, and John C. Mallery in the hallways of MIT while I was at W3C.If a server closes the input side of the connection while the client is sending data (or is planning to send data), then the server's TCP stack will signal an RST (reset) back to the client. Upon receipt of the RST, the client will flush its own incoming TCP buffer back to the un-ACKed packet indicated by the RST packet argument. If the server has sent a message, usually an error response, to the client just before the close, and the client receives the RST packet before its application code has read the error message from its incoming TCP buffer and before the server has received the ACK sent by the client upon receipt of that buffer, then the RST will flush the error message before the client application has a chance to see it. The result is that the client is left thinking that the connection failed for no apparent reason.
There are two conditions under which this is likely to occur:
- sending POST or PUT data without proper authorization
- sending multiple requests before each response (pipelining) and one of the middle requests resulting in an error or other break-the-connection result.
The solution in all cases is to send the response, close only the write half of the connection (what shutdown is supposed to do), and continue reading on the socket until it is either closed by the client (signifying it has finally read the response) or a timeout occurs. That is what the kernel is supposed to do if SO_LINGER is set. Unfortunately, SO_LINGER has no effect on some systems; on some other systems, it does not have its own timeout and thus the TCP memory segments just pile-up until the next reboot (planned or not).
Please note that simply removing the linger code will not solve the problem -- it only moves it to a different and much harder one to detect.
Apache HTTP Server Version 1.2
07070100012780000081a400000064000000640000000134b16bd8000000b9000000200000001b00000000000000000000002500000004reloc/htdocs/manual/misc/footer.html Apache HTTP Server Version 1.2
07070100012781000081a400000064000000640000000134b16bd800000086000000200000001b00000000000000000000002500000004reloc/htdocs/manual/misc/header.html
Apache HTTP Server Version 1.2
Apache HTTP Server Version 1.2
Apache HOWTO documentation
How to: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
mod_rewrite, and another which uses a CGI script.
First: if all you need to do is migrate a server from one name to
another, simply use the Redirect directive, as supplied
by mod_alias:
Redirect / http://www.apache.org/
Since Redirect will forward along the complete path,
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:
This will send an HTTP 302 Redirect back to the client, and no matter what they gave in the original URL, they'll be sent to "http://www.apache.org". The second option is to set up aRewriteEngine On RewriteRule /.* http://www.apache.org/ [R]
ScriptAlias pointing to
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 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 information.) You might also want to use a CGI script if you don't want to compile mod_rewrite into your server.
Here's how to redirect all requests to a script... In the server configuration file,
and here's a simple perl script to redirect requests:ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script
#!/usr/local/bin/perl print "Status: 302 Moved Temporarily\r Location: http://www.some.where.else.com/\r\n\r\n";
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 need.
access.log typically grows by 1Mb for each 10,000 requests.
Most people's first attempt at replacing the logfile is to just move the logfile or remove the logfile. This doesn't work.
Apache will continue writing to the logfile at the same offset as before the 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.
Apache is signaled using the SIGHUP (-1) signal. e.g.
mv access_log access_log.old
kill -1 `cat httpd.pid`
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.
Many people use this method to replace (and backup) their logfiles on a nightly or weekly basis.
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?
These clients are called robots (also known as crawlers, spiders and other cute name) - special automated clients which wander around the web looking for interesting resources.
Most robots are used to generate some kind of web index which is then used by a search engine to help locate information.
robots.txt provides a means to request that robots limit their
activities at the site, or more often than not, to leave the site alone.
When the first robots were developed, they had a bad reputation for sending hundreds/thousands of requests to each site, often resulting in the site being overloaded. Things have improved dramatically since then, thanks to Guidelines for Robot Writers, but even so, some robots may exhibit unfriendly behavior which the webmaster isn't willing to tolerate, and will want to stop.
Another reason some webmasters want to block access to robots, is to stop them indexing dynamic information. Many search engines will use the data collected from your pages for months to come - not much use if your serving stock quotes, news, weather reports or anything else that will be 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.
Apache HTTP Server Version 1.2
07070100012783000081a400000064000000640000000134b16bd800000d47000000200000001b00000000000000000000002400000004reloc/htdocs/manual/misc/index.html
Apache HTTP Server Version 1.2
Apache Miscellaneous Documentation
Below is a list of additional documentation pages that apply to the Apache web server development project.
- API
- Description of Apache's Application Programming Interface.
- FAQ
- Frequently-Asked Questions concerning the Apache project and server
- Reading Client Input in Apache 1.2
- Describes differences between Apache 1.1 and 1.2 in how modules read information from the client
- Compatibility with NCSA
- Notes about Apache's compatibility with the NCSA server
- FIN_WAIT_2
- A description of the causes of Apache processes going into the FIN_WAIT_2 state, and what you can do about it
- "How-To"
- Instructions about how to accomplish some commonly-desired server functionality changes
- Known Bugs
- Just what it says - a list of known bugs in each of the Apache releases
- No PGP
- Why we took PEM and PGP support out of the base Apache distribution
- Performance Notes (BSD 4.4)
- Some notes about ways to improve/optimize Apache performance on BSD 4.4 systems
- Performance Notes (Digital UNIX)
- Extracts of USENET postings describing how to optimize Apache performance on Digital UNIX systems
- Performance Notes (General)
- Some generic notes about how to improve Apache performance
- Security Tips
- Some "do"s - and "don't"s - for keeping your Apache web site secure
- Virtual Hosts (IP-based)
- Excerpts and notes about configuring and using Apache IP-based virtual hosts
- Windows Bug with Web Keepalive
- A brief description of a known problem with Microsoft Windows and web sites accessed using keepalive connections
Apache HTTP Server Version 1.2
07070100012784000081a400000064000000640000000134b16bd800001c41000000200000001b00000000000000000000002900000004reloc/htdocs/manual/misc/known_bugs.html
Apache HTTP Server Version 1.2
Known Bugs in Apache
The most up-to-date resource for bug tracking and information is the Apache bug database. Significant bugs at release time will also be noted there. If you are running a 1.2 beta release or version 1.1.3 or earlier and thing you have found a bug, please upgrade to 1.2. Many bugs in early versions have been fixed in 1.2.See Also: Compatibility notes
Apache 1.2 Bugs
- Exists in 1.2.1 only.
On Solaris 2.x the server will stop running after receiving a
SIGHUP. Four workarounds exist (choose one):
- Retrieve this patch.
cdto yourapache_1.2.1directory, and typepatch -s -p1 < /path/to/patchfile. Then rebuild Apache. - Use SIGUSR1 instead of SIGHUP, see
Stopping and Restarting Apache for more details.
- Add
-DNO_SLACKtoEXTRA_CFLAGSin yourConfigurationfile, re-runConfigureand rebuild your server. This disables the descriptor slack workaround - (Least preferable) Use Apache 1.2.0 instead of 1.2.1.
- Retrieve this patch.
- (Exists in 1.2.0 and in 1.2.1 after either of the
NO_SLACKor patch provided by the previous bug are applied.) Solaris 2.5.1 (and probably other versions of Solaris) appear to have a race condition completely unrelated to all the others. It is possible during a SIGHUP that the server will fail to start because it will not be able to re-open its sockets. To our knowledge this has only shown up during testing when we pummel the server with as many SIGHUP requests per second as we can. This appears unrelated to the similar sounding bug described in PR#832. - On some architectures
if your configuration uses multiple
Listen directives then it is possible
that the server will starve one of the sockets while serving hits on
another. The work-around is to add
-DUSE_FLOCK_SERIALIZED_ACCEPTto theEXTRA_CFLAGSline in your Configuration and rebuild. (If you encounter problems with that, you can also try-DUSE_FCNTL_SERIALIZED_ACCEPT.) This affects any architecture that doesn't use one of theUSE_xxxxx_SERIALIZED_ACCEPTdefinitions, see the source fileconf.hfor your architecture. This will be tracked as PR#467. - Fixed in 1.2.1. Apache's Content Negotiation should pick the smallest variant if there are several that are equally acceptable. A bug in 1.2 means it no longer does this unless all the variants have character sets. This patch fixes this problem. It also fixes the problem which makes Apache pick the last equally acceptable variant instead of the first. This will be tracked as PR#94.
-
The PATH_INFO part of a request URI cannot include the sequence
%2f. This will be tracked as PR#543. - Users of early 1.2 betas reported problems with many
connections stuck in the FIN_WAIT_2 state due to server
timeouts. Several changes were made during the beta testing of 1.2
to reduce this problem as much as possible, although you may still
see sockets in FIN_WAIT_2 state due to network or operating system
issues outside the control of Apache. See our FIN_WAIT_2 page for more details.
SunOS4 has a kernel bug in the allocation of memory for the mbuf table. When it fills up, the result is a Panic the next time any routine tries to set something in an imaginary mbuf beyond the range of the table. Due to buggy browser behavior and the lack of a FIN_WAIT_2 timeout on SunOS4, "KeepAlive Off" is necessary to avoid filling up the mbuf table on busy sites.
- Compilation fails on SCO3 when using gcc instead of cc, complaining
with "
gcc: noinline: No such file or directory". Fix is given in PR#695. - If compilation fails complaining about "unknown symbol __inet_ntoa()"
then you have probably installed version 8 of bind. You will need to
explicitly link with the bind library by adding
-lbindtoEXTRA_LDFLAGSinConfiguration. See PR#616 and the Apache FAQ. - The message "
created shared memory segment #730499" in error_log is not an error and should be ignored. See PR#696. -
Compiling on Solaris 2 with SunSoft's C compiler gives the warning
"mod_include.c", line 1123: warning: end-of-loop code not reached. This is a bogus warning and can be ignored. See PR#681. - Workaround available in 1.2.1. There appears to be a problem on BSDI 2.1 with large numbers of virtual hosts. This appears similar to a file-descriptor limit but BSDI should not have this problem. This will be tracked as PR#611. See also the Apache FAQ.
- Workaround available in 1.2.1. Solaris 2 has problems with large numbers of virtual hosts. This is because of an operating system limit of 256 file pointers, not due to Apache. See also the Apache FAQ.
Apache HTTP Server Version 1.2
07070100012785000081a400000064000000640000000134b16bd800000d71000000200000001b00000000000000000000002400000004reloc/htdocs/manual/misc/nopgp.html
Apache HTTP Server Version 1.2
Why We Took PEM Out of Apache
On May 17th, 1995, we were asked by a representative of NCSA to remove any copies of NCSA httpd prior to 1.4.1 from our web site. They were mandated by the NSA to inform us that redistribution of pre-1.4.1 code violated the same laws that make distributing Phill Zimmerman's PGP package to other countries illegal. There was no encryption in NCSA's httpd, only hooks to publicly available libraries of PEM code. By the NSA's rules, even hooks to this type of application is illegal.Because Apache is based on NCSA code, and we had basically not touched that part of the software, we were informed that Apache was also illegal to distribute to foreign countries, and advised (not mandated) by NCSA to remove it. So, we removed both the copies of the NCSA httpd we had, and all versions of Apache previous to 0.6.5.
The Apache members are strong advocates of the right to digital privacy, so the decision to submit to the NSA and remove the code was not an easy one. Here are some elements in our rationale:
- The PEM code in httpd was not widely used. No major site relied upon its use, so its loss is not a blow to encryption and security on the world wide web. There are other efforts designed to give much more flexible security - SSL and SHTTP - so this wasn't a function whose absence would really be missed on a functional level.
- We didn't feel like being just a couple more martyrs in a fight being fought very well by many other people. Rather than have the machine that supports the project confiscated or relocated to South Africa, etc., we think there are more efficient methods to address the issue.
Patches that re-implement the PEM code may be available at a foreign site soon. If it does show up, we'll point to it - that can't be illegal!
Finally, here is a compendium of pointers to sites related to encryption and export law. We can't promise this list will be up to date, so send us mail when you see a problem or want a link added. Thanks.
- Yahoo - Science: Mathematics: Security and Encryption
- EFF Crypto/Privacy/Security Archive
- Crypto page at Quadralay
- Cryptography Export Control Archives (Cygnus)
- ICLU - Your Rights in Cyberspace
Apache HTTP Server Version 1.2
07070100012786000081a400000064000000640000000134b16bd800001c8b000000200000001b00000000000000000000002900000004reloc/htdocs/manual/misc/perf-bsd44.html
Apache HTTP Server Version 1.2
Running a High-Performance Web Server for BSD
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):Edit the following two files:
/usr/include/sys/socket.h
/usr/src/sys/sys/socket.h
/*
* Maximum queue length specifiable by listen.
*/
#define SOMAXCONN 5
Just change the "5" to whatever appears to work. I bumped the two
machines I was having problems with up to 32 and haven't noticed the
problem since.
After the edit, recompile the kernel and recompile the Apache server then reboot.
FreeBSD 2.1 seems to be perfectly happy, with SOMAXCONN set to 32 already.
Addendum for very heavily loaded BSD servers
from Chuck Murcko <chuck@telebase.com>
If you're running a really busy BSD Apache server, the following are useful things to do if the system is acting sluggish:
- Run vmstat to check memory usage, page/swap rates, etc.
- Run netstat -m to check mbuf usage
- Run fstat to check file descriptor usage
maxusers 256Maxusers drives a lot of other kernel parameters:
- Maximum # of processes
- Maximum # of processes per user
- System wide open files limit
- Per-process open files limit
- Maximum # of mbuf clusters
- Proc/pgrp hash table size
# Network options. NMBCLUSTERS defines the number of mbuf clusters and # defaults to 256. This machine is a server that handles lots of traffic, # so we crank that value. options SOMAXCONN=256 # max pending connects options NMBCLUSTERS=4096 # mbuf clusters at 4096 # # Misc. options # options CHILD_MAX=512 # maximum number of child processes options OPEN_MAX=512 # maximum fds (breaks RPC svcs)SOMAXCONN is not derived from maxusers, so you'll always need to increase that yourself. We used a value guaranteed to be larger than Apache's default for the listen() of 128, currently.
In many cases, NMBCLUSTERS must be set much larger than would appear necessary at first glance. The reason for this is that if the browser disconnects in mid-transfer, the socket fd associated with that particular connection ends up in the TIME_WAIT state for several minutes, during which time its mbufs are not yet freed. Another reason is that, on server timeouts, some connections end up in FIN_WAIT_2 state forever, because this state doesn't time out on the server, and the browser never sent a final FIN. For more details see the FIN_WAIT_2 page.
Some more info on mbuf clusters (from sys/mbuf.h):
/* * Mbufs are of a single size, MSIZE (machine/machparam.h), which * includes overhead. An mbuf may add a single "mbuf cluster" of size * MCLBYTES (also in machine/machparam.h), which has no additional overhead * and is used instead of the internal data area; this is done when * at least MINCLSIZE of data must be stored. */
CHILD_MAX and OPEN_MAX are set to allow up to 512 child processes (different than the maximum value for processes per user ID) and file descriptors. These values may change for your particular configuration (a higher OPEN_MAX value if you've got modules or CGI scripts opening lots of connections or files). If you've got a lot of other activity besides httpd on the same machine, you'll have to set NPROC higher still. In this example, the NPROC value derived from maxusers proved sufficient for our load.
Caveats
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 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.
RPC services will fail when the value of OPEN_MAX is larger than 256. This is a function of the original implementations of the RPC library, which used a byte value for holding file descriptors. BSDI has partially addressed this limit in its 2.1 release, but a real fix may well await the redesign of RPC itself.
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.
From conf/httpd.conf-dist:
# Limit on total number of servers running, i.e., limit on the number # of clients who can simultaneously connect --- if this limit is ever # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW. # It is intended mainly as a brake to keep a runaway server from taking # Unix with it as it spirals down... MaxClients 150Know what you're doing if you bump this value up, and make sure you've done your system monitoring, RAM expansion, and kernel tuning beforehand. Then you're ready to service some serious hits!
Thanks to Tony Sanders and Chris Torek at BSDI for their helpful suggestions and information.
"M. Teterin" <mi@ALDAN.ziplink.net> writes:
It really does help if your kernel and frequently used utilities are fully optimized. Rebuilding the FreeBSD kernel on an AMD-133 (486-class CPU) web-server with
-m486 -fexpensive-optimizations -fomit-frame-pointer -O2
helped reduce the number of "unable" errors, because the CPU was often maxed out.
More welcome!
If you have tips to contribute, send mail to brian@organic.comApache HTTP Server Version 1.2
07070100012787000081a400000064000000640000000134b16bd80000332c000000200000001b00000000000000000000002700000004reloc/htdocs/manual/misc/perf-dec.html
Apache HTTP Server Version 1.2
Performance Tuning Tips for Digital Unix
Below is a set of newsgroup posts made by an engineer from DEC in response to queries about how to modify DEC's Digital Unix OS for more heavily loaded web sites. Copied with permission.Update
From: Jeffrey Mogul <mogul@pa.dec.com>Date: Fri, 28 Jun 96 16:07:56 MDT
- The advice given in the README file regarding the "tcbhashsize" variable is incorrect. The largest value this should be set to is 1024. Setting it any higher will have the perverse result of disabling the hashing mechanism.
- Patch ID OSF350-146 has been superseded by
Patch ID OSF350-195 for V3.2C
Patch IDs for V3.2E and V3.2F should be available soon. There is no known reason why the Patch ID OSF360-350195 won't work on these releases, but such use is not officially supported by Digital. This patch kit will not be needed for V3.2G when it is released.
Patch ID OSF360-350195 for V3.2D
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> Subject Re: Web Site Performance References 1 In article <skoogDs54BH.9pF@netcom.com> skoog@netcom.com (Jim Skoog) writes: >Where are the performance bottlenecks for Alpha AXP running the >Netscape Commerce Server 1.12 with high volume internet traffic? >We are evaluating network performance for a variety of Alpha AXP >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 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. How much larger? Well, no larger than 32767 (decimal). And probably no less than about 2048, if you have a really high volume (millions of hits per day), like AltaVista does. This change allows the system to maintain more than 8 TCP connections in the SYN_RCVD state for the HTTP server. (You can use "netstat -An |grep SYN_RCVD" to see how many such connections exist at any given instant). If you don't make this change, you might find that as the load gets high, some connection attempts take a very long time. And if a lot of your clients disconnect from the Internet during the process of TCP connection establishment (this happens a lot with dialup users), these "embryonic" connections might tie up your somaxconn quota of SYN_RCVD-state connections. Until the kernel times out these embryonic connections, no other connections will be accepted, and it will appear as if the server has died. The default value for somaxconn in Digital UNIX V4.0 will be quite a bit larger than it has been in previous versions (we inherited this default from 4.3BSD). Digital UNIX V4.0 includes some other performance-related changes that significantly improve its maximum HTTP connection rate. However, we've been using V3.2C systems to front-end for altavista.digital.com 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 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. -Jeff
---------------------------------------------------------------------------- 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> Subject Digital UNIX V3.2C Internet tuning patch info ---------------------------------------------------------------------------- Something that probably few people are aware of is that Digital has a patch kit available for Digital UNIX V3.2C that may improve Internet performance, especially for busy web servers. This patch kit is one way to increase the value of somaxconn, which I discussed in a message here a day or two ago. I've included in this message the revised README file for this patch kit below. Note that the original README file in the patch kit itself may be an earlier version; I'm told that the version below is the right one. Sorry, this patch kit is NOT available for other versions of Digital UNIX. Most (but not quite all) of these changes also made it into V4.0, 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 so I guess you'll have to call Digital's Customer Support to get it. -Jeff DESCRIPTION: Digital UNIX Network tuning patch Patch ID: OSF350-146 SUPERSEDED PATCHES: OSF350-151, OSF350-158 This set of files improves the performance of the network subsystem on a system being used as a web server. There are additional tunable parameters included here, to be used cautiously by an informed system administrator. TUNING To tune the web server, the number of simultaneous socket connection requests are limited by: somaxconn Sets the maximum number of pending requests allowed to wait on a listening socket. The default value in Digital UNIX V3.2 is 8. This patch kit increases the default to 1024, which matches the value in Digital UNIX V4.0. sominconn Sets the minimum number of pending connections allowed on a listening socket. When a user process calls listen with a backlog less than sominconn, the backlog will be set to sominconn. sominconn overrides somaxconn. The default value is 1. The effectiveness of tuning these parameters can be monitored by the sobacklog variables available in the kernel: sobacklog_hiwat Tracks the maximum pending requests to any socket. The initial value is 0. sobacklog_drops Tracks the number of drops exceeding the socket set backlog limit. The initial value is 0. somaxconn_drops Tracks the number of drops exceeding the somaxconn limit. When sominconn is larger than somaxconn, tracks the number of drops exceeding sominconn. The initial value is 0. TCP timer parameters also affect performance. Tuning the following require some knowledge of the characteristics of the network. tcp_msl Sets the tcp maximum segment lifetime. This is the maximum lifetime in half seconds that a packet can be in transit on the network. This value, when doubled, is the length of time a connection remains in the TIME_WAIT state after a incoming close request is processed. The unit is specified in 1/2 seconds, the initial value is 60. tcp_rexmit_interval_min Sets the minimum TCP retransmit interval. For some WAN networks the default value may be too short, causing unnecessary duplicate packets to be sent. The unit is specified in 1/2 seconds, the initial value is 1. tcp_keepinit This is the amount of time a partially established connection will sit on the listen queue before timing out (e.g. if a client sends a SYN but never answers our SYN/ACK). Partially established connections tie up slots on the listen queue. If the queue starts to fill with connections in SYN_RCVD state, tcp_keepinit can be decreased to make those partial connects time out sooner. This should be used with caution, since there might be legitimate clients that are taking a while to respond to SYN/ACK. The unit is specified in 1/2 seconds, the default value is 150 (ie. 75 seconds). The hashlist size for the TCP inpcb lookup table is regulated by: tcbhashsize The number of hash buckets used for the TCP connection table used in the kernel. The initial value is 32. For best results, should be specified as a power of 2. For busy Web servers, set this to 2048 or more. The hashlist size for the interface alias table is regulated by: inifaddr_hsize The number of hash buckets used for the interface alias table used in the kernel. The initial value is 32. For best results, should be specified as a power of 2. ipport_userreserved The maximum number of concurrent non-reserved, dynamically allocated ports. Default range is 1025-5000. The maximum value is 65535. This limits the numer of times you can simultaneously telnet or ftp out to connect to other systems. tcpnodelack Don't delay acknowledging TCP data; this can sometimes improve performance of locally run CAD packages. Default is value is 0, the enabled value is 1. Digital UNIX version: V3.2C Feature V3.2C patch V4.0 ======= ===== ===== ==== somaxconn X X X sominconn - X X sobacklog_hiwat - X - sobacklog_drops - X - somaxconn_drops - X - tcpnodelack X X X tcp_keepidle X X X tcp_keepintvl X X X tcp_keepcnt - X X tcp_keepinit - X X TCP keepalive per-socket - - X tcp_msl - X - tcp_rexmit_interval_min - X - TCP inpcb hashing - X X tcbhashsize - X X interface alias hashing - X X inifaddr_hsize - X X ipport_userreserved - X - sysconfig -q inet - - X sysconfig -q socket - - X
Apache HTTP Server Version 1.2
07070100012788000081a400000064000000640000000134b16bd800000f1a000000200000001b00000000000000000000002300000004reloc/htdocs/manual/misc/perf.html
Apache HTTP Server Version 1.2
Hints on Running a High-Performance Web Server
Running Apache on a heavily loaded web server, one often encounters problems related to the machine and OS configuration. "Heavy" is relative, of course - but if you are seeing more than a couple hits per second on a sustained basis you should consult the pointers on this page. In general the suggestions involve how to tune your kernel for the heavier TCP load, hardware/software conflicts that arise, etc.A/UX (Apple's UNIX)
If you are running Apache on A/UX, a page that gives some helpful performance hints (concerning the listen() queue and using virtual hosts) can be found hereBSD-based (BSDI, FreeBSD, etc)
Quick and detailed performance tuning hints for BSD-derived systems.Digital UNIX
- DIGITAL UNIX Tuning Parameters for Web Servers
- We have some newsgroup postings on how to tune Digital UNIX 3.2 and 4.0.
Linux
The most common problem on Linux shows up on heavily-loaded systems where the whole server will appear to freeze for a couple of minutes at a time, and then come back to life. This has been traced to a listen() queue overload - certain Linux implementations have a low value set for the incoming connection queue which can cause problems. Please see our Using Apache on Linux page for more info on how to fix this.SGI
Solaris 2.4
The Solaris 2.4 TCP implementation has a few inherent limitations that only became apparent under heavy loads. This has been fixed to some extent in 2.5 (and completely revamped in 2.6), but for now consult the following URL for tips on how to expand the capabilities if you are finding slowdowns and lags are hurting performance.SunOS 4.x
More information on tuning SOMAXCONN on SunOS can be found at http://www.islandnet.com/~mark/somaxconn.html.More welcome!
If you have tips to contribute, send mail to brian@organic.comApache HTTP Server Version 1.2
07070100012789000081a400000064000000640000000134b16bd8000017c0000000200000001b00000000000000000000002c00000004reloc/htdocs/manual/misc/security_tips.html
Apache HTTP Server Version 1.2
Security Tips for Server Configuration
Some hints and tips on security issues in setting up a web server. Some of the suggestions will be general, others specific to Apache.
Permissions on Log File Directories
When Apache starts, it opens the log files as the user who started the server before switching to the user defined in the User directive. Anyone who has write permission for the directory where any log files are being written to can append pseudo-arbitrary data to any file on the system which is writable by the user who starts Apache. Since the server is normally started by root, you should NOT give anyone write permission to the directory where logs are stored unless you want them to have root access.
Server Side Includes
Server side includes (SSI) can be configured so that users can execute arbitrary programs on the server. That thought alone should send a shiver down the spine of any sys-admin.
One solution is to disable that part of SSI. To do that you use the IncludesNOEXEC option to the Options directive.
Non Script Aliased CGI
Allowing users to execute CGI scripts in any directory should only be considered if;
- You trust your users not to write scripts which will deliberately or accidentally expose your system to an attack.
- You consider security at your site to be so feeble in other areas, as to make one more potential hole irrelevant.
- You have no users, and nobody ever visits your server.
Script Alias'ed CGI
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 script/program for potential security holes.
Most sites choose this option over the non script aliased CGI approach.
CGI in general
Always remember that you must trust the writers of the CGI script/programs or your ability to spot potential security holes in CGI, whether they were deliberate or accidental.
All the CGI scripts will run as the same user, so they have potential to conflict (accidentally or deliberately) with other scripts e.g. User A hates User B, so he writes a script to trash User B's CGI database. One program which can be used to allow scripts to run as different users is suEXEC which is included with Apache as of 1.2 and is called from special hooks in the Apache server code. Another popular way of doing this is with CGIWrap.
Stopping users overriding system wide settings...
To run a really tight ship, you'll want to stop users from setting
up .htaccess files which can override security features
you've configured. Here's one way to do it...
In the server configuration file, put
<Directory />
AllowOverride None
Options None
allow from all
</Directory>
This stops all overrides, Includes and accesses in all directories apart from those named.
Protect server files by default
One aspect of Apache which is occasionally misunderstood is the feature of default access. That is, unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can serve it to clients.
For instance, consider the following example:
- # cd /; ln -s / public_html
- Accessing http://localhost/~root/
This would allow clients to walk through the entire filesystem. To work around this, add the following block to your server's configuration:
<Directory />
Order deny,allow
Deny from all
</Directory>
This will forbid default access to filesystem locations. Add appropriate <Directory> blocks to allow access only in those areas you wish. For example,
<Directory /usr/users/*/public_html>
Order deny,allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order deny,allow
Allow from all
</Directory>
Pay particular attention to the interactions of <Location> and <Directory> directives; for instance, even if <Directory /> denies access, a <Location /> directive might overturn it.
Also be wary of playing games with the UserDir directive; setting it to something like "./" would have the same effect, for root, as the first example above.
Please send any other useful security tips to The Apache Group by filling out a problem report, or by sending mail to apache-bugs@mail.apache.org
Apache HTTP Server Version 1.2
0707010001278a000081a400000064000000640000000134b16bd800002e63000000200000001b00000000000000000000002700000004reloc/htdocs/manual/misc/vif-info.html
Apache HTTP Server Version 1.2
Configuring Multiple IP Addresses
This material is originally from John Ioannidis (ji@polaris.ctr.columbia.edu)
I have condensed it some and applied some corrections for SunOS 4.1.x
courtesy of Chuck Smoko (csmoko@relay.nswc.navy.mil).
Bob Baggerman (bob@bizweb.com)
12 Jan 94
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Ionnidis writes:
This is a topic that comes up once in a while on comp.protocols.tcp-ip
and other newsgroups. The question is, how to get a machine with one
network interface to respond to more than one IP addresses.
I have a solution than might suit you. For my doctoral work (there's
a paper about it in this year's ('91) SIGCOMM, also available for
anonymous FTP from cs.columbia.edu:/pub/ji/sigcomm*.ps.Z), I've
developed what I call the "Virtual Interface" (VIF). To the networking
code, it looks like an interface. It gets ifattach()ed when you open
the /dev/vif* device, and then you can ifconfig it as you like. It
does not have an if_input procedure; it only has an if_output. Packets
that it receives (from higher-level protocols) which have its
IP address, it simply loops back (like any well-behaved if driver).
Packets that it receives that are destined for some other address, it
encapsulates in an encapsulation protocol I call IPIP (IP-within-IP,
protocol number IPPROTO_IPIP == 94), and sends it to another machine
that groks that encapsulation protocol. This feature you won't need,
but here's how to have multiple IP addresses on a machine with a
single real interface:
Let's say your primary interface's IP address is 198.3.2.1, and you
also want it to respond to addresses 198.4.3.2 and 198.5.4.3 (note
that these are three distinct class C addresses in three distinct
class C nets). Here are the ifconfigs:
ifconfig le0 198.3.2.1 up -trailers # config primary interface
ifconfig vif0 198.4.3.2 up # config first virtual interface
route delete net 198.4.3 198.4.3.2 # delete spurious route
route add host 198.4.3.2 198.4.3.2 0 # add route for this i/f
ifconfig vif1 198.5.4.3 up # config second virtual interface
route delete net 198.5.4 198.5.4.3 # delete spurious route
route add host 198.5.4.3 198.5.4.3 0 # add route for this i/f
The route deletes are needed because the ifconfig creates a default
route to the interface's network, which can cause problems; all that's
needed is the (host) route to the interface's address.
Now, get le0's ethernet address (say, 8:0:20:3:2:1), and add the
following static ARP entries:
arp -s 198.4.3.2 8:0:20:3:2:1 pub
arp -s 198.5.4.3 8:0:20:3:2:1 pub
This will cause any ARP requests for the VIF addresses to be replied
with your machine's ethernet address.
Now, make sure your default route is to your segment's gateway,
through the real interface. Finally, make sure your routers and/or
hosts on the same segment as yours know that 198.4.3.2 and 198.5.4.3
are on that cable.
Here's what you've accomplished.
ARP requests for any of your host's addresses will be replied to with
the host's ethernet address (the real one, because that's what it is,
the virtual ones because of the public static arp entries). Packets
reaching your host with any of these addresses will be accepted by the
ip_input routine because they match the address of one of the host's
interfaces. Packets leaving your host can have any of its addresses
(real and virtual).
The code for vif follows. To use it, put the stuff in netinet/if_vif.c
and netinet/if_vif.h, configure your kernel with the number of
virtual interfaces you want using a line like:
pseudo-device vif4 # Virtual IP interface
in your configuration file, and the line
netinet/if_vif.c optional vif device-driver
in the "files" file. Also, add the appropriate entries in conf.c, so
that you can access the if_attach() routine when you open the device:
-------------------------- conf.c------------------------------------------
add this in the appropriate place in the headers of conf.c:
--------------------
#include "vif.h"
#if NVIF > 0
int vifopen(), vifclose(), vifread(), vifwrite(), vifselect(), vifioctl();
#else
#define vifopen nodev
#define vifclose nodev
#define vifread nodev
#define vifwrite nodev
#define vifselect nodev
#define vifioctl nodev
#endif
--------------------
then, way down in the definition for cdevsw[]:
--------------------
vifopen, vifclose, vifread, vifwrite, /*14*/
vifioctl, nodev, nodev, 0,
0, nodev,
--------------------
Make sure you remember the correct major device number, 14 in this case!
---------------------------------------------------------------------------
Finally, here's the code. It has the tunneling pieces removed (you
need more code to use that anyway), and it comes from a Mach 2.6
kernel; it should compile on any Berkeley-derived unix with minor
changes (most likely only in the includes).
---------------------netinet/if_vif.h--------------------------------------
typedef struct
{
struct ifnet vif_if;
struct ifnet *vif_sif; /* slave interface */
int vif_flags;
} vif_softc_t;
#define VIFMTU (1024+512)
---------------------------------------------------------------------------
and
---------------------netinet/if_vif.c--------------------------------------
/*
* Virtual IP interface module.
*/
#include "param.h"
#include "../sys/systm.h"
#include "../sys/mbuf.h"
#include "../sys/socket.h"
#include "../sys/errno.h"
#include "../sys/ioctl.h"
#include "../net/if.h"
#include "../net/netisr.h"
#include "../net/route.h"
#ifdef INET
#include "../netinet/in.h"
#include "../netinet/in_systm.h"
#include "../netinet/in_var.h"
#include "../netinet/ip.h"
#endif
#include "in_pcb.h"
#include "vif.h"
typedef struct
{
struct ifnet vif_if;
struct ifnet *vif_sif; /* slave interface */
int vif_flags;
} vif_softc_t;
#define VIFMTU (1024+512)
vif_softc_t vif_softc[NVIF];
int vifs_inited = 0;
vifattach()
{
register int i;
register struct ifnet *ifp;
int vifoutput(), vififioctl();
for (i=0; i<NVIF; i++)
{
ifp = &vif_softc[i].vif_if;
ifp->if_name = "vif";
ifp->if_unit = i;
ifp->if_mtu = VIFMTU;
ifp->if_flags = IFF_LOOPBACK | IFF_NOARP;
ifp->if_ioctl = vififioctl;
ifp->if_output = vifoutput;
if_attach(ifp);
}
}
vifopen(dev, flag)
int dev, flag;
{
int unit;
if (!vifs_inited)
{
vifattach();
vifs_inited = 1;
printf("vif initialized\n");
}
unit = minor(dev);
if ((unit < 0) || (unit >= NVIF))
{
return ENXIO;
}
return 0;
}
vifclose(dev, flag)
int dev, flag;
{
return 0;
}
vifread()
{
return ENXIO;
}
vifwrite()
{
return ENXIO;
}
vifselect()
{
return ENXIO;
}
vifoutput(ifp, m0, dst)
struct ifnet *ifp;
register struct mbuf *m0;
struct sockaddr *dst;
{
int s;
register struct ifqueue *ifq;
struct mbuf *m;
struct sockaddr_in *din;
if (dst->sa_family != AF_INET)
{
printf("%s%d: can't handle af%d\n",
ifp->if_name, ifp->if_unit,
dst->sa_family);
m_freem(m0);
return (EAFNOSUPPORT);
}
din = (struct sockaddr_in *)dst;
if (din->sin_addr.s_addr == IA_SIN(ifp->if_addrlist)->sin_addr.s_addr)
{
/* printf("%s%d: looping\n", ifp->if_name, ifp->if_unit); */
/*
* Place interface pointer before the data
* for the receiving protocol.
*/
if (m0->m_off <= MMAXOFF &&
m0->m_off >= MMINOFF + sizeof(struct ifnet *)) {
m0->m_off -= sizeof(struct ifnet *);
m0->m_len += sizeof(struct ifnet *);
} else {
MGET(m, M_DONTWAIT, MT_HEADER);
if (m == (struct mbuf *)0)
return (ENOBUFS);
m->m_off = MMINOFF;
m->m_len = sizeof(struct ifnet *);
m->m_next = m0;
m0 = m;
}
*(mtod(m0, struct ifnet **)) = ifp;
s = splimp();
ifp->if_opackets++;
ifq = &ipintrq;
if (IF_QFULL(ifq)) {
IF_DROP(ifq);
m_freem(m0);
splx(s);
return (ENOBUFS);
}
IF_ENQUEUE(ifq, m0);
schednetisr(NETISR_IP);
ifp->if_ipackets++;
splx(s);
return (0);
}
return EHOSTUNREACH;
}
/*
* Process an ioctl request.
*/
/* ARGSUSED */
vififioctl(ifp, cmd, data)
register struct ifnet *ifp;
int cmd;
caddr_t data;
{
int error = 0;
switch (cmd) {
case SIOCSIFADDR:
ifp->if_flags |= IFF_UP;
/*
* Everything else is done at a higher level.
*/
break;
default:
error = EINVAL;
}
return (error);
}
vifioctl(dev, cmd, arg, mode)
dev_t dev;
int cmd;
caddr_t arg;
int mode;
{
int unit;
unit = minor(dev);
if ((unit < 0) || (unit >= NVIF))
return ENXIO;
return EINVAL;
}
----------------------------------------------------------------------------
To use it, compile your kernel, and reboot. Then create the vif
device:
# mknod /dev/vif c 14 0
(or whatever major number it ended up being), and echo something into
it:
# echo > /dev/vif
This will cause the device to be opened, which will if_attach the
interfaces. If you feel like playing with the code, you may want to
kmem_alloc() the vif_softc structrure at open time, and use the minor
number of the device to tell it how many interfaces to create.
Now you can go ahead and ifconfig etc.
I'll be happy to answer minor questions, and hear about success and
failure stories, but I cannot help you if you don't already know how
to hack kernels.
Good luck!
/ji
In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027
Note: there is also a commercial-product-turned-freeware called "Col. Patch" which does this as a loadable kernel module for SunOS 4.1.3_U1.
Apache HTTP Server Version 1.2
0707010001278b000081a400000064000000640000000134b16bd900000829000000200000001b00000000000000000000002f00000004reloc/htdocs/manual/misc/windoz_keepalive.html
Apache HTTP Server Version 1.2
HTTP/1.1 KeepAlive problems with Netscape 3.0
Date: Mon, 1 Jul 1996 16:03:06 -0700 (PDT) From: Alexei Kosut <akosut@organic.com> To: Apache Group Subject: Re: keepalive and windoze Good news and good news (of a sort).. I was able to snag a Windows 95 machine here at Organic, and tried out some things: 1) On Netscape 3.0b4, I was able to reproduce the bug, each and every time. It's really simple: go to the Network Setup panel. Set it to "Connect Every Time" and only let it have 1 connection at once (this may not be neccessary, but it's helpeful). Then load an image that's kept-alive. Then wait until the connection times out (this depends on the server - 10-30 seconds, except for MIIS, which never times out, near as I can tell). Then hit reload. It will hang. (actually, once it crashed). 2) This happens with all forms of server. Apache 1.1, Netscape 2.0, Spyglass 1.2, NCSA 1.5 (although, as stated, I couldn't test MIIS). 3) Netscape 3.0b5 does, indeed, *not* have this bug. At least, I couldn't get it to perform such. Yipee. So, we just put up a note on the web page. Make sure we say that all the servers have the bug, it's a Windows bug, and Netscape Navigator 3.0b5 works around it. That way, no one can yell at us. Yes? -- Alexei Kosut <akosut@organic.com> The Apache HTTP Server http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Apache HTTP Server Version 1.2
07070100002cb0000041ed00000064000000640000000234e8a36e00000000000000200000001b00000000000000000000001800000004reloc/htdocs/manual/mod 07070100002cb1000081a400000064000000640000000134b16bd40000f0df000000200000001b00000000000000000000002200000004reloc/htdocs/manual/mod/core.html
Apache HTTP Server Version 1.2
Apache Core Features
These configuration parameters control the core Apache features, and are always available.- AccessConfig
- AccessFileName
- AddModule
- AllowOverride
- AuthName
- AuthType
- BindAddress
- ClearModuleList
- DefaultType
- <Directory>
- DocumentRoot
- ErrorDocument
- ErrorLog
- <Files>
- Group
- HostNameLookups
- IdentityCheck
- <IfModule>
- KeepAlive
- KeepAliveTimeout
- <Limit>
- Listen
- <Location>
- LockFile
- MaxClients
- MaxKeepAliveRequests
- MaxRequestsPerChild
- MaxSpareServers
- MinSpareServers
- Options
- PidFile
- Port
- require
- ResourceConfig
- RLimitCPU
- RLimitMEM
- RLimitNPROC
- Satisfy
- ScoreBoardFile
- SendBufferSize
- ServerAdmin
- ServerAlias
- ServerName
- ServerPath
- ServerRoot
- ServerType
- StartServers
- TimeOut
- User
- <VirtualHost>
AccessConfig directive
Syntax: AccessConfig filenameDefault:
AccessConfig conf/access.confContext: server config, virtual host
Status: core
The server will read this file for more directives after reading the ResourceConfig file. Filename is relative to the ServerRoot. This feature can be disabled using:
AccessConfig /dev/nullAccessFileName directive
Syntax: AccessFileName filenameDefault:
AccessFileName .htaccessContext: server config, virtual host
Status: core
When returning a document to the client the server looks for an access control file with this name in every directory of the path to the document, if access control files are enabled for that directory. For example:
AccessFileName .acl
<Directory />
AllowOverride None
</Directory>AddModule directive
Syntax: AddModule module module ...Context: server config
Status: core
Compatibility: AddModule is only available in Apache 1.2 and later
The server can have modules compiled in which are not actively in use. This directive can be used to enable the use of those modules. The server comes with a pre-loaded list of active modules; this list can be cleared with the ClearModuleList directive.
AllowOverride directive
Syntax: AllowOverride override override ...Default:
AllowOverride AllContext: directory
Status: core
When the server finds an .htaccess file (as specified by AccessFileName) it needs to know which directives declared in that file can override earlier access information.
Override can be set to None, in which case the server
will not read the file, All in which case the server will
allow all the directives, or one or more of the following:
- AuthConfig
- Allow use of the authorization directives (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, require, etc.).
- FileInfo
- Allow use of the directives controlling document types (AddEncoding, AddLanguage, AddType, DefaultType, ErrorDocument, LanguagePriority, etc.).
- Indexes
- Allow use of the directives controlling directory indexing (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, etc.).
- Limit
- Allow use of the directives controlling host access (allow, deny and order).
- Options
- Allow use of the directives controlling specific directory features (Options and XBitHack).
AuthName directive
Syntax: AuthName auth-domainContext: directory, .htaccess
Override: AuthConfig
Status: core
This directive sets the name of the authorization realm for a directory. This realm is given to the client so that the user knows which username and password to send. It must be accompanied by AuthType and require directives, and directives such as AuthUserFile and AuthGroupFile to work.
AuthType directive
Syntax: AuthType typeContext: directory, .htaccess
Override: AuthConfig
Status: core
This directive selects the type of user authentication for a directory.
Only Basic is currently implemented.
It must be accompanied by AuthName and
require directives, and directives such as
AuthUserFile and
AuthGroupFile to work.
BindAddress directive
Syntax: BindAddress saddrDefault:
BindAddress *Context: server config
Status: core
A Unix® http server can either listen for connections to every IP address of the server machine, or just one IP address of the server machine. Saddr can be
If the value is *, then the server will listen for connections on every IP address, otherwise it will only listen on the IP address specified.This option can be used as an alternative method for supporting virtual hosts instead of using <VirtualHost> sections.
See Also:
DNS Issues
See Also:
Setting which addresses and ports Apache uses
ClearModuleList directive
Syntax: ClearModuleListContext: server config
Status: core
Compatibility: ClearModuleList is only available in Apache 1.2 and later
The server comes with a built-in list of active modules. This directive clears the list. It is assumed that the list will then be re-populated using the AddModule directive.
DefaultType directive
Syntax: DefaultType mime-typeDefault:
DefaultType text/htmlContext: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: core
There will be times when the server is asked to provide a document whose type cannot be determined by its MIME types mappings.
The server must inform the client of the content-type of the document, so in
the event of an unknown type it uses the DefaultType. For
example:
DefaultType image/gif<Directory> directive
Syntax: <Directory directory> ... </Directory>Context: server config, virtual host
Status: Core.
<Directory> and </Directory> are used to enclose a group of directives which will apply only to the named directory and sub-directories of that directory. Any directive which is allowed in a directory context may be used. Directory is either the full path to a directory, or a wild-card string. In a wild-card string, `?' matches any single character, and `*' matches any sequences of characters. Example:
<Directory /usr/local/httpd/htdocs> Options Indexes FollowSymLinks </Directory>
Apache 1.2 and above:
Extended regular expressions can also be used, with the addition of the
~ character. For example:
<Directory ~ "^/www/.*/[0-9]{3}">
would match directories in /www/ that consisted of three numbers.
If multiple directory sections match the directory (or its parents) containing a document, then the directives are applied in the order of shortest match first, interspersed with the directives from the .htaccess files. For example, with
<Directory />
AllowOverride None
</Directory>
<Directory /home/*>
AllowOverride FileInfo
</Directory>/home/web/dir/doc.html the
steps are:
Note that the default Apache access for <Directory /> is Allow from All. This means that Apache will serve any file mapped from an URL. It is recommended that you change this with a block such as
<Directory />
Order Deny,Allow
Deny from All
</Directory>
and then override this for directories you want accessible. See the Security Tips page for more details.
The directory sections typically occur in the access.conf file, but they may appear in any configuration file. <Directory> directives cannot nest, and cannot appear in a <Limit> section.DocumentRoot directive
Syntax: DocumentRoot directory-filenameDefault:
DocumentRoot
/usr/local/etc/httpd/htdocsContext: server config, virtual host
Status: core
This directive sets the directory from which httpd will serve files. Unless matched by a directive like Alias, the server appends the path from the requested URL to the document root to make the path to the document. Example:
DocumentRoot /usr/webhttp://www.my.host.com/index.html refers
to /usr/web/index.html.
There appears to be a bug in mod_dir which causes problems when the DocumentRoot has a trailing slash (i.e. "DocumentRoot /usr/web/") so please avoid that.
ErrorDocument directive
Syntax: ErrorDocument error-code documentContext server config, virtual host, directory, .htaccess
Status: core
Override: FileInfo
Compatibility: The directory and .htaccess contexts are only available in Apache 1.1 and later.
In the event of a problem or error, Apache can be configured to do one of four things,
- output a simple hardcoded error message
- output a customized message
- redirect to a local URL to handle the problem/error
- redirect to an external URL to handle the problem/error
The first option is the default, while options 2-4 are configured
using the ErrorDocument directive, which is followed by
the HTTP response code and a message or URL.
Messages in this context begin with a single quote
("), which does not form part of the message itself.
Apache will sometimes offer additional information regarding the
problem/error.
URLs can begin with a slash (/) for local URLs, or be a full URL which the client can resolve. Examples:
ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today
Note that when you specify an ErrorDocument that
points to a remote URL (ie. anything with a method such as "http" in
front of it) Apache will send a redirect to the client to tell it
where to find the document, even if the document ends up being
on the same server.. This has several implications, the
most important being that if you use an "ErrorDocument 401"
directive then it must refer to a local document. This results
from the nature of the HTTP basic authentication scheme.
See Also: documentation of customizable responses.
ErrorLog directive
Syntax: ErrorLog filenameDefault:
ErrorLog logs/error_logContext: server config, virtual host
Status: core
The error log directive sets the name of the file to which the server will log any errors it encounters. If the filename does not begin with a slash (/) then it is assumed to be relative to the ServerRoot. Example:
ErrorLog /dev/nullSECURITY: See the security tips document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server.
<Files>
Syntax: <Files filename> ... </Files>Context: server config, virtual host, htaccess
Status: core
Compatibility: only available in Apache 1.2 and above.
The <Files> directive provides for access control by
filename. It is comparable to the <Directory> directive and
<Location> directives. It
should be matched with a </Files> directive. Directives that
apply to the filename given should be listed
within. <Files> sections are processed in the
order they appear in the configuration file, after the
<Directory> sections and .htaccess files are
read, but before <Location> sections.
The filename argument should include a filename, or a
wild-card string, where `?' matches any single character, and `*' matches any
sequences of characters. Extended regular expressions can also be used, with the addition of
the ~ character. For example:
<Files ~ "\.(gif|jpe?g|png)$">would match most common Internet graphics formats.
Note that unlike <Directory> and <Location> sections,
<Files> sections can be used inside .htaccess
files. This allows users to control access to their own files, at a
file-by-file level. When used in an .htaccess file, if the
filename does not begin with a / character,
the directory being applied will be prefixed automatically.
Group directive
Syntax: Group unix-groupDefault:
Group #-1Context: server config, virtual host
Status: core
The Group directive sets the group under which the server will answer requests. In order to use this directive, the stand-alone server must be run initially as root. Unix-group is one of:
- A group name
- Refers to the given group by name.
- # followed by a group number.
- Refers to a group by its number.
nobody, but this is not always
possible or desirable.Note: if you start the server as a non-root user, it will fail to change to the specified group, and will instead continue to run as the group of the original user.
Special note: Use of this directive in <VirtualHost> requires a properly configured suEXEC wrapper. When used inside a <VirtualHost> in this manner, only the group that CGIs are run as is affected. Non-CGI requests are still processed as the group specified in the main Group directive.
SECURITY: See User for a discussion of the security considerations.
HostNameLookups directive
Syntax: HostNameLookups booleanDefault:
HostNameLookups onContext: server config, virtual host
Status: core
This directive enables DNS lookups so that host names can be logged.
Having this directive set on also enables the use of names
in <Limit> blocks for access control.
Heavily loaded sites should set this directive off, since DNS
lookups can take considerable amounts of time. The utility logresolve,
provided in the /support directory, can be used to look up host names
from logged IP addresses offline.
IdentityCheck directive
Syntax: IdentityCheck booleanDefault:
IdentityCheck offContext: server config, virtual host
Status: core
This directive enables RFC1413-compliant logging of the remote user name
for each connection, where the client machine runs identd or something similar.
This information is logged in the access log. Boolean is either
on or off.
The information should not be trusted in any way except for rudimentary usage tracking.
Note that this can cause serious latency problems accessing your server since every request requires one of these lookups to be performed. When firewalls are involved each lookup might possibly fail and add 30 seconds of latency to each hit. So in general this is not very useful on public servers accessible from the Internet.
<IfModule>
Syntax: <IfModule [!]module-name> ... </IfModule>Default: None
Context: all
Status: Core Compatibility: ScriptLog is only available in 1.2 and later.
The <IfModule test>...</IfModule> section is used to mark directives that are conditional. The directives within an IfModule section are only processed if the test is true. If test is false, everything between the start and end markers is ignored.
The test in the <IfModule> section directive can be one of two forms:
- module name
- !module name
In the former case, the directives between the start and end markers are only processed if the module named module name is compiled in to Apache. The second format reverses the test, and only processes the directives if module name is not compiled in.
The module name argument is a module name as given as the file
name of the module, at the time it was compiled. For example,
mod_rewrite.c.
<IfModule> sections are nest-able, which can be used to implement simple multiple-module tests.
KeepAlive
Syntax: (Apache 1.1) KeepAlive max-requestsDefault: (Apache 1.1)
KeepAlive 5Syntax: (Apache 1.2) KeepAlive on/off
Default: (Apache 1.2)
KeepAlive OnContext: server config
Status: Core
Compatibility: KeepAlive is only available in Apache 1.1 and later.
This directive enables Keep-Alive support.
Apache 1.1: Set max-requests
to the maximum number of requests you want Apache to entertain per
request. A limit is imposed to prevent a client from hogging your
server resources. Set this to 0 to disable support.
Apache 1.2 and later: Set to "On" to enable persistent connections, "Off" to disable. See also the MaxKeepAliveRequests directive.
KeepAliveTimeout
Syntax: KeepAliveTimeout secondsDefault:
KeepAliveTimeout 15Context: server config
Status: Core
Compatibility: KeepAliveTimeout is only available in Apache 1.1 and later.
The number of seconds Apache will wait for a subsequent request before
closing the connection. Once a request has been received, the timeout
value specified by the Timeout directive
applies.
Listen
Syntax: Listen [IP address:]port numberContext: server config
Status: core
Compatibility: Listen is only available in Apache 1.1 and later.
The Listen directive instructs Apache to listen to more than one IP address or port; by default it responds to requests on all IP interfaces, but only on the port given by the Port directive.
See Also:
DNS Issues
See Also:
Setting which addresses and ports Apache uses
See Also:
Known Bugs
<Limit> directive
Syntax: <Limit method method ... > ... </Limit>Context: any
Status: core
<Limit> and </Limit> are used to enclose a group of access control directives which will then apply only to the specified access methods, where method is any valid HTTP method. Any directive except another <Limit> or <Directory> may be used; the majority will be unaffected by the <Limit>. Example:
<Limit GET POST>
require valid-user
</Limit><Location>
Syntax: <Location URL> ... </Location>Context: server config, virtual host
Status: core
Compatibility: Location is only available in Apache 1.1 and later.
The <Location> directive provides for access control by
URL. It is comparable to the <Directory> directive, and
should be matched with a </Location> directive. Directives that
apply to the URL given should be listed
within. <Location> sections are processed in the
order they appear in the configuration file, after the
<Directory> sections and .htaccess files are
read.
Note that, due to the way HTTP functions, URL prefix
should, save for proxy requests, be of the form /path/,
and should not include the http://servername. It doesn't
necessarily have to protect a directory (it can be an individual
file, or a number of files), and can include wild-cards. In a wild-card
string, `?' matches any single character, and `*' matches any
sequences of characters.
Apache 1.2 and above:
Extended regular expressions can also be used, with the addition of
the
~ character. For example:
<Location ~ "/(extra|special)/data">
would match URLs that contained the substring "/extra/data" or "/special/data".
The Location functionality is especially useful when
combined with the SetHandler directive. For example, to enable status requests, but allow them only
from browsers at foo.com, you might use:
<Location /status>
SetHandler server-status
order deny,allow
deny from all
allow from .foo.com
</Location>
LockFile
Syntax: LockFile filenameDefault:
LockFile logs/accept.lockContext: server config
Status: core
The LockFile directive sets the path to the lockfile used when
Apache is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or
USE_FLOCK_SERIALIZED_ACCEPT. This directive should normally be
left at its default value. The main reason for changing it is if
the logs directory is NFS mounted, since the lockfile
should be stored on a local disk if possible. The PID of the main
server process is automatically appended to the filename.
MaxClients
Syntax: MaxClients numberDefault:
MaxClients 256Context: server config
Status: core
The MaxClients directive sets the limit on the number of simultaneous requests that can be supported; not more than this number of child server processes will be created.
MaxKeepAliveRequests
Syntax: MaxKeepAliveRequests numberDefault:
MaxKeepAliveRequests 100Context: server config
Status: core
Compatibility: Only available in Apache 1.2 and later.
The MaxKeepAliveRequests directive limits the number of requests
allowed per connection when KeepAlive is
on. If it is set to "0", unlimited requests will be
allowed. We recommend that this setting be kept to a high value for
maximum server performance.
MaxRequestsPerChild directive
Syntax: MaxRequestsPerChild number
Default: MaxRequestsPerChild 0
Context: server config
Status: core
The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child server process will handle. After MaxRequestsPerChild requests, the child process will die. If MaxRequestsPerChild is 0, then the process will never expire.
Setting MaxRequestsPerChild to a non-zero limit has two beneficial effects:
- it limits the amount of memory that process can consume by (accidental) memory leakage;
- by giving processes a finite lifetime, it helps reduce the number of processes when the server load reduces.
MaxSpareServers directive
Syntax: MaxSpareServers numberDefault:
MaxSpareServers 10Context: server config
Status: core
The MaxSpareServers directive sets the desired maximum number of idle child server processes. An idle process is one which is not handling a request. If there are more than MaxSpareServers idle, then the parent process will kill off the excess processes.
Tuning of this parameter should only be necessary on very busy sites. Setting this parameter to a large number is almost always a bad idea.
See also MinSpareServers and StartServers.
MinSpareServers directive
Syntax: MinSpareServers numberDefault:
MinSpareServers 5Context: server config
Status: core
The MinSpareServers directive sets the desired minimum number of idle child server processes. An idle process is one which is not handling a request. If there are fewer than MinSpareServers idle, then the parent process creates new children at a maximum rate of 1 per second.
Tuning of this parameter should only be necessary on very busy sites. Setting this parameter to a large number is almost always a bad idea.
See also MaxSpareServers and StartServers.
Options directive
Syntax: Options [+|-]option [+|-]option ...Context: server config, virtual host, directory, .htaccess
Override: Options
Status: core
The Options directive controls which server features are available in a particular directory.
option can be set to None, in which case none of
the extra features are enabled, or one or more of the following:
- All
- All options except for MultiViews.
- ExecCGI
- Execution of CGI scripts is permitted.
- FollowSymLinks
-
The server will follow symbolic links in this directory.
Note: even though the server follows the symlink it does not
change the pathname used to match against
<Directory>sections. - Includes
- Server-side includes are permitted.
- IncludesNOEXEC
- Server-side includes are permitted, but the #exec command and #include of CGI scripts are disabled.
- Indexes
- If a URL which maps to a directory is requested, and the there is no DirectoryIndex (e.g. index.html) in that directory, then the server will return a formatted listing of the directory.
- MultiViews
- Content negotiated MultiViews are allowed.
- SymLinksIfOwnerMatch
- The server will only follow symbolic links for which the target file or directory is owned by the same user id as the link.
Options could apply to a directory,
then the most specific one is taken complete; the options are not
merged. However if all the options on the Options
directive are preceded by a + or - symbol, the options are
merged. Any options preceded by a + are added to the options
currently in force, and any options preceded by a - are removed from
the options currently in force. For example, without any + and - symbols:
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options Includes
</Directory>
Includes will be set for the /web/docs/spec
directory. However if the second Options directive uses the +
and - symbols:
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>
FollowSymLinks and Includes
are set for the /web/docs/spec directory.
PidFile directive
Syntax: PidFile filenameDefault:
PidFile logs/httpd.pidContext: server config
Status: core
The PidFile directive sets the file to which the server records the process id of the daemon. If the filename does not begin with a slash (/) then it is assumed to be relative to the ServerRoot. The PidFile is only used in standalone mode.
It is often useful to be able to send the server a signal, so that it closes and then reopens its ErrorLog and TransferLog, and re-reads its configuration files. This is done by sending a SIGHUP (kill -1) signal to the process id listed in the PidFile.
The PidFile is subject to the same warnings about log file placement and security.
Port directive
Syntax: Port numberDefault:
Port 80Context: server config
Status: core
Number is a number from 0 to 65535; some port numbers (especially below
1024) are reserved for particular protocols. See /etc/services
for a list of some defined ports; the standard port for the http protocol
is 80.
The Port directive has two behaviors, the first of which is necessary for NCSA backwards compatibility (and which is confusing in the context of Apache).
-
In the absence of any Listen or
BindAddress directives specifying a port number,
the Port directive sets the network port on which the server listens.
If there are any Listen or BindAddress directives specifying
:numberthen Port has no effect on what address the server listens at. - The Port directive
sets the
SERVER_PORTenvironment variable (for CGI and SSI), and is used when the server must generate a URL that refers to itself (for example when creating an external redirect to itself).
The primary behaviour of Port should be considered to be similar to that of the ServerName directive. The ServerName and Port together specify what you consider to be the canonical address of the server.
Port 80 is one of Unix's special ports. All ports numbered below 1024 are reserved for system use, i.e. regular (non-root) users cannot make use of them; instead they can only use higher port numbers. To use port 80, you must start the server from the root account. After binding to the port and before accepting requests, Apache will change to a low privileged user as set by the User directive.
If you cannot use port 80, choose any other unused port. Non-root users will have to choose a port number higher than 1023, such as 8000.
SECURITY: if you do start the server as root, be sure not to set User to root. If you run the server as root whilst handling connections, your site may be open to a major security attack.
require directive
Syntax: require entity-name entity entity...Context: directory, .htaccess
Override: AuthConfig
Status: core
This directive selects which authenticated users can access a directory. The allowed syntaxes are:
- require user userid userid ...
Only the named users can access the directory.
- require group group-name group-name ...
Only users in the named groups can access the directory.
- require valid-user
All valid users can access the directory.
If require appears in a <Limit>
section, then it restricts access to the named methods, otherwise
it restricts access for all methods. Example:
AuthType Basic
AuthName somedomain
AuthUserFile /web/users
AuthGroupFile /web/groups
<Limit GET POST>
require group admin
</Limit>
ResourceConfig directive
Syntax: ResourceConfig filenameDefault:
ResourceConfig conf/srm.confContext: server config, virtual host
Status: core
The server will read this file for more directives after reading the httpd.conf file. Filename is relative to the ServerRoot. This feature can be disabled using:
ResourceConfig /dev/nullSee also AccessConfig.
RLimitCPU directive
Syntax: RLimitCPU # or 'max' [# or 'max']Default:
Unset uses operating system defaultsContext: server config, virtual host
Status: core
Compatibility: RLimitCPU is only available in Apache 1.2 and later
Takes 1 or 2 parameters. The first parameter sets the soft resource limit for all processes and the second parameter sets the maximum resource limit. Either parameter can be a number, or max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration. Raising the maximum resource limit requires that the server is running as root, or in the initial startup phase.
CPU resource limits are expressed in seconds per process.
See also RLimitMEM or RLimitNPROC.
RLimitMEM directive
Syntax: RLimitMEM # or 'max' [# or 'max']Default:
Unset uses operating system defaultsContext: server config, virtual host
Status: core
Compatibility: RLimitMEM is only available in Apache 1.2 and later
Takes 1 or 2 parameters. The first parameter sets the soft resource limit for all processes and the second parameter sets the maximum resource limit. Either parameter can be a number, or max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration. Raising the maximum resource limit requires that the server is running as root, or in the initial startup phase.
Memory resource limits are expressed in bytes per process.
See also RLimitCPU or RLimitNPROC.
RLimitNPROC directive
Syntax: RLimitNPROC # or 'max' [# or 'max']Default:
Unset uses operating system defaultsContext: server config, virtual host
Status: core
Compatibility: RLimitNPROC is only available in Apache 1.2 and later
Takes 1 or 2 parameters. The first parameter sets the soft resource limit for all processes and the second parameter sets the maximum resource limit. Either parameter can be a number, or max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration. Raising the maximum resource limit requires that the server is running as root, or in the initial startup phase.
Process limits control the number of processes per user.
Note: If CGI processes are not running under userids other than the web server userid, this directive will limit the number of processes that the server itself can create. Evidence of this situation will be indicated by cannot fork messages in the error_log.
See also RLimitMEM or RLimitCPU.
Satisfy
Syntax: Satisfy 'any' or 'all'Default: Satisfy all
Context: directory, .htaccess
Status: core
Compatibility: Satisfy is only available in Apache 1.2 and later
Access policy if both allow and require used. The parameter can be either 'all' or 'any'. This directive is only useful if access to a particular area is being restricted by both username/password and client host address. In this case the default behavior ("all") is to require that the client passes the address access restriction and enters a valid username and password. With the "any" option the client will be granted access if they either pass the host restriction or enter a valid username and password. This can be used to password restrict an area, but to let clients from particular addresses in without prompting for a password.
ScoreBoardFile directive
Syntax: ScoreBoardFile filenameDefault:
ScoreBoardFile logs/apache_statusContext: server config
Status: core
The ScoreBoardFile directive is required on some architectures to place a file that the server will use to communicate between its children and the parent. The easiest way to find out if your architecture requires a scoreboard file is to run Apache and see if it creates the file named by the directive. If your architecture requires it then you must ensure that this file is not used at the same time by more than one invocation of Apache.
If you have to use a ScoreBoardFile then you may see improved speed by placing it on a RAM disk. But be careful that you heed the same warnings about log file placement and security.
Apache 1.2 and above:
Linux 1.x users might be able to add -DHAVE_SHMGET to
the EXTRA_CFLAGS in your Configuration. This
might work with some 1.x installations, but won't work with all of
them.
SVR4 users should consider adding -DHAVE_SHMGET to the
EXTRA_CFLAGS in your Configuration. This
is believed to work, but we were unable to test it in time for 1.2
release.
See Also: Stopping and Restarting Apache
SendBufferSize directive
Syntax: SendBufferSize bytesContext: server config
Status: core
The server will set the TCP buffer size to the number of bytes specified. Very useful to increase past standard OS defaults on high speed high latency (i.e. 100ms or so, such as transcontinental fast pipes)
ServerAdmin directive
Syntax: ServerAdmin email-addressContext: server config, virtual host
Status: core
The ServerAdmin sets the e-mail address that the server includes in any error messages it returns to the client.
It may be worth setting up a dedicated address for this, e.g.
ServerAdmin www-admin@foo.bar.comServerAlias directive
Syntax: ServerAlias host1 host2 ...Context: virtual host
Status: core
Compatibility: ServerAlias is only available in Apache 1.1 and later.
The ServerAlias directive sets the alternate names for a host, for use with Host-header based virtual hosts.
See Also: In-depth description of Virtual Host matching
ServerName directive
Syntax: ServerName fully-qualified domain nameContext: server config, virtual host
Status: core
The ServerName directive sets the hostname of the server; this is only used when creating redirection URLs. If it is not specified, then the server attempts to deduce it from its own IP address; however this may not work reliably, or may not return the preferred hostname. For example:
ServerName www.wibble.commonster.wibble.com.
See Also: DNS Issues
ServerPath directive
Syntax: ServerPath pathnameContext: virtual host
Status: core
Compatibility: ServerPath is only available in Apache 1.1 and later.
The ServerPath directive sets the legacy URL pathname for a host, for use with Host-header based virtual hosts.
See Also: In-depth description of Virtual Host matching
ServerRoot directive
Syntax: ServerRoot directory-filenameDefault:
ServerRoot /usr/local/etc/httpdContext: server config
Status: core
The ServerRoot directive sets the directory in which the server lives.
Typically it will contain the subdirectories conf/ and
logs/. Relative paths for other configuration files are taken
as relative to this directory.
See also the -d option to httpd.
ServerType directive
Syntax: ServerType typeDefault:
ServerType standaloneContext: server config
Status: core
The ServerType directive sets how the server is executed by the system. Type is one of
- inetd
- The server will be run from the system process inetd; the command to start
the server is added to
/etc/inetd.conf - standalone
- The server will run as a daemon process; the command to start the server
is added to the system startup scripts. (
/etc/rc.localor/etc/rc3.d/....)
Standalone is the most common setting for ServerType since it is far more efficient. The server is started once, and services all subsequent connections. If you intend running Apache to serve a busy site, standalone will probably be your only option.
SECURITY: if you are paranoid about security, run in inetd mode. Security cannot be guaranteed in either, but whilst most people are happy to use standalone, inetd is probably least prone to attack.
StartServers directive
Syntax: StartServers numberDefault:
StartServers 5Context: server config
Status: core
The StartServers directive sets the number of child server processes created on startup. As the number of processes is dynamically controlled depending on the load, there is usually little reason to adjust this parameter.
See also MinSpareServers and MaxSpareServers.
TimeOut directive
Syntax: TimeOut numberDefault:
TimeOut 300Context: server config
Status: core
The TimeOut directive currently defines the amount of time Apache will wait for three things:
- The total amount of time it takes to receive a GET request.
- The amount of time between receipt of TCP packets on a POST or PUT request.
- The amount of time between ACKs on transmissions of TCP packets in responses.
User directive
Syntax: User unix-useridDefault:
User #-1Context: server config, virtual host
Status: core
The User directive sets the userid as which the server will answer requests. In order to use this directive, the standalone server must be run initially as root. Unix-userid is one of:
- A username
- Refers to the given user by name.
- # followed by a user number.
- Refers to a user by their number.
nobody, but this is not always possible or desirable.Notes: If you start the server as a non-root user, it will fail to change to the lesser privileged user, and will instead continue to run as that original user. If you do start the server as root, then it is normal for the parent process to remain running as root.
Special note: Use of this directive in <VirtualHost> requires a properly configured suEXEC wrapper. When used inside a <VirtualHost> in this manner, only the user that CGIs are run as is affected. Non-CGI requests are still processed with the user specified in the main User directive.
SECURITY: Don't set User (or Group) to
root unless you know exactly what you are doing, and what the
dangers are.
<VirtualHost> directive
Syntax: <VirtualHost addr[:port] ...> ... </VirtualHost>Context: server config
Status: Core.
Compatibility: Non-IP address-based Virtual Hosting only available in Apache 1.1 and later.
Compatibility: Multiple address support only available in Apache 1.2 and later.
<VirtualHost> and </VirtualHost> are used to enclose a group of directives which will apply only to a particular virtual host. Any directive which is allowed in a virtual host context may be used. When the server receives a request for a document on a particular virtual host, it uses the configuration directives enclosed in the <VirtualHost> section. Addr can be
Example:
<VirtualHost 10.1.2.3>
ServerAdmin webmaster@host.foo.com
DocumentRoot /www/docs/host.foo.com
ServerName host.foo.com
ErrorLog logs/host.foo.com-error_log
TransferLog logs/host.foo.com-access_log
</VirtualHost>
Each VirtualHost must correspond to a different IP address or a
different host name for the server, in the latter case the server
machine must be configured to accept IP packets for multiple
addresses. (If the machine does not have multiple network interfaces,
then this can be accomplished with the ifconfig alias
command (if your OS supports it), or with kernel patches like VIF (for SunOS(TM) 4.1.x)).
The special name _default_ can be specified in which case
this virtual host will match any IP address that is not explicitly listed
in another virtual host. In the absence of any _default_ virtual host
the "main" server config, consisting of all those definitions outside
any VirtualHost section, is used when no match occurs.
You can specify a :port to change the port that is matched.
If unspecified then it defaults to the same port as the most recent
Port statement of the main server. You
may also specify :* to match all ports on that address.
(This is recommended when used with _default_.)
SECURITY: See the security tips document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server.
See also:
Warnings about DNS and Apache
See also:
Information on Virtual Hosts.
(multihome)
See also:
Non-IP address-based Virtual Hosts
See also:
In-depth description of Virtual Host matching
Apache HTTP Server Version 1.2
07070100002cb2000081a400000064000000640000000134b16bd4000024fd000000200000001b00000000000000000000002800000004reloc/htdocs/manual/mod/directives.html
Apache HTTP Server Version 1.2
Apache directives
- AccessConfig
- AccessFileName
- Action
- AddAlt
- AddAltByEncoding
- AddAltByType
- AddDescription
- AddEncoding
- AddHandler
- AddIcon
- AddIconByEncoding
- AddIconByType
- AddLanguage
- AddModule
- AddType
- AgentLog
- Alias
- allow
- AllowOverride
- Anonymous
- Anonymous_Authoritative
- Anonymous_LogEmail
- Anonymous_MustGiveEmail
- Anonymous_NoUserID
- Anonymous_VerifyEmail
- AuthAuthoritative
- AuthDBAuthoritative
- AuthDBGroupFile
- AuthDBMAuthoritative
- AuthDBMGroupFile
- AuthDBMGroupFile
- AuthDBUserFile
- AuthDBMUserFile
- AuthDigestFile
- AuthGroupFile
- AuthName
- AuthType
- AuthUserFile
- BindAddress
- BrowserMatch
- BrowserMatchNoCase
- CacheDefaultExpire
- CacheDirLength
- CacheDirLevels
- CacheGcInterval
- CacheLastModifiedFactor
- CacheMaxExpire
- CacheNegotiatedDocs
- CacheRoot
- CacheSize
- ClearModuleList
- CookieExpires
- CookieLog (mod_cookies)
- CookieLog (mod_log_config)
- CookieTracking
- CustomLog
- DefaultIcon
- DefaultType
- deny
- <Directory>
- DirectoryIndex
- DocumentRoot
- ErrorDocument
- ErrorLog
- Example
- ExpiresActive
- ExpiresByType
- ExpiresDefault
- FancyIndexing
- <Files>
- ForceType
- Group
- Header
- HeaderName
- HostNameLookups
- IdentityCheck
- <IfModule>
- ImapBase
- ImapDefault
- ImapMenu
- IndexIgnore
- IndexOptions
- KeepAlive
- KeepAliveTimeout
- LanguagePriority
- <Limit>
- Listen
- LoadFile
- LoadModule
- <Location>
- LockFile
- LogFormat
- MaxClients
- MaxKeepAliveRequests
- MaxRequestsPerChild
- MaxSpareServers
- MetaDir
- MetaSuffix
- MinSpareServers
- NoCache
- Options
- order
- PassEnv
- PidFile
- Port
- ProxyBlock
- ProxyPass
- ProxyRemote
- ProxyRequests
- ReadmeName
- Redirect
- RedirectPermanent
- RedirectTemp
- RefererIgnore
- RefererLog
- require
- ResourceConfig
- RewriteBase
- RewriteCond
- RewriteEngine
- RewriteLog
- RewriteLogLevel
- RewriteMap
- RewriteOptions
- RewriteRule
- RLimitCPU
- RLimitMEM
- RLimitNPROC
- Satisfy
- ScoreBoardFile
- Script
- ScriptAlias
- ScriptLog
- ScriptLogBuffer
- ScriptLogLength
- SendBufferSize
- ServerAdmin
- ServerAlias
- ServerName
- ServerPath
- ServerRoot
- ServerType
- SetEnv
- SetHandler
- StartServers
- TimeOut
- TransferLog (mod_log_common)
- TransferLog (mod_log_config)
- TypesConfig
- UnsetEnv
- User
- UserDir
- <VirtualHost>
- XBitHack
Apache HTTP Server Version 1.2
07070100002cb3000081a400000064000000640000000134b16bd4000000b9000000200000001b00000000000000000000002400000004reloc/htdocs/manual/mod/footer.html Apache HTTP Server Version 1.2
07070100002cb4000081a400000064000000640000000134b16bd400000086000000200000001b00000000000000000000002400000004reloc/htdocs/manual/mod/header.html
Apache HTTP Server Version 1.2
Apache HTTP Server Version 1.2
Apache modules
Below is a list of all of the modules that come as part of the Apache distribution. See also the complete alphabetical list of all Apache directives.
- Core
- Core Apache features.
- mod_access
- Host based access control.
- mod_actions Apache 1.1 and later.
- Filetype/method-based script execution
- mod_alias
- Aliases and redirects.
- mod_asis
- The .asis file handler.
- mod_auth
- User authentication using text files.
- mod_auth_anon
- Anonymous user authentication, FTP-style.
- mod_auth_db
- User authentication using Berkeley DB files.
- mod_auth_dbm
- User authentication using DBM files.
- mod_auth_msql
- User authentication using mSQL files.
- mod_browser Apache 1.2 and up
- Set environment variables based on User-Agent strings
- mod_cern_meta
- Support for HTTP header metafiles.
- mod_cgi
- Invoking CGI scripts.
- mod_cookies up to Apache 1.1.1
- Support for Netscape-like cookies. Replaced in Apache 1.2 by mod_usertrack
- mod_digest
- MD5 authentication
- mod_dir
- Automatic directory listings.
- mod_dld
- Start-time linking with the GNU libdld.
- mod_env
- Passing of environments to CGI scripts
- mod_example Apache 1.2 and up
- Demonstrates Apache API
- mod_expires Apache 1.2 and up
- Apply Expires: headers to resources
- mod_headers Apache 1.2 and up
- Add arbitrary HTTP headers to resources
- mod_imap
- The imagemap file handler.
- mod_include
- Server-parsed documents.
- mod_info
- Server configuration information
- mod_log_agent
- Logging of User Agents.
- mod_log_common up to Apache 1.1.1
- Standard logging in the Common Logfile Format. Replaced by the mod_log_config module in Apache 1.2 and up
- mod_log_config
- User-configurable logging replacement for mod_log_common.
- mod_log_referer
- Logging of document references.
- mod_mime
- Determining document types.
- mod_negotiation
- Content negotiation.
- mod_rewrite Apache 1.2 and up
- Powerful URI-to-filename mapping using regular expressions
- mod_proxy
- Caching proxy abilities
- mod_status
- Server status display
- mod_userdir
- User home directories.
- mod_usertrack Apache 1.2 and up
- User tracking using Cookies (replacement for mod_cookies.c)
Apache HTTP Server Version 1.2
07070100002cb6000081a400000064000000640000000134b16bd400001701000000200000001b00000000000000000000002800000004reloc/htdocs/manual/mod/mod_access.html
Apache HTTP Server Version 1.2
Module mod_access
This module is contained in themod_access.c file, and
is compiled in by default. It provides access control based on client
hostname or IP address.
allow
Syntax: allow from host host ...Context: directory, .htaccess
Override: Limit
Status: Base
Module: mod_access
The allow directive affects which hosts can access a given directory. Host is one of the following:
all- all hosts are allowed access
- A (partial) domain-name
- host whose name is, or ends in, this string are allowed access.
- A full IP address
- An IP address of a host allowed access
- A partial IP address
- The first 1 to 3 bytes of an IP address, for subnet restriction.
allow from .ncsa.uiuc.edu
Note that this compares whole components; bar.edu
would not match foobar.edu.
See also deny, order, and BrowserMatch.
Syntax: allow from env=variablename
Context: directory, .htaccess
Override: Limit
Status: Base
Module: mod_access
Compatibility: Apache 1.2 and above
The allow from env directive controls access to a directory by the existence (or non-existence) of an environment variable. Example:
See also deny from env and order.BrowserMatch ^KnockKnock/2.0 let_me_in <Directory /docroot> order allow,deny allow from env=let_me_in deny from all </Directory>
deny
Syntax: deny from host host ...Context: directory, .htaccess
Override: Limit
Status: Base
Module: mod_access
The deny directive affects which hosts can access a given directory. Host is one of the following:
all- all hosts are denied access
- A (partial) domain-name
- host whose name is, or ends in, this string are denied access.
- A full IP address
- An IP address of a host denied access
- A partial IP address
- The first 1 to 3 bytes of an IP address, for subnet restriction.
deny from 16
Note that this compares whole components; bar.edu
would not match foobar.edu.
Syntax: deny from env=variablename
Context: directory, .htaccess
Override: Limit
Status: Base
Module: mod_access
Compatibility: Apache 1.2 and above
The deny from env directive controls access to a directory by the existence (or non-existence) of an environment variable. Example:
See also allow from env and order.BrowserMatch ^BadRobot/0.9 go_away <Directory /docroot> order deny,allow deny from env=go_away allow from all </Directory>
order
Syntax: order orderingDefault:
order deny,allowContext: directory, .htaccess
Override: Limit
Status: Base
Module: mod_access
The order directive controls the order in which allow and deny directives are evaluated. Ordering is one of
- deny,allow
- the deny directives are evaluated before the allow directives. (The initial state is OK.)
- allow,deny
- the allow directives are evaluated before the deny directives. (The initial state is FORBIDDEN.)
- mutual-failure
- Only those hosts which appear on the allow list and do not appear on the deny list are granted access. (The initial state is irrelevant.)
allow and deny
statement is evaluated, there is no "short-circuiting".
Example:
order deny,allow
deny from all
allow from .ncsa.uiuc.edu
Apache HTTP Server Version 1.2
07070100002cb7000081a400000064000000640000000134b16bd400000bcd000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_actions.html
Apache HTTP Server Version 1.2
Module mod_actions
This module is contained in themod_actions.c file, and
is compiled in by default. It provides for
executing CGI scripts based on media type or request method. It is not
present in versions prior to Apache 1.1.
Summary
This module lets you run CGI scripts whenever a file of a certain type is requested. This makes it much easier to execute scripts that process files.Directives
Action
Syntax: Action mime-type cgi-scriptContext: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_actions
Compatibility: Action is only available in Apache 1.1 and later
This directive adds an action, which will activate cgi-script when a file of content type mime-type is requested. It sends the URL and file path of the requested document using the standard CGI PATH_INFO and PATH_TRANSLATED environment variables.
Script
Syntax: Script method cgi-scriptContext: server config, virtual host, directory
Status: Base
Module: mod_actions
Compatibility: Script is only available in Apache 1.1 and later
This directive adds an action, which will activate cgi-script when
a file is requested using the method of method, which can be
one of GET, POST, PUT or
DELETE. It sends the
URL and file path of the requested document using the standard
CGI PATH_INFO and PATH_TRANSLATED environment variables.
Note that the Script command defines default actions only. If a CGI
script is called, or some other resource that is capable of handling
the requested method internally, it will do so. Also note that script
with a method of GET will only be called if there are
query arguments present (e.g. foo.html?hi). Otherwise, the request
will proceed normally.
Examples:
Script GET /cgi-bin/search #e.g. for <ISINDEX>-style searching
Script PUT /~bob/put.cgi
Apache HTTP Server Version 1.2
07070100002cb8000081a400000064000000640000000134b16bd50000198a000000200000001b00000000000000000000002700000004reloc/htdocs/manual/mod/mod_alias.html
Apache HTTP Server Version 1.2
Module mod_alias
This module is contained in themod_alias.c file, and
is compiled in by default. It provides for mapping different parts of the
host filesystem in the the document tree, and for URL redirection.
Alias
Syntax: Alias url-path directory-filenameContext: server config, virtual host
Status: Base
Module: mod_alias
The Alias directive allows documents to be stored in the local filesystem other than under the DocumentRoot. URLs with a (%-decoded) path beginning with url-path will be mapped to local files beginning with directory-filename. Example:
Alias /image /ftp/pub/image
Note that if you include a trailing / on the url-path then the
server will require a trailing / in order to expand the alias. That is,
if you use Alias /icons/ /usr/local/etc/httpd/icons/ then
the url /icons will not be aliased.
See also ScriptAlias.
Redirect
Syntax: Redirect [ status ] url-path urlContext: server config, virtual host, directory, .htaccess
Status: Base
Module: mod_alias
Compatibility: The directory and .htaccess context's are only available in versions 1.1 and later. The status argument is only available in Apache 1.2 or later.
The Redirect directive maps an old URL into a new one. The new URL is returned to the client which attempts to fetch it again with the new address. Url-path a (%-decoded) path; any requests for documents beginning with this path will be returned a redirect error to a new (%-encoded) url beginning with url. Example:
Redirect /service
http://foo2.bar.com/serviceNote: Redirect directives take precedence over Alias and ScriptAlias directives, irrespective of their ordering in the configuration file. Also, Url-path must be an absolute path, not a relative path, even when used with .htaccess files or inside of <Directory> sections.
If no status argument is given, the redirect will be "temporary" (HTTP status 302). This indicates to the client that the resources is has moved temporarily. The status argument can be used to return other HTTP status codes:
- permanent
- Returns a permanent redirect status (301) indicating that the resource has moved permanently.
- temp
- Returns a temporary redirect status (302). This is the default.
- seeother
- Returns a "See Other" status (303) indicating that the resource has been replaced.
- gone
- Returns a "Gone" status (410) indicating that the resource has been permanently removed. When this status is used the url argument should be omitted.
send_error_response in http_protocol.c).
RedirectTemp
Syntax: RedirectTemp url-path urlContext: server config, virtual host, directory, .htaccess
Status: Base
Module: mod_alias
Compatibility: This directive is only available in 1.2
This directive makes the client know that the Redirect is only
temporary. (Status 302). Exactly equivalent to Redirect temporary
RedirectPermanent
Syntax: RedirectPermanent url-path url
Context: server config, virtual host, directory, .htaccess
Status: Base
Module: mod_alias
Compatibility: This directive is only available in 1.2
This directive makes the client know that the Redirect is permanent.
(Status 301). Exactly equivalent to Redirect permanent
ScriptAlias
Syntax: ScriptAlias url-path directory-filenameContext: server config, virtual host
Status: Base
Module: mod_alias
The ScriptAlias directive has the same behavior as the Alias directive, except that in addition it marks the target directory as containing CGI scripts. URLs with a (%-decoded) path beginning with url-path will be mapped to scripts beginning with directory-filename. Example:
ScriptAlias /cgi-bin/ /web/cgi-bin/
Apache HTTP Server Version 1.2
07070100002cb9000081a400000064000000640000000134b16bd500000a70000000200000001b00000000000000000000002600000004reloc/htdocs/manual/mod/mod_asis.html
Apache HTTP Server Version 1.2
Module mod_asis
This module is contained in themod_asis.c file, and
is compiled in by default. It provides for .asis files. Any
document with mime type httpd/send-as-is will be processed by
this module.
Purpose
To allow file types to be defined such that Apache sends them without adding HTTP headers.This can be used to send any kind of data from the server, including redirects and other special HTTP responses, without requiring a cgi-script or an nph script.
Usage
In the server configuration file, define a new mime type calledhttpd/send-as-is e.g.
AddType httpd/send-as-is asis.asis file extension as being of the new
httpd/send-as-is mime type. The contents of any file with a
.asis extension will then be sent by Apache to the client with
almost no changes. Clients will need HTTP headers to be attached, so do not
forget them. A Status: header is also required; the data should be the
3-digit HTTP response code, followed by a textual message.Here's an example of a file whose contents are sent as is so as to tell the client that a file has redirected.
Status: 302 Now where did I leave that URL
Location: http://xyz.abc.com/foo/bar.html
Content-type: text/html
<HTML>
<HEAD>
<TITLE>Lame excuses'R'us</TITLE>
</HEAD>
<BODY>
<H1>Fred's exceptionally wonderful page has moved to
<A HREF="http://xyz.abc.com/foo/bar.html">Joe's</A> site.
</H1>
</BODY>
</HTML>
Apache HTTP Server Version 1.2
07070100002cba000081a400000064000000640000000134b16bd50000172b000000200000001b00000000000000000000002600000004reloc/htdocs/manual/mod/mod_auth.html
Apache HTTP Server Version 1.2
Module mod_auth
This module is contained in themod_auth.c file, and
is compiled in by default. It provides for user authentication using
textual files.
AuthGroupFile
Syntax: AuthGroupFile filenameContext: directory, .htaccess
Override: AuthConfig
Status: Base
Module: mod_auth
The AuthGroupFile directive sets the name of a textual file containing the list of user groups for user authentication. Filename is the absolute path to the group file.
Each line of the group file contains a groupname followed by a colon, followed by the member usernames separated by spaces. Example:
mygroup: bob joe anneSecurity: make sure that the AuthGroupFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthGroupFile.
See also AuthName, AuthType and AuthUserFile.
AuthUserFile
Syntax: AuthUserFile filenameContext: directory, .htaccess
Override: AuthConfig
Status: Base
Module: mod_auth
The AuthUserFile directive sets the name of a textual file containing the list of users and passwords for user authentication. Filename is the absolute path to the user file.
Each line of the user file file contains a username followed by a colon, followed by the crypt() encrypted password. The behavior of multiple occurrences of the same user is undefined.
Note that searching user groups files is inefficient; AuthDBMUserFile should be used instead.
Security: make sure that the AuthUserFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthUserFile.
See also AuthName, AuthType and AuthGroupFile.
AuthAuthoritative
Syntax: AuthAuthoritative < on(default) | off >Context: directory, .htaccess
Override: AuthConfig
Status: Base
Module: mod_auth
Setting the AuthAuthoritative directive explicitly to 'off'
allows for both authentication and authorization to be passed on to
lower level modules (as defined in the Configuration and
modules.c files) if there is no userID or
rule matching the supplied userID. If there is a userID and/or
rule specified; the usual password and access checks will be applied
and a failure will give an Authorization Required reply.
So if a userID appears in the database of more than one module; or if a valid require directive applies to more than one module; then the first module will verify the credentials; and no access is passed on; regardless of the AuthAuthoritative setting.
A common use for this is in conjunction with one of the database
modules; such as mod_auth_db.c, mod_auth_dbm.c, mod_auth_msql.c and mod_auth_anon.c. These modules
supply the bulk of the user credential checking; but a few
(administrator) related accesses fall through to a lower level with a
well protected AuthUserFile.
Default: By default; control is not passed on; and an unknown userID or rule will result in an Authorization Required reply. Not setting it thus keeps the system secure; and forces an NSCA compliant behaviour.
Security: Do consider the implications of allowing a user to allow fall-through in his .htaccess file; and verify that this is really what you want; Generally it is easier to just secure a single .htpasswd file, than it is to secure a database such as mSQL. Make sure that the AuthUserFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthUserFile.
See also AuthName, AuthType and AuthGroupFile.
Apache HTTP Server Version 1.2
07070100002cbb000081a400000064000000640000000134b16bd50000246e000000200000001b00000000000000000000002b00000004reloc/htdocs/manual/mod/mod_auth_anon.html
Apache HTTP Server Version 1.2
Module mod_auth_anon
This module is contained in themod_auth_anon.c file and
is not compiled in by default. It is only available in Apache 1.1 and
later. It allows "anonymous" user access to authenticated areas.
Summary
It does access control in a manner similar to anonymous-ftp sites; i.e. have a 'magic' user id 'anonymous' and the email address as a password. These email addresses can be logged.Combined with other (database) access control methods, this allows for effective user tracking and customization according to a user profile while still keeping the site open for 'unregistered' users. One advantage of using Auth-based user tracking is that, unlike magic-cookies and funny URL pre/postfixes, it is completely browser independent and it allows users to share URLs.
Directives / Example / Compile time options / RevisionHistory / Person to blame / Sourcecode
Directives
- Anonymous
- Anonymous_Authoritative
- Anonymous_LogEmail
- Anonymous_MustGiveEmail
- Anonymous_NoUserID
- Anonymous_VerifyEmail
Anonymous
Syntax: Anonymous user user ...Default: none
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_anon
A list of one or more 'magic' userIDs which are allowed access without password verification. The userIDs are space separated. It is possible to use the ' and " quotes to allow a space in a userID as well as the \ escape character.
Please note that the comparison is case-IN-sensitive.
I strongly suggest that the magic username 'anonymous'
is always one of the allowed userIDs.
Example:
Anonymous: anonymous "Not Registered" 'I don\'t know'
This would allow the user to enter without password verification by using the userId's 'anonymous', 'AnonyMous','Not Registered' and 'I Don't Know'.
Anonymous_Authoritative
Syntax: Anonymous_Authoritative on | offDefault:
Anonymous_Authoritative offContext: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_anon
When set 'on', there is no
fall-through to other authorization methods. So if a
userID does not match the values specified in the
Anonymous directive, access is denied.
Be sure you know what you are doing when you decide to switch it on. And remember that it is the linking order of the modules (in the Configuration / Make file) which details the order in which the Authorization modules are queried.
Anonymous_LogEmail
Syntax: Anonymous_LogEmail on | offDefault:
offContext: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_anon
When set 'on', the default, the 'password' entered (which hopefully contains a sensible email address) is logged in the httpd-log file.
Anonymous_MustGiveEmail
Syntax: Anonymous_MustGiveEmail on | offDefault: off
Context: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_anon
Specifies whether the user must specify an email address as the password. This prohibits blank passwords.
Anonymous_NoUserID
Syntax: Anonymous_NoUserID on | offDefault:
Anonymous_NoUserID offContext: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_anon
When set 'on', users can leave the userID (and perhaps the password field) empty. This can be very convenient for MS-Explorer users who can just hit return or click directly on the OK button; which seems a natural reaction.
Anonymous_VerifyEmail
Syntax: Anonymous on | offDefault:
Anonymous_VerifyEmail offContext: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_anon
When set 'on' the 'password' entered is
checked for at least one '@' and a '.' to encourage users to enter
valid email addresses (see the above Auth_LogEmail).
Example
The example below (when combined with the Auth directives of a htpasswd-file based (or GDM, mSQL etc) base access control system allows users in as 'guests' with the following properties:-
It insists that the user enters a userId. (
Anonymous_NoUserId) -
It insists that the user enters a password. (
Anonymous_MustGiveEmail) -
The password entered must be a valid email address, ie. contain at least one '@' and a '.'.
(
Anonymous_VerifyEmail) -
The userID must be one of
anonymous guest www test welcomeand comparison is not case sensitive.<directory /web/docs/public> -
And the Email addresses entered in the passswd field are logged to
the httpd-log file
(
Anonymous_LogEmail)
Excerpt of access.conf:
Anonymous anonymous guest www test welcomeAnonymous_MustGiveEmail on
Anonymous_VerifyEmail on
Anonymous_NoUserId off
Anonymous_LogEmail on
AuthName Use 'anonymous' & Email address for guest entry
AuthType basic-
Normal Apache/NCSA tokens for access control
<limit get post head>
order deny,allow
allow from all
require valid-user
<limit>
Compile Time Options
Currently there are no Compile options.Revision History
This version: 23 Nov 1995, 24 Feb 1996, 16 May 1996.- Version 0.4
- First release
- Version 0.5
- Added 'VerifyEmail' and 'LogEmail' options. Multiple 'anonymous' tokens allowed. more docs. Added Authoritative functionality.
Contact/person to blame
This module was written for the European Wide Service Exchange by <Dirk.vanGulik@jrc.it>.
Feel free to contact me if you have any problems, ice-creams or bugs. This
documentation, courtesy of Nick Himba,
<himba@cs.utwente.nl>.
Sourcecode
The source code can be found at
http://www.apache.org. A snapshot of a development version
usually resides at
http://me-www.jrc.it/~dirkx/mod_auth_anon.c. Please make sure
that you always quote the version you use when filing a bug report.
Apache HTTP Server Version 1.2
07070100002cbc000081a400000064000000640000000134b16bd500001b20000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_auth_db.html
Apache HTTP Server Version 1.2
Module mod_auth_db
This module is contained in themod_auth_db.c file, and
is not compiled in by default. It provides for user authentication using
Berkeley DB files. It is an alternative to DBM
files for those systems which support DB and not DBM. It is only
available in Apache 1.1 and later.
AuthDBGroupFile
Syntax: AuthDBGroupFile filenameContext: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_db
The AuthDBGroupFile directive sets the name of a DB file containing the list of user groups for user authentication. Filename is the absolute path to the group file.
The group file is keyed on the username. The value for a user is a comma-separated list of the groups to which the users belongs. There must be no whitespace within the value, and it must never contain any colons.
Security: make sure that the AuthDBGroupFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthDBGroupFile unless otherwise protected.
Combining Group and Password DB files: In some cases it is easier to manage a single database which contains both the password and group details for each user. This simplifies any support programs that need to be written: they now only have to deal with writing to and locking a single DBM file. This can be accomplished by first setting the group and password files to point to the same DB file:
AuthDBGroupFile /www/userbase
AuthDBUserFile /www/userbase
Unix Crypt-ed Password : List of Groups [ : (ignored) ]
See also AuthName, AuthType and AuthDBUserFile.
AuthDBUserFile
Syntax: AuthDBUserFile filenameContext: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_db
The AuthDBUserFile directive sets the name of a DB file containing the list of users and passwords for user authentication. Filename is the absolute path to the user file.
The user file is keyed on the username. The value for a user is the crypt() encrypted password, optionally followed by a colon and arbitrary data. The colon and the data following it will be ignored by the server.
Security: make sure that the AuthDBUserFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthDBUserFile.
Important compatibility note: The implementation of "dbmopen" in the apache modules reads the string length of the hashed values from the DB data structures, rather than relying upon the string being NULL-appended. Some applications, such as the Netscape web server, rely upon the string being NULL-appended, so if you are having trouble using DB files interchangeably between applications this may be a part of the problem.
See also AuthName, AuthType and AuthDBGroupFile.
AuthDBAuthoritative
Syntax: AuthDBAuthoritative < on(default) | off >Context: directory, .htaccess
Override: AuthConfig
Status: Base
Module: mod_auth
Setting the AuthDBAuthoritative directive explicitly to 'off'
allows for both authentication and authorization to be passed on
to lower level modules (as defined in the Configuration
and modules.c file if there is no userID or
rule matching the supplied userID. If there is a userID
and/or rule specified; the usual password and access checks will
be applied and a failure will give an Authorization Required reply.
So if a userID appears in the database of more than one module; or if a valid require directive applies to more than one module; then the first module will verify the credentials; and no access is passed on; regardless of the AuthAuthoritative setting.
A common use for this is in conjunction with one of the basic auth
modules; such as mod_auth.c.
Whereas this DB module supplies the bulk of the user credential
checking; a few (administrator) related accesses fall through to
a lower level with a well protected .htpasswd file.
Default: By default; control is not passed on; and an unknown userID or rule will result in an Authorization Required reply. Not setting it thus keeps the system secure; and forces an NSCA compliant behaviour.
Security: Do consider the implications of allowing a user to allow fall-through in his .htaccess file; and verify that this is really what you want; Generally it is easier to just secure a single .htpasswd file, than it is to secure a database which might have more access interfaces.
See also AuthName, AuthType and AuthDBGroupFile.
Apache HTTP Server Version 1.2
07070100002cbd000081a400000064000000640000000134b16bd500001af1000000200000001b00000000000000000000002a00000004reloc/htdocs/manual/mod/mod_auth_dbm.html
Apache HTTP Server Version 1.2
Module mod_auth_dbm
This module is contained in themod_auth_dbm.c file, and
is not compiled in by default. It provides for user authentication using
DBM files.
AuthDbmGroupFile
Syntax: AuthDBMGroupFile filenameContext: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_dbm
The AuthDBMGroupFile directive sets the name of a DBM file containing the list of user groups for user authentication. Filename is the absolute path to the group file.
The group file is keyed on the username. The value for a user is a comma-separated list of the groups to which the users belongs. There must be no whitespace within the value, and it must never contain any colons.
Security: make sure that the AuthDBMGroupFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthDBMGroupFile unless otherwise protected.
Combining Group and Password DBM files: In some cases it is easier to manage a single database which contains both the password and group details for each user. This simplifies any support programs that need to be written: they now only have to deal with writing to and locking a single DBM file. This can be accomplished by first setting the group and password files to point to the same DBM:
AuthDBMGroupFile /www/userbase
AuthDBMUserFile /www/userbase
Unix Crypt-ed Password : List of Groups [ : (ignored) ]
See also AuthName, AuthType and AuthDBMUserFile.
AuthDBMUserFile
Syntax: AuthDBMUserFile filenameContext: directory, .htaccess
Override: AuthConfig
Status: Extension
Module: mod_auth_dbm
The AuthDBMUserFile directive sets the name of a DBM file containing the list of users and passwords for user authentication. Filename is the absolute path to the user file.
The user file is keyed on the username. The value for a user is the crypt() encrypted password, optionally followed by a colon and arbitrary data. The colon and the data following it will be ignored by the server.
Security: make sure that the AuthDBMUserFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthDBMUserFile.
Important compatibility note: The implementation of "dbmopen" in the apache modules reads the string length of the hashed values from the DBM data structures, rather than relying upon the string being NULL-appended. Some applications, such as the Netscape web server, rely upon the string being NULL-appended, so if you are having trouble using DBM files interchangeably between applications this may be a part of the problem.
See also AuthName, AuthType and AuthDBMGroupFile.
AuthDBMAuthoritative
Syntax: AuthDBMAuthoritative < on(default) | off >Context: directory, .htaccess
Override: AuthConfig
Status: Base
Module: mod_auth
Setting the AuthDBMAuthoritative directive explicitly to 'off'
allows for both authentication and authorization to be passed on
to lower level modules (as defined in the Configuration
and modules.c file if there is no userID or
rule matching the supplied userID. If there is a userID
and/or rule specified; the usual password and access checks will
be applied and a failure will give an Authorization Required reply.
So if a userID appears in the database of more than one module; or if a valid require directive applies to more than one module; then the first module will verify the credentials; and no access is passed on; regardless of the AuthAuthoritative setting.
A common use for this is in conjunction with one of the basic auth
modules; such as mod_auth.c.
Whereas this DBM module supplies the bulk of the user credential
checking; a few (administrator) related accesses fall through to
a lower level with a well protected .htpasswd file.
Default: By default; control is not passed on; and an unknown userID or rule will result in an Authorization Required reply. Not setting it thus keeps the system secure; and forces an NSCA compliant behaviour.
Security: Do consider the implications of allowing a user to allow fall-through in his .htaccess file; and verify that this is really what you want; Generally it is easier to just secure a single .htpasswd file, than it is to secure a database which might have more access interfaces.
See also AuthName, AuthType and AuthDBMGroupFile.
Apache HTTP Server Version 1.2
07070100002cbe000081a400000064000000640000000134b16bd500004d57000000200000001b00000000000000000000002b00000004reloc/htdocs/manual/mod/mod_auth_msql.html
Apache HTTP Server Version 1.2
Module mod_auth_msql
This module is contained in themod_auth_msql.c file and
is compiled in by default. It allows access control using the public
domain mSQL database ftp://ftp.bond.edu.au/pub/Minerva/msql,
a fast but limited SQL engine which can be contacted over an internal
Unix domain protocol as well as over normal TCP/IP socket
communication. It is only available in Apache 1.1 and later. Full description / Example / Compile time options / RevisionHistory / Person to blame / Sourcecode
Full description of all tokens
- Auth_MSQLhost < FQHN | IP Address | localhost >
-
Hostname of the machine running the mSQL demon. The effective uid
of the server should be allowed access. If not given, or if it is
the magic name
localhost, it is passed to the mSQL library as a null pointer. This effectively forces it to use /dev/msql rather than the (slower) socket communication. - Auth_MSQLdatabase < mSQL database name >
-
Name of the database in which the following table(s) are contained (Quick check: use the
mSQL command
relshow [<hostname> dbase]to verify the spelling of the database name). - Auth_MSQLpwd_table < mSQL table name >
-
Contains at least the fields with the username
and the (encrypted) password. Each uid should only occur once in this table and
for performance reasons should be a primary key.
Normally this table is compulsory, but it is
possible to use a fall-through to other methods
and use the mSQL module for group control only.
See the
Auth_MSQL_Authoritativedirective below. - Auth_MSQLgrp_table < mSQL table name in the above database >
- Contains at least the fields with the username and the groupname. A user which is in multiple groups has therefore multiple entries. There might be some performance problems associated with this and one might consider to have separate tables for each group (rather than all groups in one table) if your directory structure allows for it. One only need to specify this table when doing group control.
- Auth_MSQLuid_field < mSQL field name >
-
Name of the field containing the username in the
Auth_MSQLpwd_tableand optionally in theAuth_MSQLgrp_tabletables. - Auth_MSQLpwd_field < mSQL field name >
-
Fieldname for the passwords in the
Auth_MSQLpwd_tabletable. - Auth_MSQLgrp_field < mSQL field name >
-
Fieldname for the groupname
Only the fields used need to be specified. When this module is compiled with theBACKWARD_VITEKoption then the uid and pwd field names default to 'user' and 'password'. However you are strongly encouraged to always specify these values explicitly given the security issues involved. - Auth_MSQL_nopasswd < on | off >
- Skip password comparison if passwd field is empty, i.e. allow any password. This is 'off' by default to ensure that an empty field in the mSQL table does not allow people in by default with a random password.
- Auth_MSQL_Authoritative < on | off >
- Default is 'on'. When set 'on', there is no fall-through to other authorization methods. So if a user is not in the mSQL dbase table (and perhaps not in the right group) or has the password wrong, then he or she is denied access. When this directive is set to 'off', control is passed on to any other authorization modules, such as the basic auth module with the htpasswd file or the Unix-(g)dbm modules. The default is 'on' to avoid nasty 'fall-through' surprises. Be sure you know what you are doing when you decide to switch it off.
- Auth_MSQL_EncryptedPasswords < on | off >
- Default is 'on'. When set on, the values in the pwd_field are assumed to be crypt-ed using *your* machines 'crypt()' function and the incoming password is 'crypt'ed before comparison. When this function is 'off', the comparison is done directly with the plaintext entered password. (Yes, http-basic-auth does send the password as plaintext over the wire :-( ). The default is a sensible 'on', and I personally think that it is a *very-bad-idea* to change this. However a multi vendor or international environment (which sometimes leads to different crypts functions) might force you to.
Example
An example mSQL table could be created with the following commands:
% msqladmin create www
% msql www
-> create table user_records (
-> User_id char(32) primary key,
-> Cpasswd char(32),
-> Xgroup char(32)
-> ) \g
query OK
-> \q
%
The
User_id can be as long as desired. However some of the
popular web browsers truncate names at or stop the user from entering
names longer than 32 characters. Furthermore the 'crypt' function
on your platform might impose further limits. Also use of
the require users uid [uid..] directive in the
access.conf file where the uid's are separated by
spaces can possibly prohibit the use of spaces in your usernames.
Also, please note the MAX_FIELD_LEN
directive somewhere below.
To use the above, the following example could be in your
access.conf file. Also there is a more elaborate description
below this example.
<directory /web/docs/private>
Auth_MSQLhost localhost
Auth_MSQLhost datab.machine.your.org-
If this directive is omitted or set to
localhost, it is assumed that Apache and the mSQL database run on the same (physical) machine and the faster /dev/msql communication channel will be used. Otherwise, it is the machine to contact by TCP/IP. Consult the mSQL documentation for more information. Auth_MSQLdatabase www-
The name of the database on the above machine,
which contains *both* the tables for group and
for user/passwords. Currently it is not possible
to have these split over two databases. Make
sure that the
msql.acl(access control file) of mSQL does indeed allow the effective uid of the web server read access to this database. Check the httpd.conf file for this uid. - Auth_MSQLpwd_table user_records
- This is the table which contain the uid/password combination is specified.
-
Auth_MSQLuid_field User_id
Auth_MSQLpwd_field Cpasswd -
These two directive specify the field names in the
user_recordtable. If this module is compiled with theBACKWARD_VITEKcompatibility switch, the defaultsuserandpasswordare assumed if you do not specify them. Currently the user_id field *MUST* be a primary key or one must ensure that each user only occurs once in the table. If a uid occurs twice access is denied by default; but see theONLY_ONCEcompiler directive for more information. -
Auth_MSQLgrp_table user_records
Auth_MSQLgrp_field Xgroup
- Optionally one can also specify a table which contains the user/group combinations. This can be the same table which also contains the username/password combinations. However if a user belongs to two or more groups, one will have to use a different table with multiple entries.
-
Auth_MSQL_nopasswd off
Auth_MSQL_Authoritative on
Auth_MSQL_EncryptedPasswords on
- These three optional fields (all set to the sensible defaults, so you really do not have to enter them) are described in more detail below. If you choose to set these to any other values then the above, be very sure you understand the security implications and do verify that Apache does what you expect it to do.
-
AuthName example mSQL realm
AuthType basic -
Normal Apache/NCSA tokens for access control
<limit get post head>
order deny,allow
allow from all
require valid-user
valid-user; allow in any user which has a valid uid/passwd pair in the above pwd_table.
require user smith jones
- Limit access to users who have a valid uid/passwd pair in the above pwd_table *and* whose uid is 'smith' or 'jones'. Do note that the uid's are separated by 'spaces' for historic (NCSA) reasons. So allowing uids with spaces might cause problems.
require group has_paid
- Optionally also ensure that the uid has the value 'has_paid' in the group field in the group table.
<limit>
or
Compile Time Options
#define ONLY_ONCE 1-
If the mSQL table containing the uid/passwd combination does
not have the uid field as a primary key, it is possible for the
uid to occur more than once in the table with possibly different
passwords. When this module is compiled with the
ONLY_ONCEdirective set, access is denied if the uid occurs more than once in the uid/passwd table. If you choose not to set it, the software takes the first pair returned and ignores any further pairs. The SQL statement used for this is
"select password form pwd_table where user='UID'"this might lead to unpredictable results. For this reason as well as for performance reasons you are strongly advised to make the uid field a primary key. Use at your own peril :-)
#define KEEP_MSQL_CONNECTION_OPEN-
Normally the (TCP/IP) connection with the database is opened and
closed for each SQL query. When the Apache web-server and the database
are on the same machine, and /dev/msql is used this does not
cause a serious overhead. However when your platform does not
support this (see the mSQL documentation) or when the web server
and the database are on different machines the overhead can be
considerable. When the above directive is set defined the server leaves
the connection open, i.e. no call to
msqlClose(). If an error occurs an attempt is made to reopen the connection for the next http request.This has a number of very serious drawbacks
- It costs 2 already rare file-descriptors for each child.
- It costs msql-connections, typically one per child. The (compiled in) number of connections mSQL can handle is low, typically 6 or 12. which might prohibit access to the mSQL database for later processes.
- When a child dies, it might not free that connection properly or quick enough.
- When errors start to occur, connection/file-descriptor resources might become exhausted very quickly.
In short, use this at your own peril and only in a highly controlled and monitored environment.
#define BACKWARD_VITEK
#define VITEK_uid_name "user"
#define VITEK_gid_name "passwd"-
A second mSQL auth module for Apache has also been developed by Vivek Khera
<
khera@kciLink.com> and was subsequently distributed with some early versions of Apache. It can be obtained fromftp://ftp.kcilink.com/pub/mod_auth_msql.c*. Older 'vitek' versions had the field/table names compiled in. Newer versions, v.1.11 have moreaccess.confconfiguration options. However these where chosen not to be in line the 'ewse' version of this module. Also, the 'vitek' module does not give group control or 'empty' password control.To get things slightly more in line this version (0.9) should be backward compatible with the 'vitek' module by:
- Adding support for the
Auth_MSQL_EncryptedPasswordson/off functionality - Adding support for the different spelling of the 4 configuration tokens for user-table-name, user/password-field-name and dbase-name.
- Setting some field names to a default which used to be hard coded in in older 'vitek' modules.
If this troubles you, remove the 'BACKWARD_VITEK' define.
- Adding support for the
#define MAX_FIELD_LEN (64)
#define MAX_QUERY_LEN (32+24+MAX_FIELD_LEN*2+3*MSQL_FIELD_NAME_LEN+1*MSQL_TABLE_NAME_LEN)
-
In order to avoid using the very large
HUGE_STRING_LENGTH, the above two compile time directives are supplies. TheMAX_FIELD_LENcontains the maximum number of characters in your user, password and group fields. The maximum query length is derived from those values.We only do the following two queries:
- For the user/passwd combination
"select PWDFIELD from PWDTABLE where USERFIELD='UID'"
- Optionally for the user/group combination:
"select GROUPFIELD from GROUPTABLE where USERFIELD='UID' and GROUPFIELD='GID'"
This leads to the above limit for the query string. We are ignoring escaping a wee bit here assuming not more than 24 escapes.)
- For the user/passwd combination
Revision History
This version: 23 Nov 1995, 24 Feb 1996, 16 May 1996.- Version 0.0
- First release
- Version 0.1
- Update to Apache 1.00
- Version 0.2
- Added lines which got missing God knows when and which did the valid-user authentication no good at all !
- Version 0.3
- Added '
Auth_MSQL_nopasswd' option - Version 0.4
- Cleaned out the error messages mess.
- Version 0.6
- Inconsistency with gid/grp in comment/token/source
Make sure you really use '
Auth_MSQLgrp_field' as indicated above. - Version 0.7
*hosttohostfixed. Credits go to Rob Stout, <stout@lava.et.tudelft.nl> for spotting this one.- Version 0.8
- Authoritative directive added. See above.
- Version 0.9
pallocreturn code check(s), should be backward compatible with 1.11 version of Vivek Khera <khera@kciLink.com> msql module, fixed broken err msg in group control, changed command table messages to make more sense when displayed in that new module management tool. AddedAuth_MSQL_EncryptedPasswordson/off functionality. msqlClose() statements added upon error. Support for persistent connections with the mSQL database (riscy). Escaping of ' and \. Replaced someMAX_STRING_LENGTHclaims.
Contact/person to blame
This module was written for the European Wide Service Exchange by <Dirk.vanGulik@jrc.it>.
Feel free to contact me if you have any problems, ice-creams or bugs. This
documentation, courtesy of Nick Himba,
<himba@cs.utwente.nl>.
Sourcecode
The source code can be found at
http://www.apache.org. A snapshot of a development version
usually resides at
http://me-www.jrc.it/~dirkx/mod_auth_msql.c. Please make sure
that you always quote the version you use when filing a bug report.
Furthermore a test/demonstration suite (which assumes that you have
both mSQL and Apache compiled and installed) is available at the contrib
section of
ftp://ftp.apache.org/apache/dist/contrib or
http://me-www.jrc.it/~dirkx/apache-msql-demo.tar.gz and
its
README file.
Apache HTTP Server Version 1.2
07070100002cbf000081a400000064000000640000000134b16bd500000caa000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_browser.html
Apache HTTP Server Version 1.2
Module mod_browser
This module is contained in themod_browser.c file, and
is compiled in by default with Apache 1.2 and above. It provides for
setting environment variables based on the browser.
Summary
This module allows you to set environment variables based on the name of
the browser accessing your document, based on the User-Agent
header field. This is especially useful when combined with a conditional
HTML language such as XSSI or PHP, and
can provide for simple browser-based negotiation of HTML features.
Directives
BrowserMatch
Syntax: BrowserMatch regex attr1 attr2...Context: server config
Status: base
Module: mod_browser
Compatibility: Apache 1.2 and above
The BrowserMatch directive defines environment variables based on the
User-Agent
header. The first argument should be a POSIX.2 extended regular
expression (similar to an egrep-style regex). The rest of the arguments
give names of variables to set. These take the form of either
"varname", "!varname" or
"varname=value". In the first form, the value will be set
to "1". The second will remove the given variable if already defined,
and the third will set the variable to the value given by value. If a User-Agent
string matches more than one entry, they will
be merged. Entries are processed in the order they appear, and later
entries can override earlier ones.
For example:
BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
BrowserMatch MSIE !javascript
BrowserMatchNoCase
Syntax: BrowserMatchNoCase regex attr1 attr2...Context: server config
Status: base
Module: mod_browser
Compatibility: Apache 1.2 and above
The BrowserMatchNoCase directive is semantically identical to
the BrowserMatch
directive. However, it provides for case-insensitive matching. For
example:
BrowserMatchNoCase mac platform=macintosh
BrowserMatchNoCase win platform=windows
Apache HTTP Server Version 1.2
07070100002cc0000081a400000064000000640000000134b16bd500000b97000000200000001b00000000000000000000002b00000004reloc/htdocs/manual/mod/mod_cern_meta.html
Apache HTTP Server Version 1.2
Module mod_cern_meta
This module is contained in themod_cern_meta.c file, and
is not compiled in by default. It provides for CERN httpd metafile
semantics. It is only available in Apache 1.1 and later.
Summary
Emulate the CERN HTTPD Meta file semantics. Meta files are HTTP headers that can be output in addition to the normal range of headers for each file accessed. They appear rather like the Apache .asis files, and are able to provide a crude way of influencing the Expires: header, as well as providing other curiosities. There are many ways to manage meta information, this one was chosen because there is already a large number of CERN users who can exploit this module.More information on the CERN metafile semantics is available.
Directives
MetaDir
Syntax: MetaDir directory nameDefault:
MetaDir .webContext: server config
Status: Base
Module: mod_cern_meta
Compatibility: MetaDir is only available in Apache 1.1 and later.
Specifies the name of the directory in which Apache can find
meta information files. The directory is usually a 'hidden'
subdirectory of the directory that contains the file being
accessed. Set to "." to look in the same directory as the
file.
MetaSuffix
Syntax: MetaSuffix suffixDefault:
MetaSuffix .metaContext: server config
Status: Base
Module: mod_cern_meta
Compatibility: MetaSuffix is only available in Apache 1.1 and later.
Specifies the file name suffix for the file containing the
meta information. For example, the default values for the two
directives will cause a request to
DOCUMENT_ROOT/somedir/index.html to look in
DOCUMENT_ROOT/somedir/.web/index.html.meta and will use
its contents to generate additional MIME header information.
Apache HTTP Server Version 1.2
07070100002cc1000081a400000064000000640000000134b16bd500001727000000200000001b00000000000000000000002500000004reloc/htdocs/manual/mod/mod_cgi.html
Apache HTTP Server Version 1.2
Module mod_cgi
This module is contained in themod_cgi.c file, and
is compiled in by default. It provides for execution of CGI scripts.
Any file with mime type application/x-httpd-cgi will be
processed by this module.
Summary
Any file that has the mime typeapplication/x-httpd-cgi
or handler cgi-script (Apache 1.1 or later)
will be treated as a CGI script, and run by the server, with its output
being returned to the client. Files acquire this type either by
having a name ending in an extension defined by the
AddType directive, or by being in
a ScriptAlias directory.
When the server invokes a CGI script, it will add a variable called
DOCUMENT_ROOT to the environment. This variable will contain the
value of the DocumentRoot
configuration variable.
CGI Environment variables
The server will set the CGI environment variables as described in the CGI specification, with the following provisions:- REMOTE_HOST
- This will only be set if the server has not been compiled with
MINIMAL_DNS. - REMOTE_IDENT
- This will only be set if
IdentityCheck is set to
on. - REMOTE_USER
- This will only be set if the CGI script is subject to authentication.
CGI Debugging
Debugging CGI scripts has traditionally been difficult, mainly because it has not been possible to study the output (standard output and error) for scripts which are failing to run properly. These directives, included in Apache 1.2 and later, provide more detailed logging of errors when they occur.CGI Logfile Format
When configured, the CGI error log logs any CGI which does not execute properly. Each CGI script which fails to operate causes several lines of information to be logged. The first two lines are always of the format:%% [time] request-line %% HTTP-status CGI-script-filenameIf the error is that CGI script cannot be run, the log file will contain an extra two lines:
%%error error-messageAlternatively, if the error is the result of the script returning incorrect header information (often due to a bug in the script), the following information is logged:
%request All HTTP request headers received POST or PUT entity (if any) %response All headers output by the CGI script %stdout CGI standard output %stderr CGI standard error(The %stdout and %stderr parts may be missing if the script did not output anything on standard output or standard error).
Directives
ScriptLog
Syntax: ScriptLog filenameDefault: none
Context: resource config
Status: mod_cgi
The ScriptLog directive sets the CGI script error logfile. If no ScriptLog is given, no error log is created. If given, any CGI errors are logged into the filename given as argument. If this is a relative file or path it is taken relative to the server root.
This log will be opened as the user the child processes run as, ie. the user specified in the main User directive. This means that either the directory the script log is in needs to be writable by that user or the file needs to be manually created and set to be writable by that user. If you place the script log in your main logs directory, do NOT change the directory permissions to make it writable by the user the child processes run as.
Note that script logging is meant to be a debugging feature when writing CGI scripts, and is not meant to be activated continuously on running servers. It is not optimized for speed or efficiency, and may have security problems if used in a manner other than that for which it was designed.
ScriptLogLength
Syntax: ScriptLogLength sizeDefault: 10385760
Context: resource config
Status: mod_cgi
ScriptLogLength can be used to limit the size of the CGI script logfile. Since the logfile logs a lot of information per CGI error (all request headers, all script output) it can grow to be a big file. To prevent problems due to unbounded growth, this directive can be used to set an maximum file-size for the CGI logfile. If the file exceeds this size, no more information will be written to it.
ScriptLogBuffer
Syntax: ScriptLogBuffer sizeDefault: 1024
Context: resource config
Status: mod_cgi
The size of any PUT or POST entity body that is logged to the file is limited, to prevent the log file growing too big too quickly if large bodies are being received. By default, up to 1024 bytes are logged, but this can be changed with this directive.
Apache HTTP Server Version 1.2
07070100002cc2000081a400000064000000640000000134b16bd500000564000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_cookies.html
Apache HTTP Server Version 1.2
Module mod_cookies
This module is contained in themod_cookies.c file, and
is not compiled in by default. It provides for Netscape(TM) cookies.
There is no documentation available for this module.
CookieLog
Syntax: CookieLog filenameContext: server config, virtual host
Status: Experimental
Module: mod_cookies
The CookieLog directive sets the filename for logging of cookies. The filename is relative to the ServerRoot.
Apache HTTP Server Version 1.2
07070100002cc3000081a400000064000000640000000134b16bd6000008ea000000200000001b00000000000000000000002800000004reloc/htdocs/manual/mod/mod_digest.html
Apache HTTP Server Version 1.2
Module mod_digest
This module is contained in themod_digest.c file, and is
not compiled in by default. It is only available in Apache 1.1 and
later. It provides for user authentication using MD5 Digest
Authentication.
AuthDigestFile
Syntax: AuthDigestFile filenameContext: directory, .htaccess
Override: AuthConfig
Status: Base
Module: mod_digest
The AuthDigestFile directive sets the name of a textual file containing the list of users and encoded passwords for digest authentication. Filename is the absolute path to the user file.
The digest file uses a special format. Files in this format can be created using the "htdigest" utility found in the support/ subdirectory of the Apache distribution.
Using Digest Authentication
Using MD5 Digest authentication is very simple. Simply set up authentication normally. However, use "AuthType Digest" and "AuthDigestFile" instead of the normal "AuthType Basic" and "AuthUserFile". Everything else should remain the same.
MD5 authentication provides a more secure password system, but only works with supporting browsers. As of this writing (July 1996), the majority of browsers do not support digest authentication. Therefore, we do not recommend using this feature on a large Internet site. However, for personal and intra-net use, where browser users can be controlled, it is ideal.
Apache HTTP Server Version 1.2
07070100002cc4000081a400000064000000640000000134b16bd600003f03000000200000001b00000000000000000000002500000004reloc/htdocs/manual/mod/mod_dir.html
Apache HTTP Server Version 1.2
Module mod_dir
This module is contained in themod_dir.c file, and
is compiled in by default. It provides for directory indexing.
Summary
This module controls the directory indexing. The index of a directory can come from one of two sources:- A file written by the user, typically called
index.html. The DirectoryIndex directive sets the name of this file. - Otherwise, a listing generated by the server. The other directives control the format of this listing. The AddIcon, AddIconByEncoding and AddIconByType are used to set a list of icons to display for various file types; for each file listed, the first icon listed that matches the file is displayed.
Directives
AddAlt
Syntax: AddAlt string file file...Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
This sets the alternate text to display for a file, instead of an icon, for
FancyIndexing. File is a file
extension, partial filename, wild-card expression or full filename for files
to describe. String is enclosed in double quotes
("). This alternate text is displayed if the client is
image-incapable or has image loading disabled.
AddAltByEncoding
Syntax: AddAltByEncoding string MIME-encoding MIME-encoding...Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
This sets the alternate text to display for a file, instead of an icon, for
FancyIndexing. MIME-encoding is a
valid content-encoding, such as x-compress.
String is enclosed in double quotes
("). This alternate text is displayed if the client is
image-incapable or has image loading disabled.
AddAltByType
Syntax: AddAltByType string MIME-type MIME-type...Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
This sets the alternate text to display for a file, instead of an icon, for
FancyIndexing. MIME-type is a
valid content-type, such as text/html.
String is enclosed in double quotes
("). This alternate text is displayed if the client is
image-incapable or has image loading disabled.
AddDescription
Syntax: AddDescription string file file...Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
This sets the description to display for a file, for
FancyIndexing. File is a file
extension, partial filename, wild-card expression or full filename for files
to describe. String is enclosed in double quotes
("). Example:
AddDescription "The planet Mars" /web/pics/mars.gif
AddIcon
Syntax: AddIcon icon name name ...Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
This sets the icon to display next to a file ending in name for FancyIndexing. Icon is either a (%-escaped) relative URL to the icon, or of the format (alttext,url) where alttext is the text tag given for an icon for non-graphical browsers.
Name is either ^^DIRECTORY^^ for directories, ^^BLANKICON^^ for blank lines (to format the list correctly), a file extension, a wildcard expression, a partial filename or a complete filename. Examples:
AddIcon (IMG,/icons/image.xbm) .gif .jpg .xbm
AddIcon /icons/dir.xbm ^^DIRECTORY^^
AddIcon /icons/backup.xbm *~
AddIconByEncoding
Syntax: AddIconByEncoding icon mime-encoding mime-encoding ...Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
This sets the icon to display next to files with mime-encoding for FancyIndexing. Icon is either a (%-escaped) relative URL to the icon, or of the format (alttext,url) where alttext is the text tag given for an icon for non-graphical browsers.
Mime-encoding is a wildcard expression matching required the content-encoding. Examples:
AddIconByEncoding /icons/compress.xbm x-compress
AddIconByType
Syntax: AddIconByType icon mime-type mime-type ...Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
This sets the icon to display next to files of type mime-type for FancyIndexing. Icon is either a (%-escaped) relative URL to the icon, or of the format (alttext,url) where alttext is the text tag given for an icon for non-graphical browsers.
Mime-type is a wildcard expression matching required the mime types. Examples:
AddIconByType (IMG,/icons/image.xbm) image/*
DefaultIcon
Syntax: DefaultIcon urlContext: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
The DefaultIcon directive sets the icon to display for files when no specific icon is known, for FancyIndexing. Url is a (%-escaped) relative URL to the icon. Examples:
DefaultIcon /icon/unknown.xbm
DirectoryIndex
Syntax: DirectoryIndex local-url local-url ...Default:
DirectoryIndex index.htmlContext: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
The DirectoryIndex directive sets the list of resources to look for,
when the client requests an index of the directory by specifying a /
at the end of the a directory name. Local-url is the
(%-encoded) URL of a document on the server relative to the requested
directory; it is usually the name of a file in the directory. Several
URLs may be given, in which case the server will return the first one
that it finds. If none of the resources exist and the
Indexes option is set, the server will generate its own
listing of the directory.
Example:
DirectoryIndex index.html
http://myserver/docs/ would return
http://myserver/docs/index.html if it exists, or would list
the directory if it did not. Note that the documents do not need to be relative to the directory;
DirectoryIndex index.html index.txt /cgi-bin/index.pl/cgi-bin/index.pl to be executed
if neither index.html or index.txt existed in
a directory.FancyIndexing
Syntax: FancyIndexing booleanContext: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
The FancyIndexing directive sets the FancyIndexing option for a directory.
Boolean can be on or off. The
IndexOptions directive should be used in
preference.
HeaderName
Syntax: HeaderName filenameContext: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
The HeaderName directive sets the name of the file that will be inserted
at the top of the index listing. Filename is the name of the file
to include, and is taken to be relative to the directory being indexed.
The server first attempts to include filename.html
as an HTML document, otherwise it will include filename as plain
text. Example:
HeaderName HEADER/web, the server will first look for
the HTML file /web/HEADER.html and include it if found, otherwise
it will include the plain text file /web/HEADER, if it exists.
See also ReadmeName.
IndexIgnore
Syntax: IndexIgnore file file ...Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
The IndexIgnore directive adds to the list of files to hide when listing
a directory. File is a file extension, partial filename,
wildcard expression or full filename for files to ignore. Multiple
IndexIgnore directives add to the list, rather than the replacing the list
of ignored files. By default, the list contains `.'. Example:
IndexIgnore README .htaccess *~
IndexOptions
Syntax: IndexOptions option option ...Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
The IndexOptions directive specifies the behavior of the directory indexing. Option can be one of
- FancyIndexing
- This turns on fancy indexing of directories.
- IconsAreLinks
- This makes the icons part of the anchor for the filename, for fancy indexing.
- ScanHTMLTitles
- This enables the extraction of the title from HTML documents for fancy indexing. If the file does not have a description given by AddDescription then httpd will read the document for the value of the TITLE tag. This is CPU and disk intensive.
- SuppressLastModified
- This will suppress the display of the last modification date, in fancy indexing listings.
- SuppressSize
- This will suppress the file size in fancy indexing listings.
- SuppressDescription
- This will suppress the file description in fancy indexing listings.
<Directory /web/docs>
IndexOptions FancyIndexing
</Directory>
<Directory /web/docs/spec>
IndexOptions ScanHTMLTitles
</Directory>
ScanHTMLTitles will be set for the /web/docs/spec
directory.ReadmeName
Syntax: ReadmeName filenameContext: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Base
Module: mod_dir
The ReadmeName directive sets the name of the file that will be appended
to the end of the index listing. Filename is the name of the file
to include, and is taken to be relative to the directory being indexed.
The server first attempts to include filename.html
as an HTML document, otherwise it will include filename as plain
text. Example:
ReadmeName README/web, the server will first look for
the HTML file /web/README.html and include it if found, otherwise
it will include the plain text file /web/README, if it exists.
See also HeaderName.
Apache HTTP Server Version 1.2
07070100002cc5000081a400000064000000640000000134b16bd600000bef000000200000001b00000000000000000000002500000004reloc/htdocs/manual/mod/mod_dld.html
Apache HTTP Server Version 1.2
Module mod_dld
This module is contained in themod_dld.c file, and is not
compiled in by default. It provides for loading of executable code
and modules into the server at start-up time, using the GNU dld library.
Summary
The optional dld module is a proof-of-concept piece of code which loads other modules into the server as it is configuring itself (the first time only; for now, rereading the config files cannot affect the state of loaded modules), using the GNU dynamic linking library, DLD. It isn't compiled into the server by default, since not everyone has DLD, but it works when I try it. (Famous last words.)
Note that for some reason, LoadFile /lib/libc.a seems to be
required for just about everything.
Note: that DLD needs to read the symbol table out of the server binary when starting up; these commands will fail if the server can't find its own binary when it starts up, or if that binary is stripped.
Directives
LoadFile
Syntax: LoadFile filename filename ...Context: server config
Status: Experimental
Module: mod_dld
The LoadFile directive links in the named object files or libraries when the server is started; this is used to load additional code which may be required for some module to work. Filename is relative to ServerRoot.
LoadModule
Syntax: LoadModule module filenameContext: server config
Status: Experimental
Module: mod_dld
The LoadModule directive links in the object file or library filename
and adds the module structure named module to the list of active
modules. Module is the name of the external variable of type
module in the file. Example:
LoadModule ai_backcompat_module modules/mod_ai_backcompat.o
LoadFile /lib/libc.a
Apache HTTP Server Version 1.2
07070100002cc6000081a400000064000000640000000134b16bd600000aa6000000200000001b00000000000000000000002500000004reloc/htdocs/manual/mod/mod_env.html
Apache HTTP Server Version 1.2
Module mod_env
This module is contained in themod_env.c file, and
is not compiled in by default. It provides for
passing environment variables to CGI/SSI scripts. Is is only available
in Apache 1.1 and later.
Summary
This module allows Apache's CGI and SSI environment to inherit environment variables from the shell which invoked the httpd process. CERN web-servers are able to do this, so this module is especially useful to web-admins who wish to migrate from CERN to Apache without rewriting all their scriptsDirectives
PassEnv
Syntax: PassEnv variable variable ...Context: server config, virtual host
Status: Base
Module: mod_env
Compatibility: PassEnv is only available in Apache 1.1 and later.
Specifies one or more environment variables to pass to CGI scripts from the server's own environment. Example:
PassEnv LD_LIBRARY_PATH
SetEnv
Syntax: SetEnv variable valueContext: server config, virtual host
Status: Base
Module: mod_env
Compatibility: SetEnv is only available in Apache 1.1 and later.
Sets an environment variable, which is then passed on to CGI scripts. Example:
SetEnv SPECIAL_PATH /foo/bin
UnsetEnv
Syntax: UnsetEnv variable variable ...Context: server config, virtual host
Status: Base
Module: mod_env
Compatibility: UnsetEnv is only available in Apache 1.1 and later.
Removes one or more environment variables from those passed on to CGI scripts. Example:
UnsetEnv LD_LIBRARY_PATH
Apache HTTP Server Version 1.2
07070100002cc7000081a400000064000000640000000134b16bd60000117b000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_example.html
Apache HTTP Server Version 1.2
Module mod_example
This module is contained in the modules/mod_example.c file, and
is not compiled in by default. It illustrates many of
the aspects of the
Apache 1.2 API
and, when used, demonstrates the manner in which module callbacks are
triggered by the server.
Summary
The files in the src/modules/example directory under the
Apache distribution directory tree are provided as an example to those
that wish to write modules that use the Apache API.
The main file is mod_example.c, which illustrates all
the different callback mechanisms and call syntaces. By no means does
an add-on module need to include routines for all of the callbacks -
quite the contrary!
The example module is an actual working module. If you link it into your server, enable the "example-handler" handler for a location, and then browse to that location, you will see a display of some of the tracing the example module did as the various callbacks were made.
To include the example module in your server, follow the steps below:
- Uncomment the "Module example_module" line near the bottom of
the
src/Configurationfile. If there isn't one, add it; it should look like this:Module example_module modules/example/mod_example.o - Run the
src/Configurescript ("cd src; ./Configure"). This will build the Makefile for the server itself, and update thesrc/modules/Makefilefor any additional modules you have requested from beneath that subdirectory. - Make the server (run "make" in the
srcdirectory).
To add another module of your own:
- mkdir src/modules/mymodule
- cp src/modules/example/* src/modules/mymodule
- Modify the files in the new directory.
- Follow steps [1] through [3] above, with appropriate changes.
Using the mod_example Module
To activate the example module, include a block similar to the following in your srm.conf file:
<Location /example-info>
SetHandler example-handler
</Location>
As an alternative, you can put the following into a .htaccess file and then request the file "test.example" from that location:
AddHandler example-handler .example
After reloading/restarting your server, you should be able to browse to this location and see the brief display mentioned earlier.
Directives
Example
Syntax: Example
Default: None
Context: server config, virtual host, directory, .htaccess
Override: Options
Status: Extension
Module: mod_example
The Example directive activates the example module's content handler for a particular location or file type. It takes no arguments. If you browse to an URL to which the example content-handler applies, you will get a display of the routines within the module and how and in what order they were called to service the document request.
Apache HTTP Server Version 1.2
07070100002cc8000081a400000064000000640000000134b16bd60000197b000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_expires.html
Apache HTTP Server Version 1.2
Module mod_expires
This module is contained in the mod_expires.c file, and
is not compiled in by default. It provides for the
generation of Expires headers according to user-specified
criteria.
Summary
This module controls the setting of the Expires HTTP
header in server responses. The expiration date can set to be
relative to either the time the source file was last modified, or to
the time of the client access.
The Expires HTTP header is an instruction to the client
about the document's validity and persistence. If cached, the document
may be fetched from the cache rather than from the source until this
time has passed. After that, the cache copy is considered
"expired" and invalid, and a new copy must be obtained from
the source.
Directives
ExpiresActive directive
Syntax: ExpiresActive boolean
Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Extension
Module: mod_expires
This directive enables or disables the generation of the
Expires header for the document realm in question. (That
is, if found in an .htaccess file, for instance, it
applies only to documents generated from that directory.) If set to
Off, no Expires header will be
generated for any document in the realm (unless overridden at a lower
level, such as an .htaccess file overriding a server
config file). If set to On, the header will be
added to served documents according to the criteria defined by the
ExpiresByType
and
ExpiresDefault
directives (q.v.).
Note that this directive does not guarantee that an
Expires header will be generated. If the criteria aren't
met, no header will be sent, and the effect will be as though this
directive wasn't even specified.
ExpiresByType directive
Syntax: ExpiresByType mime-type <code>seconds
Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Extension
Module: mod_expires
This directive defines the value of the Expires header
generated for documents of the specified type (e.g.,
text/html). The second argument sets the number of
seconds that will be added to a base time to construct the expiration
date.
The base time is either the last modification time of the file, or the
time of the client's access to the document. Which should be used is
specified by the <code> field;
M means that the file's last modification time should
be used as the base time, and A means the client's
access time should be used.
The difference in effect is subtle. If M is used, all current copies of the document in all caches will expire at the same time, which can be good for something like a weekly notice that's always found at the same URL. If A is used, the date of expiration is different for each client; this can be good for image files that don't change very often, particularly for a set of related documents that all refer to the same images (i.e., the images will be accessed repeatedly within a relatively short timespan).
Example:
ExpiresActive On # enable expirations
ExpiresByType image/gif A2592000 # expire GIF images after a month
# in the client's cache
ExpiresByType text/html M604800 # HTML documents are good for a
# week from the time they were
# changed, period
Note that this directive only has effect if ExpiresActive
On has been specified. It overrides, for the specified MIME
type only, any expiration date set by the
ExpiresDefault
directive.
ExpiresDefault directive
Syntax: ExpiresDefault <code>seconds
Context: server config, virtual host, directory, .htaccess
Override: Indexes
Status: Extension
Module: mod_expires
This directive sets the default algorithm for calculating the expiration time for all documents in the affected realm. It can be overridden on a type-by-type basis by the ExpiresByType directive. See the description of that directive for details about the syntax of the argument.
Apache HTTP Server Version 1.2
07070100002cc9000081a400000064000000640000000134b16bd600000e0e000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_headers.html
Apache HTTP Server Version 1.2
Module mod_headers
The optional headers module allows for the customization of HTTP response headers. Headers can be merged, replaced or removed. The directives described in this document are only available if Apache is compiled with mod_headers.c.Directive
Header
Syntax: Header [ set | append | add ] header valueSyntax: Header unset header
Context: server config, virtual host, access.conf, .htaccess
Status: optional
Module: mod_header
This directive can replace, merge or remove HTTP response headers. The action it performs is determined by the first argument. This can be one of the following values:
- set
The response header is set, replacing any previous header with this name - append
The response header is appended to any existing header of the same name. When a new value is merged onto an existing header it is separated from the existing header with a comma. This is the HTTP standard way of giving a header multiple values. - add
The response header is added to the existing set of headers, even if this header already exists. This can result in two (or more) headers having the same name. This can lead to unforeseen consequences, and in general "append" should be used instead. - unset
The response header of this name is removed, if it exists. If there are multiple headers of the same name, only the first one set will be removed.
Order of Processing
The Header directive can occur almost anywhere within the server configuration. It is valid in the main server config and virtual host sections, inside <Directory>, <Location> and <Files> sections, and within .htaccess files.The Header directives are processed in the following order:
- main server
- virtual host
- <Directory> sections and .htaccess
- <Location>
- <Files>
Header append Author "John P. Doe" Header unset AuthorThis way round, the Author header is not set. If reversed, the Author header is set to "John P. Doe".
The Header directives are processed just before the response is sent by its handler. These means that some headers that are added just before the response is sent cannot be unset or overridden. This includes headers such as "Date" and "Server".
Apache HTTP Server Version 1.2
07070100002cca000081a400000064000000640000000134b16bd600002b73000000200000001b00000000000000000000002600000004reloc/htdocs/manual/mod/mod_imap.html
Apache HTTP Server Version 1.2
Module mod_imap
This module is contained in themod_imap.c file, and is
compiled in by default. It provides for .map files,
replacing the functionality of the imagemap CGI
program. Any directory or document type configured to use the handler
imap-file (using either AddHandler or SetHandler) will be
processed by this module.
Summary
This module is in the default Apache distribution. The following directive will activate files ending with.map as imagemap files:
AddHandler imap-file mapAddType application/x-httpd-imap mapNew Features
The imagemap module adds some new features that were not possible with previously distributed imagemap programs.
- URL references relative to the Referer: information.
- Default <BASE> assignment through a new map directive
base. - No need for
imagemap.conffile. - Point references.
- Configurable generation of imagemap menus.
Configuration Directives
ImapMenu
Syntax: ImapMenu{none, formatted, semi-formatted,
unformatted}Context: server config, virtual host, directory, .htaccess
Override: Indexes
Module: mod_imap.c
Compatibility: ImapMenu is only available in Apache 1.1 and later.
The ImapMenu directive determines the action taken if an imagemap file is called without valid coordinates.
none- If ImapMenu is
none, no menu is generated, and thedefaultaction is performed. formatted- A
formattedmenu is the simplest menu. Comments in the imagemap file are ignored. A level one header is printed, then an hrule, then the links each on a separate line. The menu has a consistent, plain look close to that of a directory listing. semiformatted- In the
semiformattedmenu, comments are printed where they occur in the imagemap file. Blank lines are turned into HTML breaks. No header or hrule is printed, but otherwise the menu is the same as aformattedmenu. unformatted- Comments are printed, blank lines are ignored. Nothing is printed that does not appear in the imagemap file. All breaks and headers must be included as comments in the imagemap file. This gives you the most flexibility over the appearance of your menus, but requires you to treat your map files as HTML instead of plaintext.
ImapDefault
Syntax: ImapDefault{error, nocontent,
map, referer, URL}Context: server config, virtual host, directory, .htaccess
Override: Indexes
Module: mod_imap.c
Compatibility: ImapDefault is only available in Apache 1.1 and later.
The ImapDefault directive sets the default default used in
the imagemap files. It's value is overridden by a default
directive within the imagemap file. If not present, the
default action is nocontent, which means
that a 204 No Content is sent to the client. In this
case, the client should continue to display the original page.
ImapBase
Syntax: ImapBase{map, referer, URL}Context: server config, virtual host, directory, .htaccess
Override: Indexes
Module: mod_imap.c
Compatibility: ImapBase is only available in Apache 1.1 and later.
The ImapBase directive sets the default base used in
the imagemap files. It's value is overridden by a base
directive within the imagemap file. If not present, the
base defaults to http://servername/.
Imagemap File
The lines in the imagemap files can have one of several formats:The directive is one ofdirective value [x,y ...]
directive value "Menu text" [x,y ...]
directive value x,y ... "Menu text"
base, default,
poly, circle, rect, or
point. The value is an absolute or relative URL, or one
of the special values listed below. The coordinates are
x,y pairs separated by whitespace. The quoted text is
used as the text of the link if a imagemap menu is generated. Lines
beginning with '#' are comments.
Imagemap File Directives
There are six directives allowed in the imagemap file. The directives can come in any order, but are processed in the order they are found in the imagemap file.baseDirective- Has the effect of
<BASE href="value">. The non-absolute URLs of the map-file are taken relative to this value. Thebasedirective overrides ImapBase as set in a .htaccess file or in the server configuration files. In the absence of an ImapBase configuration directive,basedefaults tohttp://server_name/.
base_uriis synonymous withbase. Note that a trailing slash on the URL is significant. defaultDirective- The action taken if the coordinates given do not fit any of the
poly,circleorrectdirectives, and there are nopointdirectives. Defaults tonocontentin the absence of an ImapDefault configuration setting, causing a status code of204 No Contentto be returned. The client should keep the same page displayed. polyDirective- Takes three to one-hundred points, and is obeyed if the user selected
coordinates fall within the polygon defined by these points.
circle- Takes the center coordinates of a circle and a point on the circle. Is
obeyed if the user selected point is with the circle.
rectDirective- Takes the coordinates of two opposing corners of a rectangle. Obeyed
if the point selected is within this rectangle.
pointDirective- Takes a single point. The point directive closest to the user
selected point is obeyed if no other directives are satisfied.
Note that
defaultwill not be followed if apointdirective is present and valid coordinates are given.
Values
The values for each of the directives can any of the following:- a URL
- The URL can be relative or absolute URL. Relative URLs can
contain '..' syntax and will be resolved relative to the
basevalue.
baseitself will not resolved according to the current value. A statementbase mailto:will work properly, though. map- Equivalent to the URL of the imagemap file itself. No
coordinates are sent with this, so a menu will be generated
unless ImapMenu is set to 'none'.
menu- Synonymous with
map. referer- Equivalent to the URL of the referring document.
Defaults to
http://servername/if no Referer: header was present. nocontent- Sends a status code of
204 No Content, telling the client to keep the same page displayed. Valid for all butbase. error- Fails with a
500 Server Error. Valid for all butbase, but sort of silly for anything butdefault.
Coordinates
0,0 200,200- A coordinate consists of an x and a y value
separated by a comma. The coordinates are separated from each other
by whitespace. To accommodate the way Lynx handles imagemaps, should a
user select the coordinate
0,0, it is as if no coordinate had been selected.
Quoted Text
"Menu Text"- After the value or after the coordinates, the line optionally may
contain text within double quotes. This string is used as the
text for the link if a menu is generated:
<a href="http://foo.com/">Menu text</a>
If no quoted text is present, the name of the link will be used as the text:
<a href="http://foo.com/">http://foo.com</a>
It is impossible to escape double quotes within this text.
Example Mapfile
#Comments are printed in a 'formatted' or 'semiformatted' menu.
#And can contain html tags. <hr>
base referer
poly map "Could I have a menu, please?" 0,0 0,10 10,10 10,0
rect .. 0,0 77,27 "the directory of the referer"
circle http://www.inetnebr.com/lincoln/feedback/ 195,0 305,27
rect another_file "in same directory as referer" 306,0 419,27
point http://www.zyzzyva.com/ 100,100
point http://www.tripod.com/ 200,200
rect mailto:nate@tripod.com 100,150 200,0 "Bugs?"
Referencing your mapfile
<A HREF="/maps/imagmap1.map">
<IMG ISMAP SRC="/images/imagemap1.gif">
</A>
Apache HTTP Server Version 1.2
07070100002ccb000081a400000064000000640000000134b16bd600003644000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_include.html
Apache HTTP Server Version 1.2
Module mod_include
This module is contained in themod_include.c file, and
is compiled in by default. It provides for server-parsed html
documents. Several directives beyond the original NCSA definition have been
included in Apache 1.2 - these are flagged below with the phrase
"Apache 1.2 and above". Of particular significance are the new flow
control directives documented at the bottom.
Enabling Server-Side Includes
Any document with handler of "server-parsed" will be parsed by this module, if theIncludes option is set. If documents
containing server-side include directives are given the extension
.shtml, the following directives will make Apache parse them and
assign the resulting document the mime type of text/html:
AddType text/html .shtml AddHandler server-parsed .shtmlThe following directive must be given for the directories containing the shtml files (typically in a
<Directory> section,
but this directive is also valid .htaccess files if AllowOverride
Options is set):
Options +IncludesAlternatively the
XBitHack
directive can be used to parse normal (text/html) files,
based on file permissions.
For backwards compatibility, documents with mime type
text/x-server-parsed-html or
text/x-server-parsed-html3 will also be parsed
(and the resulting output given the mime type text/html).
Basic Elements
The document is parsed as an HTML document, with special commands embedded as SGML comments. A command has the syntax:The value will often be enclosed in double quotes; many commands only allow a single attribute-value pair. Note that the comment terminator (-->) should be preceded by whitespace to ensure that it isn't considered part of an SSI token.<!--#element attribute=value attribute=value ...-->
The allowed elements are:
- config
-
This command controls various aspects of the parsing. The valid attributes
are:
- errmsg
- The value is a message that is sent back to the client if an error occurs whilst parsing the document.
- sizefmt
- The value sets the format to be used which displaying the size of a file.
Valid values are
bytesfor a count in bytes, orabbrevfor a count in Kb or Mb as appropriate. - timefmt
- The value is a string to be used by the
strftime(3)library routine when printing dates.
- echo
-
This command prints one of the include variables, defined below.
If the variable is unset, it is printed as
(none). Any dates printed are subject to the currently configuredtimefmt. Attributes:- var
- The value is the name of the variable to print.
- exec
-
The exec command executes a given shell command or CGI script.
The IncludesNOEXEC Option disables this command
completely. The valid attributes are:
- cgi
-
The value specifies a (%-encoded) URL relative path to the CGI script.
If the path does not begin with a (/), then it is taken to be relative to
the current document. The document referenced by this path is invoked
as a CGI script, even if the server would not normally recognize it as
such. However, the directory containing the script must be enabled for
CGI scripts (with ScriptAlias
or the ExecCGI Option).
The CGI script is given the PATH_INFO and query string (QUERY_STRING) of the original request from the client; these cannot be specified in the URL path. The include variables will be available to the script in addition to the standard CGI environment.
If the script returns a Location: header instead of output, then this will be translated into an HTML anchor.
The
include virtualelement should be used in preference toexec cgi. - cmd
- The server will execute the given string using
/bin/sh. The include variables are available to the command.
- fsize
-
This command prints the size of the specified file, subject to the
sizefmtformat specification. Attributes:- file
- The value is a path relative to the directory containing the current document being parsed.
- virtual
- The value is a (%-encoded) URL-path relative to the current document being parsed. If it does not begin with a slash (/) then it is taken to be relative to the current document.
- flastmod
-
This command prints the last modification date of the specified file,
subject to the
timefmtformat specification. The attributes are the same as for thefsizecommand. - include
-
This command inserts the text of another document or file into the parsed
file. Any included file is subject to the usual access control. If the
directory containing the parsed file has the
Option
IncludesNOEXEC set, and the including the document would cause a program
to be executed, then it will not be included; this prevents the execution of
CGI scripts. Otherwise CGI scripts are invoked as normal using the complete
URL given in the command, including any query string.
An attribute defines the location of the document; the inclusion is done for each attribute given to the include command. The valid attributes are:
- file
- The value is a path relative to the directory containing the current
document being parsed. It cannot contain
../, nor can it be an absolute path. Thevirtualattribute should always be used in preference to this one. - virtual
- The value is a (%-encoded) URL relative to the current document being parsed. The URL cannot contain a scheme or hostname, only a path and an optional query string. If it does not begin with a slash (/) then it is taken to be relative to the current document.
- printenv
- This prints out a listing of all existing variables and their values.
No attributes.
- For example:
<!--#printenv -->- Apache 1.2 and above.
- For example:
- set
- This sets the value of a variable. Attributes:
- var
- The name of the variable to set.
- value
- The value to give a variable.
<!--#set var="category" value="help" -->- Apache 1.2 and above.
Include Variables
In addition to the variables in the standard CGI environment, these are available for theecho command, for if and
elif, and to any program invoked by the document.
- DATE_GMT
- The current date in Greenwich Mean Time.
- DATE_LOCAL
- The current date in the local time zone.
- DOCUMENT_NAME
- The filename (excluding directories) of the document requested by the user.
- DOCUMENT_URI
- The (%-decoded) URL path of the document requested by the user. Note that in the case of nested include files, this is not then URL for the current document.
- LAST_MODIFIED
- The last modification date of the document requested by the user.
Variable Substitution
Variable substitution is done within quoted strings in most cases where they may reasonably occur as an argument to an SSI directive. This includes the config, exec, flastmod, fsize, include, and set directives, as well as the arguments to conditional operators. You can insert a literal dollar sign into the string using backslash quoting:
<!--#if expr="$a = \$test" -->
If a variable reference needs to be substituted in the middle of a character sequence that might otherwise be considered a valid identifier in its own right, it can be disambiguated by enclosing the reference in braces, à la shell substitution:
<!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" -->
This will result in the Zed variable being set to "X_Y" if REMOTE_HOST is "X" and REQUEST_METHOD is "Y".
EXAMPLE: the below example will print "in foo" if the DOCUMENT_URI is /foo/file.html, "in bar" if it is /bar/file.html and "in neither" otherwise:
<!--#if expr="\"$DOCUMENT_URI\" = \"/foo/file.html\"" -->
in foo
<!--#elif expr="\"$DOCUMENT_URI\" = \"/bar/file.html\"" -->
in bar
<!--#else -->
in neither
<!--#endif -->
Flow Control Elements
These are available in Apache 1.2 and above. The basic flow control elements are:
<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->
The if element works like an
if statement in a programming language. The test condition
is evaluated and if the result is true, then the text until
the next elif, else.
or endif element is included in the
output stream.
The elif or else
statements are be used the put text into the output stream
if the original test_condition was false. These elements
are optional.
The endif element ends the
if element and is required.
test_condition is one of the following:
- string
- true if string is not empty
- string1 = string2
string1 != string2 - Compare string1 with string 2. If string2 has the form /string/ than it is compared as a regular expression. Regular expressions have the same syntax as those found in the Unix egrep command.
- ( test_condition )
- true if test_condition is true
- ! test_condition
- true if test_condition is false
- test_condition1 && test_condition2
- true if both test_condition1 and test_condition2 are true
- test_condition1 || test_condition2
- true if either test_condition1 or test_condition2 is true
"=" and "!=" bind more tightly than "&&" and "||". "!" binds most tightly. Thus, the following are equivalent:
<!--#if expr="$a = test1 && $b = test2" -->
<!--#if expr="($a = test1) && ($b = test2)" -->
Anything that's not recognized as a variable or an operator is treated as a string. Strings can also be quoted: 'string'. Unquoted strings can't contain whitespace (blanks and tabs) because it is used to separate tokens such as variables. If multiple strings are found in a row, they are concatenated using blanks. So,
string1 string2 results in string1 string2
'string1 string2' results in string1 string2
Directives
XBitHack
Syntax: XBitHack statusDefault:
XBitHack offContext: server config, virtual host, directory, .htaccess
Override: Options
Status: Base
Module: mod_include
The XBitHack directives controls the parsing of ordinary html documents.
This directive only affects files associated with the MIME type
text/html.
Status can have the following values:
- off
- No special treatment of executable files.
- on
- Any file that has the user-execute bit set will be treated as a server-parsed html document.
- full
- As for
onbut also test the group-execute bit. If it is set, then set the Last-modified date of the returned file to be the last modified time of the file. If it is not set, then no last-modified date is sent. Setting this bit allows clients and proxies to cache the result of the request.Note: you would not want to use this, for example, when you
#includea CGI that produces different output on each hit (or potentially depends on the hit).
Apache HTTP Server Version 1.2
07070100002ccc000081a400000064000000640000000134b16bd60000097f000000200000001b00000000000000000000002600000004reloc/htdocs/manual/mod/mod_info.html
Apache HTTP Server Version 1.2
Module mod_info
This module is contained in themod_info.c file. It
provides a comprehensive overview of the server configuration
including all installed modules and directives in the configuration
files. This module is not compiled into the
server by default. It is only available in Apache 1.1 and later. To
enable it, add the following line to the server build Configuration
file, and rebuild the server:
Module info_module mod_info.o
To configure it, add the following to your access.conf file.
<Location /server-info> SetHandler server-info </Location>You may wish to add a <Limit> clause inside the location directive to limit access to your server configuration information.
Once configured, the server information is obtained by accessing http://your.host.dom/server-info
Note that the configuration files are read by the module at run-time, and therefore the display may not reflect the running server's active configuration if the files have been changed since the server was last reloaded. Also, the configuration files must be readable by the user as which the server is running (see the User directive), or else the directive settings will not be listed.It should also be noted that if mod_info is compiled into the server, its handler capability is available in all configuration files, including per-directory files (e.g., .htaccess). This may have security-related ramifications for your site.
Apache HTTP Server Version 1.2
07070100002ccd000081a400000064000000640000000134b16bd6000008c1000000200000001b00000000000000000000002b00000004reloc/htdocs/manual/mod/mod_log_agent.html
Apache HTTP Server Version 1.2
Module mod_log_agent
This module is contained in themod_log_agent.c file, and is not
compiled in by default. It provides for logging of the client user agents.
AgentLog
Syntax: AgentLog file-pipeDefault:
AgentLog logs/agent_logContext: server config, virtual host
Status: Extension
Module: mod_log_agent
The AgentLog directive sets the name of the file to which the server will log the UserAgent header of incoming requests. File-pipe is one of
- A filename
- A filename relative to the ServerRoot.
- `|' followed by a command
- A program to receive the agent log information on its standard input. Note the a new program will not be started for a VirtualHost if it inherits the AgentLog from the main server.
Security: See the security tips document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server.
This directive is provided for compatibility with NCSA 1.4.
Apache HTTP Server Version 1.2
07070100002cce000081a400000064000000640000000134b16bd600000e47000000200000001b00000000000000000000002c00000004reloc/htdocs/manual/mod/mod_log_common.html
Apache HTTP Server Version 1.2
Module mod_log_common
This module is contained in themod_log_common.c file,
and is compiled in by default. It provides for logging of the requests
made to the server using the Common Logfile Format. This module has
been replaced by mod_log_config in Apache 1.2
Log file format
The log file contains a separate line for each request. A line is composed of several tokens separated by spaces:host ident authuser date request status bytesIf a token does not have a value then it is represented by a hyphen (-). The meanings and values of these tokens are as follows:
- host
- The fully-qualified domain name of the client, or its IP number if the name is not available.
- ident
- If IdentityCheck is enabled and the client machine runs identd, then this is the identity information reported by the client.
- authuser
- If the request was for an password protected document, then this is the userid used in the request.
- date
- The date and time of the request, in the following format:
date = [day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit
- request
- The request line from the client, enclosed in double quotes
(
"). - status
- The three digit status code returned to the client.
- bytes
- The number of bytes in the object returned to the client, not including any headers.
Directives
TransferLog
Syntax: TransferLog file-pipeDefault:
TransferLog logs/transfer_logContext: server config, virtual host
Status: Base
Module: mod_log_common
The TransferLog directive sets the name of the file to which the server will log the incoming requests. File-pipe is one of
- A filename
- A filename relative to the ServerRoot.
- `|' followed by a command
- A program to receive the agent log information on its standard input. Note the a new program will not be started for a VirtualHost if it inherits the TransferLog from the main server.
Security: See the security tips document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server.
Apache HTTP Server Version 1.2
07070100002ccf000081a400000064000000640000000134b16bd600002901000000200000001b00000000000000000000002c00000004reloc/htdocs/manual/mod/mod_log_config.html
Apache HTTP Server Version 1.2
Module mod_log_config
This module is contained in themod_log_config.c file,
and is compiled in by default in Apache 1.2. mod_log_config replaces
mod_log_common in Apache 1.2. Prior to version 1.2, mod_log_config was
an optional module. It provides for logging of the requests made to
the server, using the Common Log Format or a user-specified format.
Summary
Three directives are provided by this module:TransferLog
to create a log file, LogFormat to set a custom format,
and CustomLog to define a log file and format in one go.
The TransferLog and CustomLog directives can
be used multiple times in each server to cause each request to be
logged to multiple files.
Compatibility notes
- This module is based on mod_log_config distributed with previous Apache releases, now updated to handle multiple logs. There is now no need to re-configure Apache to use configuration log formats.
- The module also implements the
CookieLogdirective, used to log user-tracking information created by mod_usertrack. The use ofCookieLogis deprecated, and aCustomLogshould be defined to log user-tracking information instead.
Log File Formats
Unless told otherwise with LogFormat the log files created by TransferLog will be in standard "Common Log Format" (CLF). The contents of each line in a CLF file are explained below. Alternatively, the log file can be customized (and if multiple log files are used, each can have a different format). Custom formats are set withLogFormat and CustomLog.
Common Log Format
The Common Log Format (CLF) file contains a separate line for each request. A line is composed of several tokens separated by spaces:host ident authuser date request status bytesIf a token does not have a value then it is represented by a hyphen (-). The meanings and values of these tokens are as follows:
- host
- The fully-qualified domain name of the client, or its IP number if the name is not available.
- ident
- If IdentityCheck is enabled and the client machine runs identd, then this is the identity information reported by the client.
- authuser
- If the request was for an password protected document, then this is the userid used in the request.
- date
- The date and time of the request, in the following format:
date = [day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit
- request
- The request line from the client, enclosed in double quotes
(
"). - status
- The three digit status code returned to the client.
- bytes
- The number of bytes in the object returned to the client, not including any headers.
Custom Log Formats
The format argument to theLogFormat and
CustomLog is a string. This string is logged to the log
file for each request. It can contain literal characters copied into
the log files, and `%' directives which are replaced in the log file
by the values as follows:
%...b: Bytes sent, excluding HTTP headers.
%...f: Filename
%...{FOOBAR}e: The contents of the environment variable FOOBAR
%...h: Remote host
%...{Foobar}i: The contents of Foobar: header line(s) in the request
sent to the server.
%...l: Remote logname (from identd, if supplied)
%...{Foobar}n: The contents of note "Foobar" from another module.
%...{Foobar}o: The contents of Foobar: header line(s) in the reply.
%...p: The port the request was served to
%...P: The process ID of the child that serviced the request.
%...r: First line of request
%...s: Status. For requests that got internally redirected, this
is status of the *original* request --- %...>s for the last.
%...t: Time, in common log format time format
%...{format}t: The time, in the form given by format, which should
be in strftime(3) format.
%...T: The time taken to serve the request, in seconds.
%...u: Remote user (from auth; may be bogus if return status (%s) is 401)
%...U: The URL path requested.
%...v: The name of the server (i.e. which virtual host?)
The `...' can be nothing at all (e.g. "%h %u %r %s %b"), or it can
indicate conditions for inclusion of the item (which will cause it
to be replaced with `-' if the condition is not met). Note that
there is no escaping performed on the strings from %r, %...i and
%...o; some with long memories may remember that I thought this was
a bad idea, once upon a time, and I'm still not comfortable with
it, but it is difficult to see how to `do the right thing' with all
of `%..i', unless we URL-escape everything and break with CLF.
The forms of condition are a list of HTTP status codes, which may or may not be preceded by `!'. Thus, `%400,501{User-agent}i' logs User-agent: on 400 errors and 501 errors (Bad Request, Not Implemented) only; `%!200,304,302{Referer}i' logs Referer: on all requests which did not return some sort of normal status.
Note that the common log format is defined by the string "%h %l
%u %t \"%r\" %s %b", which can be used as the basis for
extending for format if desired (e.g. to add extra fields at the end).
NCSA's extended/combined log format would be "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\"".
Using Multiple Log Files
TheTransferLog and CustomLog directives can
be given more than once to log requests to multiple log files. Each
request will be logged to all the log files defined by either of these
directives.
Use with Virtual Hosts
If a <VirtualHost> section does not contain any TransferLog or CustomLog directives, the logs defined for the main server will be used. If it does contain one or more of these directives, requests serviced by this virtual host will only be logged in the log files defined within its definition, not in any of the main server's log files. See the examples below.
Security Considerations
See the security tips document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server.
Directives
CookieLog
Syntax: CookieLog filenameContext: server config, virtual host
Module: mod_cookies
Compatibility: Only available in Apache 1.2 and above
The CookieLog directive sets the filename for logging of cookies. The filename is relative to the ServerRoot. This directive is included only for compatibility with mod_cookies, and is deprecated.
CustomLog
Syntax: CustomLog file-pipe formatContext: server config, virtual host
Status: Base
Module: mod_log_config
The first argument is the filename to log to. This is used exactly like the argument to TransferLog, that is, it is either a full path, or relative to the current server root.
The format argument specifies a format for each line of the log file. The options available for the format are exactly the same as for the argument of the LogFormat directive. If the format includes any spaces (which it will do in almost all cases) it should be enclosed in double quotes.
LogFormat
Syntax: LogFormat stringDefault:
LogFormat "%h %l %u %t \"%r\"
%s %b"Context: server config, virtual host
Status: Base
Module: mod_log_config
This sets the format of the logfile. See Custom Log Formats for details on the format arguments.
TransferLog
Syntax: TransferLog file-pipeDefault: none
Context: server config, virtual host
Status: Base
Module: mod_log_config
The TransferLog directive adds a log file in Common Log Format. File-pipe is one of
- A filename
- A filename relative to the ServerRoot.
- `|' followed by a command
- A program to receive the agent log information on its standard input. Note the a new program will not be started for a VirtualHost if it inherits the TransferLog from the main server.
Apache HTTP Server Version 1.2
07070100002cd0000081a400000064000000640000000134b16bd600000d6d000000200000001b00000000000000000000002d00000004reloc/htdocs/manual/mod/mod_log_referer.html
Apache HTTP Server Version 1.2
Module mod_log_referer
This module is contained in themod_log_referer.c file, and is not
compiled in by default. It provides for logging of the documents which
reference documents on the server.
Log file format
The log file contains a separate line for each refer. Each line has the formaturi -> document
where uri is the (%-escaped) URI for the document that references
the one requested by the client, and document is the (%-decoded)
local URL to the document being referred to.
Directives
RefererIgnore
Syntax: RefererIgnore string string ...Context: server config, virtual host
Status: Extension
Module: mod_log_referer
The RefererIgnore directive adds to the list of strings to ignore in Referer headers. If any of the strings in the list is contained in the Referer header, then no referrer information will be logged for the request. Example:
RefererIgnore www.ncsa.uiuc.eduRefererLog
Syntax: RefererLog file-pipeDefault:
RefererLog logs/referer_logContext: server config, virtual host
Status: Extension
Module: mod_log_referer
The RefererLog directive sets the name of the file to which the server will log the Referer header of incoming requests. File-pipe is one of
- A filename
- A filename relative to the ServerRoot.
- `|' followed by a command
- A program to receive the referrer log information on its standard input. Note the a new program will not be started for a VirtualHost if it inherits the RefererLog from the main server.
Security: See the security tips document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server.
This directive is provided for compatibility with NCSA 1.4.
Apache HTTP Server Version 1.2
07070100002cd1000081a400000064000000640000000134b16bd6000025a4000000200000001b00000000000000000000002600000004reloc/htdocs/manual/mod/mod_mime.html
Apache HTTP Server Version 1.2
Module mod_mime
This module is contained in themod_mime.c file, and is
compiled in by default. It provides for determining the types of files
from the filename.
Summary
This module is used to determine various bits of "meta information" about documents. This information relates to the content of the document and is returned to the browser or used in content-negotiation within the server. In addition, a "handler" can be set for a document, which determines how the document will be processed within the server.The directives AddEncoding, AddHandler, AddLanguage and AddType are all used to map file extensions onto the meta-information for that file. Respectively they set the content-encoding, handler, content-language and mime-type (content-type) of documents. The directive TypesConfig is used to specify a file which also maps extensions onto mime types. The directives ForceType and SetHandler are used to associated all the files in a given location (e.g. a particular directory) onto a particular mime type or handler.
Files can have more than one extension, and the order of the
extensions is normally irrelevant. For example, if the file
welcome.html.fr maps onto content type text/html and
language French then the file welcome.fr.html will map
onto exactly the same information. The only exception to this is if an
extension is given which Apache does not know how to handle. In this
case it will "forget" about any information it obtained from
extensions to the left of the unknown extension. So, for example, if
the extensions fr and html are mapped to the appropriate language and
type but extension xxx is not assigned to anything, then the file
welcome.fr.xxx.html will be associated with content-type
text/html but no language.
Directives
AddEncoding
Syntax: AddEncoding mime-enc extension extension...Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_mime
The AddEncoding directive adds to the list of filename extensions which filenames may end in for the specified encoding type. Mime-enc is the mime encoding to use for documents ending in extension. Example:
AddEncoding x-gzip gz
AddEncoding x-compress Z
AddHandler
Syntax: AddHandler handler-name extension extension...Context: server config, virtual host, directory, .htaccess
Status: Base
Module: mod_mime
Compatibility: AddHandler is only available in Apache 1.1 and later
AddHandler maps the filename extensions 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.
AddLanguage
Syntax: AddLanguage mime-lang extension extension...Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_mime
The AddLanguage directive adds to the list of filename extensions which filenames may end in for the specified content language. Mime-lang is the mime language of files with names ending extension, after any content encoding extensions have been removed. Example:
AddEncoding x-compress Z
AddLanguage en .en
AddLanguage fr .fr
xxxx.en.Z will be treated as being a compressed
English document. Although the content language is reported to the client,
the browser is unlikely to use this information. The AddLanguage directive
is more useful for content negotiation, where the server returns one
from several documents based on the client's language preference.AddType
Syntax: AddType mime-type extension extension...Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_mime
The AddType directive adds to the list of filename extensions which filenames may end in for the specified content type. Mime-enc is the mime type to use for documents ending in extension. after content-encoding and language extensions have been removed. Example:
AddType image/gif GIF
Note that, unlike the NCSA httpd, this directive cannot be used to set the type of particular files.
ForceType
Syntax: ForceType media typeContext: directory, .htaccess
Status: Base
Module: mod_mime
Compatibility: ForceType is only available in Apache 1.1 and later.
When placed into an .htaccess file or a
<Directory> or <Location> section,
this directive forces all matching files to be served
as the content type given by media type. For example, if you
had a directory full of GIF files, but did not want to label them all with
".gif", you might want to use:
ForceType image/gif
Note that this will override any filename extensions that might media type.
SetHandler
Syntax: SetHandler handler-nameContext: directory, .htaccess
Status: Base
Module: mod_mime
Compatibility: SetHandler is only available in Apache 1.1 and later.
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>
TypesConfig
Syntax: TypesConfig filenameDefault:
TypesConfig conf/mime.typesContext: server config
Status: Base
Module: mod_mime
The TypesConfig directive sets the location of the mime types configuration file. Filename is relative to the ServerRoot. This file sets the default list of mappings from filename extensions to content types; changing this file is not recommended. Use the AddType directive instead. The file contains lines in the format of the arguments to an AddType command:
mime-type extension extension ...The extensions are lower-cased. Blank lines, and lines beginning with a hash character (`#') are ignored.
Apache HTTP Server Version 1.2
07070100002cd2000081a400000064000000640000000134b16bd7000016f8000000200000001b00000000000000000000002d00000004reloc/htdocs/manual/mod/mod_negotiation.html
Apache HTTP Server Version 1.2
Module mod_negotiation
This module is contained in themod_negotiation.c file,
and is compiled in by default. It provides for content negotiation.
Summary
Content negotiation, or more accurately content selection, is the selection of the document that best matches the clients capabilities, from one of several available documents. There are two implementations of this.- A type map (a file with the handler
type-map) which explicitly lists the files containing the variants. - A MultiViews search (enabled by the MultiViews Option, where the server does an implicit filename pattern match, and choose from amongst the results.
Type maps
A type map has the same format as RFC822 mail headers. It contains document descriptions separated by blank lines, with lines beginning with a hash character ('#') treated as comments. A document description consists of several header records; records may be continued on multiple lines if the continuation lines start with spaces. The leading space will be deleted and the lines concatenated. A header record consists of a keyword name, which always ends in a colon, followed by a value. Whitespace is allowed between the header name and value, and between the tokens of value. The headers allowed are:- Content-Encoding:
- The encoding of the file. Currently only two encodings are recognized
by http;
x-compressfor compressed files, andx-gzipfor gzipped files. - Content-Language:
- The language of the variant, as an Internet standard language code, such
as
en. - Content-Length:
- The length of the file, in bytes. If this header is not present, then the actual length of the file is used.
- Content-Type:
- The MIME media type of the document, with optional parameters.
parameters are separated from the media type and from one another by
semi-colons. Parameter syntax is name=value; allowed parameters are:
- level
- the value is an integer, which specifies the version of the media type.
For
text/htmlthis defaults to 2, otherwise 0. - qs
- the value is a floating-point number with value between 0. and 1. It indications the 'quality' of this variant.
Content-Type: image/jpeg; qs=0.8 - URI:
- The path to the file containing this variant, relative to the map file.
MultiViews
A MultiViews search is enabled by the MultiViews Option. If the server receives a request for/some/dir/foo and
/some/dir/foo does not exist, then the server reads the
directory looking for all 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 returns that document.
Directives
CacheNegotiatedDocs
Syntax: CacheNegotiatedDocsContext: server config
Status: Base
Module: mod_negotiation
Compatibility: CacheNegotiatedDocs is only available in Apache 1.1 and later.
If set, this directive allows content-negotiated documents to be cached by proxy servers. This could mean that clients behind those proxys could retrieve versions of the documents that are not the best match for their abilities, but it will make caching more efficient.
This directive only applies to requests which come from HTTP/1.0 browsers. HTTP/1.1 provides much better control over the caching of negotiated documents, and this directive has no effect in responses to HTTP/1.1 requests.
LanguagePriority
Syntax: LanguagePriority mime-lang mime-lang...Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_negotiation
The LanguagePriority sets the precedence of language variants for the case where the client does not express a preference, when handling a MultiViews request. The list of mime-lang are in order of decreasing preference. Example:
LanguagePriority en fr defoo.html, where foo.html.fr
and foo.html.de both existed, but the browser did not express
a language preference, then foo.html.fr would be returned.
Note that this directive only has an effect if a 'best' language cannot be determined by other any other means. Correctly implemented HTTP/1.1 requests will mean this directive has no effect.
Apache HTTP Server Version 1.2
07070100002cd3000081a400000064000000640000000134b16bd70000382f000000200000001b00000000000000000000002700000004reloc/htdocs/manual/mod/mod_proxy.html
Apache HTTP Server Version 1.2
Module mod_proxy
This module is contained in themod_proxy.c file for Apache 1.1.x,
or the modules/proxy subdirectory for Apache 1.2, and
is not compiled in by default. It provides for an HTTP 1.0 caching proxy
server. It is only available in Apache 1.1 and later. Common configuration
questions are addressed here.
Note:
This module was experimental in Apache 1.1.x. As of Apache 1.2, mod_proxy stability is greatly improved.
Summary
This module implements a proxy/cache for Apache. It implements proxying capability forFTP,
CONNECT (for SSL),
HTTP/0.9, and
HTTP/1.0.
The module can be configured to connect to other proxy modules for these
and other protocols.
Directives
- ProxyRequests
- ProxyRemote
- ProxyPass
- ProxyBlock
- CacheRoot
- CacheSize
- CacheMaxExpire
- CacheDefaultExpire
- CacheLastModifiedFactor
- CacheGcInterval
- CacheDirLevels
- CacheDirLength
- NoCache
ProxyRequests
Syntax: ProxyRequests on/offDefault:
ProxyRequests OffContext: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: ProxyRequest is only available in Apache 1.1 and later.
This allows or prevents Apache from functioning as a proxy
server. Setting ProxyRequests to 'off' does not disable use of the ProxyPass directive.
ProxyRemote
Syntax: ProxyRemote <match> <remote-server>
Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: ProxyRemote is only available in
Apache 1.1 and later.
This defines remote proxies to this proxy. <match> is either the name of a URL-scheme that the remote server supports, or a partial URL for which the remote server should be used, or '*' to indicate the server should be contacted for all requests. <remote-server> is a partial URL for the remote server. Syntax:
<remote-server> = <protocol>://<hostname>[:port]<protocol> is the protocol that should be used to communicate with the remote server; only "http" is supported by this module. Example:
ProxyRemote http://goodguys.com/ http://mirrorguys.com:8000 ProxyRemote * http://cleversite.com ProxyRemote ftp http://ftpproxy.mydomain.com:8080In the last example, the proxy will forward FTP requests, encapsulated as yet another HTTP proxy request, to another proxy which can handle them.
ProxyPass
Syntax: ProxyPass <path> <url>Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: ProxyPass is only available in Apache 1.1 and later.
This directive allows remote servers to be mapped into the space of the local server; the local server does not act as a proxy in the conventional sense, but appears to be a mirror of the remote server. <path> is the name of a local virtual path; <url> is a partial URL for the remote server. Suppose the local server has address http://wibble.org; then
ProxyPass /mirror/foo http://foo.comWill cause a local request for the http://wibble.org/mirror/foo/bar to be internally converted into a proxy request to http://foo.com/bar
ProxyBlock
Syntax: ProxyBlock <word/host/domain list>Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: ProxyBlock is only available in Apache 1.2 and later.
The ProxyBlock directive specifies a list of words, hosts and/or domains, separated by spaces. HTTP, HTTPS, and FTP document requests to matched words, hosts or domains are blocked by the proxy server. The proxy module will also attempt to determine IP addresses of list items which may be hostnames during startup, and cache them for match test as well. Example:
ProxyBlock joes_garage.com some_host.co.uk rocky.wotsamattau.edu'rocky.wotsamattau.edu' would also be matched if referenced by IP address.
Note that 'wotsamattau' would also be sufficient to match 'wotsamattau.edu'.
Note also that
ProxyBlock *blocks connections to all sites.
CacheRoot
Syntax: CacheRoot <directory>Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: CacheRoot is only available in Apache 1.1 and later.
Sets the name of the directory to contain cache files; this must be
writable
by the httpd server.
CacheSize
Syntax: CacheSize <size>
Default: CacheSize 5
Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: CacheSize is only available in
Apache 1.1 and later.
Sets the desired space usage of the cache, in Kb (1024 byte units). Although
usage may grow above this setting, the garbage collection will delete files
until the usage is at or below this setting.
CacheGcInterval
Syntax: CacheGcInterval <time>
Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: CacheGcinterval is only available in
Apache 1.1 and later.
Check the cache every <time> hours, and delete files if the space
usage is greater than that set by CacheSize.
CacheMaxExpire
Syntax: CacheMaxExpire <time>
Default: CacheMaxExpire 24
Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: CacheMaxExpire is only available in
Apache 1.1 and later.
Cachable HTTP documents will be retained for at most <time> hours without
checking the origin server. Thus documents can be at most <time>
hours out of date. This restriction is enforced even if an expiry date
was supplied with the document.
CacheLastModifiedFactor
Syntax: CacheLastModifiedFactor <factor>
Default: CacheLastModifiedFactor 0.1
Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: CacheLastModifiedFactor is only available in
Apache 1.1 and later.
If the origin HTTP server did not supply an expiry date for the document, then estimate one using the formula
expiry-period = time-since-last-modification * <factor>For example, if the document was last modified 10 hours ago, and <factor> is 0.1, then the expiry period will be set to 10*0.1 = 1 hour.
If the expiry-period would be longer than that set by CacheMaxExpire,
then the latter takes precedence.
CacheDirLevels
Syntax: CacheDirLevels <levels>
Default: CacheDirLevels 3
Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: CacheDirLevels is only available in
Apache 1.1 and later.
CacheDirLevels sets the number of levels of subdirectories in the cache.
Cached data will be saved this many directory levels below CacheRoot.
CacheDirLength
Syntax: CacheDirLength <length>
Default: CacheDirLength 1
Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: CacheDirLength is only available in
Apache 1.1 and later.
CacheDirLength sets the number of characters in proxy cache subdirectory names.
CacheDefaultExpire
Syntax: CacheDefaultExpire <time>
Default: CacheDefaultExpire 1
Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: CacheDefaultExpire is only available in
Apache 1.1 and later.
If the document is fetched via a protocol that does not support expiry times,
then use <time> hours as the expiry time.
CacheMaxExpire does not
override.
NoCache
Syntax: NoCache <word/host/domain list>
Context: server config, virtual host
Status: Base
Module: mod_proxy
Compatibility: NoCache is only available in
Apache 1.1 and later.
The NoCache directive specifies a list of words, hosts and/or domains, separated by spaces. HTTP and non-passworded FTP documents from matched words, hosts or domains are not cached by the proxy server. The proxy module will also attempt to determine IP addresses of list items which may be hostnames during startup, and cache them for match test as well. Example:
NoCache joes_garage.com some_host.co.uk bullwinkle.wotsamattau.edu'bullwinkle.wotsamattau.edu' would also be matched if referenced by IP address.
Note that 'wotsamattau' would also be sufficient to match 'wotsamattau.edu'.
Note also that
NoCache *disables caching completely.
Common configuration topics
- Controlling access to your proxy
- Using Netscape hostname shortcuts
- Why doesn't file type xxx download via FTP?
- Why does Apache start more slowly when using the proxy module?
- Can I use the Apache proxy module with my SOCKS proxy?
Controlling access to your proxy
You can control who can access your proxy via the normal <Directory> control block using the following example:
<Directory proxy:*> <Limit GET PUT POST DELETE CONNECT OPTIONS> order deny,allow deny from [machines you'd like *not* to allow by IP address or name] allow from [machines you'd like to allow by IP address or name] </Limit> </Directory>
A <Files> block will also work, and is the only method known to work for all possible URLs in Apache versions earlier than 1.2b10.
Using Netscape hostname shortcuts
There is an optional patch to the proxy module to allow Netscape-like hostname shortcuts to be used. It's available here.
Why doesn't file type xxx download via FTP?
You probably don't have that particular file type defined as application/octet-stream in your proxy's mime.types configuration file. A useful line can be
application/octet-stream bin dms lha lzh exe class tgz taz
Why does Apache start more slowly when using the proxy module?
If you're using theProxyBlock or NoCache
directives, hostnames' IP addresses are looked up and cached during
startup for later match test. This may take a few seconds (or more)
depending on the speed with which the hostname lookups occur.
Can I use the Apache proxy module with my SOCKS proxy?
Yes. Just build Apache with the ruleSOCKS4=yes in your
Configuration file, and follow the instructions there. SOCKS5
capability can be added in a similar way (there's no SOCKS5
rule yet), so use the EXTRA_LFLAGS definition, or build Apache
normally and run it with the runsocks wrapper provided with SOCKS5,
if your OS supports dynamically linked libraries.Some users have reported problems when using SOCKS version 4.2 on Solaris. The problem was solved by upgrading to SOCKS 4.3.
Remember that you'll also have to grant access to your Apache proxy machine by permitting connections on the appropriate ports in your SOCKS daemon's configuration.
Apache HTTP Server Version 1.2
07070100002cd4000081a400000064000000640000000134b16bd70000b42f000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_rewrite.html
Apache HTTP Server Version 1.2
Module mod_rewrite
This module is contained in themod_rewrite.c file, with Apache
1.2 and later. It provides a rule-based rewriting engine to rewrite requested
URLs on the fly. mod_rewrite is not compiled into the server by
default. To use mod_rewrite you have to enable the following line
in the server build Configuration file:
Module rewrite_module mod_rewrite.o
Summary
This module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly.It supports an unlimited number of additional rule conditions (which can operate on a lot of variables, including HTTP headers) for granular matching and external database lookups (either via plain text tables, DBM hash files or external processes) for advanced URL substitution.
It operates on the full URLs (including the PATH_INFO part) both in per-server context (httpd.conf) and per-dir context (.htaccess) and even can generate QUERY_STRING parts on result. The rewritten result can lead to internal sub-processing, external request redirection or to internal proxy throughput.
This module was originally written in April 1996 and gifted exclusively to the The Apache Group in July 1997 by
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
Directives
- RewriteEngine
- RewriteOptions
- RewriteLog
- RewriteLogLevel
- RewriteMap
- RewriteBase
- RewriteCond
- RewriteRule
Configuration Directives
RewriteEngine
Syntax:RewriteEngine {on,off}Default:
RewriteEngine offContext: server config, virtual host, per-directory config
The RewriteEngine directive enables or disables the
runtime rewriting engine. If it is set to off this module does
no runtime processing at all. It does not even update the SCRIPT_URx
environment variables.
Use this directive to disable the module instead of commenting out all RewriteRule directives!
RewriteOptions
Syntax: RewriteOptions Option ...
Default: -None-
Context: server config, virtual host, per-directory config
The RewriteOption directive sets some special options for the current per-server or per-directory configuration. The Option strings can be one of the following:
- '
inherit'
This forces the current configuration to inherit the configuration of the parent. In per-virtual-server context this means that the maps, conditions and rules of the main server gets inherited. In per-directory context this means that conditions and rules of the parent directory's .htaccess configuration gets inherited.
RewriteLog
Syntax: RewriteLog Filename
Default: -None-
Context: server config, virtual host
The RewriteLog directive sets the name of the file to which the server logs any rewriting actions it performs. If the name does not begin with a slash ('/') then it is assumed to be relative to the Server Root. The directive should occur only once per server config.
To disable the logging of rewriting actions it is not recommended
to set Filename
to /dev/null, because although the rewriting engine does
not create output to a logfile it still creates the logfile
output internally. This will slow down the server with no advantage to the
administrator!
To disable logging either remove or comment out the
RewriteLog directive or use RewriteLogLevel 0!
|
| SECURITY: See the Apache Security Tips document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server. |
Example:
RewriteLog "/usr/local/var/apache/logs/rewrite.log"
RewriteLogLevel
Syntax: RewriteLogLevel Level
Default: RewriteLogLevel 0
Context: server config, virtual host
The RewriteLogLevel directive set the verbosity level of the rewriting logfile. The default level 0 means no logging, while 9 or more means that practically all actions are logged.
To disable the logging of rewriting actions simply set Level to 0. This disables all rewrite action logs.
| Notice: Using a high value for Level will slow down your Apache server dramatically! Use the rewriting logfile only for debugging or at least at Level not greater than 2! |
Example:
RewriteLogLevel 3
RewriteMap
Syntax: RewriteMap Mapname {txt,dbm,prg}:Filename
Default: not used per default
Context: server config, virtual host
The RewriteMap directive defines an external Rewriting Map which can be used inside rule substitution strings by the mapping-functions to insert/substitute fields through a key lookup.
The Mapname is the name of the map and will be used to specify a mapping-function for the substitution strings of a rewriting rule via
When such a directive occurs the map Mapname is consulted and the key LookupKey is looked-up. If the key is found, the map-function directive is substituted by SubstValue. If the key is not found then it is substituted by DefaultValue.${Mapname:LookupKey|DefaultValue}
The Filename must be a valid Unix filepath, containing one of the following formats:
- Plain Text Format
This is a ASCII file which contains either blank lines, comment lines (starting with a '#' character) or
MatchingKey SubstValue
pairs - one per line. You can create such files either manually, using your favorite editor, or by using the programs mapcollect and mapmerge from the support directory of the mod_rewrite distribution.To declare such a map prefix, Filename with a
txt:string as in the following example:# # map.real-to-user -- maps realnames to usernames # Ralf.S.Engelschall rse # Bastard Operator From Hell Dr.Fred.Klabuster fred # Mr. DAU
RewriteMap real-to-host txt:/path/to/file/map.real-to-user
- DBM Hashfile Format
This is a binary NDBM format file containing the same contents as the Plain Text Format files. You can create such a file with any NDBM tool or with the dbmmanage program from the support directory of the Apache distribution.
To declare such a map prefix Filename with a
dbm:string. - Program Format
This is a Unix executable, not a lookup file. To create it you can use the language of your choice, but the result has to be a run-able Unix binary (i.e. either object-code or a script with the magic cookie trick '#!/path/to/interpreter' as the first line).
This program gets started once at startup of the Apache servers and then communicates with the rewriting engine over its stdin and stdout file-handles. For each map-function lookup it will receive the key to lookup as a newline-terminated string on stdin. It then has to give back the looked-up value as a newline-terminated string on stdout or the four-character string ``NULL'' if it fails (i.e. there is no corresponding value for the given key). A trivial program which will implement a 1:1 map (i.e. key == value) could be:
#!/usr/bin/perl $| = 1; while (<STDIN>) { # ...here any transformations # or lookups should occur... print $_; }But be very careful:
- ``Keep the program simple, stupid'' (KISS), because if this program hangs it will lead to a hang of the Apache server when the rule occurs.
- Avoid one common mistake: never do buffered I/O on stdout! This will cause a deadloop! Hence the ``$|=1'' in the above example...
To declare such a map prefix Filename with a
prg:string.
| For plain text and DBM format files the looked-up keys are cached in-core until the mtime of the mapfile changes or the server does a restart. This way you can have map-functions in rules which are used for every request. This is no problem, because the external lookup only happens once! |
RewriteBase
Syntax: RewriteBase BaseURL
Default: default is the physical directory path
Context: per-directory config
The RewriteBase directive explicitly sets the base URL for per-directory rewrites. As you will see below, RewriteRule can be used in per-directory config files (.htaccess). There it will act locally, i.e. the local directory prefix is stripped at this stage of processing and your rewriting rules act only on the remainder. At the end it is automatically added.
When a substitution occurs for a new URL, this module has to re-inject the URL into the server processing. To be able to do this it needs to know what the corresponding URL-prefix or URL-base is. By default this prefix is the corresponding filepath itself. But at most websites URLs are NOT directly related to physical filename paths, so this assumption will be usually be wrong! There you have to use the RewriteBase directive to specify the correct URL-prefix.
| So, if your webserver's URLs are not directly related to physical file paths, you have to use RewriteBase in every .htaccess files where you want to use RewriteRule directives. |
Example:
Assume the following per-directory config file:
In the above example, a request to /xyz/oldstuff.html gets correctly rewritten to the physical file /abc/def/newstuff.html.
For the Apache hackers:
The following list gives detailed information about the internal processing steps:
Request: /xyz/oldstuff.html Internal Processing: /xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server Alias) /abc/def/oldstuff.html -> /abc/def/newstuff.html (per-dir RewriteRule) /abc/def/newstuff.html -> /xyz/newstuff.html (per-dir RewriteBase) /xyz/newstuff.html -> /abc/def/newstuff.html (per-server Alias) Result: /abc/def/newstuff.htmlThis seems very complicated but is the correct Apache internal processing, because the per-directory rewriting comes too late in the process. So, when it occurs the (rewritten) request has to be re-injected into the Apache kernel! BUT: While this seems like a serious overhead, it really isn't, because this re-injection happens fully internal to the Apache server and the same procedure is used by many other operations inside Apache. So, you can be sure the design and implementation is correct.
RewriteCond
Syntax: RewriteCond TestString CondPattern
Default: -None-
Context: server config, virtual host, per-directory config
The RewriteCond directive defines a rule condition. Precede a RewriteRule directive with one or more RewriteCond directives. The following rewriting rule is only used if its pattern matches the current state of the URI AND if these additional conditions apply, too.
TestString is a string which contains server-variables of the form
%{ NAME_OF_VARIABLE }where NAME_OF_VARIABLE can be a string of the following list:
|
HTTP headers:
HTTP_USER_AGENT |
connection & request:
REMOTE_ADDR |
|
|
server internals:
DOCUMENT_ROOT |
system stuff:
TIME_YEAR |
specials:
API_VERSION |
| These variables all correspond to the similar named HTTP MIME-headers, C variables of the Apache server or struct tm fields of the Unix system. |
Special Notes:
- The variables SCRIPT_FILENAME and REQUEST_FILENAME contain the same
value, i.e. the value of the filename field of the internal
request_rec structure of the Apache server. The first name is just the
commonly known CGI variable name while the second is the consistent
counterpart to REQUEST_URI (which contains the value of the uri
field of request_rec).
- There is the special format: %{ENV:variable} where
variable can be any environment variable. This is looked-up via
internal Apache structures and (if not found there) via getenv() from
the Apache server process.
- There is the special format: %{HTTP:header} where
header can be any HTTP MIME-header name. This is looked-up
from the HTTP request. Example: %{HTTP:Proxy-Connection}
is the value of the HTTP header ``Proxy-Connection:''.
- There is the special format: %{LA-U:url}
for look-aheads like -U. This performs a internal sub-request to
look-ahead for the final value of url.
- There is the special format: %{LA-F:file} for look-aheads like -F. This performs a internal sub-request to look-ahead for the final value of file.
CondPattern is the condition pattern, i.e. a regular expression which gets applied to the current instance of the TestString, i.e. TestString gets evaluated and then matched against CondPattern.
Remember: CondPattern is a standard Extended Regular Expression with some additions:
- You can precede the pattern string with a '!' character
(exclamation mark) to specify a non-matching pattern.
-
There are some special variants of CondPatterns. Instead of real
regular expression strings you can also use one of the following:
- '<CondPattern' (is lexicographically lower)
Treats the CondPattern as a plain string and compares it lexicographically to TestString and results in a true expression if TestString is lexicographically lower then CondPattern. - '>CondPattern' (is lexicographically greater)
Treats the CondPattern as a plain string and compares it lexicographically to TestString and results in a true expression if TestString is lexicographically greater then CondPattern. - '=CondPattern' (is lexicographically equal)
Treats the CondPattern as a plain string and compares it lexicographically to TestString and results in a true expression if TestString is lexicographically equal to CondPattern, i.e the two strings are exactly equal (character by character). - '-d' (is directory)
Treats the TestString as a pathname and tests if it exists and is a directory. - '-f' (is regular file)
Treats the TestString as a pathname and tests if it exists and is a regular file. - '-s' (is regular file with size)
Treats the TestString as a pathname and tests if it exists and is a regular file with size greater then zero. - '-l' (is symbolic link)
Treats the TestString as a pathname and tests if it exists and is a symbolic link. - '-F' (is existing file via subrequest)
Checks if TestString is a valid file and accessible via all the server's currently-configured access controls for that path. This uses an internal subrequest to determine the check, so use it with care because it decreases your servers performance! - '-U' (is existing URL via subrequest)
Checks if TestString is a valid URL and accessible via all the server's currently-configured access controls for that path. This uses an internal subrequest to determine the check, so use it with care because it decreases your servers performance!
Notice: All of these tests can also be prefixed by a not ('!') character to negate their meaning.
- '<CondPattern' (is lexicographically lower)
Additionally you can set special flags for CondPattern by appending
as the third argument to the RewriteCond directive. Flags is a comma-separated list of the following flags:[flags]
- '
nocase|NC' (no case)
This makes the condition test case-insensitive, i.e. there is no difference between 'A-Z' and 'a-z' both in the expanded TestString and the CondPattern. - '
ornext|OR' (or next condition)
Use this to combine rule conditions with a local OR instead of the implicit AND. Typical example:
Without this flag you had to write down the cond/rule three times.RewriteCond %{REMOTE_HOST} ^host1.* [OR] RewriteCond %{REMOTE_HOST} ^host2.* [OR] RewriteCond %{REMOTE_HOST} ^host3.* RewriteRule ...some special stuff for any of these hosts...
Example:
To rewrite the Homepage of a site according to the ``User-Agent:'' header of the request, you can use the following:Interpretation: If you use Netscape Navigator as your browser (which identifies itself as 'Mozilla'), then you get the max homepage, which includes Frames, etc. If you use the Lynx browser (which is Terminal-based), then you get the min homepage, which contains no images, no tables, etc. If you use any other browser you get the standard homepage.RewriteCond %{HTTP_USER_AGENT} ^Mozilla.* RewriteRule ^/$ /homepage.max.html [L] RewriteCond %{HTTP_USER_AGENT} ^Lynx.* RewriteRule ^/$ /homepage.min.html [L] RewriteRule ^/$ /homepage.std.html [L]
RewriteRule
Syntax: RewriteRule Pattern Substitution
Default: -None-
Context: server config, virtual host, per-directory config
The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once. Each directive then defines one single rewriting rule. The definition order of these rules is important, because this order is used when applying the rules at run-time.
Pattern can be (for Apache 1.1.x a System V8 and for Apache 1.2.x a POSIX) regular expression which gets applied to the current URL. Here ``current'' means the value of the URL when this rule gets applied. This may not be the original requested URL, because there could be any number of rules before which already matched and made alterations to it.
Some hints about the syntax of regular expressions:
|
Additionally the NOT character ('!') is a possible pattern prefix. This gives you the ability to negate a pattern; to say, for instance: ``if the current URL does NOT match to this pattern''. This can be used for special cases where it is better to match the negative pattern or as a last default rule.
| Notice! When using the NOT character to negate a pattern you cannot have grouped wildcard parts in the pattern. This is impossible because when the pattern does NOT match, there are no contents for the groups. In consequence, if negated patterns are used, you cannot use $N in the substitution string! |
Substitution of a rewriting rule is the string which is substituted for (or replaces) the original URL for which Pattern matched. Beside plain text you can use
- pattern-group back-references (
$N) - server-variables as in rule condition test-strings (
%{VARNAME}) - mapping-function calls (
${mapname:key|default})
$N (N=1..9) identifiers which
will be replaced by the contents of the Nth group of the matched
Pattern. The server-variables are the same as for the
TestString of a RewriteCond directive. The
mapping-functions come from the RewriteMap directive and are
explained there. These three types of variables are expanded in the order of
the above list.
As already mentioned above, all the rewriting rules are applied to the
Substitution (in the order of definition in the config file). The
URL is completely replaced by the Substitution and the
rewriting process goes on until there are no more rules (unless explicitly
terminated by a L flag - see below).
There is a special substitution string named '-' which means: NO substitution! Sounds silly? No, it is useful to provide rewriting rules which only match some URLs but do no substitution, e.g. in conjunction with the C (chain) flag to be able to have more than one pattern to be applied before a substitution occurs.
One more note: You can even create URLs in the substitution string containing a query string part. Just use a question mark inside the substitution string to indicate that the following stuff should be re-injected into the QUERY_STRING. When you want to erase an existing query string, end the substitution string with just the question mark.
|
Notice: There is a special feature. When you prefix a substitution
field with http://thishost[:thisport] then
mod_rewrite automatically strips it out. This auto-reduction on
implicit external redirect URLs is a useful and important feature when
used in combination with a mapping-function which generates the hostname
part. Have a look at the first example in the example section below to
understand this.
Remember: An unconditional external redirect to your own server will not work with the prefix http://thishost because of this feature. To achieve such a self-redirect, you have to use the R-flag (see below). |
Additionally you can set special flags for Substitution by appending
as the third argument to the RewriteRule directive. Flags is a comma-separated list of the following flags:[flags]
- '
redirect|R[=code]' (force redirect)
Prefix Substitution withhttp://thishost[:thisport]/(which makes the new URL a URI) to force a external redirection. If no code is given a HTTP response of 302 (MOVED TEMPORARILY) is used. If you want to use other response codes in the range 300-400 just specify them as a number or use one of the following symbolic names: temp (default), permanent, seeother. Use it for rules which should canonicalize the URL and gives it back to the client, e.g. translate ``/~'' into ``/u/'' or always append a slash to/u/user, etc.
Notice: When you use this flag, make sure that the substitution field is a valid URL! If not, you are redirecting to an invalid location! And remember that this flag itself only prefixes the URL with
http://thishost[:thisport]/, but rewriting goes on. Usually you also want to stop and do the redirection immediately. To stop the rewriting you also have to provide the 'L' flag. - '
forbidden|F' (force URL to be forbidden)
This forces the current URL to be forbidden, i.e. it immediately sends back a HTTP response of 403 (FORBIDDEN). Use this flag in conjunction with appropriate RewriteConds to conditionally block some URLs. - '
gone|G' (force URL to be gone)
This forces the current URL to be gone, i.e. it immediately sends back a HTTP response of 410 (GONE). Use this flag to mark no longer existing pages as gone. - '
proxy|P' (force proxy)
This flag forces the substitution part to be internally forced as a proxy request and immediately (i.e. rewriting rule processing stops here) put through the proxy module. You have to make sure that the substitution string is a valid URI (e.g. typically http://) which can be handled by the Apache proxy module. If not you get an error from the proxy module. Use this flag to achieve a more powerful implementation of the mod_proxy directive ProxyPass, to map some remote stuff into the namespace of the local server.Notice: You really have to put ProxyRequests On into your server configuration to prevent proxy requests from leading to core-dumps inside the Apache kernel. If you have not compiled in the proxy module, then there is no core-dump problem, because mod_rewrite checks for existence of the proxy module and if lost forbids proxy URLs.
- '
last|L' (last rule)
Stop the rewriting process here and don't apply any more rewriting rules. This corresponds to the Perllastcommand or thebreakcommand from the C language. Use this flag to prevent the currently rewritten URL from being rewritten further by following rules which may be wrong. For example, use it to rewrite the root-path URL ('/') to a real one, e.g. '/e/www/'. - '
next|N' (next round)
Re-run the rewriting process (starting again with the first rewriting rule). Here the URL to match is again not the original URL but the URL from the last rewriting rule. This corresponds to the Perlnextcommand or thecontinuecommand from the C language. Use this flag to restart the rewriting process, i.e. to immediately go to the top of the loop.
But be careful not to create a deadloop! - '
chain|C' (chained with next rule)
This flag chains the current rule with the next rule (which itself can also be chained with its following rule, etc.). This has the following effect: if a rule matches, then processing continues as usual, i.e. the flag has no effect. If the rule does not match, then all following chained rules are skipped. For instance, use it to remove the ``.www'' part inside a per-directory rule set when you let an external redirect happen (where the ``.www'' part should not to occur!). - '
type|T=mime-type' (force MIME type)
Force the MIME-type of the target file to be mime-type. For instance, this can be used to simulate the old mod_alias directive ScriptAlias which internally forces all files inside the mapped directory to have a MIME type of ``application/x-httpd-cgi''. - '
nosubreq|NS' (used only if no internal sub-request)
This flag forces the rewriting engine to skip a rewriting rule if the current request is an internal sub-request. For instance, sub-requests occur internally in Apache when mod_include tries to find out information about possible directory default files (index.xxx). On sub-requests it is not always useful and even sometimes causes a failure to if the complete set of rules are applied. Use this flag to exclude some rules.
Use the following rule for your decision: whenever you prefix some URLs with CGI-scripts to force them to be processed by the CGI-script, the chance is high that you will run into problems (or even overhead) on sub-requests. In these cases, use this flag.
- '
qsappend|QSA' (query string append)
This flag forces the rewriting engine to append a query string part in the substitution string to the existing one instead of replacing it. Use this when you want to add more data to the query string via a rewrite rule. - '
passthrough|PT' (pass through to next handler)
This flag forces the rewriting engine to set theurifield of the internalrequest_recstructure to the value of thefilenamefield. This flag is just a hack to be able to post-process the output of RewriteRule directives by Alias, ScriptAlias, Redirect, etc. directives from other URI-to-filename translators. A trivial example to show the semantics: If you want to rewrite /abc to /def via the rewriting engine of mod_rewrite and then /def to /ghi with mod_alias:RewriteRule ^/abc(.*) /def$1 [PT] Alias /def /ghiIf you omit the PT flag then mod_rewrite will do its job fine, i.e. it rewrites uri=/abc/... to filename=/def/... as a full API-compliant URI-to-filename translator should do. Then mod_alias comes and tries to do a URI-to-filename transition which will not work.Notice: You have to use this flag if you want to intermix directives of different modules which contain URL-to-filename translators. The typical example is the use of mod_alias and mod_rewrite..
For the Apache hackers:
If the current Apache API had a filename-to-filename hook additionally to the URI-to-filename hook then we wouldn't need this flag! But without such a hook this flag is the only solution. The Apache Group has discussed this problem and will add such hooks into Apache version 2.0. - '
skip|S=num' (skip next rule(s))
This flag forces the rewriting engine to skip the next num rules in sequence when the current rule matches. Use this to make pseudo if-then-else constructs: The last rule of the then-clause becomes a skip=N where N is the number of rules in the else-clause. (This is not the same as the 'chain|C' flag!) - '
env|E=VAR:VAL' (set environment variable)
This forces an environment variable named VAR to be set to the value VAL, where VAL can contain regexp backreferences $N which will be expanded. You can use this flag more than once to set more than one variable. The variables can be later dereferenced at a lot of situations, but the usual location will be from within XSSI (via <!--#echo var="VAR"-->) or CGI (e.g. $ENV{'VAR'}). But additionally you can also dereference it in a following RewriteCond pattern via %{ENV:VAR}. Use this to strip but remember information from URLs.
|
Remember: Never forget that Pattern gets applied to a complete URL
in per-server configuration files. But in per-directory configuration
files, the per-directory prefix (which always is the same for a specific
directory!) gets automatically removed for the pattern matching and
automatically added after the substitution has been done. This feature is
essential for many sorts of rewriting, because without this prefix stripping
you have to match the parent directory which is not always possible.
There is one exception: If a substitution string starts with ``http://'' then the directory prefix will be not added and a external redirect or proxy throughput (if flag P is used!) is forced! |
| Notice! To enable the rewriting engine for per-directory configuration files you need to set ``RewriteEngine On'' in these files and ``Option FollowSymLinks'' enabled. If your administrator has disabled override of FollowSymLinks for a user's directory, then you cannot use the rewriting engine. This restriction is needed for security reasons. |
Here are all possible substitution combinations and their meanings:
Inside per-server configuration (httpd.conf)
for request ``GET /somepath/pathinfo'':
Given Rule Resulting Substitution
---------------------------------------------- ----------------------------------
^/somepath(.*) otherpath$1 not supported, because invalid!
^/somepath(.*) otherpath$1 [R] not supported, because invalid!
^/somepath(.*) otherpath$1 [P] not supported, because invalid!
---------------------------------------------- ----------------------------------
^/somepath(.*) /otherpath$1 /otherpath/pathinfo
^/somepath(.*) /otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^/somepath(.*) /otherpath$1 [P] not supported, because silly!
---------------------------------------------- ----------------------------------
^/somepath(.*) http://thishost/otherpath$1 /otherpath/pathinfo
^/somepath(.*) http://thishost/otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^/somepath(.*) http://thishost/otherpath$1 [P] not supported, because silly!
---------------------------------------------- ----------------------------------
^/somepath(.*) http://otherhost/otherpath$1 http://otherhost/otherpath/pathinfo
via external redirection
^/somepath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo
via external redirection
(the [R] flag is redundant)
^/somepath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
via internal proxy
|
Inside per-directory configuration for /somepath
(i.e. file .htaccess in dir /physical/path/to/somepath containing
RewriteBase /somepath)
for
request ``GET /somepath/localpath/pathinfo'':
Given Rule Resulting Substitution
---------------------------------------------- ----------------------------------
^localpath(.*) otherpath$1 /somepath/otherpath/pathinfo
^localpath(.*) otherpath$1 [R] http://thishost/somepath/otherpath/pathinfo
via external redirection
^localpath(.*) otherpath$1 [P] not supported, because silly!
---------------------------------------------- ----------------------------------
^localpath(.*) /otherpath$1 /otherpath/pathinfo
^localpath(.*) /otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^localpath(.*) /otherpath$1 [P] not supported, because silly!
---------------------------------------------- ----------------------------------
^localpath(.*) http://thishost/otherpath$1 /otherpath/pathinfo
^localpath(.*) http://thishost/otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^localpath(.*) http://thishost/otherpath$1 [P] not supported, because silly!
---------------------------------------------- ----------------------------------
^localpath(.*) http://otherhost/otherpath$1 http://otherhost/otherpath/pathinfo
via external redirection
^localpath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo
via external redirection
(the [R] flag is redundant)
^localpath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
via internal proxy
|
Example:
We want to rewrite URLs of the forminto/Language/~Realname/.../File/u/Username/.../File.LanguageWe take the rewrite mapfile from above and save it under
/anywhere/map.real-to-user. Then we only have to add the following lines to the Apache server configuration file:RewriteLog /anywhere/rewrite.log RewriteMap real-to-user txt:/anywhere/map.real-to-host RewriteRule ^/([^/]+)/~([^/]+)/(.*)$ /u/${real-to-user:$2|nobody}/$3.$1
Additional Features
Environment Variables
This module keeps track of two additional (non-standard) CGI/SSI environment variables named SCRIPT_URL and SCRIPT_URI. These contain the logical Web-view to the current resource, while the standard CGI/SSI variables SCRIPT_NAME and SCRIPT_FILENAME contain the physical System-view.Notice: These variables hold the URI/URL as they were initially requested, i.e. in a state before any rewriting. This is important because the rewriting process is primarily used to rewrite logical URLs to physical pathnames.
Example:
SCRIPT_NAME=/v/sw/free/lib/apache/global/u/rse/.www/index.html SCRIPT_FILENAME=/u/rse/.www/index.html SCRIPT_URL=/u/rse/ SCRIPT_URI=http://en2.en.sdm.de/u/rse/
Apache HTTP Server Version 1.2
07070100002cd5000081a400000064000000640000000134b16bd700000fcb000000200000001b00000000000000000000002800000004reloc/htdocs/manual/mod/mod_status.html
Apache HTTP Server Version 1.2
Module mod_status
The Status Module is only available in Apache 1.1 and later.
Function
The Status module allows a server administrator to find out how well their server is performing. A HTML page is presented that gives the current server statistics in an easily readable form. If required this page can be made to automatically refresh (given a compatible browser). Another page gives a simple machine-readable list of the current server state.The details given are:
- The number of children serving requests
- The number of idle children
- The status of each child, the number of requests that child has performed and the total number of bytes served by the child (*)
- A total number of accesses and byte count served (*)
- The time the server was started/restarted and the time it has been running for
- Averages giving the number of requests per second, the number of bytes served per second and the average number of bytes per request (*)
- The current percentage CPU used by each child and in total by Apache (*)
- The current hosts and requests being processed (*)
Enabling Status Support
To enable status reports only for browsers from the foo.com domain add this code to youraccess.conf configuration file
<Location /server-status>
SetHandler server-status
order deny,allow
deny from all
allow from .foo.com
</Location>
You can now access server statistics by using a Web browser to access the
page http://your.server.name/server-status
Note that mod_status will only work when you are running Apache in standalone mode and not inetd mode.
Automatic Updates
You can get the status page to update itself automatically if you have a browser that supports "refresh". Access the pagehttp://your.server.name/server-status?refresh=N to refresh the page
every N seconds.
Machine Readable Status File
A machine-readable version of the status file is available by accessing the pagehttp://your.server.name/server-status?auto. This is useful
when automatically run, see the Perl program in the /support
directory of Apache, log_server_status.
Full Instrumentation
To obtain full statistics you must compile Apache with a special directive. On some machines there may be a small performance loss if you do this. Try full statistics and see if you notice any difference. If you do please contact mark@ukweb.com and tell me your configuration.Do this by adding the following to the AUX_CFLAGS line in the "Configuration" file and then recompiling as usual.
AUX_CFLAGS= (something) -DSTATUS
It should be noted that if mod_status is compiled into the server, its handler capability is available in all configuration files, including per-directory files (e.g., .htaccess). This may have security-related ramifications for your site.
Apache HTTP Server Version 1.2
07070100002cd6000081a400000064000000640000000134b16bd700000a58000000200000001b00000000000000000000002900000004reloc/htdocs/manual/mod/mod_userdir.html
Apache HTTP Server Version 1.2
Module mod_userdir
This module is contained in themod_userdir.c file, and
is compiled in by default. It provides for user-specific directories.
UserDir
Syntax: UserDir directory/filenameDefault:
UserDir public_htmlContext: server config, virtual host
Status: Base
Module: mod_userdir
Compatibility: All forms except the
UserDir
public_html form are only available in Apache 1.1 or above.
The UserDir directive sets the real directory in a user's home directory
to use when a request for a document for a user is received.
Directory is either disabled, to disable this feature,
or the name of a directory, following one of the following
patterns. If not disabled, then a request for
http://www.foo.com/~bob/one/two.html will be translated to:
UserDir public_html -> ~bob/public_html/one/two.html UserDir /usr/web -> /usr/web/bob/one/two.html UserDir /home/*/www -> /home/bob/www/one/two.htmlThe following directives will send redirects to the client:
UserDir http://www.foo.com/users -> http//www.foo.com/users/bob/one/two.html UserDir http://www.foo.com/*/usr -> http://www.foo.com/bob/usr/one/two.html UserDir http://www.foo.com/~*/ -> http://www.foo.com/~bob/one/two.html
Be careful when using this directive; for instance, "UserDir ./" would map "/~root" to "/" - which is probably undesirable. See also the <Directory> directive and the Security Tips page for more information.
Apache HTTP Server Version 1.2
07070100002cd7000081a400000064000000640000000134b16bd700000c47000000200000001b00000000000000000000002b00000004reloc/htdocs/manual/mod/mod_usertrack.html
Apache HTTP Server Version 1.2
Module mod_usertrack
Previous releases of Apache have included a module which generates a 'clickstream' log of user activity on a site using cookies. This was called the "cookies" module, mod_cookies. In Apache 1.2 and later this module has been renamed the "user tracking" module, mod_usertrack. This module has been simplified and new directives added.Logging
Previously, the cookies module (now the user tracking module) did its own logging, using the CookieLog directive. In this release, this module does no logging at all. Instead, a configurable log format file should be used to log user click-streams. This is possible because the logging module now allows multiple log files. The cookie itself is logged by using the text %{cookie}n in the log file format. For example:
CustomLog logs/clickstream "%{cookie}n %r %t"
For backward compatibility the configurable log module implements the
old CookieLog directive, but this should be upgraded to the
above CustomLog directive.
Directives
CookieExpires
Syntax: CookieExpires expiry-periodContext: server config, virtual host
Status: optional
Module: mod_usertrack
When used, this directive sets an expiry time on the cookie generated by the usertrack module. The expiry-period can be given either as a number of seconds, or in the format such as "2 weeks 3 days 7 hours". Valid denominations are: years, months, weeks, hours, minutes and seconds.
If this directive is not used, cookies last only for the current browser session.
CookieTracking
Syntax: CookieTracking on | offContext: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: optional
Module: mod_usertrack
When the user track module is compiled in, and "CookieTracking on" is set, Apache will start sending a user-tracking cookie for all new requests. This directive can be used to turn this behavior on or off on a per-server or per-directory basis. By default, compiling mod_usertrack will not activate cookies.
Apache HTTP Server Version 1.2
0707010000fb31000081a400000064000000640000000134b16bd300001075000000200000001b00000000000000000000002300000004reloc/htdocs/manual/multilogs.html
Apache HTTP Server Version 1.2
Multiple Log Files
It is now possible to specify multiple log files, each with a fully customizable format. This is compatible with existing configurations. Multiple log files are implemented as part of the mod_log_config module which as of Apache 1.2 is the default log module.Using Multiple Log Files
Multiple log files be created with either theTransferLog
or CustomLog directive. These directives can be
repeated to create more than one log file (in previous releases,
only one logfile could be given per server configuration).
The TransferLog directive creates a log file
in the standard "common log format", although this can be customized
with LogFormat. The syntax of these two
directives is the same as for the config log module in previous
Apache releases.
The real power of multiple log files come from the ability to create log files in different formats. For example, as well as a CLF transfer log, the server could log the user agent of each client, or the referrer information, or any other aspect of the request, such as the language preferences of the user.
The new CustomLog directive takes both a filename to log
to, and a log file format.
Syntax: CustomLog filename "format"
Context: server config, virtual host
Status: base
Module: mod_log_config
The first argument is the filename to log to. This is used
exactly like the argument to TransferLog, that is,
it is either a file as a full path or relative to the current
server root, or |programname. Be aware that anyone who can write to
the directory where a log file is written can gain access to the uid
that starts the server. See the
security tips document for details.
The format argument specifies a format for each line of the log file.
The options available for the format are exactly the same as for
the argument of the LogFormat directive. If the format
includes any spaces (which it will do in almost all cases) it
should be enclosed in double quotes.
Use with Virtual Hosts
If a <VirtualHost> section does not contain anyTransferLog or CustomLog directives, the
logs defined for the main server will be used. If it does
contain one or more of these directives, requests serviced by
this virtual host will only be logged in the log files defined
within its definition, not in any of the main server's log files.
See the examples below.
Examples
To create a normal (CLF) format log file in logs/access_log, and a log of user agents:
TransferLog logs/access_log
CustomLog logs/agents "%{user-agent}i"
To define a CLF transfer log and a referrer log which log
all accesses to both the main server and a virtual host:
TransferLog logs/access_log
CustomLog logs/referer "%{referer}i"
<VirtualHost>
DocumentRoot /whatever
ServerName my.virtual.host
</VirtualHost>
Since no TransferLog or CustomLog directives appear inside the
<VirtualHost> section, any requests for this virtual host
will be logged in the main server's log files. If however the
directive
TransferLog logs/vhost_access_logwas added inside the virtual host definition, then accesses to this virtual host will be logged in vhost_access_log file (in common log format), and not in logs/access_log or logs/referer.
Apache HTTP Server Version 1.2
0707010000fb32000081a400000064000000640000000134b16bd3000014cd000000200000001b00000000000000000000002a00000004reloc/htdocs/manual/new_features_1_0.html
Apache HTTP Server Version 1.2
Overview of new features
New Features with Apache 1.0
New features with this release, as extensions of the Apache
functionality (see also more detailed CHANGES file) in
the source directory. Because the core code has changed so
significantly, there are certain liberties that earlier versions of
Apache (and the NCSA daemon) took that Apache 1.0 is pickier about -
please check the compatibility notes if you have any problems.
- API for server extensions --- see below for a brief sermon on
philosophy, or see src/API.html for an actual
overview. Most server functionality (including includes, CGI, and
most forms of access control) are actually implemented as
API-conformant modules; you can also do other neat stuff (we've
included a sample module, for instance, which one of us is using to
track click-trails using the Netscape
cookie mechanism, for visitors who come in through Netscape
clients). Modules can also be loaded dynamically using GNU DLD.
The API is not yet quite stable (see src/TODO for some possible changes), but anything done now will be easily adapted for future versions --- after all, we have more modules to adapt than you do.
- New Process Model - much less forking, no fixed number of children.
We found that many people were using values for "MaxServers" either
too high or too low, and were hanging themselves on it. The model we
adopted is still based on long-lived minimal-forking processes, but
instead of specifying one number of persistent processes, the
web-master specifies a maximum and minimum number of processes to be
"spare" - every couple of seconds the parent checks the actual number
of spare servers and adjusts accordingly. This should keep the number
of servers concurrently running relatively low while still ensuring
minimal forking.
- <VirtualHost> (the configuration directive for
multiple-homed servers) is more general now. Just about any srm.conf or
httpd.conf command can go in a <Virtualhost> section, with the
following specific exceptions: ServerType, UserId, GroupId,
StartServers, MaxRequestsPerChild, BindAddress, PidFile, TypesConfig,
ServerRoot.
- Support for content negotiation of languages through MultiViews
(*.fr, *.de, *.en suffixes), via the new AddLanguage and LanguagePriority
commands (code written by Florent Guillaume, guillaum@clipper.ens.fr).
- Significant internal cleanups and rearrangements. The two externally
visible consequences of this are that just about all of the unchecked
fixed limits are gone, and that the server is somewhat pickier about
config file syntax (noting and complaining about extraneous command
arguments or other stuff at the end of command lines).
- XBITHACK is a run-time option, and can be selectively enabled per
directory --- the -DXBITHACK compile-time option just changes the
default. The command which configures it is "XBitHack", which is
allowed everywhere "Options" is; this takes an argument ---
"XBitHack Off" turns it off; "XBitHack On" gets you the NCSA
-DXBITHACK behavior; and "XBitHack Full" gets you the Apache GXBIT
stuff on top of that. (-DXBITHACK makes "Full" the default;
otherwise, it defaults "Off").
- TransferLog can specify a program which gets the log entries piped to it,
a la 'TransferLog "| /var/www/my-perl-script -arg valu"' --- this should
give the same SIGTERM/pause/SIGKILL treatment to the logging process on
server restarts that a CGI script gets on an aborted request. NB the
server is counting on the logging process to work, and will probably hang
or worse if it dies.
- Configurable logging module --- this is a replacement for the standard plane-jane Common Log Format code, which supports a LogFormat directive which allows you to control the formatting of entries in the TransferLog, and add some new items if you like (in particular, Referer and User-Agent). EXPERIMENTAL.
Other features of Apache
- Dynamically loading modules using GNU DLD
- Imagemap Module
- Multiple DirectoryIndex filenames
- "Send as is" file types
- XBITHACK last modified
Apache HTTP Server Version 1.2
0707010000fb33000081a400000064000000640000000134b16bd300002383000000200000001b00000000000000000000002a00000004reloc/htdocs/manual/new_features_1_1.html
Apache HTTP Server Version 1.2
Overview of new features
API Changes
A few changes to the Apache API were made for 1.1. It is possible that some third-party modules will no longer work with 1.1, though we have made every effort to provide backwards-compatibility. If you encounter a module that does not work with 1.1, please let us know.New Features with Apache 1.1
New features with this release, as extensions of the Apache
functionality (see also more detailed CHANGES file in
the source directory.) Because the core code has changed so
significantly, there are certain liberties that earlier versions of
Apache (and the NCSA daemon) took that recent Apache versions are
pickier about - please check the compatibility notes if you have any
problems.
In addition to a number of bug fixes and internal performance enhancements, Apache 1.1 has the following specific new user features:
- Support for Keep-Alive Persistent
Connections
Apache now has (optional) support for persistent connections, as defined by the HTTP/1.1 draft. This protocol, supported by a number of current HTTP servers and browsers (including Netscape Navigator 2.0) has been shown to increase speed of document transfer by up to 50% in certain cases. - New non-IP Intensive VirtualHost
Support
Apache's support for virtual hosts has been enhanced to be able to use information sent by some new Web browsers to determine the server being accessed, without requiring an additional IP address for each host. - Listen to Multiple Addresses and
Ports
Using the newListendirective, Apache can listen to more than one port and IP address, using the same configuration set. - Status
Module
Apache now contains a module that gives the web-master accurate, up-to-date information about the server's status and its resource consumption. It also gives the current state of each server process including the current URL being processed. For an example, check out the status of the www.apache.org server. - Server Information Module This module gives a plethora of information about the other modules installed, their directives, and their configurations. It is extremely helpful in debugging configuration problems. For an example, check out information about the www.apache.org server.
- Experimental Caching Proxy Server
Apache can now act as an HTTP proxy server, allowing clients behind firewalls to use the server to access the outside world. In addition, it can cache documents it proxies, speeding up access to frequently requested documents. - URL-based Access Protection
In addition to access checking and authorization by filename (with<Directory>), the new<Location>directive allows protection by URL. - Filetype-based Script "Actions"
You can now run CGI scripts whenever a file of a certain type is requested. This makes it much easier to execute scripts that process files. In addition, you can use the new Script directive to enable scripts for files called with HTTP methods Apache does not natively support. - New "Handler" Directives
The newAddHandlerandSetHandlerdirective allows "handlers" to be defined for filename extensions or directories. These handlers, which can either be built into Apache or added with the Action directive, extend Apache's range of usability, and almost entirely remove the "magic" media types. - Customizable CGI Environment
Variables
NewPassEnvandSetEnvdirectives allow you to modify the environment variables passed to CGI scripts. - CERN Metafile Support
Now emulates the CERN httpd's support for metafiles containing additional HTTP headers to be supplied with a document. - Improved Imagemap Support
The internal imagemap handling code has been rewritten and reorganized, adding new handling of default, base and relative URLs, and support for creating non-graphical menus for use with clients that do not support imagemaps. - Improved UserDir Directive
Now supports the ability to point user's files (as specified by URLs beginning with the "~" character) at directories other than those specified by the Unix password file. - Minimal DNS Now Runtime Option
NewHostnameLookupsserver configuration directive can be used to turnOnorOffDNS lookups. This supersedes the -DMINIMAL_DNS compile-time configuration option. This option can be set per-directory. - IdentityCheck Now Per-Directory Option
TheIdentityCheckdirective, which controls the use of ident to check the remote user name, can now be set per directory. The ident support is also RFC 1413-compliant. - Redirect Now Usable in
.htaccessFiles
TheRedirectdirective can now be used in.htaccessfiles when theFileInfodirective has been set on. This allows users to redirect parts of their directories without requiring CGI scripts - ErrorDocument Now Usable in
.htaccessFiles
TheErrorDocumentdirective can now be used in.htaccessfiles when theFileInfodirective has been set on. This allows users to have different error messages for different sections of a site. ForceTypeDirective
This new directive, in<Directory>sections or .htaccess files, allows you to override the filename extensions and force a single content type. (e.g.ForceType application/octet-stream)- File Owner Available to Included CGI Scripts
Server-side includes that call CGI scripts will now set aUSER_NAMEenvironment variable that contains the owner of the file which included it. - Improved Icons
Thanks to Kevin Hughes, Apache's nifty color GIF icons for directory listings have been updated. In addition, the Powered by Apache (apache_pb.gif) logo has been included.
New Authentication Modules
Note: These modules are not
compiled into the server by default, as they require special support
on the host system. They must be enabled specifically in the
Configuration file.
- Anonymous HTTP Logins
New options allow you to allow, using Basic HTTP Authentication, anonymous logins, like those of FTP. This allows you to collect email addresses of people accessing your site. - Support for Digest
Authentication
Apache now supports digest authentication using RSA MD5 encryption. When used with a supporting web browser, this provides a more secure alternative to Basic authentication. - Support for Unix DB
Authentication -
mod_auth_db.c
In addition to DBM support, Apache now contains optional support for Berkeley DB databases. - mSQL Database
Authentication -
mod_auth_msql.html
Support for the use of mSQL databases for user authentication via HTTP is now supported.
OS/2 Support
Apache now includes support for OS/2, thanks to Softlink Services.
Apache HTTP Server Version 1.2
0707010000fb34000081a400000064000000640000000134b16bd300002529000000200000001b00000000000000000000002a00000004reloc/htdocs/manual/new_features_1_2.html
Apache HTTP Server Version 1.2
Overview of new features
API Changes
Some non-compatible changes were made to the Apache API in order to deal with HTTP/1.1 compatibility. It is possible that some modules will no longer work (specifically, those that process input using the POST or PUT methods). If you encounter a module that does not work, please contact the author. A programmer's note on the subject is available.
Additionally, some changes were made to the CGI environment that may cause some CGI scripts to work incorrectly. If you are experiencing trouble with a CGI that worked fine under Apache 1.1.1, please see our explanation of the changes.
New Features with Apache 1.2
New features with this release, as extensions of the Apache functionality. Because the core code has changed so significantly, there are certain liberties that earlier versions of Apache (and the NCSA daemon) took that recent Apache versions are pickier about - please check the compatibility notes if you have any problems.
In addition to a number of bug fixes and internal performance enhancements, Apache 1.2 has the following specific new user features:
HTTP/1.1 Compliance
Aside from the optional proxy module (which operates as HTTP/1.0), Apache is conditionally compliant with the HTTP/1.1 proposed standard, as approved by the IESG and the IETF HTTP working group. HTTP/1.1 provides a much-improved protocol, and should allow for greater performance and efficiency when transferring files. Apache does, however, still work great with HTTP/1.0 browsers. We are very close to being unconditionally compliant; if you note any deviance from the proposed standard, please report it as a bug.
A new set of server-side include directives allows the user to better create WWW pages. This includes number of powerful new features, such as the ability to set variables and use conditional HTML.
The new
<Files>
section allows directives to be enabled based on full filename, not just directory and URL. In
addition, <Files> sections can appear in
.htaccess files. <Files>, along with
<Directory>
and <Location>, can
also now be based on regular expressions, not just simple prefix
matching.
Environment variables can now be set based on the
User-Agent string of the browser. Combined with XSSI, this allows you to write browser-based
conditional HTML documents.
Apache now supports the execution of CGI scripts as users other than the server user. A number of security checks are built in to try and make this as safe as possible.
The optional
mod_rewrite module is now included. This
module can provide powerful URL mapping, using regular
expressions. There's nothing this module can't do!
The optional
mod_log_config included with earlier
versions of Apache is now standard, and has been enhanced to allow
logging of much more detail about the transaction, and can be used to
open more than one log file at once
(each of which can have a different log format). If you have Apache
write any logs to a directory which is writable by anyone other than
the user that starts the server, see the
security tips document to be sure you aren't putting the security
of your server at risk.
The
mod_cookies included with previous versions of Apache
has been renamed mod_usertrack, to more accurately
reflect its function (some people inadvertently thought it enabled
cookie support in Apache, which is not true - Apache supports the use
of cookies directly). It is also now possible to disable the
generation of cookies, even when
the cookie module is compiled in. Also, an expiry time can be set
on the cookies.
The <VirtualHost> directive can now take more than one IP address or hostname. This lets a single vhost handles requests for multiple IPs or hostnames. Also the special section <VirtualHost _default_> can be used to handle requests normally left for the main server configuration.
ScriptLog allows you to now set up a log that records
all input and output to failed CGI scripts. This includes environment
variables, input headers, POST data, output, and more. This makes CGI
scripts much easier to debug.
New directives allow the limiting of resources used by CGI scripts (e.g. max CPU time). This is helpful in preventing 'runaway' CGI processes.
The Redirect directive can return permanent or temporary redirects, "Gone" or "See Other" HTTP status. For NCSA-compatibility, RedirectTemp and RedirectPermanent are also implemented.
The process of configuring Apache for compilation has been simplified.
The
Options directive can now add or remove options from
those currently in force, rather than always replacing them.
The
-h command-line option now lists all the available
directives.
The optional
mod_headers module can be used to set custom
headers in the HTTP response. It can append to existing headers,
replace them, or remove headers from the response.
A new
<IfModule> section allows directives to be
enabled only if a given module is loaded into the server.
The AuthUserFile, AuthGroupFile and AuthDigestFile commands now have a syntax compatible with the NCSA server.
Satisfy allows for more flexible access control
configurations.
Apache directives are now more compatible with NCSA 1.5 to make moving between servers easier. In particular, Apache now implements the
Satisfy,
MaxKeepAliveRequests,
RedirectPermanent and
RedirectTemp,
directives, and the following directives are now syntax-compatible with
NCSA:
AuthUserFile,
AuthGroupFile,
AuthDigestFile,
KeepAlive and
KeepAliveTimeout.
An improved FTP, HTTP, and CONNECT mode SSL proxy is included with Apache 1.2. Some of the changes visible to users:
- - Improved FTP proxy supporting PASV mode
- - ProxyBlock directive for excluding sites to proxy
- - NoCache * directive for disabling proxy caching
- - Numerous bug fixes
- - ProxyBlock directive for excluding sites to proxy
Apache HTTP Server Version 1.2
0707010000fb35000081a400000064000000640000000134b16bd300000918000000200000001b00000000000000000000002700000004reloc/htdocs/manual/process-model.html
Apache HTTP Server Version 1.2
Server Pool Management
We found that many people were using values for "MaxServers" either too high or too low, and were hanging themselves on it. The model we adopted is still based on long-lived minimal-forking processes, but instead of specifying one number of persistent processes, the web-master specifies a maximum and minimum number of processes to be "spare" - every couple of seconds the parent checks the actual number of spare servers and adjusts accordingly. This should keep the number of servers concurrently running relatively low while still ensuring minimal forking.
We renamed the current StartServers to MinSpareServers, created separate StartServers parameter which means what it says, and renamed MaxServers to MaxSpareServers (though the old name still works, for NCSA 1.4 back-compatibility). The old names were generally regarded as too confusing.
The defaults for each variable are:
MinSpareServers 5 MaxSpareServers 10 StartServers 5There is an absolute maximum number of simultaneous children defined by a compile-time limit which defaults to 256 and a "MaxClients" directive which specifies the number of simultaneous children that will be allowed. MaxClients can be adjusted up to the compile-time limit (HARD_SERVER_LIMIT, defined in httpd.h). If you need more than 256 simultaneous children, you need to modify both HARD_SERVER_LIMIT and MaxClients.
In versions before 1.2, HARD_SERVER_LIMIT defaulted to 150.
We do not recommend changing either of these values unless:
- You know you have the server resources to handle more
- You use the machine for other purposes and must limit the amount of memory Apache uses
Apache HTTP Server Version 1.2
0707010000fb36000081a400000064000000640000000134b16bd300001e88000000200000001b00000000000000000000002200000004reloc/htdocs/manual/stopping.html
Apache HTTP Server Version 1.2
Stopping and Restarting Apache
You will notice many httpd executables running on your system,
but you should not send signals to any of them except the parent, whose
pid is in the PidFile. That is to
say you shouldn't ever need to send signals to any process except the
parent. There are three signals that you can send the parent:
TERM, HUP, and USR1, which will
be described in a moment.
To send a signal to the parent you should issue a command such as:
kill -TERM `cat /usr/local/etc/httpd/logs/httpd.pid`
tail -f /usr/local/etc/httpd/logs/error_log
TERM Signal: stop now
Sending the TERM signal to the parent causes it to
immediately attempt to kill off all of its children. It may take it
several seconds to complete killing off its children. Then the
parent itself exits. Any requests in progress are terminated, and no
further requests are served.
HUP Signal: restart now
Sending the HUP signal to the parent causes it to kill off
its children like in TERM but the parent doesn't exit. It
re-reads its configuration files, and re-opens any log files.
Then it spawns a new set of children and continues
serving hits.
Users of the
status module
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 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.
The USR1 signal causes the parent process to advise
the children to exit after their current request (or to exit immediately
if they're not serving anything). The parent re-reads its configuration
files and re-opens its log files. As each child dies off the parent
replaces it with a child from the new generation of the
configuration, which begins serving new requests immediately.
This code is designed to always respect the MaxClients, MinSpareServers, and MaxSpareServers settings. Furthermore, it respects StartServers in the following manner: if after one second at least StartServers new children have not been created, then create enough to pick up the slack. This is to say that the code tries to maintain both the number of children appropriate for the current load on the server, and respect your wishes 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
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
to do this it has to keep the scoreboard used to keep track
of all children across generations.
The status module will also use a G to indicate those
children which are still serving requests started before the graceful
restart was given.
At present there is no way for a log rotation script using
USR1 to know for certain that all children writing the
pre-restart log have finished. We suggest that you use a suitable delay
after sending the USR1 signal before you do anything with the
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 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 the children which are "gracefully exiting" by handling their last request.) This will cause problems if you attempt to restart the server -- it will not be able to bind to its listening ports. At present the only work around is to check the syntax of your files before doing a restart. The easiest way is to just run httpd as a non-root user. If there are no errors it will attempt to open its sockets and logs and fail because it's not root (or because the currently running httpd already has those ports bound). If it fails for any other reason then it's probably a config file error and the error should be fixed before issuing the graceful restart.
Appendix: signals and race conditions
Prior to Apache 1.2b9 there were several race conditions involving the restart and die signals (a simple description of race condition is: a time-sensitive problem, as in if something happens at just the wrong time it won't behave as expected). For those architectures that have the "right" feature set we have eliminated as many as we can. But it should be noted that there still do exist race conditions on certain architectures.
Architectures that use an on disk
ScoreBoardFile
have the potential to corrupt their scoreboards. This can result in
the "bind: Address already in use" (after HUP) or
"long lost child came home!" (after USR1). The former is
a fatal error, while the latter just causes the server to lose a scoreboard
slot. So it might be advisable to use graceful restarts, with
an occasional hard restart. These problems are very difficult to work
around, but fortunately most architectures do not require a scoreboard file.
See the ScoreBoardFile documentation for a method to determine if your
architecture uses it.
NEXT and MACHTEN (68k only) have small race
conditions
which can cause a restart/die signal to be lost, but should not cause the
server to do anything otherwise problematic.
All architectures have a small race condition in each child involving the second and subsequent requests on a persistent HTTP connection (KeepAlive). It may exit after reading the request line but before reading any of the request headers. There is a fix that was discovered too late to make 1.2. In theory this isn't an issue because the KeepAlive client has to expect these events because of network latencies and server timeouts. In practice it doesn't seem to affect anything either -- in a test case the server was restarted twenty times per second and clients successfully browsed the site without getting broken images or empty documents.
Apache HTTP Server Version 1.2
0707010000fb37000081a400000064000000640000000134b16bd40000511d000000200000001b00000000000000000000002000000004reloc/htdocs/manual/suexec.html
Apache HTTP Server Version 1.2
Apache suEXEC Support
- What is suEXEC?
- Before we begin.
- suEXEC Security Model.
- Configuring & Installing suEXEC
- Enabling & Disabling suEXEC
- Debugging suEXEC
- Beware the Jabberwock: Warnings & Examples
What is suEXEC?
The suEXEC feature -- introduced in Apache 1.2 -- provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.
Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.
Before we begin.
Before jumping head-first into this document, you should be aware of the assumptions made on the part of the Apache Group and this document.
First, it is assumed that you are using a UNIX derivate operating system that is capable of setuid and setgid operations. All command examples are given in this regard. Other platforms, if they are capable of supporting suEXEC, may differ in their configuration.
Second, it is assumed you are familiar with some basic concepts of your computer's security and its administration. This involves an understanding of setuid/setgid operations and the various effects they 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 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 share your work with the Apache Group for consideration.
Fourth, and last, it has been the decision of the Apache Group to NOT make suEXEC part of the default installation of Apache. To this end, suEXEC configuration is a manual process requiring of the administrator careful attention to details. It is through this process that the Apache Group hopes to limit suEXEC installation only to those who are determined to use it.
Still with us? Yes? Good. Let's move on!
suEXEC Security Model
Before we begin configuring and installing suEXEC, we will first discuss the security model you are about to implement. By doing so, you may better understand what exactly is going on inside suEXEC and what precautions are taken to ensure your system's security.
suEXEC is based on a setuid "wrapper" program that is called by the main Apache web server. This wrapper is called when an HTTP request is made for a CGI or SSI program that the administrator has designated to run as a userid other than that of the main server. When such a request is made, Apache provides the suEXEC wrapper with the program's name and the 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:
- 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.
- 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.
- 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.
- 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.
- Is the target user name valid?
Does the target user exist?
- Is the target group name valid?
Does the target group exist?
- Is the target user NOT superuser?
Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
- 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.
- Is the target group NOT the superuser group?
Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs.
- 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.
- 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.
- Does the directory in which the program resides exist?
If it doesn't exist, it can't very well contain files.
- 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?
- 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.
- Does the target program exist?
If it doesn't exists, it can't very well be executed.
- 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.
- Is the target program NOT setuid or setgid?
We do not want to execute programs that will then change our UID/GID again.
- Is the target user/group the same as the program's user/group?
Is the user the owner of the file?
- 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).
- Can we successfully become the target program and execute?
Here is where suEXEC ends and the target program begins.
This is the standard operation of the the suEXEC wrapper's security model. It is somewhat stringent and can impose new limitations and guidelines for CGI/SSI design, but it was developed carefully step-by-step with security 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" section of this document.
Configuring & Installing suEXEC
Here's where we begin the fun. The configuration and installation of suEXEC is a four step process: edit the suEXEC header file, compile suEXEC, place the suEXEC binary in its proper location, and configure Apache for use with suEXEC.
EDITING THE SUEXEC HEADER FILE
- From the top-level of the Apache source tree, type:
cd support [ENTER]
Edit the suexec.h file and change the following macros to
match your local Apache installation.
From support/suexec.h
/*
* HTTPD_USER -- Define as the username under which Apache normally
* runs. This is the only user allowed to execute
* this program.
*/
#define HTTPD_USER "www"
/*
* UID_MIN -- Define this as the lowest UID allowed to be a target user
* for suEXEC. For most systems, 500 or 100 is common.
*/
#define UID_MIN 100
/*
* GID_MIN -- Define this as the lowest GID allowed to be a target group
* for suEXEC. For most systems, 100 is common.
*/
#define GID_MIN 100
/*
* USERDIR_SUFFIX -- Define to be the subdirectory under users'
* home directories where suEXEC access should
* be allowed. All executables under this directory
* will be executable by suEXEC as the user so
* they should be "safe" programs. If you are
* using a "simple" UserDir directive (ie. one
* without a "*" in it) this should be set to
* the same value. suEXEC will not work properly
* in cases where the UserDir directive points to
* a location that is not the same as the user's
* home directory as referenced in the passwd file.
*
* If you have VirtualHosts with a different
* UserDir for each, you will need to define them to
* all reside in one parent directory; then name that
* parent directory here. IF THIS IS NOT DEFINED
* PROPERLY, ~USERDIR CGI REQUESTS WILL NOT WORK!
* See the suEXEC documentation for more detailed
* information.
*/
#define USERDIR_SUFFIX "public_html"
/*
* LOG_EXEC -- Define this as a filename if you want all suEXEC
* transactions and errors logged for auditing and
* debugging purposes.
*/
#define LOG_EXEC "/usr/local/etc/httpd/logs/cgi.log" /* Need me? */
/*
* DOC_ROOT -- Define as the DocumentRoot set for Apache. This
* will be the only hierarchy (aside from UserDirs)
* that can be used for suEXEC behavior.
*/
#define DOC_ROOT "/usr/local/etc/httpd/htdocs"
/*
* SAFE_PATH -- Define a safe PATH environment to pass to CGI executables.
*
*/
#define SAFE_PATH "/usr/local/bin:/usr/bin:/bin"
COMPILING THE SUEXEC WRAPPER
You now need to compile the suEXEC wrapper. At the shell command prompt,
type: cc suexec.c -o suexec [ENTER].
This should create the suexec wrapper executable.
COMPILING APACHE FOR USE WITH SUEXEC
By default, Apache is compiled to look for the suEXEC wrapper in the following
location.
From src/httpd.h
/* The path to the suEXEC wrapper */
#define SUEXEC_BIN "/usr/local/etc/httpd/sbin/suexec"
If your installation requires location of the wrapper program in a different directory, edit src/httpd.h and recompile your Apache server. See Compiling and Installing Apache for more info on this process.
COPYING THE SUEXEC BINARY TO ITS PROPER LOCATION
Copy the suexec executable created in the
exercise above to the defined location for SUEXEC_BIN.
cp suexec /usr/local/etc/httpd/sbin/suexec [ENTER]
In order for the wrapper to set the user ID, it must me installed as owner root and must have the setuserid execution bit set for file modes. If you are not running a root user shell, do so now and execute the following commands.
chown root /usr/local/etc/httpd/sbin/suexec [ENTER]
chmod 4711 /usr/local/etc/httpd/sbin/suexec [ENTER]
Enabling & Disabling suEXEC
After properly installing the suexec wrapper
executable, you must kill and restart the Apache server. A simple
kill -1 `cat httpd.pid` will not be enough.
Upon startup of the web-server, if Apache finds a properly configured
suexec wrapper, it will print the following message to
the console:
Configuring Apache for use with suexec wrapper.
If you don't see this message at server startup, the server is most likely not finding the wrapper program where it expects it, or the executable is not installed setuid root. Check your installation and try again.
One way to use suEXEC is through the User and Group directives in VirtualHost definitions. By setting these directives to values different from the main server user ID, all requests for CGI resources will be executed as the User and Group defined for that <VirtualHost>. If only one or neither of these directives are specified for a <VirtualHost> then the main server userid is assumed.
suEXEC can also be used to to execute CGI programs as the user to which the request is being directed. This is accomplished by using the ~ character prefixing the user ID for whom execution is desired. The only requirement needed for this feature to work is for CGI execution to be enabled for the user and that the script must meet the scrutiny of the security checks above.
Debugging suEXEC
The suEXEC wrapper will write log information to the location defined in
the suexec.h as indicated above. If you feel you have
configured and installed the wrapper properly, have a look at this log
and the error_log for the server to see where you may have gone astray.
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 Online Documentation version.
There are a few points of interest regarding the wrapper that can cause limitations on server setup. Please review these before submitting any "bugs" regarding suEXEC.
- Hierarchy limitations
For security and efficiency reasons, all suexec requests must remain within either a top-level document root for virtual host requests, or one top-level personal document root for userdir requests. For example, if you have four VirtualHosts configured, you would need to structure all of your VHosts' document roots off of one main Apache document hierarchy to take advantage of suEXEC for VirtualHosts. (Example forthcoming.)
- suEXEC's PATH environment variable
This can be a dangerous thing to change. Make certain every path you include in this define is a trusted directory. You don't want to open people up to having someone from across the world running a trojan horse on them.
- Altering the suEXEC code
Again, this can cause Big Trouble if you try this without knowing what you are doing. Stay away from it if at all possible.
Apache HTTP Server Version 1.2
0707010000fb5e000081a400000064000000640000000134b16bd4000008cf000000200000001b00000000000000000000002200000004reloc/htdocs/manual/unixware.html
Apache HTTP Server Version 1.2
Compiling Apache under UnixWare
To compile a working copy of Apache under UnixWare, there are several other steps you may need to take. These prevent such problems as zombie processes, bind errors, and accept errors, to name a few.UnixWare 1.x
Make sure that USE_FCNTL_SERIALIZE_ACCEPT is defined (if not defined by Apache autoconfiguration). If using the UnixWare cc compiler, and you still see accept() errors, don't use compiler optimization, or get gcc.UnixWare 2.0.x
SCO patch tf2163 is required in order for Apache to work correctly on UnixWare 2.0.x. See http://www.sco.com for UnixWare patch information.In addition, make sure that USE_FCNTL_SERIALIZE_ACCEPT is defined (if not defined by Apache autoconfiguration). To reduce instances of connections in FIN_WAIT_2 state, you may also want to define NO_LINGCLOSE (Apache 1.2 only).
UnixWare 2.1.x
SCO patch ptf3123 is required 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
In addition, make sure that USE_FCNTL_SERIALIZE_ACCEPT is defined (if not defined by Apache autoconfiguration). To reduce instances of connections in FIN_WAIT_2 state, you may also want to define NO_LINGCLOSE (Apache 1.2 only).
Thanks to Joe Doupnik <JRD@cc.usu.edu> and Rich Vaughn <rvaughn@aad.com> for additional info for UnixWare builds.
Apache HTTP Server Version 1.2
0707010000fb5f000081a400000064000000640000000134b16bd400003dd7000000200000001b00000000000000000000002900000004reloc/htdocs/manual/vhosts-in-depth.html
Apache HTTP Server Version 1.2
An In-Depth Discussion of VirtualHost Matching
This is a very rough document that was probably out of date the moment it was written. It attempts to explain exactly what the code does when deciding what virtual host to serve a hit from. It's provided on the assumption that something is better than nothing. The server version under discussion is Apache 1.2.
If you just want to "make it work" without understanding how, there's a What Works section at the bottom.
Config File Parsing
There is a main_server which consists of all the definitions appearing
outside of VirtualHost sections. There are virtual servers,
called vhosts, which are defined by
VirtualHost
sections.
The directives Port, ServerName, ServerPath, and ServerAlias can appear anywhere within the definition of a server. However, each appearance overrides the previous appearance (within that server).
The default value of the Port field for main_server
is 80. The main_server has no default ServerName,
ServerPath, or ServerAlias.
In the absence of any
Listen
directives, the (final if there
are multiple) Port directive in the main_server indicates
which port httpd will listen on.
The Port and ServerName directives for
any server main or virtual are used when generating URLs such as during
redirects.
Each address appearing in the VirtualHost directive
can have an optional port. If the port is unspecified it defaults to
the value of the main_server's most recent Port statement.
The special port * indicates a wildcard that matches any port.
Collectively the entire set of addresses (including multiple
A record
results from DNS lookups) are called the vhost's address set.
The magic _default_ address has significance during
the matching algorithm. It essentially matches any unspecified address.
After parsing the VirtualHost directive, the vhost server
is given a default Port equal to the port assigned to the
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). Note that subsequent Port
statements for this vhost will not affect the ports assigned in the
address set.
All vhosts are stored in a list which is in the reverse order that they appeared in the config file. For example, if the config file is:
<VirtualHost A>
...
</VirtualHost>
<VirtualHost B>
...
</VirtualHost>
<VirtualHost C>
...
</VirtualHost>
After parsing has completed, the list of servers is scanned, and various merges and default values are set. In particular:
- If a vhost has no
ServerAdmin,ResourceConfig,AccessConfig,Timeout,KeepAliveTimeout,KeepAlive,MaxKeepAliveRequests, orSendBufferSizedirective then the respective value is inherited from the main_server. (That is, inherited from whatever the final setting of that value is in the main_server.) - The "lookup defaults" that define the default directory permissions for a vhost are merged with those of the main server. This includes any per-directory configuration information for any module.
- The per-server configs for each module from the main_server are merged into the vhost server.
If the main_server has no ServerName at this point,
then the hostname of the machine that httpd is running on is used
instead. We will call the main_server address set those IP
addresses returned by a DNS lookup on the ServerName of
the main_server.
Now a pass is made through the vhosts to fill in any missing
ServerName fields and to classify the vhost as either
an IP-based vhost or a name-based vhost. A vhost is
considered a name-based vhost if any of its address set overlaps the
main_server (the port associated with each address must match the
main_server's Port). Otherwise it is considered an IP-based
vhost.
For any undefined ServerName fields, a name-based vhost
defaults to the address given first in the VirtualHost
statement defining the vhost. Any vhost that includes the magic
_default_ wildcard is given the same ServerName as
the main_server. Otherwise the vhost (which is necessarily an IP-based
vhost) is given a ServerName based on the result of a reverse
DNS lookup on the first address given in the VirtualHost
statement.
Vhost Matching
The server determines which vhost to use for a request as follows:
find_virtual_server: When the connection is first made
by the client, the local IP address (the IP address to which the client
connected) is looked up in the server list. A vhost is matched if it
is an IP-based vhost, the IP address matches and the port matches
(taking into account wildcards).
If no vhosts are matched then the last occurrence, if it appears, of a _default_ address (which if you recall the ordering of the server list mentioned above means that this would be the first occurrence of _default_ in the config file) is matched.
In any event, if nothing above has matched, then the main_server is matched.
The vhost resulting from the above search is stored with data about the connection. We'll call this the connection vhost. The connection vhost is constant over all requests in a particular TCP/IP session -- that is, over all requests in a KeepAlive/persistent session.
For each request made on the connection the following sequence of events further determines the actual vhost that will be used to serve the request.
check_fulluri: If the requestURI is an absoluteURI, that
is it includes http://hostname/, then an attempt is made to
determine if the hostname's address (and optional port) match that of
the connection vhost. If it does then the hostname portion of the URI
is saved as the request_hostname. If it does not match, then the
URI remains untouched. Note: to achieve this address
comparison,
the hostname supplied goes through a DNS lookup unless it matches the
ServerName or the local IP address of the client's socket.
parse_uri: If the URI begins with a protocol
(i.e., http:, ftp:) then the request is
considered a proxy request. Note that even though we may have stripped
an http://hostname/ in the previous step, this could still
be a proxy request.
read_request: If the request does not have a hostname
from the earlier step, then any Host: header sent by the
client is used as the request hostname.
check_hostalias: If the request now has a hostname,
then an attempt is made to match for this hostname. The first step
of this match is to compare any port, if one was given in the request,
against the Port field of the connection vhost. If there's
a mismatch then the vhost used for the request is the connection vhost.
(This is a bug, see observations.)
If the port matches, then httpd scans the list of vhosts starting with the next server after the connection vhost. This scan does not stop if there are any matches, it goes through all possible vhosts, and in the end uses the last match it found. The comparisons performed are as follows:
- Compare the request hostname:port with the vhost
ServerNameandPort. - Compare the request hostname against any and all addresses given in
the
VirtualHostdirective for this vhost. - Compare the request hostname against the
ServerAliasgiven for the vhost.
check_serverpath: If the request has no hostname
(back up a few paragraphs) then a scan similar to the one
in check_hostalias is performed to match any
ServerPath directives given in the vhosts. Note that the
last match is used regardless (again consider the ordering of
the virtual hosts).
Observations
- It is difficult to define an IP-based vhost for the machine's
"main IP address". You essentially have to create a bogus
ServerNamefor the main_server that does not match the machine's IPs. - During the scans in both
check_hostaliasandcheck_serverpathno check is made that the vhost being scanned is actually a name-based vhost. This means, for example, that it's possible to match an IP-based vhost through another address. But because the scan starts in the vhost list at the first vhost that matched the local IP address of the connection, not all IP-based vhosts can be matched.Consider the config file above with three vhosts A, B, C. Suppose that B is a named-based vhost, and A and C are IP-based vhosts. If a request comes in on B or C's address containing a header "Host: A" then it will be served from A's config. If a request comes in on A's address then it will always be served from A's config regardless of any Host: header.
- Unless you have a _default_ vhost,
it doesn't matter if you mix name-based vhosts in amongst IP-based
vhosts. During the
find_virtual_serverphase above no named-based vhost will be matched, so the main_server will remain the connection vhost. Then scans will cover all vhosts in the vhost list.If you do have a _default_ vhost, then you cannot place named-based vhosts after it in the config. This is because on any connection to the main server IPs the connection vhost will always be the _default_ vhost since none of the name-based are considered during
find_virtual_server. - You should never specify DNS names in
VirtualHostdirectives because it will force your server to rely on DNS to boot. Furthermore it poses a security threat if you do not control the DNS for all the domains listed. There's more information available on this and the next two topics. ServerNameshould always be set for each vhost. Otherwise A DNS lookup is required for each vhost.- A DNS lookup is always required for the main_server's
ServerName(or to generate that if it isn't specified in the config). - If a
ServerPathdirective exists which is a prefix of anotherServerPathdirective 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.) - If a vhost that would otherwise be a name-vhost includes a
Portstatement that doesn't match the main_serverPortthen it will be considered an IP-based vhost. Thenfind_virtual_serverwill match it (because the ports associated with each address in the address set default to the port of the main_server) as the connection vhost. Thencheck_hostaliaswill refuse to check any other name-based vhost because of the port mismatch. The result is that the vhost will steal all hits going to the main_server address. - If two IP-based vhosts have an address in common, the vhost appearing
later in the file is always matched. Such a thing might happen
inadvertently. If the config has name-based vhosts and for some reason
the main_server
ServerNameresolves to the wrong address then all the name-based vhosts will be parsed as ip-based vhosts. Then the last of them will steal all the hits. - The last name-based vhost in the config is always matched for any hit which doesn't match one of the other name-based vhosts.
What Works
In addition to the tips on the DNS Issues page, here are some further tips:
- Place all main_server definitions before any VirtualHost definitions.
(This is to aid the readability of the configuration -- the post-config
merging process makes it non-obvious that definitions mixed in around
virtualhosts might affect all virtualhosts.)
- Arrange your VirtualHosts such
that all name-based virtual hosts come first, followed by IP-based
virtual hosts, followed by any _default_ virtual host
- Avoid
ServerPathswhich are prefixes of otherServerPaths. If you cannot avoid this then you have to ensure that the longer (more specific) prefix vhost appears earlier in the configuration file than the shorter (less specific) prefix (i.e., "ServerPath /abc" should appear after "ServerPath /abcdef"). - Do not use port-based vhosts in the same server as
name-based vhosts. A loose definition for port-based is a vhost which
is determined by the port on the server (i.e. one server with
ports 8000, 8080, and 80 all of which have different configurations).
Apache HTTP Server Version 1.2
0707010000fb60000081a400000064000000640000000134b16bd400001faf000000200000001b00000000000000000000002600000004reloc/htdocs/manual/virtual-host.html
Apache HTTP Server Version 1.2
Virtual Host Support
See Also: Non-IP based virtual hostsWhat are virtual hosts?
This is the ability of a single machine to be a web server for multiple domains. For example, an Internet service provider might have a machine calledwww.serve.com which provides Web space for several
organizations including, say, smallco and baygroup.
Ordinarily, these groups would be given parts of the Web tree on www.serve.com.
So smallco's home page would have the URL
http://www.serve.com/smallco/and baygroup's home page would have the URL
http://www.serve.com/baygroup/
For esthetic reasons, however, both organizations would rather their home pages appeared under their own names rather than that of the service provider's; but they do not want to set up their own Internet links and servers.
Virtual hosts are the solution to this problem. smallco and baygroup would
have their own Internet name registrations, www.smallco.com and
www.baygroup.org respectively. These hostnames would both
correspond to the service provider's machine (www.serve.com). Thus
smallco's home page would now have the URL
http://www.smallco.com/and baygroup's home page would would have the URL
http://www.baygroup.org/
System requirements
Due to limitations in the HTTP/1.0 protocol, the web server must have a different IP address for each virtual host. This can be achieved by the machine having several physical network connections, or by use of a virtual interface on some operating systems.How to set up Apache
There are two ways of configuring apache to support multiple hosts. Either by running a separate httpd daemon for each hostname, or by running a single daemon which supports all the virtual hosts.Use multiple daemons when:
- The different virtual hosts need very different httpd configurations, such as different values for: ServerType, User, Group, TypesConfig or ServerRoot.
- The machine does not process a very high request rate.
- Sharing of the httpd configuration between virtual hosts is acceptable.
- The machine services a large number of requests, and so the performance loss in running separate daemons may be significant.
Setting up multiple daemons
Create a separate httpd installation for each virtual host. For each installation, use the BindAddress directive in the configuration file to select which IP address (or virtual host) that daemon services. e.g.BindAddress www.smallco.comSetting up a single daemon
For this case, a single httpd will service requests for all the virtual hosts. The VirtualHost directive in the configuration file is used to set the values of ServerAdmin, ServerName, DocumentRoot, ErrorLog and TransferLog configuration directives to different values for each virtual host. e.g.
<VirtualHost www.smallco.com>
ServerAdmin webmaster@mail.smallco.com
DocumentRoot /groups/smallco/www
ServerName www.smallco.com
ErrorLog /groups/smallco/logs/error_log
TransferLog /groups/smallco/logs/access_log
</VirtualHost>
<VirtualHost www.baygroup.org>
ServerAdmin webmaster@mail.baygroup.org
DocumentRoot /groups/baygroup/www
ServerName www.baygroup.org
ErrorLog /groups/baygroup/logs/error_log
TransferLog /groups/baygroup/logs/access_log
</VirtualHost>
Almost ANY configuration directive can be put in the VirtualHost directive, with the exception of ServerType, User, Group, StartServers, MaxSpareServers, MinSpareServers, MaxRequestsPerChild, BindAddress, PidFile, TypesConfig, and ServerRoot.
SECURITY: When specifying where to write log files, be aware of some security risks which are present if anyone other than the user that starts Apache has write access to the directory where they are written. See the security tips document for details.
File Handle/Resource Limits:
When using a large number of Virtual Hosts, Apache may run out of available file descriptors if each Virtual Host specifies different log files. The total number of file descriptors used by Apache is one for each distinct error log file, one for every other log file directive, plus 10-20 for internal use. Unix operating systems limit the number of file descriptors that may be used by a process; the limit is typically 64, and may usually be increased up to a large hard-limit.Although Apache attempts to increase the limit as required, this may not work if:
- Your system does not provide the setrlimit() system call.
- The setrlimit(RLIMIT_NOFILE) call does not function on your system (such as Solaris 2.3)
- The number of file descriptors required exceeds the hard limit.
- Your system imposes other limits on file descriptors, such as a limit on stdio streams only using file descriptors below 256. (Solaris 2)
- Reduce the number of log files; don't specify log files in the VirtualHost sections, but only log to the main log files.
- If you system falls into 1 or 2 (above), then increase the file descriptor
limit before starting Apache, using a script like
#!/bin/sh
ulimit -S -n 100
exec httpd
- Have a
cshscript wrapper around httpd which sets the "rlimit" to some large number, like 512. - Edit http_main.c to add calls to setrlimit() from main(), along the lines of
struct rlimit rlp; rlp.rlim_cur = rlp.rlim_max = 512; if (setrlimit(RLIMIT_NPROC, &rlp)) { fprintf(stderr, "setrlimit(RLIMIT_NPROC) failed.\n"); exit(1); }(thanks to "Aaron Gifford <agifford@InfoWest.COM>" for the patch)
Apache HTTP Server Version 1.2
07070100016251000041ed00000064000000640000000234e8a37000000000000000200000001b00000000000000000000000c00000004reloc/icons 07070100016252000081a4000000640000006400000001312c576f000012d0000000200000001b00000000000000000000001300000004reloc/icons/README Public Domain Icons
These icons were originally made for Mosaic for X and have been
included in the NCSA httpd and Apache server distributions in the
past. They are in the public domain and may be freely included in any
application. The originals were done by Kevin Hughes (kevinh@eit.com).
Many thanks to Andy Polyakov for tuning the icon colors and adding a
few new images. If you'd like to contribute additions or ideas to
this set, please let me know.
The distribution site for these icons is at:
http://www.eit.com/goodies/www.icons/
Kevin Hughes
September 11, 1995
Suggested Uses
The following are a few suggestions, to serve as a starting point for ideas.
Please feel free to tweak and rename the icons as you like.
a.gif
This might be used to represent PostScript or text layout
languages.
alert.black.gif, alert.red.gif
These can be used to highlight any important items, such as a
README file in a directory.
back.gif, forward.gif
These can be used as links to go to previous and next areas.
ball.gray.gif, ball.red.gif
These might be used as bullets.
binary.gif
This can be used to represent binary files.
binhex.gif
This can represent BinHex-encoded data.
blank.gif
This can be used as a placeholder or a spacing element.
bomb.gif
This can be used to repreesnt core files.
box1.gif, box2.gif
These icons can be used to represent generic 3D applications and
related files.
broken.gif
This can represent corrupted data.
burst.gif
This can call attention to new and important items.
c.gif
This might represent C source code.
comp.blue.gif, comp.red.gif
These little computer icons can stand for telnet or FTP
sessions.
compressed.gif
This may represent compressed data.
continued.gif
This can be a link to a continued listing of a directory.
down.gif, up.gif, left.gif, right.gif
These can be used to scroll up, down, left and right in a
listing or may be used to denote items in an outline.
dvi.gif
This can represent DVI files.
f.gif
This might represent FORTRAN or Forth source code.
folder.gif, folder.open.gif, folder.sec.gif
The folder can represent directories. There is also a version
that can represent secure directories or directories that cannot
be viewed.
generic.gif, generic.sec.gif, generic.red.gif
These can represent generic files, secure files, and important
files, respectively.
hand.right.gif, hand.up.gif
These can point out important items (pun intended).
image1.gif, image2.gif, image3.gif
These can represent image formats of various types.
index.gif
This might represent a WAIS index or search facility.
layout.gif
This might represent files and formats that contain graphics as
well as text layout, such as HTML and PDF files.
link.gif
This might represent files that are symbolic links.
movie.gif
This can represent various movie formats.
p.gif
This may stand for Perl or Python source code.
pie0.gif ... pie8.gif
These icons can be used in applications where a list of
documents is returned from a search. The little pie chart images
can denote how relevant the documents may be to your search
query.
patch.gif
This may stand for patches and diff files.
portal.gif
This might be a link to an online service or a 3D world.
ps.gif, quill.gif
These may represent PostScript files.
screw1.gif, screw2.gif
These may represent CAD or engineering data and formats.
script.gif
This can represent any of various interpreted languages, such as
Perl, python, TCL, and shell scripts, as well as server
configuration files.
sound1.gif, sound2.gif
These can represent sound files.
sphere1.gif, sphere2.gif
These can represent 3D worlds or rendering applications and
formats.
tex.gif
This can represent TeX files.
text.gif
This can represent generic (plain) text files.
transfer.gif
This can represent FTP transfers or uploads/downloads.
unknown.gif
This may represent a file of an unknown type.
uuencoded.gif
This can stand for uuencoded data.
world1.gif, world2.gif
These can represent 3D worlds or other 3D formats.
07070100016253000081a4000000640000006400000001312c576f000000f6000000200000001b00000000000000000000001200000004reloc/icons/a.gif GIF89a 333 !NThis art is in the public domain. Kevin Hughes, kevinh@eit.com, September 1995 ! , i80 @#i;U"(|<ڮ:W!UJ:<<>,;IkX݂
{ mhڭuO[?>28V ; 07070100016254000081a4000000640000006400000001312c5770000000f2000000200000001b00000000000000000000001c00000004reloc/icons/alert.black.gif GIF89a 333 !NThis art is in the public domain. Kevin Hughes, kevinh@eit.com, September 1995 ! , e80 @#i;W$֕xB.Qת5e>PHQfaQv5Aݒ\̴2`Iutz08<< ; 07070100016255000081a4000000640000006400000001312c5770000000f7000000200000001b00000000000000000000001a00000004reloc/icons/alert.red.gif GIF89a 33f 333 !NThis art is in the public domain. Kevin Hughes, kevinh@eit.com, September 1995 ! , jhp@&i;WdB{^HaظjpnHP*V MW':Z+nek]G%1h~gNmg)c
P7AK ; 07070100016256000081a4000000640000006400000001312c577000000916000000200000001b00000000000000000000001a00000004reloc/icons/apache_pb.gif GIF89a ΥssskkkZZZ!B1 RޭB ƽ1 c J{֥ J c焜Rc ! , G H*\ȰÇ#JHE 0l0!(Q&XA3_h; 2 3=e%03PpWLyׯ`|Iv
*P0a? J㾕@w۵2P0!IP;._]̸b#Dh0 A R
Nσf+d^fu' u'Hhۖݺ%\0xa/^μy
5{XA30d@{ o / ˟yo]!o߽L(PSQ ST $PŴ@L)SrUFʤ} 8_RgdrT`ZnY\p[5^ -PMAGBN"rYu Ia w_x"ihlA.9y(
PMXőQ `O/ SE S @ |E@@V2i geUP _*JRM nU)N EzIM=*SVi('̪O _8pM0a Ȓx!|[Q"Y՟l5c~ x6_&;
5 %B4pBj f x, <
̜qj5On;#P
k9 ENPENL
'ʑ&me|mXc"The document has moved here.
The answer to your request is located ^()[]{}$\
%u : http:// $-_.+!*'(),:@&=~ %%%02x $-_.+!*'(),:@&=/~ < > & httpd: bad user name %s
httpd: bad group name %s
* Cannot resolve host name %s --- exiting!
Host %s has multiple addresses ---
you must choose one explicitly for use as
a virtual host. Exiting!!!
Unable to gethostname httpd: cannot determine local host name.
Use ServerName to set it manually.
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ > @ @ @ ? 4 5 6 7 8 9 : ; < = @ @ @ @ @ @ @
@ @ @ @ @ @ ! " # $ % & ' ( ) * + , - . / 0 1 2 3 @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ HTTP_ TZ TZ= = Content-type CONTENT_TYPE Content-length CONTENT_LENGTH Authorization %u PATH /bin:/usr/bin:/usr/ucb:/usr/bsd:/usr/local/bin SERVER_SOFTWARE Apache/1.2.5 SERVER_NAME SERVER_PORT REMOTE_HOST REMOTE_ADDR DOCUMENT_ROOT SERVER_ADMIN SCRIPT_FILENAME %d REMOTE_PORT REMOTE_USER AUTH_TYPE REMOTE_IDENT REDIRECT_QUERY_STRING REDIRECT_URL GATEWAY_INTERFACE CGI/1.1 SERVER_PROTOCOL REQUEST_METHOD QUERY_STRING REQUEST_URI INCLUDED SCRIPT_NAME PATH_INFO PATH_TRANSLATED read script header Premature end of script headers malformed header from script. Bad header= Status Location Content-Length Transfer-Encoding Set-Cookie - 0k 1k %4dk %4.1fM %4dM A A0 setrlimit failed to set CPU usage limit failed to set memory usage limit /~ getpwnam invalid username ~ getpwuid invalid userid getgrgid invalid groupid /opt/AGapache/sbin/suexec /bin/sh -c %x
%x
%02x %s(%d): -0+ # 0123456789 %d .%d %s:%u: failed assertion `%s'
http_bprintf.c fmtBuffPtr - fmtBuff < FMT_BUFFLEN (null) buffCount < buffLen ## @$$ #### ##:##:## * ##-@$$-## ##:##:## * @$$ ~# ##:##:## ####* @$ ?Q ? (null) %p SetEnv takes one or two arguments. An environment variable name and an optional value to pass to CGI. a list of variables to remove from the CGI environment. UnsetEnv an environment variable name and a value to pass to CGI. SetEnv a list of environment variables to pass to CGI. PassEnv mod_env.c %d - "" %ld Content-type [%d/%b/%Y:%H:%M:%S %c%.2d%.2d] %u Unrecognized LogFormat directive % Ran off end of LogFormat parsing args to some directive
%{Cookie}n "%r" %t the filename of the cookie log CookieLog a log format string (see docs) LogFormat the filename of the access log TransferLog a file name and a custom log format string CustomLog /bin/sh -c exec Exec of shell for logging failed!!!
spawn_child Couldn't fork child for TransferLog process
open httpd: could not open transfer log file %s.
%h %l %u %t "%r" %>s %b mod_log_config.c the MIME types config file TypesConfig a handler name SetHandler a media type ForceType a handler name followed by one or more file extensions AddHandler a language (e.g., fr), followed by one or more file extensions AddLanguage an encoding (e.g., gzip), followed by one or more file extensions AddEncoding a mime type followed by one or more file extensions AddType etc/mime.types r fopen httpd: could not open mime types file %s
httpd/unix-directory , none mod_mime.c Cache LanguagePriority CacheNegotiatedDocs ? text/html text/x-server-parsed-html text/x-server-parsed-html3 evel charset ? @ @@ Accept Accept-encoding Accept-language Accept-charset ? application/x-httpd-cgi */* <`x ? Syntax error in type map --- no ':' Syntax error in type map --- no header body r cannot access type map file uri: content-type: content-length: content-language: content-encoding: description: proxy: cannot read directory for multi application/x-type-map type-map :o? * :o <#
<
iso-8859-1 ? 7bit 8bit binary ? %1.3f {" " {type } , {language {charset %ld {length Alternates Vary negotiate accept accept-language accept-charset accept-encoding Available variants:
variant-list Content-Location Variant-Vary no acceptable variant mod_negotiation.c DATE_LOCAL DATE_GMT LAST_MODIFIED DOCUMENT_URI DOCUMENT_PATH_INFO USER_NAME user#%lu DOCUMENT_NAME QUERY_STRING_UNESCAPED encountered error in GET_CHAR macro, mod_include.
Q Q QP P P AgraveAacuteAtildeCcedilEgraveEacuteIgraveIacuteNtildeOgraveOacuteOtildeOslashUgraveUacuteYacuteagraveaacuteatildeccedilegraveeacuteigraveiacutentildeograveoacuteotildeoslashugraveuacuteyacute AcircAringAEligEcircIcircOcircUcircTHORNszligacircaringaeligecircicircocircucircthorn quot"AumlEumlIumlOumlUumlaumleumliumloumluumlyuml ampÐeth lt
r < > &
Index of
index.html ? Location Directory index forbidden by rule httpd/unix-directory mod_dir.c alias-forced-type cgi-script the maximum size (in bytes) to record of a POST request ScriptLogBuffer the maximum length (in bytes) of the script debug log ScriptLogLength the name of a log for script debugging info ScriptLog a %%%% [%s] %s %s%s%s %s
? %%%% %d %s
%%error
%s
%request
%s: %s
%s
%response
%s
%stdout
%stderr
exec of %s failed, reason: %s (errno = %d)
INCLUDED nph- Options ExecCGI is off in this directory attempt to include NPH CGI script attempt to invoke directory as script script not found or unable to stat file permissions deny server execution couldn't spawn child process copy script args Location read from script GET Content-Length soaking script stderr application/x-httpd-cgi mod_cgi.c File does not exist r file permissions deny server access Location GET send-as-is httpd/send-as-is mod_asis.c the base for all URL's: map, referer, URL (or start of) ImapBase the action taken if no match: error, nocontent, referer, menu, URL ImapDefault the type of menu generated: none, formatted, semiformatted, unformatted ImapMenu map menu nocontent error referer Referer / ../ .. invalid base directive in map file: %s invalid directory name in map file: %s /../ /.. Location text/html send menu
Menu for
semiformatted
unformatted (Default)
r none base default %lf%*[, ]%lf poly circle rect point all map file lines require at least two fields
[an internal server error occured]
imap-file application/x-httpd-imap mod_imap.c GET POST PUT DELETE Unknown method type for Script a method followed by a script name Script a media type followed by a script name Action File does not exist ? */* mod_actions.c public_html the public subdirectory in users' home directories, or 'disabled' UserDir disabled Location / mod_userdir.c gone permanent temp seeother URL to redirect to is missing Redirect to non-URL Redirect URL not valid for this status RedirectPermanent a document to be redirected, then the destination URL RedirectTemp an optional status, then document to be redirected and destination URL Redirect cgi-script ScriptAlias a fakename and a realname Alias alias-forced-type ? Location mod_alias.c allow,deny deny,allow mutual-failure unknown order from allow and deny must be followed by 'from' deny 'from' followed by hostnames or IP-address wildcards allow 'allow,deny', 'deny,allow', or 'mutual-failure' order env= user-agents User-Agent all Client denied by server configuration mod_access.c standard Invalid auth file type: Set to 'no' to allow access control to be passed along to lower modules if the UserID is not known to this module AuthAuthoritative AuthGroupFile AuthUserFile r Could not open password file in user %s not found user %s: password mismatch valid-user user group mod_auth.c ! 1 Browser regex could not be compiled. a browser regex and a list of variables. BrowserMatchNoCase A browser regex and a list of variables. BrowserMatch User-Agent mod_browser.c 0123456789ABCDEFabcdef xdigit ABCDEFGHIJKLMNOPQRSTUVWXYZ upper
space !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ punct ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ print abcdefghijklmnopqrstuvwxyz lower ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ graph 0123456789 digit
cntrl blank ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz alpha ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 alnum DEL tilde right-curly-bracket right-brace vertical-line left-curly-bracket left-brace grave-accent low-line underscore circumflex-accent circumflex right-square-bracket reverse-solidus backslash left-square-bracket commercial-at question-mark greater-than-sign equals-sign less-than-sign semicolon colon nine eight seven six five four three two one zero solidus slash full-stop period hyphen-minus hyphen comma plus-sign asterisk right-parenthesis left-parenthesis apostrophe ampersand percent-sign dollar-sign number-sign quotation-mark exclamation-mark US IS1 RS IS2 GS IS3 FS IS4 ESC SUB EM CAN ETB SYN NAK DC4 DC3 DC2 DC1 DLE SI SO carriage-return CR form-feed FF vertical-tab VT newline LF tab HT backspace BS alert BEL ACK ENQ EOT ETX STX SOH NUL [:<:]] [:>:]] wT $ & &' &3
G
&= w nh n8 00 <0 H0 T0 `0 l0 x0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ,0 80 D0 P0 \0 h0 t0 0 0 0 0 0 0 0 0 0 0 0 0~ 0{ 0x (0u 40r @0o L0l X0i d0f p0c |0` 0] 0Z 0W 0T 0Q 0N 0K 0H 0E 0B 0? 0< 09 $06 003 <00 H0- T0* `0' l0$ x0! 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ,0 80 D0 P0 \0 h0 t0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (0 40 @0 L0 X0 d0 p0 |0 0 0 0 0 0 0 0 0 0 0 h @ H 8 @ ( H x < p X T p T @ 8 X H < @ H 8 T t p x p H @ ɐ X H ( $ D H 8 L x | H @ \ ( x x ʔ @ 0 d ˬ ˸ h X 8
8
T
h
X T
t 0 p Θ 4 8 ( P μ P @ Ȑ ǰ
0> ~ * ) ) ) ) ) ) ) )h )P )8 ) ) ( ( ( ( ( ( (x (` (H ( ( ' ' ' ' ' 'x 'X '8 ' ' & & & & & 8 @ L ` $ L l H 4 @ L ` $ L l H 4 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ 0123456789abcdef 0123456789ABCDEF E Ep Eh \ E( E D 0> E ż < L h l $ u 8 t ʼ T r x f ɀ U Ɉ s ɐ b ɨ i o $ n ʌ e ʤ v p 8 P p G` G0 G | G F F F Ԝ F 0> H@ t Ӱ Ҵ I , I I X I` IP I I ذ H H T H H T H Hx HX 0> Jp 0 ט ڨ J J L L 0> N ݐ Z ; Z Z` = Z@ = Z0 << Y > 0> Z ; D t ^` ? X ^0 ^ ? ] ] ? ހ ] ] ?, X ]X ]H ?, ] \ ?, ހ \ \ Ad \x \h @l \H \8 @H X \ [ @ [ [ @ [ [ AD [ T [ [ T a T 0> a8 B CP P b0 XD b a Xh a a X ap d ^ a` ^ 0> d W X( e0 e8 e e8 0> eH p f@ T e e T e e T eX i@ uL i0 uL 0> i` f f 4 j ~ i i ~4 i j0 ~ 0> j8 }X } j $ jX 0> j < \ lp lP l@ l0 lP l . k k . k kx - k 0> l | 4 m mx mp , t m8 m0 , m8 0> n , n n n t nH 0> o @ L ` p@ p o o 0> p` @ p r r r r rH r r@ r8 r r0 r r r q r q q r q q` r qX p r p p r p p r p p r p pp r r w0 w( w w w w w v v v v v v v
v
v v v v v
vp
vh v` vX vP vH v@ v8 v0 v( v v v v v u u u u u u u u p u! u" u# ux$ uh% uX& uH' u0( u) u* t+ t, t- t- t. t. t/ t/ t0 t1 t2 t3 t4 t5 tx6 tp7 th8 t`9 tX: tH; t8< t(= t> t ? s@ s[ s\ s\ s] s^ sx^ sh_ sX_ sH` s8{ s { s| s } r} r~ r G n8 nh t8
wH wT w
} $ 0 % 3 $ A t W t f } t u \ 4 X ( 4 u @ ! + 7 ~ D U L j $ t 0 ~ h $ \ $ ~ \ ( h 4 T
~ ( " 1 = I Y i m x | } $ X T t T
~ * P $ 7 L B Q .
_ p 0
m ~ | , 0 H d < " +h \ . ( L ? ), J H W
L f 14 u @ }
L G` E E ^ P h Z 4 ) H 8 80
@ J Up Y g l t p p } k k { } } { @ { X
X | - t H 4 @ < G V A _ i x < ( h
, ! P ( l p 0 l ` 8 @ H ( P ( X b ż q Ȝ 0 0 l $ 1 $ # 4 << E S ; n < x p 8 &
4 # 0 \ D 0
t 3 2 t ( . : p H O
S "x c 6 s
x = #\ l ! l 4` 7 $ d p ; | > L
>T
"
, X 8
< W
K Z
V
a e8
p
{ m
f $
uL
`
q
4
f
j
g \
t p | l k $ kP 0 u( $ < q< H f T _ f k h w s rP }X t @ , / = @ L Z d m 4 { \ X u
\ < < 8 4 X ( x D L
@ X
* @ D
4
; h
B p P
M T
U
^ < d
g
p
y H
d <
T P
T
,
H
D
l
(
<
D
t ) ߤ 2 ; E , T ^ i t ( y ( ` 8 X z @ ż @ AD $ { + u` H ; ` $ J | V e8 L c }0 m } @H $ 4 L D ֘ t8 t W wD yl H L y |0 % 5 ? { K p a & s T ~ 8 I { L l 0 p l * | @ p < " ٰ 3 }\ 8 l h F O z T $ e {d j v W 0 ( $ 0 Fl } d } z 8 u l ( | . } 5 X( F 8 0
S L [ , \ t H z, 0 h H E\ $ | h J % x , l U < H , S 4 y, 8 < H 0 E M e { n d } | T $
L } ` ?, ` XD $ ( 8 8 ' } 3 ` A y F y< M xt b iL k ʌ t @! y L @ ִ yd < } ~4 \\ I t $ D W < wH 0 x 7 8 8 G , T 4 8 a ( ` w < y0 x < u P L yx R( ˬ + 3 = @ 0 S H h [ 8 c ~ m @ { T y z\ P 0 z l d X O H {| < 0 y * z 2 T @ _ < N i x t z { cP D T x h ɐ x( d $x 0 L ʼ { " L * l 9 y ? K V e ` _ 0 w t < ڨ | @ L /$ p \ l , #
$ L < ( ͈ L 7 e< P < { D Θ $ R |T Z @ h ( l t x@ { _ |l , p | D ( }t 8 . v 0 B z G Ԝ $ V d j :`
~ ~ L \ p h } |( 8 P J D , ( w 2 $ E { K }D P p 4 e z p z , @ | x X $ l } , D ʔ T % p \ / p ? L P P ` L [ , c ݐ 0 y w` | ~ z y $ :
M z, X ̬ L 8 + ` 4 P d b { | }X @ \ T L P Ȝ 4 μ { % 0 : h C w P y [ @ ` e | 4 | l Ad < ` 4 P |H E@ ( \ X a x @ H S 5h | 0 % 6 4 ; X D A }h H } N ( ^ x |x ( t x ˸ d | \ ) 3 9 y > | F W T j ʤ v }8 | , $ < @ y X y < t x| zh L h ! d L ! ذ , !# !2 p t !P !f T !x 0 ! Ȑ D ! ! $ ! wT ! 8 ! } ! " | " t "" "(
"6 t "A :H "H p "U "i "x " ] < " \ " ' " " ( " | " ( " {( # 8 @ # < # y #$ D D #6 #E '| D #W P #f x #} L # p # < # D$ # { # @ # { # d # zD # # H $ # # ( $ f $" < ` $2 \ d $D $P 8 $V H P $_ T $j H $z x $ p 0 $ RH x $ p $ q $ H $ , $ ` $ ` $ P % ɀ % |$ %# L L %/ l , %C 1 %T x l %o $ ` % } % {L % % % z % p % { % | % A $ % c x % | % } & {4 & R < & L & D &/ R < &: 0 &G 0 &Y &g H &{ ` & & L & | & & _X X & $ ' P ' 8 ') '9 'F x 'M x4 'S 'd @ 'v , ` ' | ' ) ' ~ ' | ' < ' l ' 5 ' ' ` ' ט (
D ( (' ! (/ Eh (< + (M yH (T x (d l 8 (n T (t $ ( ( j 8 ( x ( | ( yT ( 0 (
\ ( T ( ? ( X ) | ) Q ) 4 8 )1 , l )C {p )J y )R h )a { )k X , )x { )~ zt ) e 8 ) < ( ) R ) ) ^ X ) \ ) ) ] ) z ) ` * y *
!P * d *' X l *: Ll *P z *\ P *f x *l \ *w L * * * 8 * * L * h * t | * P \ * 94 l * < L + ~0 + } + l +& +1 +J I +U x +Z +j p +q | < +y t + + 0 + 7 + {@ + H + | + {X + + + v x , S , Ӱ ( ,* ,4 B ,F v ,P ,\ ` ,m D ,x 8 T ,~ | , ٸ P , , l P , 0 , Xh 0 , , CP , - , - w
-! x -' x` -5 X 0 -J xX -Q z8 -\ -l K -} Qd \ - >T - @ ` - P - p < - < h - y - } - P - - L 8 . mX . y` . | ." |` $ .0 8 .A 8 .T .^ Ɉ .n xp .u . ` . 4 . . \ . D . D . . wG
.
. y$ . < / / p / /$ < /. { /5 | L /G v $ /Q /e s $ /| L L / z / 8 / / / \ D / / l L / | t / 4 0 ! 0
t 0 0( } 0/ h 0H % 0` }, 0h $ 8 0u d 0z ɐ | 0 d 0 , , 0 }P 0 l 0 Մ 0 0 0 H 0 \ 1 @ 1 t 1+ P 14 y 19 V 1F 0 T 1Y Y < 1c t 1t |` 1} x 1 1 xd 1 1 ǰ ( 1 ^h 1 | 1 z 1 { 1 |< 1 @l $ 2 Ҵ 2 p 2+ zP 20 x 23 F \ 2= 2N } 2g { L 2r 2| L 2 H 2 2 4 H 2 | 2 P 2 ` 2 2 T 2 3 $ H 3 | 3$ ' l 36 < 3D x x 3K p( 3Z L 3f ހ 3t t 3 $ 3 , 3 f$ ` 3 3 . 3 ބ L 3 @ H 3 z 3 d d 3 xL 4 , 4 H 4 | X 40 ɨ d 4? $ h 4N T 4] ] < 4i 4w P 4 ( 4 ~ 4 9 4 d 4 G| 4 | < 4 | 4 Ŕ ( httpd crti.s values-Xa.c crtstuff.c __CTOR_LIST__ __DTOR_LIST__ __do_global_dtors_aux gcc2_compiled. force_to_data fini_dummy alloc.c run_child_cleanups file_cleanup free_proc_chain regex_cleanup run_cleanups fd_cleanup gcc2_compiled. cleanup_pool_for_exec file_child_cleanup http_main.c make_sock is_graceful timeout_name setup_shared_mem deferred_die_handler child_num listenfds lingerout find_listener unlock_it current_conn generation alarm_pending old_listeners gcc2_compiled. restart linger_timeout wait_or_timeout alarms_blocked main_fds copy_listeners listenmaxfd timeout_req restart_pending set_group_privs srv dupped_csd csd lock_fd lock_it expand_lock_fname sock_disable_nagle lingering_close requests_this_child close_unused_listeners deferred_die find_virtual_server scoreboard_image http_core.c no_set_limit set_rlimit gcc2_compiled. end_url_magic end_dir_magic end_file_magic http_config.c num_modules get_addresses gcc2_compiled. total_modules http_request.c gcc2_compiled. decl_die check_safe_file http_log.c gcc2_compiled. http_protocol.c use_range_x terminate_header make_allow status_lines gcc2_compiled. get_chunk_size getline parse_byterange shortcut.52 internal_byterange check_hostalias rfc1413.c result.15 ident_timeout gcc2_compiled. get_rfc1413 sock.16 user.14 util.c x2c find_fqdn next_token gcc2_compiled. days.14 tspecials substring_conf util_script.c http2env original_uri gcc2_compiled. create_argv modules.c gcc2_compiled. buff.c start_chunk write_it_all end_chunk gcc2_compiled. bcwrite saferead doerror md5c.c MD5Transform Decode gcc2_compiled. Encode PADDING util_md5.c gcc2_compiled. basis_64 explain.c gcc2_compiled. http_bprintf.c gcc2_compiled. CopyAndAdvance util_date.c gcc2_compiled. util_snprintf.c upper_digits.24 strx_printv format_converter gcc2_compiled. low_digits.23 ap_cvt buf.10 conv_10 conv_p2 conv_fp ap_gcvt ap_fcvt ap_ecvt mod_env.c gcc2_compiled. mod_log_config.c xfer_mode xfer_flags gcc2_compiled. pfmt mod_mime.c gcc2_compiled. hash_buckets mod_negotiation.c read_type_map gcc2_compiled. mod_include.c handle_if safe_copy add_include_vars send_parsed_file handle_config create_includes_dir_config find_file get_directive parse_expr handle_set decodehtml get_ptoken handle_include gcc2_compiled. includes_cmds get_tag include_cmd_child handle_exec handle_else handle_elif includes_handlers handle_echo is_only_below entlist.16 handle_flastmod handle_printenv find_string send_shtml_file re_check handle_fsize handle_endif parse_string send_parsed_content include_cmd include_cgi set_xbithack xbithack_handler mod_dir.c gcc2_compiled. mod_cgi.c log_scripterror gcc2_compiled. log_script mod_asis.c gcc2_compiled. mod_imap.c imap_url create_imap_dir_config imap_handler imap_cmds menu_blank imap_handlers gcc2_compiled. is_closer pointincircle menu_directive imap_reply read_quoted get_y_coord get_x_coord menu_footer menu_header merge_imap_dir_configs pointinrect pointinpoly menu_default menu_comment mod_actions.c gcc2_compiled. mod_userdir.c gcc2_compiled. mod_alias.c gcc2_compiled. mod_access.c its_an_allow is_ip gcc2_compiled. mod_auth.c gcc2_compiled. mod_browser.c gcc2_compiled. browser_match regcomp.c allocset p_b_coll_elem doinsert dupl nuls ordinary isinsets mccase p_b_symbol p_b_eclass p_b_cclass dofwd seterr repeat categorize pluscount bothcases nch p_count gcc2_compiled. freezeset othercase stripsnug cnames doemit nonnewline firstch p_b_term samesets cclasses mcinvert enlarge p_bre p_ere p_str freeset findmust mcadd p_simp_re p_ere_exp p_bracket regexec.c lfast sfast lmatcher smatcher lstep sstep lslow sslow gcc2_compiled. lbackref sbackref ldissect sdissect regfree.c gcc2_compiled. libgcc2.c crtstuff.c __do_global_ctors_aux gcc2_compiled. force_to_data init_dummy __DTOR_END__ __CTOR_END__ crtn.s pcalloc get_entry rwrite group_id socket log_format create_env_server_config fancy_indexing getopt chk_on_blk_list os_escape_path clear_table asis_handler table_set destroy_sub_req add_desc browser_module log_request_duration header_parse merge_core_dir_configs set_charset_quality _start cfg_getline init_alloc sigemptyset alias_module read gmtime handle_map_file pid_fname getpeername create_request_config get_basic_auth_pw child_main set_max_free_servers find_title array_cat negotiation_module standalone_main soft_timeout satisfies checkmask send_http_options virtualhost_section bgetopt bfilbuf find_module_name atof clean_var_rec table_do atoi make_sub_request atol server_root create_cgi_config note_cleanups_for_file kill_timeout log_format_substring insert_readme find_allowdeny rewind is_url strtod setuid find_free_child_num free_blocks core_handlers fread strtol merge_cgi_config month_snames bskiplf create_access_dir_config action_cmds getpwuid create_mime_dir_config reclaim_child_processes client_to_stdout table_get strcmp_match set_user note_digest_auth_failure allow_cmd getword_conf_nc error_log_child getword pstrdup get_time user_id end_virtualhost_section vfprintf add_custom_log toupper _environ _end show_modules set_server_string_slot end_virthost_magic includes_module memmove log_printf add_alt set_scriptlog create_auth_dir_config die pregfree one_process check_fulluri fork getpid bytes_in_free_blocks uudecode log_note _iob is_matchexp check_user_id pstrndup readdir set_script create_core_server_config find_last_token gm_timestr_822 set_limit_cpu store_variant_list is_scriptaliased _GLOBAL_OFFSET_TABLE_ blookc log_server_port add_language hard_timeout parse_log_misc_string urlsection sleep daemons_to_start pipe set_last_modified malloc_block bind_address init_modules sigaction dsortf update_scoreboard_global merge_core_server_configs set_content_md5 __ctype parse_uri create_browser_config ht_time log_pid core_cmds alias_matches kill_cleanup abort gethostbyname bus_error in_domain should_client_block push_array strip_paren_comments accept_mutex_off getparents fseek set_listener userdir_cmds sigaddset geteuid getword_nulls construct_url add_env_module_vars_passed strcasecmp accept is_directory set_string_slot setup_choice_response atexit config_log_child log_status exit server_type finalize_sub_req_protocol auth_module log_request_time strerror timebuf handle_command alarm server_conf standalone uname2id setup_prelinked_modules make_config_log_state find_ct config_log_module setup_client_block escape_shell_cmd merge_server_configs exists_scoreboard_image set_sub_req_protocol cgi_module end_filesection parse_log_item rind bcreate set_limit_mem tolower reset_timeout read_config malloc show_overrides escape_path_segment bread sprintf md5 endlimit bonerror allow_options set_encoding_quality create_alias_config dirsection check_access opendir response_code_string bytes_in_block_list bind set_cookie_log find_content_length send_error_response open_error_log bsetflag _init is_variant_better_na add_env_module_vars_set in_ip init_server_config fwrite copy_array_hdr bflsbuf make_dir_entry pclosef get_child_status call_exec log_remote_logname fputc modf merge_browser_config setsockopt c_by_type init_mime set_language_priority find_child_by_pid bpushfd allow_overrides .umul set_auth_slot merge_string_array fputs check_auth best_match translate_name set_keep_alive md5digest find_lang_index fixup_env_module dir_module regfree create_neg_dir_config clear_pool add_action time .rem process_resource_config set_scoreboard overlay_tables pr2six do_languages_line output_directories make_array find_log_func just_die log_item_keys cgi_cmds maybe_add_default_encodings read_request_line default_server_hostnames reopen_scoreboard writev create_action_dir_config find_command_in_modules _Explain asis_module create_empty_config format_integer set_bind_address sscanf log_remote_host kill_cleanups_for_fd dir_cmds destroy_pool siglongjmp auth_cmds merge_alias_dir_config bvputs add_opts ap_snprintf tm2sec lock_fname run_sub_req strftime find_default_icon find_token escape_html add_header getword_white discard_request_body set_serverpath send_fd_length bwrite limit ungetc qsort init_config_log clear_module_list_command getpwnam each_byterange parse_accept_headers show_directives fclose set_daemons_to_start set_min_free_servers getenv parseHTTPdate MD5Update try_alias_list set_language_quality listeners pconf dup2 strncat log_virtual_host get_remote_logname log_env_var frexp document_root ap_signal select add_redirect waitpid groups_for_user set_flag_slot order strncpy is_variant_better gethostbyaddr config_log_transaction ind add_handler end_dirsection create_default_per_dir_config merge_per_dir_configs keepalive_timeout make_variant_list set_send_buffer_size negotiation_handlers sync_scoreboard_image _DYNAMIC server_root_relative block_freelist directory_walk make_table add_named_module usage set_byterange run_method rflush process_item sub_req_lookup_file invoke_handler add_module spacetoplus create_connection_config basic_http_header translate_alias_redir cache_negotiated_docs timeout open_config_log strncmp log_remote_user pfclose chdir preloaded_modules core_translate send_header_field new_connection set_keep_alive_timeout action_module asis_handlers regcomp find_item printf __iob execl fixup_redir setgid auth_type do_cache_negotiated_docs make_child add_per_dir_conf get_virthost_addr env_module_cmds translate_userdir start_ifmod bputs sig_term handle_dir server_confname fileno register_cleanup index_directory add_browser add_cgi_vars daemons_min_free bclose find_default_index count_busy_servers set_content_length log_request_file ctime mime_module get_scoreboard_info get_client_block internal_internal_redirect note_auth_failure crypt strncasecmp set_mime_fields detach setsid set_hostname_lookups inet_addr getgrnam add_opts_int make_full_path write realloc strrchr count_dirs ptrans prelinked_modules chdir_file handle_multi get_module_config log_header_in browser_module_cmds add_env_module_vars_unset lcase_header_name_return_body env_module set_transfer_log create_userdir_config construct_server set_options restart_time internal_redirect_handler get_remote_host block_alarms fdopen _exit set_max_requests set_module_config do_header_line log_transaction send_http_trace table_merge execle pfdopen create_environment send_fd set_pidfile access_cmds merge_mime_dir_configs set_lockfile action_handlers environ ignore_entry send_http_header perror config_log_cmds table_add errno set_access_name cleanup_scoreboard ap_slack log_request_line table_elts unlink create_alias_dir_config open_logs set_server_limit add_icon c_by_path getgrgid make_dirstr count_live_servers init_virtual_host strchr pstrcat get_local_host setrlimit add_encoding lstat inet_ntoa str_tolower add_per_url_conf getword_nc level_cmp cgi_handler max_requests_per_child constant_item cgi_child free user_name shutdown read_request server_argv0 some_auth_required terminate_description getsockname seg_fault close log_reason authenticate_basic_user sub_req_lookup_uri rfc1413_timeout add_alias log_unixerr access_module pgrp MD5Final popenf rprintf set_override table_unset closedir scoreboard_fname do_nothing merge_env_server_configs get_gmtoff open process_request optarg bsetopt accept_mutex_on init_config_globals error_log2stderr rputc strcmp pfopen fgets getrlimit internal_redirect open_multi_logs make_sub_pool getword_white_nc merge_config_log_state mime_cmds create_dir_config new_block set_signals srm_command_loop find_types rputs memchr find_linked_module check_dir_access pregcomp default_type set_scriptlog_length md5contextTo64 merge_dir_configs invoke_cmd _edata _PROCEDURE_LINKAGE_TABLE_ fopen bytes_in_pool set_scriptlog_buffer memset initgroups spawn_child_err strcasecmp_match no2slash push_item update_child_status reinit_scoreboard log_child_pid file_walk mmap suexec_enabled require set_error_document pregsub add_common_vars fcntl execve append_arrays set_types_config count_idle_servers end_ifmod log_request_uri strcpy end_urlsection run_fixups run_cleanup mime_match satisfy unblock_alarms find_command cgi_handlers _etext _lib_version kill default_handler top_module get_mime_headers regexec __eprintf fflush clear_module_list send_size fixup_virtual_hosts scan_script_header_err imap_module memcmp log_error get_path_info location_walk vbprintf alias_cmds userdir_module create_server_config merge_neg_dir_configs _ctype server_port is_virtual_server strspn set_default_lang_quality note_basic_auth_failure _Q_qtod set_user_dir main set_group add_file_conf add_type .udiv init_suexec create_per_dir_config set_keep_alive_max rename_original_env negotiation_cmds set_timeout accept_mutex_init set_document_root requires .div getword_conf set_accept_quality get_token daemons_max_free __filbuf memcpy check_serverpath strlen create_core_dir_config add_module_command unescape_url gethostname sigsetjmp strstr localtime add_ignore multi_log_transaction set_neg_headers stat sd find_opts parse_log_string merge_action_dir_configs copy_array auth_name bflush check_symlinks process_request_internal merge_alias_config copy_table dir_handlers check_user_access _fini getword_nulls_nc bgets get_header_line permanent_pool index_of_response set_keepalive palloc find_path_info core_module c_by_encoding is_identity_encoding note_cleanups_for_fd note_subprocess gname2id get_pw finalize_request_protocol jmpbuffer add_readme listen can_exec fprintf default_parms filesection read_types_multi log_bytes_sent log_header_out parse_htaccess plustospace daemons_limit set_server_root cleanup_for_exec action_handler rvputs set_idcheck rfc1413 MD5Init connect ap_vsnprintf
< @(#)SunOS 5.5.1 Generic May 1996 as: SC4.0 dev 15 Feb 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.0 dev 15 Feb 1995
GCC: (GNU) 2.7.2 as: SC4.0 dev 15 Feb 1995
GCC: (GNU) 2.7.2 ld: (SGU) SunOS/ELF (LK-2.0 (S/I) - versioning) 0 < d @d L n ހ " f À ߀ J e ڀ + > t K U ` B l C v D E F H I O R Ā u s$ @ @ @ @ d .interp .hash .dynsym .dynstr .rela.bss .rela.plt .text .init .fini .rodata .got .dynamic .plt .data .ctors .dtors .bss .symtab .strtab .stab.index .comment .stab .shstrtab .stab.indexstr .stabstr values-Xa.c Xt ; V=2.0 libgcc2.c gcc2_compiled. /home/parzival/mshort/todo/gcc-2.7.2/ ./libgcc2.c int:t1=r1;-2147483648;2147483647; char:t2=r2;0;127; long int:t3=r1;-2147483648;2147483647; unsigned int:t4=r1;0;-1; long unsigned int:t5=r1;0;-1; long long int:t6=r1;01000000000000000000000;0777777777777777777777; long long unsigned int:t7=r1;0000000000000;01777777777777777777777; short int:t8=r1;-32768;32767; short unsigned int:t9=r1;0;65535; signed char:t10=r1;-128;127; unsigned char:t11=r1;0;255; float:t12=r1;4;0; double:t13=r1;8;0; long double:t14=r1;16;0; complex int:t15=s8real:1,0,32;imag:1,32,32;; complex float:t16=r16;4;0; complex double:t17=r17;8;0; complex long double:t18=r18;16;0; void:t19=19 arch_type:T20=eARCH_32BIT:0,ARCH_64BIT:1,; reg_class:T21=eNO_REGS:0,GENERAL_REGS:1,FP_REGS:2,ALL_REGS:3,LIM_REG_CLASSES:4,; machine_mode:T22=eVOIDmode:0,QImode:1,HImode:2,PSImode:3,SImode:4,PDImode:5,DImode:6,TImode:7,OImode:8,QFmode:9,HFmode:10,TQFmode:11,SFmode:12,DFmode:13,XFmode:14,TFmode:15,SCmode:16,DCmode:17,XCmode:18,TCmode:19,CQImode:20,CHImode:21,CSImode:22,CDImode:23,CTImode:24,COImode:25,BLKmode:26,CCmode:27,CCXmode:28,CC_NOOVmode:29,CCX_NOOVmode:30,CCFPmode:31,CCFPEmode:32,MAX_MACHINE_MODE:33,; mode_class:T23=eMODE_RANDOM:0,MODE_INT:1,MODE_FLOAT:2,MODE_PARTIAL_INT:3,MODE_CC:4,MODE_COMPLEX_INT:5,MODE_COMPLEX_FLOAT:6,MAX_MODE_CLASS:7,; ptrdiff_t:t1 size_t:t4 wchar_t:t3 UQItype:t11 SItype:t1 USItype:t4 DItype:t6 UDItype:t7 SFtype:t12 DFtype:t13 TFtype:t14 word_type:t1 DIstruct:T24=s8high:1,0,32;low:1,32,32;; DIunion:t25=u8s:24,0,64;ll:6,0,64;; fpos_t:t3 FILE:t26=s16_cnt:1,0,32;_ptr:27=*11,32,32;_base:27,64,32;_flag:11,96,8;_file:11,104,8;; __eprintf:F19 string:P28=*2 expression:P28 line:P1 filename:P28 /p G G &= n8 n8 0 ) nh nh
3 t8 t8 H 9 ? E M wH wH R wT wT [ w w ` } } , f m $ $ t 0 0 H y , B R 4
- D L V n 0707010000cee1000081a400000064000000640000000134e8a331000023fc000000200000001b00000000000000000000001900000004reloc/sbin/httpd_monitor ELF 4 < 4 ( 4 4 X /usr/lib/ld.so.1 5 C B 7 6 $ & > / < @ ) A = ; ' % - + 2 8 0 ! " 5 ? * : , 3 . 1 ( # 4 9 T x l
t t " ' / @! 4 = S L Y P ` \ e m l s d z 4 P 4 @ h ! p X
! @ (
| - ( 4 9 ? getopt _start read atoi _environ _end lookfor _iob __flsbuf _GLOBAL_OFFSET_TABLE_ sleep atexit exit sprintf _init sscanf fclose _DYNAMIC usage fscanf printf __iob strcat _exit environ perror close open optarg strcmp fgets _edata _PROCEDURE_LINKAGE_TABLE_ fopen strcpy _etext _lib_version fflush main strlen stat _fini fprintf libc.so.1 4 - P # \ $ h / t : . 9 1 B ( + @ 3 2 % ( ? 4 , @ = L " X 6 d ' p 5 @D# @ B D"@ B @ % , @
" @ @ B @ B 㿐@ / B/ Bp ` 㿐 % D D"# " ? '7 @ B !f" s? d c 0@ B c@ B @ Bcߺ @ @ ܐ D@ Bb D@ Bb Db@ B 2
D@ B" " Db@ B~ @ Bd @ @ Bx @ Bl 2
D@ Bi" " Dc@ Bf @ BL Dc ?l@ Bc
@ B^ + ?# ?#p@ BY "
? D@ BG" " Dc(@ BD @ B* # @ BE
D@ B/" " DcH@ B, @ B - ?#l @ B/ "O쀢 J
"
`` ` . . `` @ B Dch @ B " b? %b @ B ``&`*@ b@ B ( 4 D " b? %b @ A ``&`*@ b D " b? %b @ AՒ ``&`*@ b D#x@ A͒ @ Aΐb@ AƐ @ A̐ T 㿐 D@ A# D@ A# D# D@ Ab D#@ A @ Az ?*@ ?*@
?#/ A?
#@ A / E` @ A E@ A` O @ AT E@ A`( O @ AG E@ A`8 2
O " @ A9 ̐ ?#O !? " E@ A9`H@ A N
? E`>`"` 2`
*`N 2 N Ep> p ::2
*N / @ A 5?@ @ D@ @b @ @5?N / @ @ 0 ?c@ @ D@ @b @ @ 㿐@ / @/ @ ? ? ? ? 㿐 㿠 㿠 /opt/AGapache s:d:f: / etc/httpd.conf r httpd_monitor Can't open config file: %s
Can't open PIDfile: %s
%ld Can't stat scoreboard file: %s
Can't open scoreboard file: %s
(%d/%d) %s httpd_monitor: Usage
httpd_monitor [ -d config-dir] [ -s sleep-time ]
Defaults: config-dir = %s
sleep-time = %d seconds
%s %s PidFile ScoreBoardFile ServerRoot Can't find ServerRoot!
logs/httpd.pid logs/apache_runtime_status G l
Q , x T P 00 <0 H0 T0 `0 l0 x0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ,0 80 D0 P0 _sRtWKLD T x l
" - ; I
_
n |
p
| ` t # t * / 4 = B J @! O X n L t P { \ l d 4 P 4 @ h ! p X
! (
/
< @ C
| H ( O T Z httpd_monitor crti.s values-Xa.c crtstuff.c __CTOR_LIST__ __DTOR_LIST__ __do_global_dtors_aux gcc2_compiled. force_to_data fini_dummy httpd_monitor.c gcc2_compiled. kid_stat.10 crtstuff.c __do_global_ctors_aux gcc2_compiled. force_to_data init_dummy __DTOR_END__ __CTOR_END__ crtn.s getopt _start read atoi _environ _end lookfor _iob __flsbuf _GLOBAL_OFFSET_TABLE_ sleep atexit exit sprintf _init sscanf fclose _DYNAMIC usage fscanf printf __iob strcat _exit environ perror close open optarg strcmp fgets _edata _PROCEDURE_LINKAGE_TABLE_ fopen strcpy _etext _lib_version fflush main strlen stat _fini fprintf
< @(#)SunOS 5.5.1 Generic May 1996 as: SC4.0 dev 15 Feb 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.0 dev 15 Feb 1995
GCC: (GNU) 2.7.2 ld: (SGU) SunOS/ELF (LK-2.0 (S/I) - versioning) .interp .hash .dynsym .dynstr .rela.bss .rela.plt .text .init .fini .rodata .got .dynamic .plt .data .ctors .dtors .bss .symtab .strtab .stab.index .comment .shstrtab .stab.indexstr values-Xa.c Xt ; V=2.0 0 Q T T $ ) x x ,
3 9 l l ? E M R [ ` ` f m t L y - b | m $ 0707010000cee2000081a400000064000000640000000134e8a331000010b2000000200000001b00000000000000000000001d00000004reloc/sbin/log_server_status #!/usr/local/bin/perl
# ====================================================================
# Copyright (c) 1995-1997 The Apache Group. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# 1. Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in
# the documentation and/or other materials provided with the
# distribution.
#
# 3. All advertising materials mentioning features or use of this
# software must display the following acknowledgment:
# "This product includes software developed by the Apache Group
# for use in the Apache HTTP server project (http://www.apache.org/)."
#
# 4. The names "Apache Server" and "Apache Group" must not be used to
# endorse or promote products derived from this software without
# prior written permission.
#
# 5. Redistributions of any form whatsoever must retain the following
# acknowledgment:
# "This product includes software developed by the Apache Group
# for use in the Apache HTTP server project (http://www.apache.org/)."
#
# THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY
# EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE GROUP OR
# ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
# NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
# STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
# OF THE POSSIBILITY OF SUCH DAMAGE.
# ====================================================================
#
# This software consists of voluntary contributions made by many
# individuals on behalf of the Apache Group and was originally based
# on public domain software written at the National Center for
# Supercomputing Applications, University of Illinois, Urbana-Champaign.
# For more information on the Apache Group and the Apache HTTP server
# project, please see ) {
$requests=$1 if ( m|^BusyServers:\ (\S+)|);
$idle=$1 if ( m|^IdleServers:\ (\S+)|);
$number=$1 if ( m|sses:\ (\S+)|);
$cpu=$1 if (m|^CPULoad:\ (\S+)|);
}
print OUT "$time:$requests:$idle:$number:$cpu\n";
}
0707010000cee3000081a400000064000000640000000134e8a3310000252c000000200000001b00000000000000000000001600000004reloc/sbin/logresolve ELF 0 4 !l 4 ( 4 4 a a d d d p p /usr/lib/ld.so.1 5 ? > $ 6 5 ! % < # . : ; 1 * = 9 , 0 7 / ( 4 8 3 + & - ' 2 " ) @ 0 < P h
d p
, @ H P 0 t p @! " d 8 x @ N 8 U D Z b \ i n < t | p @ P p ! h P
a
h
, x ! 3 @ 8 P > t _start _environ _end strdup _iob _GLOBAL_OFFSET_TABLE_ __ctype gethostbyname atexit exit nscache malloc puts _init h_errno fclose strncpy gethostbyaddr _DYNAMIC printf __iob inet_addr _exit environ perror strchr inet_ntoa free strcmp fgets _edata _PROCEDURE_LINKAGE_TABLE_ fopen _etext _lib_version _ctype main _fini fprintf libsocket.so.1 libnsl.so.1 libc.so.1 p x , 8 D ! P . \ # h 0 t > ) 2 3 ( 5 1 4 - $ + 8 ' @D# @ C; D"P@ C7 @ 6 , @
p" @ @ C, @ C- 㿐@ / B/ B㼮 ` 㿐 㿈 '6 6 6
* a @" 0 `@ B"0 2 % D@ B"p ! D@ Bbx@ Bߐ $ @ B$ 2 $ ! cP` "` #P*`" !$@ B'@ B M @ B H D@ B" ! D@ Bbx@ B @ B @ " @ " @ `@ 2 @ " ! # a! D"@ B' @ B $@ B @ B'@ B P `" $ D@ Br" ! D@ Bpbx@ Bb c, "c, `@ Bx! .a h D""@
6" D"' D"' D"' D#' D#' D@ BFc0 c4 D@ B@cH c< D@ B:cX c8 D@ B4cp #T #T D@ B+c D@ B$c D@ B c D@ Bc D@ Bc E` - E+ E) E ,@ B c0 E@ A` E@ A`0 ! " $` @ A' ` `x @ Aߖ
* @ A֖
2 ``٤ 㿐 @ A۔ @ Aג
2 * 㺀 ) - E+ E?# `@ @ Aƒ 2 @ @ A` 2 a 2 `a E@ A`@ A @ E@ A`@ A ` !#"@<"@ #P "@<"@+ #y# % $ 4O耢` c4 %c4
@ @ A} 2 . @ A~ ?2 '䀦 . @ Ax c< $c< 8 1$8 E! @ Ai ϐ @ Ab ː E@ A`a( ! Ea0@ A1 @ A# ̐ @ AU 㿐@ / @/ @㈮ ? ? ? ? 㿐 㿠 㿠 malloc Insufficient memory
strdup Bad host: %s != %s
Unknown error Host not found Try again Non recoverable error No data record No address No reverse entry logresolve Statistics:
Entries: %d
With name : %d
Resolves : %d
- Not found : %d
- Try again : %d
- No data : %d
- No address: %d
- No reverse: %d
Cache hits : %d
Cache size : %d
Cache buckets : IP number * hostname
%3d %15s - %s
%3d %15s : Unknown error
%3d %15s : %s
-c -s logresolve: missing filename to -s
Usage: logresolve [-s statfile] [-c] < input > output %s %s
w logresolve: could not open statistics file '%s'
p H D F U a <
P
k @ 00 <0 H0 T0 `0 l0 x0 0 0 0 0 0 0 0 0 0 0 0 0 0 @ 0 < P h
d p
, @ H P * @ 8 H F \ k , y 0 , \
L L P 4 8
<
@ * 0 5 L B D O V 0 t ] p f k r @! w d x 8 D \ < p @ P p ! h # * 4 9 @ F P M
g m a
t h
x ! @ P t logresolve crti.s values-Xa.c crtstuff.c __CTOR_LIST__ __DTOR_LIST__ __do_global_dtors_aux gcc2_compiled. force_to_data fini_dummy logresolve.c cachesize cachehits stats gcc2_compiled. getline errors entries resolves cgethost withname crtstuff.c __do_global_ctors_aux gcc2_compiled. force_to_data init_dummy __DTOR_END__ __CTOR_END__ crtn.s _start _environ _end strdup _iob _GLOBAL_OFFSET_TABLE_ __ctype gethostbyname atexit exit nscache malloc puts _init h_errno fclose strncpy gethostbyaddr _DYNAMIC printf __iob inet_addr _exit environ perror strchr inet_ntoa free strcmp fgets _edata _PROCEDURE_LINKAGE_TABLE_ fopen _etext _lib_version _ctype main _fini fprintf
< @(#)SunOS 5.5.1 Generic May 1996 as: SC4.0 dev 15 Feb 1995
GCC: (GNU) 2.7.2 as: SC4.2 dev 30 Nov 1995
GCC: (GNU) 2.7.2 as: SC4.0 dev 15 Feb 1995
GCC: (GNU) 2.7.2 ld: (SGU) SunOS/ELF (LK-2.0 (S/I) - versioning) .interp .hash .dynsym .dynstr .rela.bss .rela.plt .text .init .fini .rodata .got .dynamic .plt .data .ctors .dtors .bss .symtab .strtab .stab.index .comment .shstrtab .stab.indexstr values-Xa.c Xt ; V=2.0 k $ ) @ @
3 0 0 9 < < ? P P E h h M d d R p p [ $ ` , , f @ @ m H H t P P x y P 5 !T 0707010000cee4000081a400000064000000640000000134e8a33200001a00000000200000001b00000000000000000000001600000004reloc/sbin/rotatelogs ELF X 4 @ 4 ( 4 4 i i l l x x /usr/lib/ld.so.1 6 + 1 ( % ! 5 * 0 . 4 , ' 3 2 - & # " $ ) / D X
|
l x
X t
l
`
<
@! % l ;
0 B
< G
O
| U
[
x ` x i
@ o
u
H {
!
8
i
0
T _start read atoi _environ _end _iob _GLOBAL_OFFSET_TABLE_ atexit exit sprintf _init .umul time _DYNAMIC __iob write _exit environ perror errno close open _edata _PROCEDURE_LINKAGE_TABLE_ _etext _lib_version main .div _fini fprintf libc.so.1
&
0
<
H (
T 5
`
l
x $
,
3
#
!
-
*
' @D# @ Ao B"@ Ak @ , @
" @ @ A` @ Aa 㿐@ / A/ A ` 㿐 ?c ?! " B@ @ A>b B@ @ A9b B@ A5c B@ A1ch B@ A-c C@ A)`@ A! `@ A'` +? " C@ A `@@ A -? @ A @ @ A ` #8 ` @ @
` @ A
` @ A ?` @ @ @ A @ A C`` @ @ ! @ @! @ @ @ @ؐ @ @ Ð @ @@ @͐ 㿐@ / @/ @P ? ? ? ? 㿐 㿠 㿠N %s