Release 2 (9.0.2)
Part Number A92173-02
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle HTTP Server Administration Guide Release 2 (9.0.2) Part Number A92173-02 |
|
This chapter describes distributed authoring and versioning concepts, and explains how to configure and use mod_oradav. mod_oradav enables you to use OraDAV to access content in an Oracle database from a Web browser or a WebDAV client. It includes the following major sections:
The term OraDAV refers to the capabilities available through the mod_oradav module. mod_oradav is an extended implementation of mod_dav, which is an implementation of the WebDAV specification. This section explains these concepts.
WebDAV is a protocol extension to HTTP 1.1 that supports distributed authoring and versioning. With WebDAV, the Internet becomes a transparent read and write medium, where content can be checked out, edited, and checked in to a URL address.
WebDAV enables collaboration among authors building Web sites. WebDAV also serves as universal read and write access protocol to arbitrary hierarchies of content (not necessarily Web sites). With WebDAV, you can save content to a URL provided by an Internet service provider (ISP) and then be able to access and optionally change that content from various devices.
WebDAV was initiated as an IETF standard. The first phase of WebDAV is specified in RFC 2518, which provides the basic primitives for managing hierarchies of information, locking, reading, writing, and querying properties of a WebDAV document. Subsequent work on WebDAV is ongoing and is focusing on completing issues relating to content management over the Web. This includes WebDAV authentication and authorization (access controls), versioning, bindings, ordered collections, and querying (DAV Advanced Searching and Locating).
Microsoft Web folders is a WebDAV client in Windows 2000 and on NT (using Internet Explorer 5.0). Windows 2000 applications and the IIS server support WebDAV, meaning that you can start a Microsoft Office application and specify a URL, edit the content, and save it back to the URL from which it was retrieved. WebDAV also has Java Clients (such as DAV Explorer), open source tools (such as Cadaver and Sitecopy), and Apple GUI tools (such as Goliath).
mod_dav is the Apache Software Foundation's native implementation of the WebDAV specification. Originally, mod_dav was a third-party Apache module; however, as of Apache 2.0, mod_dav is included.
mod_oradav is the Oracle module (an OCI application written in C) that is an extended implementation of mod_dav, and is integrated with the Oracle HTTP Server. mod_oradav performs read/write activity to local files and to Oracle databases. The Oracle databases must have an OraDAV driver (a stored procedure package) that mod_oradav calls to map WebDAV activity to database activity. Essentially, mod_oradav enables mod_dav to connect to an Oracle database, read and write content, and query and lock documents in various schemas.
You can configure mod_oradav to an Oracle database using standard Oracle HTTP Server directives. mod_oradav can immediately leverage other module code (such as mime_magic) in order to perform content management tasks. Most WebDAV processing activity involves streaming content to and from a content provider; and mod_oradav uses OCI streaming logic directly within the Oracle HTTP Server.
OraDAV refers to the whole set of capabilities that are available through mod_oradav to Oracle9iAS users. Some OraDAV-specific terms include:
The OraDAV interMedia driver is included with the interMedia Clipboard, which you can download from the Oracle Technology Network (http://otn.oracle.com) and install. This driver lets you use third-party tools to access files and database content; for example, Dreamweaver can use WebDAV as the protocol for transferring files between a local folder on your system to the remote site where your Web site is published.
OraDAV fits into an architecture in which mod_oradav, within the Oracle HTTP Server, provides access to content in one or more schemas in one or more Oracle databases.
A simple form of the architecture is illustrated in Figure 7-1.
Figure 7-1 shows a WebDAV client, such as Microsoft Web folders, passing HTTP requests to the Oracle HTTP Server. If the request is for content stored in the file system (not in an Oracle database), mod_oradav handles the access. If the request is for content stored in an Oracle database, the OraDAV API handles the access.
The OraDAV API provides capabilities that are equivalent to using mod_oradav running with a file system. The following HTTP methods are supported by the OraDAV API:
The OraDAV API supports shared and exclusive locking, retrieving basic DAV properties, and defining and retrieving server-defined live properties or client-defined dead properties. Set-based operations such as COPY, MOVE, DELETE can be done completely by a single call to an OraDAV driver.
The primary direct users of OraDAV are Oracle HTTP Server administrators and Oracle DBAs. "End users" interact only indirectly with OraDAV through Web browsers or WebDAV client tools; they usually are not aware that they are using WebDAV technology and do not know or care about the details of the WebDAV implementation on the server.
OraDAV administration involves tasks for a webmaster and for a DBA:
httpd.conf file to direct URL traffic to an OraDAV driver.
OraDAV usage can involve any combination of the following activities:
Configuration of OraDAV is mainly done through parameters in the httpd.conf file, which is used by an Oracle HTTP Server instance when it is initializing. Some configuration parameters are required for all OraDAV drivers, and others are driver-specific.
When Oracle9iAS is installed, all required OraDAV parameters are set with values that are designed to enable Oracle database content to be accessed through a Web browser or WebDAV client. If necessary, you can later modify the values for required parameters and specify values for optional parameters if the default values do not meet your needs. The parameters used in httpd.conf to support OraDAV configuration start with DAV and DAVParam. These parameters are specified within a <Location> directive, and they provide:
The DAV parameter indicates that a URL location is DAV-enabled. The DAV keyword is followed by a single value: On (indicating that mod_oradav is to use the local file system for content) or Oracle (indicating that mod_oradav is to use OraDAV for all content).
DAVParam parameters are used to specify name-value pairs. The required pairs are those that enable the Oracle HTTP Server to connect to an Oracle database. These include the names OraService, OraUser, and OraPassword.
Example 7-1 shows a configuration for accessing files on the local system. It specifies that the directory myfiles under the Web server documents directory (htdocs by default) is to be DAV-enabled, along with all directories under myfiles in the hierarchy. (Note that there must not be any symlinks defined on myfiles or any directory under it in the hierarchy.)
<Location /myfiles> DAV On </Location>
Example 7-2 shows a configuration for accessing content through an Oracle9iAS portal. After Portal has been installed in iAS, the Oracle HTTP Server configuration file should be populated with a <Location> directive which points to the Portal schema. In this example, the location /portal will be OraDAV-enabled and will (once populated with the correct values) connect to the Portal schema so that users can use WebDAV clients to access Portal data.
<Location /portal> DAV Oracle DAVParam ORACONNECT dbhost:dbport:dbsid DAVParam ORAUSER portal_schema DAVParam ORAPASSWORD portal_schema_password DAVParam ORAPACKAGENAME portal_schema.wwdav_api_driver </Location>
Each OraDAV driver can use the DAVParam mechanism to create its own driver-specific settings. All DAVParam name-value pairs are passed to the OraDAV driver.
In addition to the OraDAV parameters, you should consider whether to specify certain DAV parameters, such as DAVDepthInfinity. For information about these DAV parameters, see "DAV Parameter Information".
Table 7-1 lists each OraDAV parameter, whether it is required or optional, and its default value. The ORAGetSource parameter applies only to file system access; the other parameters apply only to Portal driver and other (non-file system) access.
| Name | Required? | Default Value |
|---|---|---|
|
RequiredFootref 1 |
(none) |
|
|
RequiredFoot 1 |
(none) |
|
|
Required |
(none) |
|
|
Required |
(none) |
|
|
Optional |
ORDSYS.DAV_API_DRIVER |
|
|
Optional |
0 (seconds) |
|
|
Optional |
FALSE |
|
|
Optional |
(none) |
|
|
Optional |
(none) |
|
|
Optional |
(none) |
|
|
Optional |
25 |
|
|
OptionalFoot 2 |
(none) |
1
Either ORAService or ORAConnect must be specified, but not both.2 OraCacheTotalSize is required if OraCacheDirectory is used; otherwise, do not specify the parameter. |
Applies to: Portal driver and other (non-file system) access
Required/Optional: Optional
Values: TRUE or FALSE
Default: FALSE
In an Oracle HTTP Server environment that is not OraDAV-enabled, mod_dav itself does not respond to HTTP GET requests. Instead, normal Oracle HTTP Server mechanisms are used to respond to GET requests. However, when all your content is in an Oracle database, normal Oracle HTTP Server mechanisms cannot be used to respond to GET requests, and thus OraDAV must respond to GET requests.
The ORAAllowIndexDetails parameter controls how OraDAV responds when a GET request is performed on a DAV collection and no index.html file is found in that collection (directory). In a typical Oracle HTTP Server environment, a separate module takes control, automatically generating and returning to the client HTML that represents an "index" of the resources (files) in that collection.
An OraDAV-enabled Oracle HTTP Server performs similar actions when responding to a GET request on a collection. A Description column (containing links to more detailed information about each resource) is included in the generated index when ORAAllowIndexDetails is set to TRUE.
These links consist of the URL for the resource itself followed by ?details.
The default is FALSE, in which case no "Description" column appears in the generated index, and if ?details is used in a URL, it is ignored and the URL contents are returned.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Optional
Values: (character string)
Default: (none)
The ORACacheDirectory parameter specifies the directory to use for disk caching operations (see "Using Disk Caching with OraDAV"). If you do not use this parameter, disk caching is not performed for OraDAV operations.
The specified directory must exist and be readable by the Oracle HTTP Server, but cannot be visible to normal GET requests. (If the directory is visible to normal GET requests, security measures could be bypassed by users accessing the cache directory.)
The directory should not be an NFS mounted directory, because most UNIX locking mechanisms caution against this. The directory should be located on a file system that supports a "last accessed" time. For Windows systems this means using NTFS (not FAT) formatted partitions.
Do not use the cache directory for anything other than caching. Any files in the cache directory are subject to deletion.
If you use the ORACacheDirectory parameter, you must also use the ORACacheTotalSize parameter.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Optional
Values: (integer, with optional unit character string)
Default: (none)
The ORACacheMaxResourceSize parameter specifies a maximum cachable resource size for disk caching operations (see "Using Disk Caching with OraDAV"). For example,
DAVParam ORACacheMaxResourceSize 1024KB
would prevent OraDAV from caching any resource larger than one megabyte. The goal is to give webmasters the ability to prevent large media files from dominating the cache. However, be aware that the performance benefit from caching a large file is greater than from caching a small file.
You can specify KB (for kilobytes) or MB (for megabytes) after an integer. If you do not specify a unit after the integer, the default unit is bytes.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Optional
Values: integer (1 to 100)
Default: 25
The ORACachePrunePercent parameter specifies determines a percentage of disk cache usage to be freed up when the cache is full (see "Using Disk Caching with OraDAV"). When the disk cache is full, the oldest files in the cache are deleted ("pruned") until the cache disk usage is reduced by the ORACachePrunePercent value.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Optional, unless ORACacheDirectory is specified
Values: (integer, with optional unit character string)
Default: (none)
The ORACacheTotalSize parameter specifies the size of the cache to use for disk caching operations (see "Using Disk Caching with OraDAV"). Examples:
DAVParam ORACacheTotalSize 1GB DAVParam ORACacheTotalSize 10485760
You can specify MB (for megabytes) or GB (for gigabytes) after an integer. If you do not specify a unit after the integer, the default unit is bytes. The maximum value is 4GB.
If you use the ORACacheDirectory parameter, you must also use the ORACacheTotalSize parameter.
The ORACacheTotalSize value should be large enough to hold either a significant fraction of the your Web site or all of your most frequently accessed files plus 25% or more space. If the value is too small, overall performance will degrade because of the extra work of writing BLOB data to the file system and quickly deleting files to make room for newer cache requests.
The actual space utilized by the disk cache might sometimes exceed the ORACacheTotalSize value, possibly by as much as the ORACacheMaxResourceSize value. Administrators should also be aware of file system block size issues that could cause the cache to use more disk space than the ORACacheTotalSize value.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Required, unless ORAService is specified
Values: (character string)
Default: (none)
The ORAConnect parameter specifies the Oracle database to connect to. The value must be in the following format: database-host:database-port:database-sid. For example:
my-pc.acme.com:1521:mysid
The ORAConnect parameter lets you connect to a database that is not included in the tnsnames.ora file.
You must specify either the ORAService or ORAConnect parameter; however, you cannot specify both.
Applies to: File system access
Required/Optional: Optional
Values: (character string in double-quotes)
Default: (none)
The ORAGetSource parameter applies only to file system access. It specifies one or more file extensions (including periods) to identify types of files that are not to be executed, but rather opened for editing. Use a comma to separate file extensions. For example:
".htm, .html, .jsp1, .jsp2"
The ORAGetSource parameter lets you open for editing files that are usually executed as a result of a GET operation.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Optional
Values: (number of seconds)
Default: 0
The ORALockExpirationPad parameter is intended to be used in high-latency network environments, to adjust for the "refresh lock" behavior in Microsoft Office. Microsoft Office attempts to refresh locks on DAV resources just before the lock is set to expire. However, if there is network congestion between the Microsoft Office client and the DAV server, the refresh request might arrive too late, that is, after the lock has expired.
OraDAV periodically looks for locks on resources that have expired and deletes those locks. The ORALockExpirationPad parameter can be used to provide some additional ("pad") time between when a lock expires and when that lock is deleted. For example, if ORALockExpirationPad is set to 120, OraDAV does not actually delete locks until at least two minutes after the expiration time.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Required
Values: (character string)
Default: ORDSYS.DAV_API_DRIVER
The ORAPackageName parameter identifies the OraDAV driver implementation that is to be called when issuing OraDAV commands. The default is the OraDAV interMedia driver, which is the ORDSYS.DAV_API_DRIVER package.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Required
Values: (character string)
Default: (none)
The ORAPassword parameter specifies the password associated with the user specified by the ORAUser parameter.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Required, unless ORAConnect is specified
Values: (character string matching an entry in the tnsnames.ora file)
Default: (none)
The ORAService parameter specifies the Oracle database to connect to. The specified value must match a SID value in the tnsnames.ora file. For example: mydbsid.mydomain.com
To connect to a database that is not included in the tnsnames.ora file, use the ORAConnect parameter.
You must specify either the ORAService or ORAConnect parameter; however, you cannot specify both.
Applies to: Portal driver and other (non-file system) access
Required/Optional: Required
Values: (character string)
Default: (none)
The ORAUser parameter specifies the database user (schema) to use when connecting to the service specified by the ORAService parameter.
This user must have been granted the following privileges:
All OraDAV parameters are passed from the Oracle HTTP Server to the routines in the ORAPackageName package as part of the context parameter.
The keys are uppercase in the Oracle HTTP Server (for example, ORAUSER), but the values are not (for example, scott).
Because WebDAV enables read-write capabilities, users on the Internet can write to your Web site or to an Oracle database. A major concern is preventing users from placing an inappropriate file (a "Trojan horse") that can execute on the Web server system. If the WebDAV configuration an authorization is not set up properly, an inappropriate file from the file system can be executed. (This problem does not apply to content from an Oracle database, because such content cannot execute in the middle tier.)
The HTTP protocol issues GET requests both to static and executable files, without differentiation. The Oracle HTTP Server executes files based on their location or extension. For example, a shell script (which typically has no file extension) will be executed if it is in the cgi-bin directory, but will be retrieved as a static text file if it is in the htdocs directory. On the other hand, a Java server page, which has a .jsp extension, will normally be executed regardless of its location. However, by default, mod_oradav prevents a WebDAV-enabled directory from executing a .jsp or .sqljsp file. For a file with one of these extensions, mod_oradav reads the content directly, bypassing any Oracle HTTP Server logic that attempts to execute the file. Files with these extensions are retrieved as having the text/plain MIME type and can be edited. You can add to the list of file types that are never to be executed and always retrieved as text/plain by using the ORAGetSource parameter.
One way to limit execution of files is to use the Apache ForceType directive in a <Location> directive. This forces all content under a location to be retrieved as text/plain. However, this simple and sweeping approach may not be what you want in many cases, wherein you want the standard behavior associated with the actual MIME type (for example, for .gif files) to be used.
To decide how to handle these security issues with content on file systems, you should determine what kinds of WebDAV users are going to have access to the content. WebDAV users typically fall into two categories: Web authors who want to collaborate and manage a Web site, and end users who want to use WebDAV as a public storage area. End users should never be able to upload and execute a file, so for end users you may want to specify many file extensions with the ORAGetSource parameter or to use the ForceType directive.
Be sure to apply the standard Basic or Digest authentication and authorization mechanisms supported by the Oracle HTTP Server. You probably want to do this for the default location (dav_public) in the supplied moddav.conf file. This will restrict who can use your system for remote storage, preventing unauthorized users from filling up your disks. You should always apply Oracle HTTP Server authentication and authorization to authors of the Web site.
You should also provide both an execution context and an editing context, so that Web authors (after being properly authenticated and authorized) can edit a .jsp or other executable file and then see how it executes. To do this, create an alias for the directory associated with the execution context, and then DAV-enable the aliased location. For example, assume that you want to be able to execute a script if the URL specifies the cgi-bin directory (for example, http://www.acme.com/cgi-bin/printenv) but edit the script if the URL specifies an alias named edit-cgi-bin (for example, http://www.acme.com/cgi-bin/printenv). The following configuration file entries achieve this goal, setting up edit-cgi-bin as an editing context for content in the cgi-bin directory:
Alias /edit-cgi-bin /usr/local/apache/cgi-bin <Location /edit-cgi-bin> DAV On ForceType text/plain </Location>
This section provides information that can help you optimize the performance of various kinds of operations. It contains the following topics:
Oracle9iAS can use local file system disk caching with data that is retrieved from an Oracle database. Disk caching is designed to improve the performance of HTTP GET operations on frequently accessed database data. When data is requested from the database, it is retrieved and is also stored in a disk cache on the local file system. If a subsequent request is for the same data and if the data is still in the disk cache, Oracle9iAS checks to see if the data has changed in the database (by examining the etag value); and if the data has not changed, it is retrieved from the cache, which is more efficient than retrieving it from the database unless the files are very small.
The performance benefit from disk caching is greatest with medium-size to large files (roughly 50 KB and larger). With very small files, performance can be worse with disk caching than without. For example, if the file myfile.dat is requested and if the file size is only 24 bytes, the time required for copying the file from the database to the local system is very small compared to the time required for accessing the database to check if the file has changed. If disk caching is not used, there is no check of the database to see if the file has changed, and the file is copied from the database in all cases.
You can set several OraDAV parameters to control disk caching for OraDAV operations:
If you specify ORACacheDirectory, disk caching for OraDAV operations is enabled; and in this case you must also specify an ORACacheTotalSize value, and you can specify ORACacheMaxResourceSize and ORACachePrunePercent values. If you do not specify ORACacheDirectory, disk caching for OraDAV operations is not enabled, and the other disk cache-related parameters are not relevant.
For reference information about each parameter, see "OraDAV Configuration Parameters".
Oracle9iAS Web Cache is a feature that enhances performance for most Web activity, which involves client read-only operations of data on the Web server system. However, Web Cache does not cache OraDAV operations (which are designed for read/write capability). Thus, for better performance, WebDAV clients can connect directly to the Oracle HTTP Server.
To bypass Web Cache for WebDAV clients, you must add a new port for listening and specify a different virtual host when using this port. Choose any port number that is not currently used by the Oracle HTTP Server and is not in a range of reserved port numbers.
For example, you could choose port number 7900 and add the following lines to the moddav.conf file:
Listen 7900 <VirtualHost _default_:7900> </VirtualHost>
WebDAV clients will connect directly to port 7900 for better performance.
If your WebDAV clients always bypass Web Cache (see "Bypassing Web Cache for WebDAV Activities"), you may want to tune Web Cache for read-only clients such as Web browsers. To do so, add the DAVOraWebCacheReadOnly On setting for an OraDAV-enabled location in the httpd.conf file. For example:
<Location /dav_public> DAV On DAVOraWebCacheReadOnly On </Location>
This setting prevents WebDAV clients from using Web Cache and thus potentially retrieving stale documents for editing. (That is, the cached version of the document might not reflect edits that were recently made.) This setting, however, does allow read-only activity by browsers and other clients to use Web Cache.
This section contains usage notes relating to mod_oradav. Some of the information, including most of the material relating to DAV parameters, is taken or adapted from material written by Greg Stein (gstein@lyra.org) and available at the following URL:
http://www.webdav.org/mod_dav/install.html
Following are practices to avoid when mapping containers under the root location.
Location />.
<Location /project1> and <Location /project1/project2>. However, it is acceptable to specify <Location /project1> and <Location /project2>.
For access to database data, the character set used for client requests, such as in URLs and file names, must be compatible with the character set used for the database. Specifically, if the character set for the database is not the same as for the client requests, the character set for the database must provide for conversion of all possible characters in client requests (and thus must be a superset of the character set for client requests). That is, the character set for the database must not cause replacement characters during the conversion.
When you start the Oracle HTTP Server, the NLS_LANG environment variable must reflect the character set for client requests. For example, if file names and URLs contain Kanji characters, you can specify NLS_LANG=JAPANESE_JAPAN.JA16SJIS (for ShiftJIS characters). In this case, the database character set must be one that accommodates SJIS characters, for example, UTF8.
For access to the local file system (as opposed to database access), the character set for the file system must be the same as or compatible with the character set for URLs embedded in client requests. The character set for the file system must provide for conversion of all possible characters in client requests. You must also specify the parameter DAVOraNLS On.
For example, assume that you are using Web folders on a system where the files have ShiftJIS characters and that the file system under dav_public is represented by the operating system in the JAPANESE_JAPAN.JA16SJIS character set, as shown in Figure 7-2.
In this case, you must do the following:
NLS_LANG value to JAPANESE_JAPAN.JA16SJIS.
httpd.conf file.
<Location /dav_public> DAV On DAVOraNLS On </Location>
This section describes some DAV parameters that you can set in the httpd.conf file.
To create the DAV lock database, add a DAVLockDB directive at the top-level of the configuration file (that is, outside a <Directory> or <Location> directive). The DAVLockDB directive should specify the name of a file that mod_dav will create. The directory in which the file is to be created must exist and, and the Oracle HTTP Server process must have write permission to it.
In the following example:
DAVLockDB ORACLE_HOME/Apache/var/DAVLock
The DAV lock database will be stored in the ORACLE_HOME/Apache/var directory (which must be writable by the Oracle HTTP Server process). The file name will be DAVLock when mod_dav needs to create it. (Actually, mod_dav will create one or more files using this file name plus an extension).
The DAVLockDB directive can appear outside of any container or within a <VirtualHost> specification. It only needs to appear once, and a file extension should not be supplied.
The DAVMinTimeout directive specifies the minimum lifetime of a lock in seconds. If a client requests a lock timeout less than DAVMinTimeout value, then the DAVMinTimeout value is used and returned instead. For example, Microsoft's Web Folders defaults to a lock timeout of 2 minutes (120 seconds); however, you might decide to specify 10 minutes (600 seconds) instead, to reduce network traffic and the chance that the client might lose a lock due to network latency.
The DAVMinTimeout directive is optional, and may be used on a per-server or per-directory or location basis. The DAVMinTimeout directive takes a single positive integer. Because this value represents a minimum allowed, setting it to zero (0) will disable this feature. The default value for DAVMinTimeout is zero.
A PROPFIND request with a Depth: Infinity header can impose a large burden on the server. These kinds of requests could "walk" the entire repository, returning information about each resource found. mod_dav builds the response in memory, so these kinds of requests can consume a lot of memory. (The memory is released at the end of the request, but the peak memory usage can be high.)
To prevent these kinds of requests, the DAVDepthInfinity directive is provided. It is a simple on/off directive, which can be used on a per-server, per-directory or location basis. The default value for this directive is off, meaning that these kinds of requests are not allowed. A value of on (that is, allowing depth infinity requests) makes it easier for denial of service attacks to occur. However, some clients, such as sitecopy, require a DAVDepthInfinity value of on.
The DAVOraNLS directive provides globalization support for access to the local file systems. This directive specifies whether or not the file names in the file system need to go through conversion using the NLS_LANG setting. A value of Off, the default, means that no conversion is needed. A value of On means that the character set for the file system provides for conversion of all possible characters in client requests. For more information, see "Globalization Support Considerations with OraDAV".
The DAVOraWebCacheReadOnly directive specifies whether or not Web Cache should be used by WebDAV clients. A value of Off, the default, means that Web Cache functions normally. A value of On prevents WebDAV clients from using Web Cache and thus potentially retrieving stale documents for editing; however, it does allow read-only activity by browsers and it does allow other clients to use Web Cache. For more information, see "Using Web Cache for Browsing Activities".
mod_dav parses XML request bodies into memory. One technique used in denial of service attacks is to send a large request body at a mod_dav server. The Oracle HTTP Server defines a directive named LimitRequestBody, which limits all methods' request bodies. Unfortunately, this is not an effective mechanism for a mod_dav server because large PUT operations should be allowed.
To limit just the methods that have an XML request body, mod_dav provides the LimitXMLRequestBody directive. The default for this value is a compile-time constant, which is set to one million (1000000) bytes in the standard distribution. Setting the value to zero (0) will disable the size limit.
LimitXMLRequestBody may be set on a per-server or a per-directory or location basis, and takes a single non-negative integer argument.
The DAV and DAVLockDB directives are the only two configuration changes necessary to operate a DAV server. However, it is usually best to secure the site to be writable only by specific authorized users. This requires the use of the <Limit> directive. For example:
<Location /mypages> DAV On <Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> Require user greg </Limit> </Location>
This configuration will allow only authorized users to manipulate the site. However, it does allow them a bit more freedom than you may like. In particular, they may be able to place an .htaccess file into the target directory, altering your server configuration. The server may have already been configured to not read .htaccess files, but it is best to make sure. Also, you may want to disallow other options within the DAV-enabled directory -- CGI, symbolic links, server-side includes, and so on. Here is a modified configuration with the additional restrictions placed on it through the addition of AllowOverride None and Options None:
<Location /mypages> DAV On AllowOverride None Options None <Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> Require user greg </Limit> </Location> <Location /mypages> DAV On AllowOverride None Options None <Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> Require user greg </Limit> </Location>
Rather than using the <Limit> directive and specifying an exhaustive list of HTTP methods to secure, it is also possible to use the <LimitExcept> directive. This directive applies the access restrictions to all methods except for the methods listed. For example:
<Location /mypages> DAV On AllowOverride None Options None <LimitExcept GET HEAD OPTIONS> require user webadmin </LimitExcept> </Location>
Choosing to use one or the other is a matter of preference. The <Limit> directive is precise and explicit, but the <LimitExcept> directive will automatically restrict methods that are added in the future.
In the example configurations in the preceding sections on the <Limit> and <LimitExcept> directives, the PROPFIND method was limited, even though it is read-only. This is because the PROPFIND method can be used to list all the files in the DAV-enabled directory. For security reasons, it is probably best to protect the list of files from general read access.
An alternative would be to limit the PROPFIND to a group of people, a set of domains, or a set of hosts, while the methods that modify content are limited to just a few authors. This scenario allows, say, your company's employees to browse the files on the server, yet only a few people can change them. Anonymous (non-authenticated) visitors cannot browse or modify.
Finally, you can simply omit PROPFIND from the limits if your Web server is intended as a general, read-only repository of files. This allows anybody to arbitrarily browse the directories and then to fetch the files.
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|