Apache > HTTP Server > Documentation > Version 2.4 > Modules

Apache Core Features

Available Languages:  de  |  en  |  es  |  fr  |  ja  |  tr 

Description:Core Apache HTTP Server features that are always available



AcceptFilter Directive

Description:Configures optimizations for a Protocol's Listener Sockets
Syntax:AcceptFilter protocol accept_filter
Context:server config

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 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 data
AcceptFilter https data

Window's mpm_winnt interprets the AcceptFilter to toggle the AcceptEx() API, and does not support http protocol buffering. There are two values which utilize the Windows AcceptEx() API and will recycle network sockets between connections. data waits until data has been transmitted as documented above, and the initial data buffer and network endpoint addresses are all retrieved from the single AcceptEx() invocation. 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


AcceptPathInfo Directive

Description:Resources accept trailing pathname information
Syntax:AcceptPathInfo On|Off|Default
Default:AcceptPathInfo Default
Context:server config, virtual host, directory, .htaccess

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:

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

AccessFileName Directive

Description:Name of the distributed configuration file
Syntax:AccessFileName filename [filename] ...
Default:AccessFileName .htaccess
Context:server config, virtual host

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

See also


AddDefaultCharset Directive

Description:Default charset parameter to be added when a response content-type is text/plain or text/html
Syntax:AddDefaultCharset On|Off|charset
Default:AddDefaultCharset Off
Context:server config, virtual host, directory, .htaccess

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