Configuring the Oracle HTTP Server

In the second article in a five-part series covering the Oracle HTTP Server (OHS), you will learn about server configuration directives, including access control directives and others. This article is excerpted from chapter five of the book Oracle 10g Application Server Exam Guide, written by Sam Alapati (McGraw-Hill, 2006; ISBN: 0072262710).

Basic Oracle HTTP Server Configuration Directives

There are several configuration directives that you can use to configure basic things such as the directories from which OHS will serve static Web documents or the directories for storing the error logs. You also have directives that help configure access control by specifying the server and port names.

When I discuss the OHS processing model subsequently in the chapter, I discuss several OHS processing-related directives, such as those that determine whether persistent browser-server connections should be maintained and for how long. Finally, in the last part of this chapter, I explain several OHS configuration directives that are applied under a limited scope instead of being applicable to the entire OHS server. I also explain some special OHS directives that limit or enable several OHS features in a later section in this chapter. In the following sections, I discuss three types of basic OHS configuration directives:

  1. File Location Specification directives
  2. Access Control directives
  3. Administration directives

Let’s start by discussing the simple OHS configuration directives, starting with directives that let you configure the location of various OHS server files.

File Location Specification Directives

There are several important directives that govern the location of various OHS server files. The following directives can be specified in the server configuration context.

ServerRoot    The ServerRoot directive by default specifies the main OHS or base directory for the OHS server installation, underneath which lie the subdirectories where the binaries, log files, configuration files, and other documents such as HTML files are located. Typically, the ServerRoot directive points to the $ORACLE_HOME /Apache directory. The directory specified by the ServerRoot directive usually contains the subdirectories bin, conf, htdocs, and logs. It’s important to remember that often, other configuration directives use ServerRoot as part of their relative path name.

  Example: ServerRoot /usr/local/ohs

PidFile   The PidFile directive lets you specify the location of the PID file. The PID file contains the Process ID of the OHS server. If you don’t begin the
filename with a slash (/), the path is relative to the ServerRoot directory.

ScoreBoardFile   The ScoreBoardFile directive is an optional directive required only under some systems; it helps to set the location of a file used by the main control server process to communicate with the child processes. You can check for the presence of the ScoreBoardFile on your system by seeing whether an active OHS server has created this file. Usually, only Windows-based OHS implementations will have the ScoreBoardFile.

OHS uses a scoreboard to record communications between the parent and child processes. Some architectures may be able to maintain this "scoreboard" in memory, but some others actually require a physical file to do so. If you use this directive, OHS will create a file on disk to record the communication details. Here’s how you use the ScoreBoardFile directive:

  ScoreBoardFile /var/run/apache_status

CoreDumpDirectory   The CoreDumpDirectory is found only in UNIX systems and is the directory location where the OHS server will try to switch before dumping core dumps. By default, the CoreDumpDirectory is set to the same value as the ServerRoot directory. However, you must use the CoreDumpDirectory directive to specify a more secure location, because you don’t

exam watch:  The OHS recognizes changes to the main configuration files only when you start or restart the server.

want the server, running as just any user, to be able to write to the all-important ServerRoot directory, which holds critical OHS binaries and configuration files in its various subdirectories.

DocumentRoot    This directory is where the HTTP Server stores and serves files from, and the default location is the htdocs directory, whish is relative to the ServerRoot directory. The directory specified by DocumentRoot is the main document visible to a Web browser. This directory location allows public access to all pages, so you mustn’t keep sensitive information here.

Unless you use a directive such as Alias, the HTTP Server will append the requested URL’s path to the document root to make the complete path to the document. Here’s a simple example that illustrates this point:

  documentRoot /usr/web

In the preceding example, when a user accesses html, the user will be referred to /usr/web/index.html.

Note that you must specify DocumentRoot without a trailing slash.

ErrorLog    The ErrorLog directive sets the name of the HTTP Server log file, and by default it is logs/error_log. Note that this path is relative to the ServerRoot

exam watch:  By default, the error log path name is relative to the ServerRoot directory.

directory. Thus, if the ServerRoot directory is specified as /usr/web/ohs, then the error log files will be located in the /usr/web/ohs/logs directory. You can also specify an alternative pathname by explicitly providing the entire pathname of the alternative directory. The two important OHS log files are the access log and the error log.

{mospagebreak title=Access Control Directives}

There are several important directives that relate to access control. These directives set the server and server administrator options, and they can be set for the main OHS server or a virtual host. Access control directives are useful when you want to limit the IP addresses or ports the OHS server will listen to, for example. Let’s discuss the important access control-related OHS configuration directives, which are the Listen, UseCanonicalName, ServerName, and Port directives.

Listen   The Listen directive tells the OHS server which port and IP address combinations it should listen to for client connection requests. The syntax for the Listen directive is as follows:

  Listen [IP-address:]portnumber

As you can see, you can specify both the IP address and the port number as arguments to the Listen directive. However, the IP address is only an optional argument. If you specify only a certain port number, the OHS server will listen to all requests from all IP addresses on that port. If you specify the optional port number as well as the mandatory port number arguments, the OHS server will listen to requests only from the port number and IP address combination. Here’s an example:


exam watch:  By default, the OHS Server listens to every IP address, if you just specify the port number for the Listen directive specification.

The OHS server will listen to requests only from the IP address, on port 80. If you specify multiple Listen directives with various IP and port number combinations, OHS will accept connection requests from all the specified combinations of IP addresses and ports. Note that if you leave out the IP address, OHS will honor requests from all IP addresses, as long as they come through the
specified port.

UseCanonicalName   On occasion, the OHS server needs to construct self-referential URLs–that is, URLs that refer back to the same server. When redirecting a URL to the same server (i.e., when the OHS Server has to construct a self-referential URL), it has two choices regarding the host name and port. The first option is to use the host name and port specified by users in the HTTP 1.1 header. The other way is to use the host name and port numbers specified by the ServerName and Port directives. You can choose the latter option by setting the UseCanonicalName setting to ON, which is the default setting for this directive. If you set the UseCanonicalName directive to ON, the Oracle HTTP Server will use the Server Name and Port directives to construct the canonical name for the server.

  Example: ServerName =
           Port = 9090
          Canonical Name =

Self referential URLs may be useful when you have an intranet server, where you use short names such as www. If a user types a short name such as http://www/test (without the trailing slash), OHS will redirect it by default ( UseCanonicalName is ON by default) to /, and the user may thus be forced to authenticate twice (if you have enabled authentication)–first to //www, and then to //www/test. If you set UseCanonicalName to OFF instead, OHS will redirect this self-referential URL to simply http://www/test/ .

ServerName   The ServerName directive specifies the host name and port that the server uses to identify itself when redirecting user URLs. IF you don’t specify the ServerName directive, the OHS server will try to perform a reverse lookup on the IP address to gather the host name information. If you omit the optional port argument for the ServerName directive, then OHS will use the port number specified in the incoming requests. It’s a good idea to always explicitly specify the hostname and port by using the ServerName directive. Here’s the syntax of the ServerName directive:

  ServerName fully-qualified-domain-name[:port]

As you can see, the fully qualified domain name is mandatory, and the port specification is optional, for the ServerName directive. Let’s say the name of the server hosting the OHS server is Let’s say the server also has a DNS alias named If your goal is for the server to be always identified as, you can do that by setting the following value for the ServerName directive:


Under a virtual hosting system, the ServerName directive inside the <VirtualHost> container specifies the host names that should be specified in the HTTP 1.1 headers to match the virtual host name.

The ServerName directive defines the host name for the SERVER_NAME variable used in the canonical server name for URL redirection requests.

Port    The Port directive sets the SERVER_PORT environment variable used in redirection requests. If you don’t set the Listen directive, the OHS Server accepts connections and redirects to the port number specified by the Port directive. That is, in the absence of the Listen directive, the Port directive specifies the default port for the Web server. If you do set the Listen directive, however, OHS uses the Port directive only for redirection; this is usually the IP and port on the Web cache that sits in front of the OHS. When you use the Listen directive, that directive will override any port value that’s been set by you, which will become the default port for redirected URLs or any other URLs generated by the Oracle HTTP Server. The port numbers OHS can use range from 0 to 65535, but all port numbers below 1024 are reserved for system use.

on the job:  You can start OHS only from the root account if you choose port number 80.

{mospagebreak title=Administration Directives}

The following four directives determine the Oracle HTTP Server privileges.

User   The User directive specifies the userid that the server will assume when answering requests. The user must have privileges to access common files and execute non httpd request type code.

Group   Use the Group directive to specify the operating system group under which the HTTP Server will handle requests. You must create a new group for running the HTTP Server.

on the job:   The User and Group directives are available only for OHS Servers running on UNIX operating systems. They aren’t available on Windows operating systems.

ServerAdmin   The ServerAdmin directive creates an email address to be included in all error messages to the clients. Ideally, you should create a separate email address solely for this purpose.

ServerTokens    The ServerTokens directive specifies the amount of OHS Server details that should be revealed to the clients as part of the error messages. You can use the following four settings:

  • Prod is the preferred setting and outputs only the server name.
  • The min setting includes the server name and version.
  • The os setting shows server name, the version, and the operating system.
  • The full setting, which is the default, outputs server name, version, operating system, and compiled modules. Obviously, this default setting could be dangerous, as it reveals quite a bit of information about your Web server.

Note that both the ServerAdmin and ServerTokens directives determine the information the OHS server will present when it generates documents such as error messages. The ServerTokens directive also sets the value of the OHS HTTP response header field.

The directives inside the .htaccess file apply to the directory in which the file is located, as well as to all subdirectories that are underneath that directory. You can control the directives that can be placed in the .htaccess files by using the AllowOverride directive.

The .htaccess Files

Remember that the configuration directives placed in the httpd.conf file are read only upon starting the Apache Web server. Thus, there is no way you can make dynamic configuration changes by modifying the httpd.conf file. However, you can use a special file called the .htaccess file to make dynamic changes to the Web server. The configuration directives within the .htaccess file are read each time a request is made to the Web server, not each time it’s started.

The directives in an .htaccess file apply to the directory in which you place the file and to all subdirectories underneath it. Using .htaccess files, you can make
configuration changes solely on a per-directory basis instead of making server-wide changes. The syntax of the .htaccess files is similar to that of the main OHS configuration file, httpd.conf . The httpd.conf file is read-only when you start the OHS Server. Unlike the httpd.conf file, .htaccess files are read on every access to the HTTP server and the directives placed in the .htaccess files come into immediate effect, without a need for bouncing the server. You can also refer to the .htaccess files as distributed configuration files, because they enable you to make per-directory
configuration changes rather than server-wide
configuration changes.

Note that you can change the default name .htaccess by using the configuration directive AccessFileName. Here’s an example that shows how you can use the AccessFileName directive to change the default .htaccess filename to the default file name

  AccessFileName config_dir

You can also limit the directives that are permitted in an .htaccess file by using the AllowOverride directive in the httpd.conf configuration file.

The .htaccess file’s main purpose is to enable you to make a configuration change on a per-directory basis instead of a per-server basis. If you place some
configuration directives in a text file named .htaccess
file and place it in a certain directory, those directives will apply to that directory and its subdirectories only. Note that you can include any directive you may place in an .htaccess file in the main configuration file, httpd.conf itself, by using the <Directory> container. You use .htaccess files mainly to allow users without root access to alter the Apache Server configuration, albeit on a limited basis.

Note that there are disadvantages to using the .htaccess file for configuring the Apache server. For one thing, your Web server will take a performance hit, because Apache must look in every directory for potential .htaccess files when you enable .htaccess
files by using the AllowOverride option (more on this directive later). For example, if you place an .htaccess
file in the /www/htdocs/example directory, Apache must look for the .htaccess file in each of these locations:


Each time a document is requested, the Apache server must load the .htaccess file as well, thus hurting its performance.

In addition to the performance implications, there are security issues when you allow users to use .htaccess files to configure the server. Basically, you are relinquishing some control over the Web server to the users. To avoid this, you may just put the directives in the <Directory> section of your main httpd.conf file and avoid the use of the .htaccess files altogether. For example, the following two are equivalent ways of specifying the AddType directive, the first using the .htaccess file and the second using the <Directory> container.

Using the .htaccess file:

  AddType text/example .exm

Using the <Directory> section in the httpd.conf file:

  <Directory /www/htdocs/example>
  AddType text/example .exm

Thus, from both the security point of view as well as the performance angle, .htaccess files are not a good choice for setting per-directory directives. You can use the directory container in the httpd.conf file itself, to set the per-directory scoped configuration directives. .htaccess files are mainly used to allow users limited privileges to modify certain OHS server configuration directives, without the involvement of the Web server administrator. In this sense, they do serve a valid purpose. However, when you allow users to specify OHS configuration directives, remember that you’re introducing potential security vulnerabilities into your system as well. Because the OHS server has to scan all the directories and subdirectories when you use . htaccess files, theres a potential performance hit.

{mospagebreak title=Managing Processes and Connections}

There are several server configuration-level directives you can use in the httpd.conf server configuration file to control the number of OHS processes and other runtime server-related issues. On a UNIX server, you use the following server-level directives to manage processes and connections:

  • StartServers   The StartServers directive determines the number of child server processes created with the parent control process. The default value for the StartServers directive is 5. Because the OHS server will dynamically adjust the number of child server processes depending on the load, you don’t have to worry about setting the value for this directive, in general.
  • MaxClients    The MaxClients directive determines the maximum number of simultaneous connections that will be handled by the OHS server. Any connection attempts over the MaxClients setting will be queued, and will be accepted once the existing connections start dropping off. The default value for the MaxClients directive is 150.
  • MaxRequestsPerChild   This directive lets you specify the number of requests each child process can handle before it dies. Each child process will handle a maximum of 30 requests during its lifetime before it automatically expires. If you set the MaxRequestsPerChild directive to a value of 0, the child processes will not die until you reboot the OHS server. Although this may seem like a tempting thing to do, remember that you increase the risk of running out of memory, say by a child process incurring a memory leak during its (eternal) lifetime. Also, when the OHS server load drops, it’s advisable to run with a smaller number of child processes than that required during the peak load times. By setting a positive value (the default is a positive value of 30), you guarantee that the child processes have a finite lifetime, thus matching the number of child processes with the OHS server load.
  • MaxSpareServers   This directive specifies the maximum number of unused child server processes that must be kept running. By default, the value for this directive is a maximum of ten server processes. If there are more idle servers than that specified by the MaxSpareServers directive, OHS will start killing idle child processes until it reaches the MaxSpareServers setting.
  • MinSpareServers    This directive specifies the minimum number of child servers that must be kept running, and the default value for this directive is 5. If there are fewer than five child server processes alive, new processes are created at an increasing rate on a per second basis, until the rate set by the MAX_SPAWN_ RATE parameter is reached. Default value for the MAX_SPAWN_RATE parameter is 32.

    You use the following directives in both the UNIX and the Windows systems: 
  • KeepAlive   This directive enables you to use a persistent connection, which improves the scalability of the Oracle HTTP Server. By default, the KeepAlive directive is set to ON, meaning persistent connections are enabled by default when you use OHS. Since HTTP connections are stateless, if you don’t set this parameter to ON, a browser will need to make separate connections for each request from the server. Thus, for a Web page that contains a half a dozen images calling for .gif files, a client Web browser is forced to open a total of seven connections–one for the page and six requests for the six image files. Making multiple connections to satisfy the client request as shown here will increase the latency due to the time it takes to establish all the connections. By letting the KeepAlive directive remain at its default ON setting, your Web server performance will be dramatically higher, because latency will drop due to the need for fewer connections. Of course, there is an inherent tradeoff in using the KeepAlive On setting, because this way your server will have the burden of managing more persistent connections than if you had set the KeepAlive directive OFF.

on the job:   You must keep the KeepAlive directive set to OFF if you’re using OracleAS Clusters.

  • KeepAliveTimeout   This directive determines the number of seconds the OHS Server waits for a connection request following the first connection, before terminating the connection.
  • MaxKeepAliveRequests    This directive determines the number of requests allowed per connection, when you set the KeepAlive directive to ON. Default value is 0, which means that there is no limit to the number of requests that are allowed. You must set MaxKeepAliveRequests at a high value to make OHS perform efficiently.
  • ThreadsPerChild   This directive controls the number of simultaneous requests for connections. It is applicable only to a Windows server.

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

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

chat sex hikayeleri Ensest hikaye