9 Configuring mod_oradav

This chapter describes distributed authoring and versioning (DAV) concepts, and explains how to configure OraDAV using the mod_oradav module. The mod_oradav module enables you to use OraDAV to access content in files from a Web browser or a WebDAV client.


Unless otherwise mentioned, the information in this document is applicable when Oracle HTTP Server is installed with Oracle WebLogic Server and Oracle Fusion Middleware Control. It is assumed that readers are familiar with the key concepts of Oracle Fusion Middleware, as described in the Oracle Fusion Middleware Concepts Guide and the Oracle Fusion Middleware Administrator's Guide.

For information about installing Oracle HTTP Server in standalone mode, see “Installing Oracle Web Tier Without Oracle WebLogic Server” in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier.

This chapter includes the following sections:

9.1 Introduction to the mod_oradav Module

The mod_oradav module is an extended implementation of the Apache implementation of the WebDAV specification. The mod_oradav module is an OCI application written in C and is integrated with Oracle HTTP Server. The mod_oradav module enables WebDAV clients to connect to files, read and write content, and query and lock documents.

This section includes the following subsections:

9.1.1 WebDAV

WebDAV is a protocol extension to HTTP 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 access and optionally change that content from various devices.


When a WebDAV client first connects to Oracle HTTP Server, it must use the full ServerName string in the URL for the connection. Do not use an abbreviated form of the server name.

For example, if the server name value is server1.example.com, then connect to Oracle HTTP Server using the string http://server1.example.com:7778, not an abbreviated form such as http://server1:7778.

If you use an abbreviated form, the connection might succeed, but COPY and MOVE operations will fail to run, and generate BAD_GATEWAY errors.

9.1.2 OraDAV

OraDAV refers to the set of capabilities available through the mod_oradav module to Oracle Fusion Middleware users. Some OraDAV-specific terms include:

  • OraDAV: Code in the Oracle HTTP Server that supports file-based DAV access. Apache DAV directives can be used with OraDAV.

    See Also:

    For more information about DAV directives, see the article written by Greg Stein (gstein@lyra.org) available at


  • OraDAV API: Stored procedure calls that are used by the OraDAV driver to provide support for the following WebDAV functions over the Internet:

    • Reading and writing documents

    • Locking and unlocking documents

    • Managing, such as creating, populating, and deleting, hierarchies of information

    • Retrieving properties associated with documents

    • Associating properties with specific documents

  • OraDAV driver: Stored procedure implementation of the OraDAV driver API that runs in Oracle and manages a repository.

The primary users of OraDAV are Oracle HTTP Server Web administrators and content editors. End users interact only indirectly with OraDAV through Web browsers or WebDAV client tools. OraDAV interaction requires the following proficiency:

  • The Web administrator needs to know how to start and stop Oracle HTTP Server, and how to configure Oracle HTTP Server to direct URL traffic to an OraDAV driver.

  • The content editors need to know how to connect to the server, and upload and retrieve files.

9.1.3 OraDAV Architecture

The mod_oradav module, which includes OraDAV, is part of the Oracle HTTP Server architecture. A simple form of the architecture is illustrated in Figure 9-1.

Figure 9-1 OraDAV Architecture

Description of Figure 9-1 follows
Description of "Figure 9-1 OraDAV Architecture"

Figure 9-1 shows a WebDAV client, such as Web folders, passing HTTP requests to Oracle HTTP Server. If the request is for content stored in the file system, the mod_oradav module handles the access. If the request is for content stored in Oracle Portal, the OraDAV API handles the access.

The OraDAV API capabilities are equivalent to using the mod_oradav module running with a file system. The following HTTP methods are supported by the OraDAV API:

  • COPY: Copies files within a Web site folder.

  • DELETE: Deletes files within a Web site folder.

  • MOVE: Moves files within a Web site folder.

  • MKCOL: Makes a new directory.

  • GET: Retrieves a file from the server. This method is not supported by Oracle Web Cache.

  • PUT: Puts a file back to the server. This method is not supported by Oracle Web Cache.

  • HEAD: Gets the header content of a file without retrieving the file.

  • LOCK: Locks a file when the file is checked out. This method is not supported by Oracle Web Cache.

  • UNLOCK: Unlocks a file after check in. This method is not supported by Oracle Web Cache.

  • PROPFIND: Gets properties defined for a file.

  • PROPPATCH: Sets the properties for a file.

The OraDAV API supports shared and exclusive locking, retrieving basic DAV properties, and defining and retrieving server-defined properties or client-defined properties. Set-based operations such as COPY, MOVE, DELETE can be done completely by a single call to an OraDAV driver.

9.1.4 OraDAV Usage Model

OraDAV usage can involve any combination of the following activities:

  • Browsing: Read-only activity which uses WebDAV to access content on the file server. Its usage model is typical of a read-only Web site.

    The DAVOraReadOnly directive specifies whether or not WebDAV should be used in a read-only mode by WebDAV clients. A value of Off specifies that WebDAV clients function normally. A value of On prevents WebDAV clients from performing write operations while using WebDAV. It does allow read-only activity by Web browsers and WebDAV clients. The default is Off.

  • Restructuring: Deleting, moving, and copying content. Restructuring is usually done infrequently by a restricted set of individuals who have write access to the WebDAV content.

    Restructuring has the same limitations and complications that one encounters when restructuring a file directory. In some cases, this directory hierarchy is owned and managed by one user. If the directory is shared, then the client doing restructuring is given sole access to the hierarchy through WebDAV exclusive locks.

  • Editing: Modifying one or a small subset of resources in a hierarchy. Properly designed WebDAV clients use shared or exclusive locks on such resources to coordinate these activities.

  • Property Management: Associating properties and attributes (for example, author) with documents for ease of lookup and for categorization. WebDAV clients assign properties to documents using the PROPPATCH directive and retrieve properties using the PROPFIND directive.

9.1.5 PROPFIND Security

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 is 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, for example, 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 to fetch the files.

9.2 Configuring mod_oradav

Use the Advanced Server Configuration page of Fusion Middleware Control to configure the mod_oradav module.

This section includes the following subsections:

9.2.1 OraDAV Configuration Directives

When Oracle Fusion Middleware is installed, all required OraDAV parameters, called "directives", are set to their default values. If the default values do not meet your needs, you can modify the values for required parameters and specify values for optional parameters. The OraDAV parameters in the mod_oradav.conf file start with "DAV" and "DAVParam".


To configure the parameters use Fusion Middleware Control. Do not edit the mod_oradav.conf file directly. Doing so may harm your installation.

The DAV parameter indicates that a URL location is DAV-enabled. The DAV keyword is followed by one of the following values:

  • On – indicates that mod_oradav is to use the local file system for content.

  • Oracle – indicates that mod_oradav is to use OraDAV for all content.

The DAVParam parameters are used to specify name-value pairs. The required pairs are those that enable Oracle HTTP Server to connect to an Oracle database. These include the names OraService, OraUser, and OraPassword or OraAltPassword.

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 additional DAV parameters, such as DavMinTimeout.

Example 9-1 shows the syntax to configure access to files on the local system. It specifies that the directory dav_portal under the Web server documents directory is to be DAV-enabled, along with all directories under dav_portal in the hierarchy. There must not be any symlinks defined on the dav_portal directory or any of its subdirectories.

Example 9-1 Configuring File System Access

<Location /dav_portal>
  DAV On

The following recommendations should be considered when mapping containers under the root location:

  • Do not map the root itself. For example, do not specify <Location / > in the mod_oradav.conf file.

  • Do not map a container as a subelement in the hierarchy to another container. For example, do not specify the containers <Location /project1> and <Location /project1/project2>. It is acceptable to specify <Location /project1> and <Location /project2>.

  • Do not create any symbolic links to the container or any location under the container in the hierarchy.


The OraDAV directives are described in Appendix D, "OHS Module Directives". See Section E.3, "mod_oradav."

9.2.2 Using Fusion Middleware Control to Configure mod_oradav

On the Advanced Server Configuration page of Fusion Middleware Control, you can enter parameters within a <Location> container directive in the mod_oradav.conf file. The <Location> container directive specifies the DAV-enabled URL. The DAV keyword is followed by the parameter On, which instructs mod_dav to use the local file system for content.

The following example specifies that the directory myfiles under the Web server documents directory (htdocs by default) to be DAV-enabled, along with all directories under myfiles in the hierarchy. There must not be any symbolic links defined on the myfiles directory or any of its subdirectories.

<Location /myfiles>
   DAV On

9.2.3 Editing mod_oradev.conf

Create the mod_oradev.conf file at the following location:


Insert the below mentioned entries in the mod_oradev file.

LoadModule oradav_module "${ORACLE_HOME}/ohs/modules/mod_oradav.so"
#<Location /dav/lsn> 
#DAV oracle 
#DAVDepthInfinity Off 
#DavParam ORALockExpirationPad 0 
#DavParam ORAException RAISE 
#DavParam ORATraceLevel 0 
#DavParam OraTraceEvents "request" 
#DavParam ORASERVICE psgprod 
#DavParam ORACONNECTSN db-host 
#DAVParam ORAUser lsn 
#DAVParam ORAPassword psg_lsn 
#DAVParam ORAPackageName ordsys.dav_api_driver 
#DAVParam OraWebCacheReadOnly On 

Save the file, and restart Oracle HTTP Server as described in Section 4.1.4, "Restarting Oracle HTTP Server." The option for editing mod_oradev.conf file is displayed on the Advanced Server Configuration page of Fusion Middleware Control.

9.3 WebDAV Security Considerations

Because WebDAV enables read/write capabilities, Internet users can write to your Web site or to an Oracle repository. A major concern is preventing users from placing an inappropriate file, such as a Trojan horse, that can run on the Web server system. If the WebDAV configuration and authorization is not set up properly, an inappropriate file from the file system can be run. However, mod_oradav is disabled by default in new installations of Oracle HTTP Server so that your system is secure out-of-the-box.

See Also:

Apache Module mod_dav Security Issues in the Apache HTTP Server documentation.

Be sure to apply the standard Basic or Digest authentication and authorization mechanisms supported by Oracle HTTP Server. Generally, you do this for the default location, such as dav_public, in the supplied mod_oradav.conf file. This restricts who can use your system for remote storage, preventing unauthorized users from filling up your disks.

In addition, 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 file or other executable file and then see how it runs. To do this, create an alias for the directory associated with the execution context, and then DAV-enable the aliased location.

9.4 OraDAV Performance Considerations

This section provides information that can help you optimize the performance of various operations. It contains the following subsections:

9.4.1 Using Disk Caching with OraDAV

The performance benefit from disk caching is greatest with medium to large-size files (approximately 50 KB and larger). With smaller files, the performance benefit is less, and with very small files the performance can be worse with disk caching than without disk caching. 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 server to the local system is very small compared to the time required for accessing the server to check if the file has changed. If disk caching is not used, there is no check of the server to see if the file has changed, and the file is copied in all cases.

You can set the following OraDAV parameters to control disk caching for OraDAV operations:

  • ORACacheDirectory

  • ORACacheTotalSize

  • ORACacheMaxResourceSize

  • ORACachePrunePercent

If you specify ORACacheDirectory, disk caching for OraDAV operations is enabled. You must also specify a value for ORACacheTotalSize, and you can specify values for ORACacheMaxResourceSize and ORACachePrunePercent parameters. If you do not specify ORACacheDirectory, disk caching for OraDAV operations is not enabled, and other disk cache-related parameters are not relevant.

9.4.2 Bypassing Oracle Web Cache for WebDAV Activities

Oracle Web Cache enhances performance for most Web activity that involves client read-only operations of data on the Web server system. Oracle Web Cache does not cache OraDAV operations for GET, PUT, LOCK and UNLOCK, which are designed for read/write capability. For better performance, WebDAV clients can connect directly to Oracle HTTP Server.

To bypass Oracle Web Cache for WebDAV clients, you can send requests directly to the Oracle HTTP Server listen port, which is set in the httpd.conf file. By doing this, WebDAV clients will connect directly to Oracle HTTP Server, resulting in better performance than if Oracle Web Cache is used.

9.5 Globalization Support Considerations with OraDAV

The DAVOraNLSLangClient 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 specifies that no conversion is needed. A value of On specifies that the character set for the file system provides for conversion of all possible characters in client requests. The default is Off.

For access to the local file system, 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. The NLS_LANG parameter value must represent the character set of both the client and the OraDAV server. You must also specify a value of On for the parameter DAVOraUseNLSLang.

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 sets shown in Figure 9-2.

Figure 9-2 OraDAV Access to File System with ShiftJIS Characters

Description of Figure 9-2 follows
Description of "Figure 9-2 OraDAV Access to File System with ShiftJIS Characters"

You must do the following:

  1. Set the NLS_LANG value to JAPANESE_JAPAN.JA16SJIS.

  2. Include the following in the mod_oradav.conf file:

    <Location /dav_public>
     DAV On
     DAVOraNLSLangClient On


If you use Microsoft Internet Explorer with OraDAV and a multibyte character set, you must disable the Internet option Always send URLs as UTF-8, located under the Advanced tab in the Internet Options section. By default, this option is enabled. The requirement to disable this option applies to both database access and file system access.

9.6 Location of DAV Files

When the ORACLE_HOME/ohs/cas/templates/default/moduleconf/mod_oradav.conf file is configured to use file storage, it places the files by default in:


Oracle Fusion Middleware Backup and Recovery Service backs up this default location. If you change the location where the files are stored, and you want Oracle Fusion Middleware Backup and Recovery Service to backup the files, then you must register the new location.