Understanding Directives and More with the Oracle HTTP Server

Directory Context

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
configure the serving of both static and dynamic Web pages. You use configuration containers to modify the configuration of either particular physical locations in your file system, or particular locations in the Web space. The file system is the physical view of your disks as it appears to the operating system. The Web space, on the other hand, is how your site appears to the Web server and your clients. A path such as /dir may appear to a client as /usr/local/apache/htdocs/dir. Note that there may not be a one-to-one correspondence mapping between the Web space and the file system, because a dynamic Web page my not be present anywhere on the file system; instead, it may be generated with the help of database input, for example.

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
file system objects; the restrictions you specify can be circumvented because a file system location doesn't have a one-to-one correspondence with a Web space (URL) location.

<Directory>

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:

• <Directory /> operates on the whole file system.
  
• <Directory dir> refers only to absolute directories.
  
• <Directory/ home/*public_html> points to the public_html sub directory under any directory in the /home directory.
  
• You can't nest <Directory> containers inside each other.

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.

  <Directory />
  AllowOverride none
  </Directory>
  <Directory /home/>
  Allowoverride FileInfo
  </Directory>

OHS will process the directory directives in the following order:

1. AllowOverride None (this will disable all .htaccess files).
   
2. AllowOverride FileInfo (for the directory /home).
   
3. Look for and apply the FileInfo directives in / home/.htaccess, / home/www/. htaccess and / home/www/dir/.htaccess in that order.

on the job:   A directive that's valid in the directory context can be used inside <Directory>, <Location>, and <Files> containers in the server configuration files, subject to some restrictions.

<DirectoryMatch>

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:

 <DirectoryMatch “/web[1-9]/”>

<Files>

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 directives inside this section can be applied to all files matching the specified filename. Note the following:

1. <Files> sections are read after the <Directory> sections and the .htaccess files are read.
   
2. <Files> sections are read before the <Location> sections.
   
3. You can nest <Files> sections inside <Directory> sections.

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:

  <Files secret.html>
  Order allow,deny
  Deny from all
  </Files>

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:

  <Directory /var/web/dir1>
  <Files secret.html>
  Order allow,deny
  Deny from all
  </Files>
  </Directory>

The preceding combination means that the client will be denied access to all of the following files:

  /var/web/dir1/secret.html
  /var/web/dir1/subdir2/secret.html
  /var/web/dir1/subdir3/secret.html
  Any file named secret.html under the /var/web/dir1/ directory.

<FilesMatch>

This is the counterpart of the <DirectoryMatch> directive, which enables you to control access by
filename. Unlike the <Files> directive, it accepts regular expressions to match filenames.

  Syntax: <FilesMatch regex> ... </FilesMatch>
  Example: <FilesMatch "\.(gif|jpe?g|png)$">

<Limit>

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:

  <Limit POST>
  Require valid-user
  </Limit>

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.

<LimitExcept>

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:

  <LimitExcept POST>
  Require valid-user
  </LimitExcept>

exam watch:   You must always use the <LimitExcept> container in preference to <Limit> when restricting access, because a <LimitExcept> section provides complete protection against arbitrary and unknown access methods.

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.

<Location>

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:

1. <Directory>
   
2. .htaccess files
   
3. <Files>
   
4. <Location>

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.

exam watch:   If you use the <Location />
specification instead of just <Location>, your configuration directives in that container will applyto the entire server.

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.

<LocationMatch>

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
/finance/data string.

  <LocationMatch "/(hr|finance)/data">

.htaccess Context

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 .