There are two kinds of environment variables that affect the Apache HTTP Server.
First, there are the environment variables controlled by the underlying operating system. These are set before the server starts. They can be used in expansions in configuration files, and can optionally be passed to CGI scripts and SSI using the PassEnv directive.
Second, the Apache HTTP Server provides a mechanism for storing information in named variables that are also called environment variables. This information can be used to control various operations such as logging or access control. The variables are also used as a mechanism to communicate with external programs such as CGI scripts. This document discusses different ways to manipulate and use these variables.
Although these variables are referred to as environment variables, they are not the same as the environment variables controlled by the underlying operating system. Instead, these variables are stored and manipulated in an internal Apache structure. They only become actual operating system environment variables when they are provided to CGI scripts and Server Side Include scripts. If you wish to manipulate the operating system environment under which the server itself runs, you must use the standard environment manipulation mechanisms provided by your operating system shell.
The most basic way to set an environment variable in Apache
is using the unconditional
For additional flexibility, the directives provided by
[E=...]
option to set environment variables.
Finally, UNIQUE_ID
for each request to a value which is
guaranteed to be unique across "all" requests under very
specific conditions.
In addition to all environment variables set within the Apache configuration and passed from the shell, CGI scripts and SSI pages are provided with a set of environment variables containing meta-information about the request as required by the CGI specification.
suexec.c
.One of the primary uses of environment variables is to communicate information to CGI scripts. As discussed above, the environment passed to CGI scripts includes standard meta-information about the request in addition to any variables set within the Apache configuration. For more details, see the CGI tutorial.
Server-parsed (SSI) documents processed by
INCLUDES
filter can print environment variables
using the echo
element, and can use environment
variables in flow control elements to makes parts of a page
conditional on characteristics of a request. Apache also
provides SSI pages with the standard CGI environment variables
as discussed above. For more details, see the SSI tutorial.
Access to the server can be controlled based on
environment variables using the Require env
and Require not env
directives. In combination with
Environment variables can be logged in the access log using
the %e
. In addition, the decision on whether
or not to log requests can be made based on the status of
environment variables using the conditional form of the
gif
, or you can
choose to only log requests from clients which are outside your
subnet.
The
External filters configured by disableenv=
and enableenv=
options.
The %{ENV:variable}
form of
TestString in the ENV:
prefix are not actually environment
variables. Rather, they are variables special to
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
This forces the request to be treated as a HTTP/1.0 request even if it was in a later dialect.
If you have the DEFLATE
filter activated, this
environment variable will ignore the accept-encoding setting of
your browser and will send compressed output unconditionally.
This causes any Vary
fields to be removed from
the response header before it is sent back to the client. Some
clients don't interpret this field correctly; setting this
variable can work around this problem. Setting this variable
also implies force-response-1.0.
This forces an HTTP/1.0 response to clients making an HTTP/1.0 request. It was originally implemented as a result of a problem with AOL's proxies. Some HTTP/1.0 clients may not behave correctly when given an HTTP/1.1 response, and this can be used to interoperate with them.
When set to a value of "1", this variable disables the
DEFLATE
output filter provided by
text/html
. If you'd rather
use statically compressed files,
When set, the DEFLATE
filter of
Available in versions 2.2.12 and later
When set,
This disables
This influences en
, ja
or x-klingon
),
This forces the server to be more careful when sending a redirect to the client. This is typically used when a client has a known problem handling redirects. This was originally implemented as a result of a problem with Microsoft's WebFolders software which has a problem handling redirects on directory resources via DAV methods.
Available in versions after 2.0.54
When Apache issues a redirect in response to a client request, the response includes some actual text to be displayed in case the client can't (or doesn't) automatically follow the redirection. Apache ordinarily labels this text according to the character set which it uses, which is ISO-8859-1.
However, if the redirection is to a page that uses a different character set, some broken browser versions will try to use the character set from the redirection text rather than the actual page. This can result in Greek, for instance, being incorrectly rendered.
Setting this environment variable causes Apache to omit the character set for the redirection text, and these broken browsers will then correctly use that of the destination page.
Sending error pages without a specified character set may allow a cross-site-scripting attack for existing browsers (MSIE) which do not follow the HTTP/1.1 specification and attempt to "guess" the character set from the content. Such browsers can be easily fooled into using the UTF-7 character set, and UTF-7 content from input data (such as the request-URI) will not be escaped by the usual escaping mechanisms designed to prevent cross-site-scripting attacks.
These directives alter the protocol behavior of
Starting with version 2.4, Apache is more strict about how HTTP
headers are converted to environment variables in
If you have to support a client which sends broken headers and
which can't be fixed, a simple workaround involving
Earlier versions recommended that the following lines be included in httpd.conf to deal with known client problems. Since the affected clients are no longer seen in the wild, this configuration is likely no-longer necessary.
This example keeps requests for images from appearing in the access log. It can be easily modified to prevent logging of particular directories, or to prevent logging of requests coming from particular hosts.
This example shows how to keep people not on your server
from using images on your server as inline-images on their
pages. This is not a recommended configuration, but it can work
in limited circumstances. We assume that all your images are in
a directory called /web/images
.
For more information about this technique, see the "Keeping Your Images from Adorning Other Sites" tutorial on ServerWatch.