Web servers can serve static and dynamic content, with most of the static content being stored on the server (corresponding to the default htdocs directory) and the dynamic content being generated on the spur of the moment, usually with the help of data from databases, for example. Containers help you
The <Directory> and <Files> directives are file system--related containers, which apply directives to selected parts of the file system on the server. The <Location> and <LocationMatch> containers aren't file system related. These are Web space containers and are put in to change the configuration for (usually dynamic) Web space content only.
You choose between the file system--based containers and the Web space--related containers (URL based), depending on where the objects are located. If the objects are loaded on your file system, use the <Directory> and <Files> (and <DirectoryMatch> and <FilesMatch) containers. If, instead of the file system, the objects are from elsewhere, as is the case when you generate dynamic Web pages from a database, use the <Location> and <LocationMatch> directives. Don't use the <Location> directive to limit access to
The <Directory> container can contain any directory context directives that apply to a named directory and its subdirectories. You may use a full path to a directory or a wildcard string (? imatches a single character and * matches any sequence of characters). Note the following:
Note that although you can't nest <Directory> containers inside each other, you may refer to nested directories in the document root.
If more than one directory section in the httpd.conf file matches the directory containing a document, Apache will apply the directives to all of the directory sections! Apache will apply the directives to the shortest directory first and then process through all the directory sections, ending with the longest directory match. In addition, any .htaccess file directives are applied as and when Apache finds them during this process.
Here's an example with multiple directory sections. In this example, the document test.html is in the / home/www/dir/ directory.
OHS will process the directory directives in the following order:
The DirectoryMatch directive is very similar to the Directory directive, with the difference that the Web server will accept regular expressions as arguments as shown in the following example, which matches directories starting with web and ending with a number from 1 to 0:
The <Files> directive is a container directive that matches files instead of directories and is similar to the <Directory> and <Location> directives. The <Files> directive is used to control access by filenames.
The filename argument can include a filename or a wild-card string, where ? matches any single character, and * matches any sequence of characters. You can also use extended regular expressions by adding the ~ character, as shown here:
<Files ~ "\.(gif|jpe?g|png)$">
Although the example shows the use of regular expressions to match filenames, the <FilesMatch> container is more appropriate in such cases.
In the following example, the directives within the <Files> and <Files> tags fall into the Files container, and they deny access to any file on your server that's named secret.html, no matter where it is on the server:
If you want to restrict access to only certain files within a directory, you can do so, by combining the <Files> and <Directory> containers. The following example shows this:
The preceding combination means that the client will be denied access to all of the following files:
This is the counterpart of the <DirectoryMatch> directive, which enables you to control access by
Syntax: <FilesMatch regex> ... </FilesMatch>
You use the <Limit> directive to restrict enclosed access control directives only to certain HTTP methods. By default, the Web server imposes access controls on all access methods, which is as it should be. Using the Limit directive, you can specify that only the listed HTTP methods fall under the purview of access controls. Any access method that isn't listed with the Limit directive won't have any access restrictions. Here's an example:
In the example, the access control restriction is imposed only where the POST method is used. All other methods are unrestricted or unprotected by these access control restrictions, which apply only to the POST method. Because the POST method lets users write to the server, the Limit directive requires the users to be authenticated as valid users.
You use the <LimitExcept> container to restrict access controls to all HTTP methods except the named methods. You use <LimitExcept> and </LimitExcept> to enclose a group of access control directives that will apply to any HTTP access method not listed inside the container. Thus, <LimitExcept> is the opposite of a <Limit> container, and you can use it to control both standard and nonstandard methods of access.
To prevent unknown access methods from evading access control restrictions, you should use the LimitExcept directive, which imposes access restrictions on all access methods except those specified in the LimitExcept directive, as shown here:
In this example, the access control directive enclosed in the LimitExcept directive (Require valid-user) applies to any HTTP access method except the POST access method.
You use the <Location> directive to specify that the directives in a block be applied only to the stated URLs and not a physical directory. Thus, the scope of the <Location> directives is limited by URLs and not physical directories. Note the order in which the various configuration sections (containers) are read upon starting the Oracle HTTP server:
Note that you can use regular expressions with the tilde character and wildcard directories with the <Location> directive.
Make sure you aren't using the <Location> container to control access to physical files or directories.
The <Directory> container controls access to the physical directories and files. If you use the <Location> container directives to control access to directories and files, your access controls could be easily sidestepped, because more than one URL can point to the same physical directory. You must use the <Location> container only to apply directives to content that doesn't live in your file system. If the content is actually located in the file system, you must use the <Directory> and <Files> containers to apply configuration directives to that content.
The URLs affected by the <Limit> directive may use wildcards, with ? matching a single character, and * matching any sequences of characters. You may also use regular expressions by adding the ~ character.
The <LocationMatch> directive is similar to the <Location> directive, but it lets you specify all types of regular expressions. Note that the <Location> directive lets you use only regular expressions with the tilde character and wildcard directories. In the following example, the <LocationMatch> directive matches the URLs contained in either the /hr/data or the
The .htaccess context applies to the .htaccess files in which you can place any directory to limit the directive to that directory only. Although a directive that is valid in the .htaccess context appears inside per-directory .htaccess files, it may or may not be processed, depending on the value of the OverRides directive .
blog comments powered by Disqus