当前位置:Linux教程 - Apache - Apache Reference Manual (7)

Apache Reference Manual (7)

<Location> directive
Syntax: <Location 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 behaviour 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


--------------------------------------------------------------------------------

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

LockFile directive
Syntax: LockFile filename
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.




--------------------------------------------------------------------------------

LogLevel directive
Syntax: LogLevel level
Default: LogLevel error
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.



--------------------------------------------------------------------------------

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


--------------------------------------------------------------------------------

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


------------------------------