Directives, Access, and More with the Oracle HTTP Server

In our fifth article of a five-part series that covers managing the Oracle HTTP Server (OHS), you will learn how to handle aliases, index directories, find out the status of the server, and more. It is excerpted from chapter five of the book Oracle 10g Application Server Exam Guide, written by Sam Alapati (McGraw-Hill, 2006; ISBN: 0072262710).

Using Special Configuration Directives

In addition to the many OHS configuration directives you have learned about so far, Oracle HTTP Server provides two special directives, Options and AllowOverride, which you can use to allow or disable several features of the Oracle HTTP Server.

Options

You use the Options directive to configure the server features available in a directory. In other words, you enable or disable specific HTTP server features with the Options directive. You thus can use the Options directive to control what programmers can and can’t do with a directory The syntax of the Options directives is as follows:

  Options [+|-]option [[+|-]option] …

If you set the Options directive to None, no extra features are enabled whatsoever.

All   The All option means that all options are allowed, and this is the default parameter for the Options directive. The only exceptions are the MultiViews directive, which isn’t allowed by default. Of course, any mutually exclusive directives such as Includes and IncludesNoexec won’t be allowed together.

ExecCGI   If you want CGI scripts to be allowed, you must set this parameter. The only exception is for directories defined with ScriptAlias.

FollowSymLinks    This parameter allows the HTTP Server to follow symbolic links for files or directories. However, this parameter doesn’t affect the contents of the Location container.

SymlinksIfOwnerMatch   This is a more limited version of the FollowSymLinks parameter; it allows the HTTP Server to follow symbolic links only if the target file (or directory) and the symbolic link are owned by the same user.

Includes   The Includes parameter controls the execution of server-side includes (SSI).

IncludesNOEXEC    The IncludesNOEXEC parameter allows server-side includes but won’t allow CGI script execution via the #exec and #include commands.

Indexes   This parameter will return a listing of the directory contents when a URL maps to a directory and there’s no index file associated with the DirectoryIndex directive.

MultiViews   The option will allow content-negotiated multiple views.

If multiple options are applicable to the same directory, the options aren’t merged. OHS will use the most specific options and ignore the rest. However, if you prefix all the options under the Options directive with a + or –  sign, OHS will merge the various options. The options you specify with the + sign will be added to the current options being used, and those you prefix with the –  sign will be removed from the currently operative options.

Here’s an example showing the use of the Options directive without the + and — symbols:

  <Directory /web/docs>
  Options Indexes FollowSymLinks 
  </Directory>
  <Directory /web/docs/test>
  Options Includes
  </Directory>

As you can see, only the Includes option will be used for the /web/docs/test directory. This means that I’m replacing the set of options for the /web/docs/ directory (Indexes, FollowSymLinks) with the single Includes option, for the /web/docs/test directory. If instead, I want to add the Includes option to the existing option FollowSymLinks and not use the Indexes option, I can do so by using the + and –symbols, as shown here:

  <Directory /web/docs>
  Options Indexes FollowSymLinks
  </Directory>
  <Directory /web/docs/test>
  Options +Includes -Indexes
  </Directory>

AllowOverride

Whereas the Options directive lets you enable and disable features, the AllowOverride directive lets you exercise an even finer-grained control over several HTTP Server features. As you can recall, the per-directory configuration files, called .htaccess files,

exam watch:  The AllowOverride directive  applies only to Directory containers.

supplement the main OHS server configuration file, httpd.conf. The AllowOverride directive determines which of the directives in a directory .htaccess file can override the server configuration. The HTTP Server will consider any .htaccess file in a directory as though they were in a Directory container.

Directives in lower Directory containers will have preferences over directives in the higher directories. The default setting or the AllowOverride directive is ALL, which enables the overriding of all directives. The HTTP server will merge the directives in all .htaccess files at the same level. Here are the other options for the AllowOverride directive:

  • AuthConfig
  • FileInfo
  • Indexes
  • Limit
  • Options
  • None

Here’s an example showing how to use the AllowOverride directive:

AllowOverride AuthConfig Indexes

exam watch:  The None option for
the AllowOverride directive will cause
the .htaccess files to be completely
ignored by the HTTP Server. For security
and performance reasons, this is the
recommended setting for the Override
directive. When you set the directive to
ALL, any directive within the .htaccess
context is allowed in the .htaccess files.

{mospagebreak title=Directory Indexing}

As you have learned, Indexes is one of the parameters you can use with the Options directive. You use the Indexes option to tell the HTTP Server whether it should produce an HTML page when a directory is requested. You add indexes to the list of options in this way:

  Options +Indexes

You have several options when a user requests a directory rather than a file:

  • The HTTP Server can return a default file: You can use the DirectoryIndex directive, which follows, to specify the default file:

    DirectoryIndex index.html index.htm

    In the foregoing example, the server will first try to return the index.html and then the index.htm file.
  • An HTML page of the directory contents can be generated and sent back
  • A "permission denied" error can be issued
  • A "file not found" error can be issued, as shown here:

    DirectoryIndex index.html /cgi-bin/error404.cgi

If you enable Indexes and none of the resources specified with the DirectoryIndex directive are found, by default the HTTP Server will generate an index of the directory. To avoid this default behavior, you must specify a non-relative URL as the (last) option for the DirectoryIndex directive, as illustrated in the preceding example.

Directory Listings

You may not want all users to have access to backup files and files such as the .profile and the .cshrc files. To prevent all files from showing up in file listings, you use the IndexIgnore directive. Any files you specify as options for the IndexIgnore directive will not appear in file listings. Heres a simple example:

  IndexIgnore .??* *~ *# *.bak HEADER* README*

The following are the results of using the IndexIgnore directive in the above manner:

  • All backup, header, and readme files are not listed.
  • Any filename that starts with a dot and is longer than three characters is ignored.

on the job:  Once you eliminate a file from being listed, through the IndexIgnore directive, that file can no longer be reinstated as part of a file listing.

Response Handling

When the Oracle HTTP Server encounters an error while processing a user’s request, it first logs the error in the error_log file and then sends an error message to the client. Using the ErrorDocument directive, you can customize the Oracle HTTP Server’s response in the form of an HTML document.

When the Oracle HTTP Server encounters an error, it can do one of the following four things:

  • Send a simple hard coded message.
  • Send a custom message.
  • Redirect to a local URL-path.
  • Redirect to an external URL.

By default, the Oracle HTTP Server will choose option 1 when it encounters errors. Since this means that the user will get an ugly error message, you must choose one of the options and customize the response of the Web server to error conditions. You can use the ErrorDocument directive to configure one of the other three options. You can specify an HTTP error-response code and a URL or a message when you use the ErrorDocument directive. Local URL paths start with a slash (/) relative to the DocumentRoot, or a full URL, if it’s external. The HTTP Server can also provide a message to be displayed by the browser. Here are some examples:

  ErrorDocument 500 http://foo.example.com/cgi-bin/tester 
  ErrorDocument 404 /cgi-bin/bad_urls.pl
  ErrorDocument 401 /subscription_info.html
  ErrorDocument 403 "Sorry can’t allow you access today"

You can also use the special value default, to specify the simple hardcode message by the HTTP Server, as shown here. Doing this will ensure that the simple hardcoded message will be restored, instead of inheriting an existing ErrorDocument value.

  ErrorDocument 404 /cgi-bin/bad_urls.pl
  <Directory /web/docs>
  ErrorDocument 404 default
  </Directory>

Expires Header

The Expires header in a document determines when a document becomes out of date. Using the ExpireActive directive, you can turn the sending of the Expires header on and off.

on the job:  Themod_expires module controls the Expires header.

{mospagebreak title=Using Aliases}

The Alias directive maps URLs to file system locations. The file system location can be a file or a directory, as indicated in the syntax for the Alias directive shown here:

  Alias URL-path file-path|directory-path

Using the Alias directive, you can store documents in directories other than the directory specified by the DocumentRoot directive. Here’s an example:

Alias /image /ftp/test/image

In the preceding example, a client request for the http://myserver/image/foo.gif file will return the file /ftp/test/image/foo.gif. Here’s another example, showing how you can create an entire virtual path structure to hide the underlying file system:

  Alias /pub /public
  Alias /pub/users /home/users/pub 
  Alias
/pub/users/john /support/staff/john/public

on the job:  If you include a trailing / on the url-path, the server will require a trailing / in order to expand the alias.

You can also specify additional <Directory> sections, which cover the destination of aliases. Because OHS checks aliases before it checks the <Directory> containers, only the destinations of the aliases are affected. Heres an example:

  Alias /image /ftp/test/image
  <Directory /ftp/test/image>
  Order allow,deny
  Allow from all
  </Directory>

If you’ve already specified access control for the /ftp/test /image directory, using the Alias directive as shown here will modify the access settings for that directory and its subdirectories.

If you’re creating aliases to directories outside the directory specified by DocumentRoot, you must ensure that the server has access to the target directory.

AliasMatch

The AliasMatch directive works similar to the way the Alias directive does, but it uses standard regular expressions instead of simple prefix matching. If the regular expression matches the URL-path, any parenthesized matches are substituted into the given string and used as a filename. Here’s an example, which shows how the AliasMatch directive activates the /icons directory:

  AliasMatch ^/icons(.*) /usr/local/apache/icons$1

A reference to the icons directory in a URL will be redirected to the real icons directory.

ScriptAlias

The ScriptAlias directive works like the Alias directive, with the difference that it marks the target directory as containing CGI scripts to be executed by the mod_cgi’s cgi-script handler. URLs will be mapped to scripts beginning with the second

exam watch: Using ScriptAlias is the
only way to enable the execution of CGI
scripts without specifying the ExecCGI
option, and therefore is useful if you
have a policy of not permitting users to
execute their own CGI scripts.

 

argument, which refers to a full path name in the local file system. Heres an example:

  ScriptAlias /cgi-bin/ /web/cgi-bin/

In the foregoing example, a request for http://myserver/cgi-bin/foo would result in the HTTP server’s running the script /web/cgi-bin/foo.

{mospagebreak title=Access Restriction Directives}

Often times, you may find it necessary to control access to the server, based on certain characteristics of a client request. For example, you may wish to restrict requests based on client’s host name, IP address, or some other characteristic. You can use special access control directives in the <Directory>, <Files>, and <Location> containers, as well as in the .htaccess files, to restrict access to particular parts of the OHS server.

There are three types of access control directives you can use to restrict access by users. You use the Allow and Deny directives to determine which users are allowed or denied access to the server. A third access directive, Order, determines the default access state, as well as determining the way the Allow and Deny directives will interact. Note that the access restrictions apply to all access methods such as GET, POST, and PUT. However, by enclosing directives inside the <Limit> directive, you can restrict requests using only certain access methods.

The all-important access directives are examined in some detail in the following subsections.

Allow

Using the Allow directive, you can control which host can access an area of the server. You can control access by specifying host names or IP addresses or by some other client characteristics captured through the environmental variables.

You always use the keyword from when using the Allow directive (Allow from . . . ), if you choose to specify the value for the Allow directive, as shown here:

  Allow from all

All hosts are allowed access to your server, unless you restrict them by configuring them with the Deny and Order directives, which are discussed in the following subsections. Here’s an example showing how to use the Allow directive. By using this directive, you are allowing access from the host with the IP number 10.1.2.3.

  Allow from 10.1.2.3

Deny

The Deny directive restricts access to the server based on the host name, the IP address, or environment variables. The syntax and the arguments for the Deny directive are similar to those of the Allow directive. Here’s an example:

  Deny from 10.1.2.3

The Deny directive here refuses client requests to the OHS server from the IP address 10.1.2.3.

Order

It’s possible to use both Allow and Deny directives together on a Web server. To avoid a confiict between these two directives, you must have some way to specify the precedence rules for applying the Allow and Deny directives. Using the Order directive, you control the default access state for the Web server, as well as the order in which the server will apply the Allow and Deny directives.

The Order directive could take the following values (both values are part of the Order specification):

  • Deny, Allow   OHS will evaluate the Deny directives before the Allow directives. By default, access is allowed to all clients. A client who doesn’t match a Deny directive or matches an Allow directive is allowed access to OHS.
  • Allow, Deny   OHS evaluates the Allow directives before the Deny directives. By default, access is denied to all clients. A client who doesn’t match an Allow directive or matches a Deny directive will be denied access by OHS.

In the following example, only the hosts in the oracle.org domain are allowed access, and all the other hosts are denied access.

  Order Deny,Allow
  Deny from all
  Allow from oracle.org

In this example, all hosts in the oracle.org domain are allowed access, except for the hosts in the test.oracle.org subdomain. The latter group is denied access by the Deny directive (Deny from test.oracle.org). All hosts that aren’t in the oracle.org domain are denied access, because by default, the Allow, Deny order means that access is denied to the OHS server.

  Order Allow,Deny
  Allow from oracle.org
  Deny from test.oracle.org

In this example, I use the same domains and sub domains as before for the Allow and Deny directives, but reverse the order to Deny, Allow.

  Order Deny,Allow
  Allow from oracle.org
  Deny from test.oracle.org

Now, all hosts are allowed access to the OHS server, because although the Allow and Deny directives are listed in that order, Deny will be evaluated first. OHS evaluates the Allow directive last, and this will override the Deny directive, which specifies that requests from the test.oracle.org subdomain will be denied. Not only will all hosts in the oracle.org domain be allowed access (inasmuch as the Allow directive specifies that), but all hosts from any domain are allowed access, because the default access state of Deny< Allow is to allow access.

{mospagebreak title=Obtaining the HTTP Server Status}

You can use the Status module, which lets you check OHS Server performance statistics though an HTML page. You use the Location directive, to specify whether you want to allow the generation of server status reports from a specific IP address (or symbolic machine name). In the Location directive, for the Allow from attribute, you must provide the IP address/machine name, as shown in the following example:

  <Location /server-status>
     SetHandler server-status
     Order deny,allow
     Deny from all
     Allow from ntl-alapatisam.netbsa.org
  </Location>


Figure 5-4.  The HTTP Server Status Page

The Location directive shown in the foregoing example allows server status reports only for browsers from the ntl-alapatisam.netbsa.org domain.

Once you set up the Location directive as shown here, you can access the server status reports using the following URL:

  http://servername:port/server-status

Figure 5-4 shows the server status page for the HTTP Server.

TWO-MINUTE DRILL

Introduction to the Oracle HTTP Server

  1. The Oracle HTTP Server (OHS) is based on the Apache 1.3 Web Server.
  2. The following three OHS components run within a single OHP process: the HTTP listener, the modules, and the Perl Interpreter.
  3. OHS modules extend the functionality of the OHS server.
  4. There are two types of OHS modules: standard Apache modules and OracleAS specific modules.
  5. In a UNIX/Linux system, the main http process runs as the root user and the other processes under a less-privileged user.
  6. On Windows server, there’s a multithreaded implementation of the HTTP Server processes, with a single control process and a child process.
  7. The httpd.pid file contains the process ID of the parent server process.
  8. You must not keep sensitive information in the htdocs directory.
  9. The main configuration file of the Oracle HTTP Server is called the httpd. conf file.
  10. The recommended way to modify the OHS configuration is through editing the httpd.conf file through the Application Server Control Console.
  11. The httpd.conf file is a server configuration file, read only when you start or restart the Oracle HTTP Server.
  12. The httpd.conf file contains directives, which are configuration instructions as well as pointers to other configuration files.
  13. The "other" configuration files include the mod_oc4j.conf, mime.types, and the oracle_apache_conf file.
  14. There are three types of directives: server-level, container, and per-directory directives.
  15. The default name of the per-directory configuration file is .htaccess.
  16. You control the directives that can be placed in the .htaccess file by using the AllowOverride directive.
  17. Directives are always applied in a hierarchical manner.
  18. If you set UseCanonicalName to ON, the HTTP Server will use the ServerName and Port directives to construct the canonical name for the server.
  19. If you don’t set the Listen directive, the Port directive specifies the default port.
  20. If you set the Listen directive, the Port directive is used only for redirection.

Managing the Oracle HTTP Server

  1. You use the opmnctl and dcmtl command-line utilities to manage the Oracle HTTP Server.
  2. You can edit the httpd.conf file from the Application Server Control Console.
  3. When you modify the httpd.conf file using the Application Server Control Console, the HTTP Server is bounced automatically.
  4. The error_log file contains OHS error messages, and you can change the name of this file with the ErrorLog directive.
  5. The access_log contains a detailed account of all HTTP Server access.
  6. If the error_log grows too big, you should reset the log file rather than try to remove it (or move it).
  7. By default, all HTTP log files are in the Common Log Format (CLF).

OHS Configuration Directives

  • You can classify directives into various classes, based on the following types of contexts: Server config, Virtual directory, Directory, and .htaccess.
  • Server Config context directives can’t be used in the <Directory> or <VirtualHost> containers or in the .htaccess files.
  • Directives in the . htaccess file are applied in the order in which they appear.
  • Global directives are applicable only outside of container directives.
  • You can use per-directory class directives anywhere.
  • Container directives limit the scope of a directive.
  • Containers can’t be included in another container, except the <VirtualHost> container.
  • Block directives specify the conditions under which a directive will take effect.
  • Virtual host directives take precedence over the main server directives, since virtual host directives are processed later.
  • Directory containers are processed from the shortest component to the longest.
  • Virtual hosting is the maintenance of multiple Web servers on a single machine.
  • You can define IP-based or name-based virtual hosts using the VirtualHost directive.
  • Under name-based hosting, there are multiple Web sites for each IP address.
  • Under IP-based virtual hosting, you’ll have a separate IP address for each Web site.
  • The NameVirtualHost directive is required when you configure name-based virtual hosts.
  • You use the Options directive to specify features that the HTTP Server will allow.
  • The default parameter for the Options directive is All, meaning that all options are allowed by default.
  • The AllowOverride directive determines which of the directives in a directory .htaccess file can override the server configuration.
  • You use the IndexIgnore directive to prevent all files in a directory from showing up in file listings.
  • The Alias directive lets you store documents in directories other than that specified by the DocumentRoot directive.
  • The AliasMatch directive works like the Alias directive but uses standard regular expressions instead of simple prefix matching.

Self Test

  1. You can change the name of the .htaccess file in a directory in your path, with the help of which of the following directives?

    A. AccessFileName

    B. ChangeAccessFile

    C. AccessNameFile

    D. AccessConfig 
  2. The AllowOverride directive is valid only in

    A. Server containers

    B. Virtual Hosts

    C. Directory containers

    D. File containers 
  3. The IndexIgnore directive

    A. Prevents users from finding backups of CGI scripts.

    B. Is not a good idea because users can find backups of CGI scripts.

    C. Helps list all available files.

    D. Keeps users from seeing any file listing at all. 
  4. The default name for the per-directory configuration file is

    A. .access

    B. .htaccess

    C. httpd.conf

    D. osso.conf 
  5. Which of the following can be used by specifying the AllowOverride directive?

    A. .htaccess files

    B. Directories

    C. Containers

    D. Server log files
  6. The Oracle HTTP Server processes all section groups in the order in which they appear in the
    configuration files, with the exception of

    A. The <Files> container

    B. The <FilesMatch> container

    C. The <Location> container

    D. The <Directory> container
  7. What’s the difference between the Alias and AliasMatch directives?

    A. AliasMatch uses standard regular expressions instead of simple prefix matching.

    B. AliasMatch uses simple prefix matching instead of standard regular expressions.

    C. AliasMatch allows the use of CGI scripts.

    D. Only AliasMatch allows you to create aliases outside of the directory specified by
    DocumentRoot.
  8. If you set UseCanonicalName directive to ON,

    A. The HTTP server will use only the Port directive.

    B. The HTTP server will use only the ServiceName directive.

    C. The HTTP server will use neither the Port nor the ServiceName directives.

    D. The HTTP server will use the Port and ServiceName directives.

Self Test Answers

  1. A is correct. If you want to call your .htaccess file by a different name, you can do so by using the AccessFileName directive.

    B and C are incorrect because they refer to nonexistent directives. D is incorrect because the AccessConfig directive doesn’t allow you to change the .htaccess filename.
  2. C is correct. The AllowOverride directive is valid only in the <Directory> containers.

    A, B, and D are incorrect because the AllowOverride directive can’t be used in those containers.
  3. A is correct because you use the IndexIgnore directive to keep users from accessing various files, including the backups of CGI scripts.

    B is incorrect because users can’t find backups of CGI scripts when you use the IndexIgnore directive. C is incorrect because the IndexIgnore directive helps you prevent all available files from being listed. D is incorrect because users can see all files that you don’t restrict with the IndexIgnore directive.
  4. B is correct because .htaccess is the default name for the per-directory configuration file.

    A is incorrect because .access is a made up filename. C and D are incorrect because they are configuration files for the HTTP Server and for the SSO Server.
  5. A is correct because you use the AllowOverride directive to control the contents of the .htaccess files.

    B, C, and D are incorrect because the AllowOverride directive isn’t meant to control the contents of those three entities.
  6. D is correct because in the case of the <Directory> container, the HTTP Server processes from the shortest directory to the longest, not in the order they appear in the configuration files.

    A, B, and C are incorrect because they are all processed in the order in which they appear in the configuration files.
  7. A is correct because the AliasMatch directive uses standard regular expressions instead of simple prefix matching for filenames. 

    B is incorrect because the AliasMatch directive uses regular expressions, not prefix matching. C is incorrect because AliasMatch has nothing to do with CGI scripts. D is incorrect because the AliasMatch doesn’t give you the right to create aliases outside the directory specified by the DocumentRoot directive. 
  8. D is correct because the HTTP Server will use both the Port and ServiceName directives when you set the UseCanonicalName directive to ON.

    A, B, and C are incorrect because the HTTP Server will use the values specified by both the Port and ServiceName directives.

Google+ Comments

Google+ Comments