Apache Core Features

AcceptFilter Directive

This directive enables operating system specific optimizations for a listening socket by the Protocol type. The basic premise is for the kernel to not send a socket to the server process until either data is received or an entire HTTP Request is buffered. Only FreeBSD's Accept Filters, Linux's more primitive TCP_DEFER_ACCEPT, and Windows' optimized AcceptEx() are currently supported.

Using none for an argument will disable any accept filters for that protocol. This is useful for protocols that require a server send data first, such as ftp: or nntp:

AcceptFilter nntp none

The default protocol names are https for port 443 and http for all other ports. To specify that another protocol is being used with a listening port, add the protocol argument to the Listen directive.

The default values on FreeBSD are:

AcceptFilter http httpready
AcceptFilter https dataready

The httpready accept filter buffers entire HTTP requests at the kernel level. Once an entire request is received, the kernel then sends it to the server. See the accf_http(9) man page for more details. Since HTTPS requests are encrypted, only the accf_data(9) filter is used.

The default values on Linux are:

AcceptFilter http data
AcceptFilter https data

Linux's TCP_DEFER_ACCEPT does not support buffering http requests. Any value besides none will enable TCP_DEFER_ACCEPT on that listener. For more details see the Linux tcp(7) man page.

The default values on Windows are:

AcceptFilter http connect
AcceptFilter https connect

Window's mpm_winnt interprets the AcceptFilter to toggle the AcceptEx() API, and does not support http protocol buffering. connect will use the AcceptEx() API, also retrieve the network endpoint addresses, but like none the connect option does not wait for the initial data transmission.

On Windows, none uses accept() rather than AcceptEx() and will not recycle sockets between connections. This is useful for network adapters with broken driver support, as well as some virtual network providers such as vpn drivers, or spam, virus or spyware filters.

See also

• Protocol

AcceptPathInfo Directive

This directive controls whether requests that contain trailing pathname information that follows an actual filename (or non-existent file in an existing directory) will be accepted or rejected. The trailing pathname information can be made available to scripts in the PATH_INFO environment variable.

For example, assume the location /test/ points to a directory that contains only the single file here.html. Then requests for /test/here.html/more and /test/nothere.html/more both collect /more as PATH_INFO.

The three possible arguments for the AcceptPathInfo directive are:

Off

A request will only be accepted if it maps to a literal path that exists. Therefore a request with trailing pathname information after the true filename such as /test/here.html/more in the above example will return a 404 NOT FOUND error.

On

A request will be accepted if a leading path component maps to a file that exists. The above example /test/here.html/more will be accepted if /test/here.html maps to a valid file.

Default

The treatment of requests with trailing pathname information is determined by the handler responsible for the request. The core handler for normal files defaults to rejecting PATH_INFO requests. Handlers that serve scripts, such as cgi-script and isapi-handler, generally accept PATH_INFO by default.

The primary purpose of the AcceptPathInfo directive is to allow you to override the handler's choice of accepting or rejecting PATH_INFO. This override is required, for example, when you use a filter, such as INCLUDES, to generate content based on PATH_INFO. The core handler would usually reject the request, so you can use the following configuration to enable such a script:

<Files "mypaths.shtml">
  Options +Includes
  SetOutputFilter INCLUDES
  AcceptPathInfo On
</Files>

AccessFileName Directive

While processing a request, the server looks for the first existing configuration file from this list of names in every directory of the path to the document, if distributed configuration files are enabled for that directory. For example:

AccessFileName .acl

Before returning the document /usr/local/web/index.html, the server will read /.acl, /usr/.acl, /usr/local/.acl and /usr/local/web/.acl for directives unless they have been disabled with:

<Directory "/">
    AllowOverride None
</Directory>

See also

• AllowOverride
• Configuration Files
• .htaccess Files

AddDefaultCharset Directive

This directive specifies a default value for the media type charset parameter (the name of a character encoding) to be added to a response if and only if the response's content-type is either text/plain or text/html. This should override any charset specified in the body of the response via a META element, though the exact behavior is often dependent on the user's client configuration. A setting of AddDefaultCharset Off disables this functionality. AddDefaultCharset On enables a default charset of iso-8859-1. Any other value is assumed to be the charset to be used, which should be one of the IANA registered charset values for use in Internet media types (MIME types). For example:

AddDefaultCharset utf-8

AddDefaultCharset should only be used when all of the text resources to which it applies are known to be in that character encoding and it is too inconvenient to label their charset individually. One such example is to add the charset parameter to resources containing generated content, such as legacy CGI scripts, that might be vulnerable to cross-site scripting attacks due to user-provided data being included in the output. Note, however, that a better solution is to just fix (or delete) those scripts, since setting a default charset does not protect users that have enabled the "auto-detect character encoding" feature on their browser.

See also

• AddCharset

AllowEncodedSlashes Directive

The AllowEncodedSlashes directive allows URLs which contain encoded path separators (%2F for / and additionally %5C for \ on accordant systems) to be used in the path info.

With the default value, Off, such URLs are refused with a 404 (Not found) error.

With the value On, such URLs are accepted, and encoded slashes are decoded like all other encoded characters.

With the value NoDecode, such URLs are accepted, but encoded slashes are not decoded but left in their encoded state.

Turning AllowEncodedSlashes On is mostly useful when used in conjunction with PATH_INFO.

See also

• AcceptPathInfo

AllowOverride Directive

When the server finds an .htaccess file (as specified by AccessFileName), it needs to know which directives declared in that file can override earlier configuration directives.

When this directive is set to None and AllowOverrideList is set to None, .htaccess files are completely ignored. In this case, the server will not even attempt to read .htaccess files in the filesystem.

When this directive is set to All, then any directive which has the .htaccess Context is allowed in .htaccess files.

The directive-type can be one of the following groupings of directives. (See the override class index for an up-to-date listing of which directives are enabled by each directive-type.)

AuthConfig

Allow use of the authorization directives (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, etc.).

FileInfo

Allow use of the directives controlling document types (ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, and mod_mime Add* and Remove* directives), document meta data (Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName), mod_rewrite directives (RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule), mod_alias directives (Redirect, RedirectTemp, RedirectPermanent, RedirectMatch), and Action from mod_actions.

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).

Nonfatal=[Override|Unknown|All]

Allow use of AllowOverride option to treat syntax errors in .htaccess as nonfatal. Instead of causing an Internal Server Error, disallowed or unrecognised directives will be ignored and a warning logged:

• Nonfatal=Override treats directives forbidden by AllowOverride as nonfatal.
• Nonfatal=Unknown treats unknown directives as nonfatal. This covers typos and directives implemented by a module that's not present.
• Nonfatal=All treats both the above as nonfatal.

Note that a syntax error in a valid directive will still cause an internal server error.

Security

Nonfatal errors may have security implications for .htaccess users. For example, if AllowOverride disallows AuthConfig, users' configuration designed to restrict access to a site will be disabled.

Options[=Option,...]

Allow use of the directives controlling specific directory features (Options and XBitHack). An equal sign may be given followed by a comma-separated list, without spaces, of options that may be set using the Options command.

Implicit disabling of Options

Even though the list of options that may be used in .htaccess files can be limited with this directive, as long as any Options directive is allowed any other inherited option can be disabled by using the non-relative syntax. In other words, this mechanism cannot force a specific option to remain set while allowing any others to be set.

AllowOverride Options=Indexes,MultiViews

Example:

AllowOverride AuthConfig Indexes

In the example above, all directives that are neither in the group AuthConfig nor Indexes cause an internal server error.

See also

• AccessFileName
• AllowOverrideList
• Configuration Files
• .htaccess Files
• Override Class Index for .htaccess

AllowOverrideList Directive

When the server finds an .htaccess file (as specified by AccessFileName), it needs to know which directives declared in that file can override earlier configuration directives.

When this directive is set to None and AllowOverride is set to None, then .htaccess files are completely ignored. In this case, the server will not even attempt to read .htaccess files in the filesystem.

Example:

AllowOverride None
AllowOverrideList Redirect RedirectMatch

In the example above, only the Redirect and RedirectMatch directives are allowed. All others will cause an internal server error.

Example:

AllowOverride AuthConfig
AllowOverrideList CookieTracking CookieName

In the example above, AllowOverride grants permission to the AuthConfig directive grouping and AllowOverrideList grants permission to only two directives from the FileInfo directive grouping. All others will cause an internal server error.

See also

• AccessFileName
• AllowOverride
• Configuration Files
• .htaccess Files

CGIMapExtension Directive

This directive is used to control how Apache httpd finds the interpreter used to run CGI scripts. For example, setting CGIMapExtension sys:\foo.nlm .foo will cause all CGI script files with a .foo extension to be passed to the FOO interpreter.

CGIPassAuth Directive

CGIPassAuth allows scripts access to HTTP authorization headers such as Authorization, which is required for scripts that implement HTTP Basic authentication. Normally these HTTP headers are hidden from scripts. This is to disallow scripts from seeing user ids and passwords used to access the server when HTTP Basic authentication is enabled in the web server. This directive should be used when scripts are allowed to implement HTTP Basic authentication.

This directive can be used instead of the compile-time setting SECURITY_HOLE_PASS_AUTHORIZATION which has been available in previous versions of Apache HTTP Server.

The setting is respected by any modules which use ap_add_common_vars(), such as mod_cgi, mod_cgid, mod_proxy_fcgi, mod_proxy_scgi, and so on. Notably, it affects modules which don't handle the request in the usual sense but still use this API; examples of this are mod_include and mod_ext_filter. Third-party modules that don't use ap_add_common_vars() may choose to respect the setting as well.

CGIVar Directive

This directive controls how some CGI variables are set.

REQUEST_URI rules:

original-uri (default)

The value is taken from the original request line, and will not reflect internal redirects or subrequests which change the requested resource.

current-uri

The value reflects the resource currently being processed, which may be different than the original request from the client due to internal redirects or subrequests.

ContentDigest Directive

This directive enables the generation of Content-MD5 headers as defined in RFC1864 respectively RFC2616.

MD5 is an algorithm for computing a "message digest" (sometimes called "fingerprint") of arbitrary-length data, with a high degree of confidence that any alterations in the data will be reflected in alterations in the message digest.

The Content-MD5 header provides an end-to-end message integrity check (MIC) of the entity-body. A proxy or client may check this header for detecting accidental modification of the entity-body in transit. Example header:

Note that this can cause performance problems on your server since the message digest is computed on every request (the values are not cached).

Content-MD5 is only sent for documents served by the core, and not by any module. For example, SSI documents, output from CGI scripts, and byte range responses do not have this header.

DefaultRuntimeDir Directive

The DefaultRuntimeDir directive sets the directory in which the server will create various run-time files (shared memory, locks, etc.). If set as a relative path, the full path will be relative to ServerRoot.

Example

DefaultRuntimeDir scratch/

The default location of DefaultRuntimeDir may be modified by changing the DEFAULT_REL_RUNTIMEDIR #define at build time.

Note: ServerRoot should be specified before this directive is used. Otherwise, the default value of ServerRoot would be used to set the base directory.

See also

• the security tips for information on how to properly set permissions on the ServerRoot

DefaultType Directive

This directive has been disabled. For backwards compatibility of configuration files, it may be specified with the value none, meaning no default media type. For example:

DefaultType None

DefaultType None is only available in httpd-2.2.7 and later.

Use the mime.types configuration file and the AddType to configure media type assignments via file extensions, or the ForceType directive to configure the media type for specific resources. Otherwise, the server will send the response without a Content-Type header field and the recipient may attempt to guess the media type.

Define Directive

In its one parameter form, Define is equivalent to passing the -D argument to httpd. It can be used to toggle the use of <IfDefine> sections without needing to alter -D arguments in any startup scripts.

In addition to that, if the second parameter is given, a config variable is set to this value. The variable can be used in the configuration using the ${VAR} syntax. The variable is always globally defined and not limited to the scope of the surrounding config section.

<IfDefine TEST>
  Define servername test.example.com
</IfDefine>
<IfDefine !TEST>
  Define servername www.example.com
  Define SSL
</IfDefine>

DocumentRoot "/var/www/${servername}/htdocs"

Variable names may not contain colon ":" characters, to avoid clashes with RewriteMap's syntax.

See also

• UnDefine
• IfDefine

<Directory> Directive

<Directory> and </Directory> are used to enclose a group of directives that will apply only to the named directory, sub-directories of that directory, and the files within the respective directories. Any directive that is allowed in a directory context may be used. Directory-path is either the full path to a directory, or a wild-card string using Unix shell-style matching. In a wild-card string, ? matches any single character, and * matches any sequences of characters. You may also use [] character ranges. None of the wildcards match a `/' character, so <Directory "/*/public_html"> will not match /home/user/public_html, but <Directory "/home/*/public_html"> will match. Example:

<Directory "/usr/local/httpd/htdocs">
  Options Indexes FollowSymLinks
</Directory>

Directory paths may be quoted, if you like, however, it must be quoted if the path contains spaces. This is because a space would otherwise indicate the end of an argument.

Regular expressions can also be used, with the addition of the ~ character. For example:

<Directory ~ "^/www/[0-9]{3}">

</Directory>

would match directories in /www/ that consisted of three numbers.

If multiple (non-regular expression) <Directory> sections match the directory (or one of its parents) containing a document, then the directives are applied in the or