Configuring the Oracle HTTP Server - Administration Directives
(Page 3 of 4 )
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
config_dir:
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:
/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess
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
</Directory>
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.
Next: Managing Processes and Connections >>
More Oracle Articles
More By McGraw-Hill/Osborne
|
 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). Check it out today at your favorite bookstore. Buy this book now.
|
|
