Server and Environment Variables are used by The Apache HTTP Server by provides a mechanism for storing information. 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.
« SSL example usage in htaccess | .htaccess Tutorial Index | » .htaccess Security with MOD_SECURITY
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.mod_env
Article:Additional SetEnvIf examples
SetEnvIf User-Agent ^KnockKnock/2.0 let_me_in Order Deny,Allow Deny from all Allow from env=let_me_in
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.
The SetEnvIf directive defines environment variables based on attributes of the request. These attributes can be the values of various HTTP request header fields (see RFC2616 for more information about these), or of other aspects of the request, including the following:
Some of the more commonly used request header field names include Host, User-Agent, and Referer.
If the attribute name doesn't match any of the special keywords, nor any of the request's header field names, it is tested as the name of an environment variable in the list of those associated with the request. This allows SetEnvIf directives to test against the result of prior matches.
Only those environment variables defined by earlier SetEnvIf[NoCase] directives are available for testing in this manner. 'Earlier' means that they were defined at a broader scope (such as server-wide) or previously in the current directive's scope.
The first three will set the environment variable is_image if the request was for an image file, and the fourth sets in_site_referral if the referring page was somewhere on the www.askapache.com Web site.
The sixth example will set the NetscapeComment environment variable to the string found in the corresponding SSL client certificate field (if found).
The last example will set environment variable HAVE_TS if the request contains any headers that begin with "TS" whose values begins with any character in the set [a-z].
SetEnvIfNoCase Request_URI ".gif$" is_image=gif SetEnvIfNoCase Request_URI ".jpg$" is_image=jpg SetEnvIfNoCase Request_URI ".xbm$" is_image=xbm SetEnvIfNoCase Referer www.askapache.com in_site_referral SetEnvIfNoCase ^TS* ^[a-z].* HAVE_TS
This will cause the site environment variable to be set to "askapache" if the HTTP request header field Host: was included and contained askapache.com, askApache.COm, or any other combination.
SetEnvIfNoCase Host askapache.com site=askapache
SetEnvIf Request_URI ^/manual/(de|en|es|fr|ja|ko|ru)/ prefer-language=$1
RedirectMatch 301 ^/manual(?:/(de|en|es|fr|ja|ko|ru)){2,}(/.*)?$ /manual/$1$2
Additional and detailed info on each htaccess code snippet can be found athtaccessElite
The most basic way to set an environment variable in Apache is using the unconditional SetEnv directive. Variables may also be passed from the environment of the shell which started the server using the PassEnv directive.
For additional flexibility, the directives provided by mod_setenvif allow environment variables to be set on a per-request basis, conditional on characteristics of particular requests. For example, a variable could be set only when a specific browser (User-Agent) is making a request, or only when a specific Referer [sic] header is found. Even more flexibility is available through the mod_rewrite's RewriteRule which uses the [E=...] option to set environment variables.
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 mod_include's 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 the value of environment variables using the allow from env= and deny from env= directives. In combination with SetEnvIf, this allows for flexible control of access to the server based on characteristics of the client. For example, you can use these directives to deny access to a particular browser (User-Agent).
Environment variables can be logged in the access log using the LogFormat option %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 CustomLog directive. In combination with SetEnvIf this allows for flexible control of which requests are logged. For example, you can choose not to log requests for filenames ending in gif, or you can choose to only log requests from clients which are outside your subnet.
The Header directive can use the presence or absence of an environment variable to determine whether or not a certain HTTP header will be placed in the response to the client. This allows, for example, a certain response header to be sent only if a corresponding header is received in the request from the client.
External filters configured by mod_ext_filter using the ExtFilterDefine directive can by activated conditional on an environment variable using the disableenv= and enableenv= options.
The %{ENV:...} form of TestString in the RewriteCond allows mod_rewrite's rewrite engine to make decisions conditional on environment variables. Note that the variables accessible in mod_rewrite without the ENV: prefix are not actually environment variables. Rather, they are variables special to mod_rewrite which cannot be accessed from other modules.
Getting prefetching to show up in our logs
First of all, how do we know a prefetch when we see one?
Firefox puts a header in each prefetching request, like this:X-moz: prefetchSo we'll need to ask our web server to trap that information and log it somewhere useful. The options are:
Make a separate log file, just for prefetching requests.
Add an extra field to our log file format.
Mush something about prefetching into an existing field in our log file.
I have enough log files as it is, and I don't want to confuse my log analysis software by adding a custom field, so I'm going to squidge the X-Moz header onto the end of the User-Agent field of my current logs. (They're in "combined" format, which includes a field for the referer). Log analysis software will usually ignore crap tagged on the end of the User-Agent field, so this will tell me which hits have been prefetched without breaking anything else.
Let's tell Apache about the new log format we're inventing. We'll call the format "combined_with_prefetching_hack".
Somewhere in our apache configuration file (httpd.conf or apache2.conf) we should have a line like this.LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combinedUnderneath that, we'll add another line like this:LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i %{X-Moz}i"" combined_with_prefetching_hackThen we'll find the place where we are currently telling apache to use the "combined" format for our site, and tell it to use "combined_with_prefetching_hack" instead.
Comment out a line a bit like this:CustomLog /var/log/apache2/access.log combinedand replace it with something more like this:CustomLog /var/log/apache2/access.log combined_with_prefetching_hackthen restart apache.
Now if we want our log file without the prefetched stuff:grep -v prefetch access.log
« SSL example usage in htaccess | .htaccess Tutorial Index | » .htaccess Security with MOD_SECURITY