Apache Core Features 6
Syntax: (Apache 1.1) KeepAlive max-requests
Default: (Apache 1.1) KeepAlive 5
Syntax: (Apache 1.2) KeepAlive on|off
Default: (Apache 1.2) KeepAlive On
Context:
server config
Status:
Core
Compatibility:
KeepAlive is only available in Apache 1.1 and later.
The Keep-Alive extension to HTTP/1.0 and the persistent connection feature of HTTP/1.1
provide long-lived HTTP sessions which allow multiple requests to be sent over the same TCP
connection. In some cases this has been shown to result in an almost 50% speedup in latency
times for HTML documents with many images. To enable Keep-Alive connections in Apache 1.2 and
later, set KeepAlive On.
For HTTP/1.0 clients, Keep-Alive connections will only be used if they are specifically
requested by a client. In addition, a Keep-Alive connection with an HTTP/1.0 client can only
be used when the length of the content is known in advance. This implies that dynamic content
such as CGI output, SSI pages, and server-generated directory listings will generally not use
Keep-Alive connections to HTTP/1.0 clients. For HTTP/1.1 clients, persistent connections are
the default unless otherwise specified. If the client requests it, chunked encoding will be
used in order to send content of unknown length over persistent connections.
Apache 1.1 only: Set max-requests to the maximum number of
requests you want Apache to entertain per connection. A limit is imposed to prevent a client
from hogging your server resources. Set this to 0 to disable support. In Apache
1.2 and 1.3, this is controlled through the MaxKeepAliveRequests directive instead.
See also MaxKeepAliveRequests.
Syntax:
KeepAliveTimeout seconds
Default:
KeepAliveTimeout 15
Context:
server config
Status:
Core
Compatibility:
KeepAliveTimeout is only available in Apache 1.1 and later.
The number of seconds Apache will wait for a subsequent request before closing the
connection. Once a request has been received, the timeout value specified by the Timeout directive applies.
Setting KeepAliveTimeout to a high value may cause performance problems in
heavily loaded servers. The higher the timeout, the more server processes will be kept
occupied waiting on connections with idle clients.
Syntax:
<Limit method [method] ... > ... </Limit>
Context:
any
Status:
core
Access controls are normally effective for all access methods, and this is
the usual desired behavior. In the general case, access control directives should not
be placed within a <limit> section.
The purpose of the <Limit> directive is to restrict the effect of the access controls
to the nominated HTTP methods. For all other methods, the access restrictions that are
enclosed in the <Limit> bracket will have no effect. The following
example applies the access control only to the methods POST, PUT, and DELETE, leaving all
other methods unprotected:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
The method names listed can be one or more of: GET, POST, PUT, DELETE, CONNECT, OPTIONS,
PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK. The method name is
case-sensitive. If GET is used it will also restrict HEAD requests. The TRACE method
cannot be limited.
Warning: A <LimitExcept> section should
always be used in preference to a <Limit> section when restricting
access, since a <LimitExcept> section provides protection
against arbitrary methods.
Syntax:
<LimitExcept method [method] ... > ... </LimitExcept>
Context:
any
Status:
core
Compatibility:
Available in Apache 1.3.5 and later
<LimitExcept> and </LimitExcept> are used to enclose a group of access control
directives which will then apply to any HTTP access method not listed in the
arguments; i.e., it is the opposite of a <Limit> section
and can be used to control both standard and nonstandard/unrecognized methods. See the
documentation for <Limit> for more details.
For example:
<LimitExcept POST GET>
Require valid-user
</LimitExcept>
Syntax:
LimitInternalRecursion number [number]
Default:
LimitInternalRecursion 20
Context:
server config, virtual host
Status:
core
Compatibility:
LimitInternalRecursion is only available in Apache 1.3.28 and later.
An internal redirect happens, for example, when using the
Action directive, which
internally redirects the original request to a CGI script. A subrequest is Apache's mechanism
to find out what would happen for some URI if it were requested. For example,
mod_dir uses subrequests to look for
the files listed in the
DirectoryIndex
directive.
LimitInternalRecursion prevents the server from crashing when entering an
infinite loop of internal redirects or subrequests. Such loops are usually caused by
misconfigurations.
The directive stores two different limits, which are evaluated on per-request basis. The
first number is the maximum number of internal redirects, that may follow each other.
The second number determines, how deep subrequests may be nested. If you specify only
one number, it will be assigned to both limits. A value of 0 means
"unlimited".
Example
LimitInternalRecursion 5
Syntax:
LimitRequestBody bytes
Default:
LimitRequestBody 0
Context:
server config, virtual host, directory, .htaccess
Status:
core
Compatibility:
LimitRequestBody is only available in Apache 1.3.2 and later.
This directive specifies the number of bytes from 0 (meaning unlimited) to
2147483647 (2GB) that are allowed in a request body.
The LimitRequestBody directive allows the user to set a limit on the allowed size of an
HTTP request message body within the context in which the directive is given (server,
per-directory, per-file or per-location). If the client request exceeds that limit, the server
will return an error response instead of servicing the request. The size of a normal request
message body will vary greatly depending on the nature of the resource and the methods allowed
on that resource. CGI scripts typically use the message body for passing form information to
the server. Implementations of the PUT method will require a value at least as large as any
representation that the server wishes to accept for that resource.
This directive gives the server administrator greater control over abnormal client request
behavior, which may be useful for avoiding some forms of denial-of-service attacks.
If, for example, you are permitting file upload to a particular location, and wich to limit
the size of the uploaded file to 100K, you might use the following directive:
LimitRequestBody 102400
Syntax:
LimitRequestFields number
Default:
LimitRequestFields 100
Context:
server config
Status:
core
Compatibility:
LimitRequestFields is only available in Apache 1.3.2 and later.
Number is an integer from 0 (meaning unlimited) to 32767. The default value is
defined by the compile-time constant DEFAULT_LIMIT_REQUEST_FIELDS (100 as
distributed).
The LimitRequestFields directive allows the server administrator to modify the limit on the
number of request header fields allowed in an HTTP request. A server needs this value to be
larger than the number of fields that a normal client request might include. The number of
request header fields used by a client rarely exceeds 20, but this may vary among different
client implementations, often depending upon the extent to which a user has configured their
browser to support detailed content negotiation. Optional HTTP extensions are often expressed
using request header fields.
This directive gives the server administrator greater control over abnormal client request
behavior, which may be useful for avoiding some forms of denial-of-service attacks. The value
should be increased if normal clients see an error response from the server that indicates too
many fields were sent in the request.
For example:
LimitRequestFields 50
Syntax:
LimitRequestFieldsize bytes
Default:
LimitRequestFieldsize 8190
Context:
server config
Status:
core
Compatibility:
LimitRequestFieldsize is only available in Apache 1.3.2 and later.
This directive specifies the number of bytes from 0 to the value of the
compile-time constant DEFAULT_LIMIT_REQUEST_FIELDSIZE (8190 as distributed) that
will be allowed in an HTTP request header.
The LimitRequestFieldsize directive allows the server administrator to reduce the limit on
the allowed size of an HTTP request header field below the normal input buffer size compiled
with the server. A server needs this value to be large enough to hold any one header field
from a normal client request. The size of a normal request header field will vary greatly
among different client implementations, often depending upon the extent to which a user has
configured their browser to support detailed content negotiation.
This directive gives the server administrator greater control over abnormal client request
behavior, which may be useful for avoiding some forms of denial-of-service attacks.
For example:
LimitRequestFieldSize 16380
Under normal conditions, the value should not be changed from the default.
Syntax:
LimitRequestLine bytes
Default:
LimitRequestLine 8190
Context:
server config
Status:
core
Compatibility:
LimitRequestLine is only available in Apache 1.3.2 and later.
This directive sets the number of bytes from 0 to the value of the compile-time
constant DEFAULT_LIMIT_REQUEST_LINE (8190 as distributed) that will be allowed on
the HTTP request-line.
The LimitRequestLine directive allows the server administrator to reduce the limit on the
allowed size of a client's HTTP request-line below the normal input buffer size compiled with
the server. Since the request-line consists of the HTTP method, URI, and protocol version, the
LimitRequestLine directive places a restriction on the length of a request-URI allowed for a
request on the server. A server needs this value to be large enough to hold any of its
resource names, including any information that might be passed in the query part of a GET
request.
This directive gives the server administrator greater control over abnormal client request
behavior, which may be useful for avoiding some forms of denial-of-service attacks.
For example:
LimitRequestLine 16380
Under normal conditions, the value should not be changed from the default.
Syntax:
Listen [IP-address:]port
Context:
server config
Status:
core
Compatibility:
Listen is only available in Apache 1.1 and later.
The Listen directive instructs Apache to listen to more than one IP address or port; by
default it responds to requests on all IP interfaces, but only on the port given by the Port directive.
Listen can be used instead of BindAddress and Port.
It tells the server to accept incoming requests on the specified port or address-and-port
combination. If the first format is used, with a port number only, the server listens to the
given port on all interfaces, instead of the port given by the Port directive. If an
IP address is given as well as a port, the server will listen on the given port and interface.
Note that you may still require a Port directive so that URLs that Apache
generates that point to your server still work.
Multiple Listen directives may be used to specify a number of addresses and ports to listen
to. The server will respond to requests from any of the listed addresses and ports.
For example, to make the server accept connections on both port 80 and port 8000, use:
Listen 80
Listen 8000
To make the server accept connections on two specified interfaces and port numbers, use
Listen 192.170.2.1:80
Listen 192.170.2.5:8000
See Also:
DNS
Issues
See Also:
Setting which
addresses and ports Apache uses
See Also:
Known
Bugs
Syntax:
ListenBacklog backlog
Default:
ListenBacklog 511
Context:
server config
Status:
Core
Compatibility:
ListenBacklog is only available in Apache versions after 1.2.0.
The maximum length of the queue of pending connections. Generally no tuning is needed or
desired, however on some systems it is desirable to increase this when under a TCP SYN flood
attack. See the backlog parameter to the listen(2) system call.
This will often be limited to a smaller number by the operating system. This varies from OS
to OS. Also note that many OSes do not use exactly what is specified as the backlog, but use a
number based on (but normally larger than) what is set.
|
