Understanding Directives and More with the Oracle HTTP Server

In this fourth article in a five-part series, you’ll learn about block directives, virtual hosting, and more as they apply to the Oracle HTTP Server (OHS). It is excerpted from chapter five of the book Oracle 10g Application Server Exam Guide, written by Sam Alapati (McGraw-Hill, 2006; ISBN: 0072262710).

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 .

{mospagebreak title=What Are Block Directives?}

A block directive specifies conditions under which the directive will take effect. Thus, block directives aren’t scope based, but rather depend on whether the HTTP Server will take its directives into account when starting up, based on some condition holding true or false. You can use block directives to limit directives to work only on certain virtual hosts, directories, or files. There are two block directives: <IfModule> and <IfDefine>.

<IfModule>

You use the <IfModule> directive to mark those directives that are processed only if a certain module is present and is available in the OHS server. The stated module can be made available to OHS in either of two ways. It can be statically compiled into the OHS server, or you must make the module dynamically available by compiling the module and placing a LoadModule line in the httpd.conf file. The LoadModule line must appear before the <IfModule> directive.

Here’s an example using the <IfModule> directive that comes into effect only for the mod_user_dir.c module:

  <IfModule mod_userdir.c>
  UserDir public_html
  </IfModule>

Any URL whose path starts with a tilde would be mapped to UserDir, provided the mod_userdir.c module exists. Otherwise, the <IfModule> directive has no effect.

<IfDefine>

As you’re probably aware, in the Apache HyperText Transfer Protocol (HTTP) server program, the httpd daemon, when run as a standalone process, creates child processes or threads to handle user service requests. You normally don’t invoke the httpd daemon directly, but rather do so through using the apachectl utility on Apache systems, and the opmnctl utility in Oracle HTTP Server.

The directives within an <IfDefine> section are processed only if the enclosed test is evaluated to be true; otherwise, everything between the two
<IfDefine> section markers is ignored. The <IfDefine> directive uses the parameter-name argument given on the httpd command line via the -D parameter. Note that the <IfDefine>directive is thus used for conditionally processing directives, based on the evaluation of the conditions that prevail when the OHS server is started. OHS will apply the directives within the <IfDefine> directive only if the stated parameter
is defined on the httpd command line. In the following example, requests will be redirected to alternative sites only if you start the OHS server with the httpd
–DclosedForNow option.

  <IfDefine ClosedForNow>
  Redirect /
http://otherserver.example.com/
  </IfDefine>

By using the parameter-name specification, you can reverse the test and process directives within the <IfDefine> sections if the parameter name isn’t
defined.

Note that containers can’t include other containers, with the exception of the Limit directive and the Files container. You can include a Files container in a
Directory container. You can place any directive inside a Limit or LimitExcept container, as long as the Limit or LimitExcept directive is placed within a container that conforms to these directives. You can include all the other container types inside a <VirtualHost> container.

{mospagebreak title=Merging Containers and Contents}

The Oracle HTTP Server merges multiple directives in a very particular order, with directories being searched from the top down, as shown here:

  1. Directories inside (non-regular expression) directory containers and .htaccess directives are processed simultaneously. The .htaccess directories, if they are allowed, will always override the Directory container directives.
  2. Next to be applied are the DirectoryMatch containers and the Directory containers.
  3. Files and FilesMatch container directives are merged simultaneously next.
  4. Location and LocationMatch directives are applied simultaneously last.

Each group is processed in the order it appears in the httpd.conf file, except for the <Directory> containers. The <Directory> containers are processed from the shortest directory component to the largest directory component. For example, OHS will process /usr/web/dir before it processes /usr/web/dir/sub_dir. If more than one <Directory> container refers to the same directory, they are processed in the order in which they appear in the httpd.conf file.

Directives inside the <VirtualHost> container are applied after the corresponding directives from the main server are applied. This allows virtual host configuration directives to override the main server configuration settings.

The following example shows how containers are merged, when all the containers are applied to a particular client request. The merging starts at 1 and ends at 5.

  <Location />
  5
  </Location>
  <Files f.html>
  4
  </Files>
  <VirtualHost *>
  <Directory /a/b>
  2
  </Directory>
  </VirtualHost>
  <DirectoryMatch "^.*b$">
  3
  </DirectoryMatch>
  <Directory /a/b>
  1
  </Directory>

The following example shows that although you placed some access restrictions, given that the <Location> container is evaluated last, your access restrictions specified in the <Directory> container don’t actually apply.

  <Location />
  Order deny,allow
  Allow from all
  </Location>
  # <Directory> section’s directive
  # will be ignored since <Location>
is processed after this
  <Directory />
  Order allow,deny
  Allow from all
  Deny from hacker.example.com
  </Directory>

exam watch:   Directives that share the same scope will be merged in the order they are found.

Note that the VirtualHost container directives are processed after the main server configuration directives. This allows the virtual host directives to take precedence over the main server directives.

The Oracle HTTP Server processes all section groups in the order in which they appear in the configuration files, with one exception. The Directory container (<Directory>) sections are processed from the shortest directory component to the longest. Here are some things to remember:

  1. Use the <Directory> or <Files> directives to match objects at the file system level.
  2. Use the <Location> directive to match URLs.
  3. The <Location> container is always processed last.

{mospagebreak title=Virtual Hosting}

Virtual hosting is the maintenance of multiple Web sites on a single machine. For example, you may run both www.mycompany1.com and www.mycompany2.com Web sites from the same server. You can define IP-based or name-based virtual hosts using the VirtualHost directive. IP-based virtual hosts have different IP addresses for each Web site. Name-based virtual hosts run multiple names on a single IP address.

You use the <VirtualHost> container to enclose a set of directives that apply only to a named virtual host. You may place any directive that can be used in a virtual host context in the virtual host container. When OHS receives a client request for a document that’s on a virtual host, OHS will use the configuration directives for that virtual host’s virtual host container. Using the <VirtualHost> container directive, you can specify the following alternative directives to the main HTTP server:

  1. ServerAdmin
  2. ServerName
  3. DocumentRoot
  4. ErrorLog
  5. CustomLog

Here’s how you use the <VirtualHost> directive to specify additional hosts:

<VirtualHost       www.myhost1.com> DocumentRoot   /usr/virtual/htdocs/info ServerName        www.myhost1.com ErrorLog     /usr/virtual/h1/logs/error_log </VirtualHost>
<VirtualHost     
www.myhost2.com> DocumentRoot    /usr/virtual/htdocs/finance ServerName        www.myhost2.com
ErrorLog     /usr/virtual/h2/logs/error_log </VirtualHost>

The foregoing example uses a name-based virtual hosting system. Here’s an example showing a virtual host that’s IP based:

<VirtualHost   172.14.12.14  205.123.33.199>
ServerName     
www.myhost.com
ServerAdmin    Webmaster@myhost.com DocumentRoot   /docs/myhost/www ErrorLog       /docs/myhost/logs/error_log TransferLog    /docs/myhost/logs/access_log </VirtualHost>

exam watch:  Name-based virtual hosting means that you’ll have multiple Web sites for each IP address, and IP-based virtual hosting means that you’ll have an address for each Web site.

IP-Based Virtual Hosts

You must provide a different IP address for each IP-based virtual host, either by setting up your machine within multiple physical network connections, or by using virtual interfaces called "ip aliases." You can run multiple httpd daemons to support the different IP-based virtual hosts, or you can continue to use the default setup of a single httpd daemon. In our examples in this section, the single httpd daemon mode is assumed.

You can configure multiple hosts on a single server, using a separate VirtualHost directive for each virtual host. You can’t use the following HTTP Server directives in a VirtualHost directive, because they can be used only in the server configuration context:

  • ServerType
  • StartServers
  • MaxSpareServers
  • MinSpareServers
  • MaxRequestsPerChild
  • BindAddress
  • Listen
  • PidFile
  • TypesConfig
  • ServerRoot
  • NameVirtualHost

Here’s an example showing how you use the <VirtualHost> container to set up different configuration values for the ServerAdmin, ServerName, DocumentRoot, ErrorLog, and TransferLog or CustomLog configuration directives for the two virtual hosts defined here:

  <VirtualHost 10.0.0.1>
  ServerName
www.newco.com
  ServerAdmin webmaster@mail.newco.com  
  DocumentRoot /groups/newco/www
  ServerName
www.newco.com  
  ErrorLog /groups/newco/logs/error_log
  TransferLog /groups/newco/logs/access_log
  </VirtualHost> 
  <VirtualHost 10.0.0.2>
  ServerName 
www.citygroup.org
  ServerAdmin webmaster@mail.citygroup.org
  DocumentRoot /groups/citigroup/www 
  ServerName
www.citigroup.org  
  ErrorLog
/groups/citigroup/logs/error_log  
  TransferLog
/groups/citigroup/logs/access_log
  </VirtualHost>

Name-Based Virtual Hosts

In an IP-based virtual hosting system, each virtual host will need a separate IP address, because the virtual host uses the IP address to determine which host to serve. This forces you to have multiple IP addresses, one for each virtual host you wish to set up. When you use name-based virtual hosting, the HTTP Server expects the client to supply the hostname as part of the HTTP header information. This way, several hosts can share a single IP address.

It’s very simple to configure name-based virtual hosting. All you need to do is to configure the DNS server to map host names to their correct IP addresses and then configure OHS so it can recognize the multiple host names. Name-based virtual hosting means you’ll need fewer hard-to-acquire IP addresses. Unless you have strong reasons for doing so, you should use name-based virtual hosting. Following are some of those reasons:

  1. If you’re supporting some obsolete clients, you may find that they aren’t compatible with name-based virtual hosting.
  2. You may not be able to use name-based virtual hosting with some SSL secure servers.
  3. There are some operating system and network bandwidth management techniques that can’t distinguish between hosts unless they are on distinct IP addresses.

You must use the NameVirtualHost directive to designate the IP address on the server that will accept requests for the name-based virtual hosts. If you want any or all IP addresses on the server to be used, you must provide * as the argument to the NameVirtualHost directive. Make sure that the IP address you specify is associated with a network interface on the server. You must provide a port argument (*:80, for example) if you intend to use multiple ports.

Once you do specify the NameVirtualHost directive, you must specify a <VirtualHost> block for each of the virtual hosts you wish to serve. You provide arguments to the <VirtualHost> directive that are similar to those you use for the NameVirtualHost directive. You need at least the following two directives inside each <VirtualHost> directive:

  • The ServerName directive to designate the host to be served
  • The DocumentRoot directive to indicate the directory where the host’s contents are stored

In the following example, originally you have the domain www.mydomain.com. You now wish to add the virtual host www.myotherdomain.com, pointing to the same IP address. Here’s how your httpd.conf file will look:

  NameVirtualHost *:80
  <VirtualHost *:80>
  ServerName  
www.mydomain.com
  ServerAlias mydomain.com *.mydomain.com 
  DocumentRoot /www/mydomain
  </VirtualHost> 
  <VirtualHost *:80>
  ServerName  
www.myotherdomain.com
  ServerAlias mydomain.com *.mydomain.com
  DocumentRoot /www/myotherdomain
  </VirtualHost>

exam watch:  You can also specify an IP address in place of the * in both the NameVirtualHost and <VirtualHost> directives. You may do this if you wish to run name-based virtual hosts on one IP
address and either IP-based or another set of name-based virtual hosts on another address.

The ServerAlias directive inside the first <VirtualHost> block, shown as follows, indicates that the name inside is an alternative name that clients can use to access the same Web site.

  ServerAlias domain.com *.com.

Once you specify the <VirtualHost> directive in the manner shown in the preceding example, all requests for hosts in the domain.com domain will be served by the virtual host www.domain.com You must make sure that you configure your DNS server to map the names to an actual IP address on your server.

on the job:  Any configuration directives set in the main server context (that is, outside the <VirtualHost> container) will be used only if they are not overridden by any
virtual host settings.

When a client connects to the Web address, the HTTP server will first check whether the client is the IP address specified by the NameVirtualHost directive. If so, the server will check for a matching IP address in one of the <VirtualHost> sections and look for a matching ServerName or ServerAlias for the requested host name. If it can’t find any matching host names, it uses the first listed virtual host that matches the IP address. In order to provide a special configuration for client requests that don’t match any of your virtual hosts, all you have to do is put that configuration in the first <VirtualHost> container in the httpd.conf file.

The first listed virtual host is the default virtual host. When an IP address matches the NameVirtualHost directive, the HTTP Server will not use the DocumentRoot for the main server.

Please check back next week for the conclusion of this article.

[gp-comments width="770" linklove="off" ]

antalya escort bayan antalya escort bayan Antalya escort diyarbakir escort