Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









Container or Block Directives

Oracle Application Server Tips by Burleson Consulting

Container or Block Directives change the configuration within the area defined by the container.  They use the familiar HTML notation, with some restrictions.  Directives must be on their own line.  Container Directives have limited scope and if included directives are outside the scope of the container they will be ignored.  The code sample below demonstrates the basic structure of a Container Directive.

<ContainerType objects>
   list of directives

<Directory />
    Options All
    AllowOverride All

The example container is a Directory container for our DocumentRoot directory.  Before we go into detail, let?s discuss the different types of Container Directives and their function.

Directory Container Directives

Directory Container Directives apply only to the named directory and all subdirectories under the named directory.  For this reason, an administrator normally starts by defining a Directory Container for the root directory to setup default directives for all directories that are not explicitly defined.  For example:

<Directory />
    Options FollowSymLinks MultiViews
    AllowOverride None

One alternative to control access to directories is to place a .htaccess file in each subdirectory containing specific directives.  If the AllowOverride is not set to None, OHS will read the .htaccess file and override the directives in the httpd.conf file with the directives in the .htaccess file.  To preclude this, set AllowOverride to None.  Note that we have set AllowOverride to None in the container for the root directory.  This will not preclude us from specifying other directory containers in the httpd.conf file.

AllowOverride only applies to the .htaccess file.  The Options parameter can be set to None, All, a combination of Indexes, FollowSymLinks, ExecCGI, or MultiViews.

None is self-explanatory, as is All, except that All does not include MultiViews.  If you use MultiViews, then you can?t use All and must list each option. 

MultiViews is a nice capability that allows OHS to do an implicit filename search and pick from the results.  For example, if you request the file pictures.html and it does not exist, OHS will look for pictures.html.* and may find pictures.html.en,, etc.  OHS will check the mapping for languages and select pictures.html.en, if that is the first language on the language mapping priority.  OHS could also find pictures.html.gz (a compressed file), and either uncompress the file before serving it, or serve it compressed and let the client uncompress it. ExecCGI allows the execution of CGI scripts located in that directory.  FollowSymLinks allows OHS to follow symbolic links to another directory or file.  This does not change the Directory directives it is executing under.  If the symbolic link leads to a directory with different defined options, OHS will continue to execute under the directives of the directory that it came from.  The SymLinksIfOwnerMatch option is the same, except that the target directory or file must be owned by the same user id as the link.  The Indexes option will cause OHS to return a formatted listing of the directory if it fails to find the Index.html file, otherwise it returns an error message.  The Includes option allows server-side includes.  If not set, the options directive defaults to all (excluding MultiViews). 

Normally, an administrator will define all options explicitly, however, for confusion?s sake you can add a ?+? or ??? to an option.  If the option uses a ?+?, as in option +Indexes, then the Indexes option is added to the options of the directories? parent options.  Likewise, the ?-?, as in ?FollowSymLinks, will exclude that option from the options of the directories? parent options.  For example:

<Directory /www/docs>
    Options FollowSymLinks MultiViews
    AllowOverride None
<Directory /www/docs/time>
    Options -FollowSymLinks +Indexes

The directory /www/docs/time has the Indexes and MultiViews options.

Now lets return to the httpd.conf file and look at how the directory containers are defined.  The first step is to define the directives for the root directory, since all other directories are subdirectories of root.  By defining the root directives, we establish default directives for any directories that are not explicitly defined. 

<Directory />
    Options FollowSymLinks MultiViews
    AllowOverride None

Next, the httpd.conf file defines directives for the DocumentRoot directory.

<Directory "/home/oracle/oraportal904/Apache/Apache/htdocs">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all

This container contains a couple of new clauses used to limit access to the directory.  Since the container can both limit and grant access, it uses the order clause to direct the order in which grants and limits are evaluated.  In this case, execute the Allow clause or clauses, then the Deny clauses.

Order Deny,Allow
Deny from all
Allow from

Here, we first deny access to all users, then allow access to those users from the domain.  If the order clause was ?Order Allow, Deny? the result would be to deny access to everyone, including those from  At this point, we should discuss the Limit and LimitExcept Containers.

Limit and LimitExcept Containers

The Limit and LimitExcept containers define directives on HTTP methods.  Limits defines directives on named HTTP methods, while LimitExcept defines directives on all HTTP methods, except those named.

Require valid-user

<LimitExcept POST GET>
Require valid-user

The first example limits the POST, PUT, and DELETE methods to a valid-user.  The second example limits all methods to a valid user, except for the POST and GET methods.  The Limit and LimitExcept Containers should rarely be used.

As we continue through the httpd.conf file, we find a block directive.

Block Directives

Block directives are used to test for an item during the processing of the configuration file.  The directives that they contain are only executed if the test returns true.  If the test returns false then the directives between the block start and end are ignored.  The two types of block directives are <IfModule> and <IfDefined>. 

<IfModule mod_userdir.c>
    UserDir public_html

<IfDefine ReverseProxy>
  LoadModule rewrite_module libexec/
  LoadModule proxy_module   libexec/

If module mod_userdir.c is loaded in the first example, then the variable UserDir is defined as public_html.  If the module is not loaded, then the block is skipped, and UserDir either remains with it?s current definition or is undefined.  In the second example, if ReverseProxy is defined, then load the directed module headers.

It is important to note that Block Directives can be nested and that they do not limit the scope of the contained directives, which execute within the scope of the container in which they were called, as well as globally. 

Files and FilesMatch Containers

The Files and FilesMatch Containers allow for file level access control.  The difference between the Files container and the FilesMatch container is that the FilesMatch container uses regular expressions to identify effected files.  The Files containers are placed after the Directories container in the httpd.conf file, however, they can also be nested inside a Directory container. The following Files Container is located in the httpd.conf file of the OHS.

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all

This Files container denies all access to any file that starts with .ht.  Since directories may contain a .htaccess file that contains access information, this Files container insures that no user can request that file.  If the Files container is nested inside a Directories container, then the scope of the Files container directives is limited to the scope of the Directories container.

The use of the ?~? character in the filename allows Files to use regular expressions.  Starting with Apache 1.3, it is preferred to use FilesMatch when regular expressions are needed.  Many directives have a *Match companion. It is preferred to use the *Match version when using regulare expressions rather than the ~ option.   Lastly, the Files and FilesMatch containers can be used in the .htaccess file.

Location Containers

The OHS httpd.conf file contains a number of Location containers spread through the file, so I will give a brief explanation here.  Location containers limit access by URL.  They are normally located after the Files section of the httpd.conf file.  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.

<Location /status>
    Order Deny,Allow
    Deny from all
    Allow from

Here, access to the /status path is limited only to those requests originating from  For more information on the Location Container, see the Apache documentation.


This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.

If you like Oracle tuning, you may enjoy the new book "Oracle Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational