| Oracle® HTTP Server Administrator's G
uide 10g Release 1 (10.1) Part Number B12255-01 |
|
|
View PDF< /font> |
This chapter introduces you to the Oracle HTTP Server directory structure, an d configuration files, configuration file syntax, modules, and directives.
Topics discussed are:
Documentation from the Apache Softw are Foundation is referenced when applicable.
Oracle HTTP Serve
r is installed in the ORACLE_HOME/Apache directory on UNIX or ORACLE_HOMEmodplsql folder contains the subdirecto
ries necessary to configure and run PL/SQL applications.
The Apache directory
is located at the top level under the ORACLE_HOME. It contains subdirectories for configuring modules mod
_plsql. It also contains a subdirectory called Apache, which is the base directory of Oracle HTTP Server.
Oracle HTTP Server is configured by placing directives, which are basically instructions, into text configuration files. Most of the configuration files are locate d in:
Some of these files are read only once when the server starts or is relo aded, whereas some files are read every time a related file or directory is requested.
The configuration files which are read only once are called server-wide configuration files.
Oracle HTTP Serve r contains one directive for each line. The back-slash "\" can be used as the last character on a line to indicate that the directive continues onto the next line. There must be no other characters or white space between the back-slash and the end of the line.
< a name="1006706">Directives in the configuration files are case-insensitive, but arguments to directives are ofte n case-sensitive. Lines which begin with the character "#" are considered comments, and are ignored. Comments may not be included on a line after a configuration directive. Blank lines and white space occurring before a directive are ignored, so you may indent direc tives for clarity.
Oracle HTTP Server is a modular serv er. Modules extend the basic functionality of the Web server, and support integration between Oracle HTTP Server and other Oracle Dat abase components. Oracle HTTP Server includes Apache modules as well as Oracle HTTP Server modules.
You can add modules using the LoadModule directive. Following is an example of LoadModule usage.
p>
LoadModule status_module modules/mod_status.so
| See Al so: Chapter 7, "Oracle HTTP Server Modules" |
Table 2-1 classifies directives according to the context in which they can be used: global, p er-server, and per-directory.
|
Note: In Table 2-1, each class is a subset of the class preceding it. For example, directives from the per-directory class can also be used in the per-server and global contexts, and directives from the per-server c lass can be used in the global context. |
Directives placed in the main configuration files apply to the entire server. If you wish to change the configura tion for only a part of the server, you can scope your directives by placing them in specific sections.
< p class="BP">The following section discusses the following types of directives:Co ntainer directives specify the scope within which directives take effect. The following container directives are discussed in detail in subsequent sections:
It is used to enclose a group of directives that apply only to the named directory and subdirectorie
s of that directory. Any directory that is allowed in a directory context may be used. The directory is either the full path to a dir
ectory, or a wildcard string. In a wildcard string, ? matches any single character and * matches any sequences of characters. It is i
mportant to note that <Directory /> operated on the whole file system, where as <Directory Directory> containers cannot be nested inside each other,
but can refer to directories in the document root that are nested.
Directory>
with wildcards in the directory specification. The following two examples have the same result, matching directories starting with <
code>web and ending with a number from 1 to 9:
<Directory ~/web[1-9]/> <DirectoryMatch "/web[1-9]/">
The <Files file> and </Files> directives support access con
trol by filename. It is comparable to the <Directory> and <Location> directives. The directives given within this section can be applied to any object within
a base name (the last component of the filename) matching the specified file name. <Files> sections are processed
in the order that they appear in the configuration file, after the <Directory> sections, and .htaccess files are read, but before <Location> sections. Note that the <Files> directives can be neste
d inside <Directory> sections to restrict the portion of the file system to which they apply.
Provides access control by filename, just as the <Files> directive does. However, it accepts regular expression.
Limits the application of the directives within a block to those URLs specified, rather than to the phys
ical file location like the <Directory> directive. <Location>
; sections are processed in the order that they appear in the configuration file, after the <Directory> sections a
nd .htaccess files are read, and after the <Files> sections. <<
code>Location> accepts wildcard directories and regular expressions with the tilde character.
Functions in an identical manner to <Locatio
n> and you should use it for specifying regular expressions instead of the tilde form of <Location>
with wildcards in the location specification.
For example:
<LocationMatch "/(extra|special)/data">
matches t
he URLs that contained the /extra/data or /special/data sub string.
<Limit method> defines a block according to the HTTP method o
f the incoming request. The following example limits the application of the directives that follow scripts that use the specified met
hod:
<Limit POST PUT OPTIONS> order deny, allow deny from all allow from 127.0.0.192.168 </Limit> a>
Generally, <Limit> should not be used unless needed. It is useful
only for restricting directives to particular methods. <Limit> is frequently used with other containers, and it is
contained in any of them.
Restrict access controls to al l HTTP methods except the named ones.
Oracle HTTP Server
has the capabilities to serve many different Web sites simultaneously. Directives can also be scoped by placing them inside <VirtualHost> sections, so that they will only apply to requests for a particular Web site.
Virtual host refers to the practice of maintaining more than one server on one machine, as differentiated by their apparen
t hostname. For example, it is often desirable for companies sharing a Web server to have their own domain, and Web servers accessibl
e as, for example, www.oracle1.com and www.oracle2.com, without requiring you to know any extra path inform
ation.
Oracle HTTP Server supports both IP-based virtual hosts and name-based virtual hosts . The latter variant is sometimes also called host-based or non-IP virtual hosts.
Each virt
ual host can have its own name, IP address, and error and access logs. Within a <VirtualHost> container, you can s
et up a large number of individual servers run by a single invocation of the Oracle HTTP Server. With virtual hosting, you can specif
y a replacement set of the server-level configuration directives that define the main host, and are not allowed in any other containe
r.
Specify a condition which must be true in order for direc tives within to take effect.
<IfModule> and <IfDefine>
; are block directives rather than container directives because they do not limit the scope of the directives they contain. They defi
ne whether Oracle HTTP Server parses the directives inside the block into its configuration, and the directives are ignored once the
server is running.
Oracle HTTP Server enables for decen
tralized management of configuration through special files places inside the Web tree. The special files are usually called .ht
access, but can be specified in the AccessFileName directive. Directives placed in .htaccess files a
pply to the directory where you place the file, and all subdirectories. The .htaccess files follow the same syntax as th
e main configuration files. Since .htaccess files are read on every request, changes made in these files take immediate
effect.
The server administrator further controls what directives may be placed in .h
taccess files by configuring the AllowOverride directive in the main configuration files.
|
![]() Copyright © 2003 Oracle Corporation All Rights Reserved. |
|