<-
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
Status:Core
Support Apache!

Directives

Bugfix checklist

See also

top

AcceptFilter Directive

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

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.

The data AcceptFilter (Windows)

For versions 2.4.23 and prior, the Windows data accept filter waited until data had been transmitted and the initial data buffer and network endpoint addresses had been retrieved from the single AcceptEx() invocation. This implementation was subject to a denial of service attack and has been disabled.

Current releases of httpd default to the connect filter on Windows, and will fall back to connect if data is specified. Users of prior releases are encouraged to add an explicit setting of connect for their AcceptFilter, as shown above.

See also

top

AcceptPathInfo Directive

Description:Resources accept trailing pathname information
Syntax:AcceptPathInfo On|Off|Default
Default:AcceptPathInfo Default
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Core
Module:core

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