Apache Core Features 7
Syntax:
<Location URL-path|URL> ... </Location>
Context:
server config, virtual host
Status:
core
Compatibility:
Location is only available in Apache 1.1 and later.
The <Location> directive provides for access control by URL. It is similar to the <Directory> directive, and starts a subsection which is terminated
with a </Location> directive. <Location> sections are processed in
the order they appear in the configuration file, after the <Directory> sections and .htaccess
files are read, and after the <Files> sections.
Note that URLs do not have to line up with the filesystem at all, it should be emphasized
that <Location> operates completely outside the filesystem.
For all origin (non-proxy) requests, the URL to be matched is of the form /path/,
and you should not include any http://servername prefix. For proxy requests, the
URL to be matched is of the form scheme://servername/path, and you must include
the prefix.
The URL may use wildcards In a wild-card string, `?' matches any single character, and `*'
matches any sequences of characters.
Apache 1.2 and above: Extended regular expressions can also be used, with
the addition of the ~ character. For example:
<Location ~ "/(extra|special)/data">
would match URLs that contained the substring "/extra/data" or
"/special/data". In Apache 1.3 and above, a new directive <LocationMatch>
exists which behaves identical to the regex version of <Location>.
The Location functionality is especially useful when combined with the
SetHandler
directive. For example, to enable status requests, but allow them only from browsers at
foo.com, you might use:
<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>
Apache 1.3 and above note about / (slash): The slash character has special
meaning depending on where in a URL it appears. People may be used to its behavior in the
filesystem where multiple adjacent slashes are frequently collapsed to a single slash (i.e.,
/home///foo is the same as /home/foo). In URL-space this is not
necessarily true. The <LocationMatch> directive and the regex version of <Location>
require you to explicitly specify multiple slashes if that is your intention. For example, <LocationMatch
^/abc> would match the request URL /abc but not the request URL //abc.
The (non-regex) <Location> directive behaves similarly when used for proxy
requests. But when (non-regex) <Location> is used for non-proxy requests it
will implicitly match multiple slashes with a single slash. For example, if you specify <Location
/abc/def> and the request is to /abc//def then it will match.
See also:
How
Directory, Location and Files sections work for an explanation of how these different
sections are combined when a request is received
Syntax:
<LocationMatch regex> ... </LocationMatch>
Context:
server config, virtual host
Status:
core
Compatibility:
LocationMatch is only available in Apache 1.3 and later.
The <LocationMatch> directive provides for access control by URL, in an identical
manner to <Location>. However, it takes a regular expression as
an argument instead of a simple string. For example:
<LocationMatch "/(extra|special)/data">
would match URLs that contained the substring "/extra/data" or
"/special/data".
See also:
How Directory,
Location and Files sections work for an explanation of how these different sections are
combined when a request is received
Syntax:
LockFile file-path
Default:
LockFile logs/accept.lock
Context:
server config
Status:
core
The LockFile directive sets the path to the lockfile used when Apache is compiled with
either USE_FCNTL_SERIALIZED_ACCEPT or USE_FLOCK_SERIALIZED_ACCEPT. This directive should
normally be left at its default value. The main reason for changing it is if the logs
directory is NFS mounted, since the lockfile must be stored on a local disk.
The PID of the main server process is automatically appended to the filename.
SECURITY: It is best to avoid putting this file in a world writable
directory such as /var/tmp because someone could create a denial of service
attack and prevent the server from starting by creating a lockfile with the same name as the
one the server will try to create.
Syntax:
LogLevel level
Default:
LogLevel warn
Context:
server config, virtual host
Status:
core
Compatibility:
LogLevel is only available in 1.3 or later.
LogLevel adjusts the verbosity of the messages recorded in the error logs (see ErrorLog directive). The following levels are available, in
order of decreasing significance:
| Level |
Description |
Example |
emerg |
Emergencies - system is unusable. |
"Child cannot open lock file. Exiting" |
alert |
Action must be taken immediately. |
"getpwuid: couldn't determine user name from uid" |
crit |
Critical Conditions. |
"socket: Failed to get a socket, exiting child" |
error |
Error conditions. |
"Premature end of script headers" |
warn |
Warning conditions. |
"child process 1234 did not exit, sending another SIGHUP" |
notice |
Normal but significant condition. |
"httpd: caught SIGBUS, attempting to dump core in ..." |
info |
Informational. |
"Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..." |
debug |
Debug-level messages |
"Opening config file ..." |
When a particular level is specified, messages from all other levels of higher significance
will be reported as well. E.g., when LogLevel info is specified, then
messages with log levels of notice and warn will also be posted.
Using a level of at least crit is recommended.
For example:
LogLevel notice
NOTE: When logging to a regular file messages of the level notice
cannot be suppressed and thus are always logged. However, this doesn't apply when logging is
done using syslog.
Syntax:
MaxClients number
Default:
MaxClients 256
Context:
server config
Status:
core
The MaxClients directive sets the limit on the number of simultaneous requests that can be
supported; not more than this number of child server processes will be created. To configure
more than 256 clients, you must edit the HARD_SERVER_LIMIT entry in httpd.h and recompile.
Any connection attempts over the MaxClients limit will normally be queued, up to a number
based on the ListenBacklog directive. Once a child process is
freed at the end of a different request, the connection will then be serviced.
Syntax:
MaxKeepAliveRequests number
Default:
MaxKeepAliveRequests 100
Context:
server config
Status:
core
Compatibility:
Only available in Apache 1.2 and later.
The MaxKeepAliveRequests directive limits the number of requests allowed per connection
when KeepAlive is on. If it is set to "0",
unlimited requests will be allowed. We recommend that this setting be kept to a high value for
maximum server performance. In Apache 1.1, this is controlled through an option to the
KeepAlive directive.
For example
MaxKeepAliveRequests 500
Syntax:
MaxRequestsPerChild number
Default:
MaxRequestsPerChild 0
Context:
server config
Status:
core
The MaxRequestsPerChild directive sets the limit on the number of requests that an
individual child server process will handle. After MaxRequestsPerChild requests, the child
process will die. If MaxRequestsPerChild is 0, then the process will never expire.
Setting MaxRequestsPerChild to a non-zero limit has two beneficial effects:
- it limits the amount of memory that process can consume by (accidental) memory leakage;
- by giving processes a finite lifetime, it helps reduce the number of processes when the
server load reduces.
However, on Win32, It is recommended that this be set to 0. If it is set to a non-zero
value, when the request count is reached, the child process exits, and is respawned, at which
time it re-reads the configuration files. This can lead to unexpected behavior if you have
modified a configuration file, but are not expecting the changes to be applied yet. See also ThreadsPerChild.
NOTE: For KeepAlive requests, only the first request is counted
towards this limit. In effect, it changes the behavior to limit the number of connections
per child.
Syntax:
MaxSpareServers number
Default:
MaxSpareServers 10
Context:
server config
Status:
core
The MaxSpareServers directive sets the desired maximum number of idle child server
processes. An idle process is one which is not handling a request. If there are more than
MaxSpareServers idle, then the parent process will kill off the excess processes.
Tuning of this parameter should only be necessary on very busy sites. Setting this
parameter to a large number is almost always a bad idea.
Note that this is the maximum number of spare servers, not the maximum total
number of client requests that can be handled at one time. If you wish to limit that number,
see the MaxClients directive.
This directive has no effect when used with the Apache Web server on a Microsoft Windows
platform.
See also MinSpareServers, StartServers,
and MaxClients.
Syntax:
MinSpareServers number
Default:
MinSpareServers 5
Context:
server config
Status:
core
The MinSpareServers directive sets the desired minimum number of idle child server
processes. An idle process is one which is not handling a request. If there are fewer than
MinSpareServers idle, then the parent process creates new children at a maximum rate of 1 per
second.
Tuning of this parameter should only be necessary on very busy sites. Setting this
parameter to a large number is almost always a bad idea.
Note that setting this directive to some value m ensures that you will always have
at least n + m httpd processes running when you have n active
client requests.
This directive has no effect on Microsoft Windows.
See also MaxSpareServers, StartServers,
and MaxClients.
|
