Web Server supports WebDAV or Web-based Distributed Authoring
and Versioning, a standard in Web-based collaboration. WebDAV is an extension
to the HTTP/1.1 protocol that allows clients to perform remote web content
authoring operations.

A complete WebDAV transaction involves a WebDAV-enabled server, such
as Web Server that can service requests for WebDAV resources,
as well as a WebDAV-enabled client such as Adobe®
GoLive® or Macromedia® DreamWeaver® that supports WebDAV-enabled
Web publishing requests.

On the server-side, you need to enable and configure Web Server to
be able to service WebDAV requests.

You might want to configure WebDAV for several reasons: for example,
to tune server performance, to eliminate security risks, or to provide for
conflict-free remote authoring.

To suit your configuration requirements, you can change the minimum
amount of time the server holds a lock on a WebDAV resource, the depth of
the PROPFIND request on a collection, and the maximum size of the XML content
allowed in the body of a request, and so on.

Default WebDAV attributes can be configured at the virtual server level
for all collections under a virtual server. The values configured here correspond
to the DAV element in the server.xml file.

WebDAV attributes can also be configured at a collection level and override
any virtual server level attributes configured for the collection. The attribute
values configured at the collection level correspond to the DAVCOLLECTION element in the server.xml file.

About WebDAV

WebDAV is an extension of the HTTP/1.1 protocol, and adds new HTTP methods
and headers that provide authoring support for Web resources of any type,
not only HTML and XML but also, text, graphics, spreadsheets, and all other
formats. Some of the tasks you can accomplish using WebDAV are:

Properties (meta-data) manipulation.
You can create, remove and query information about web pages, such as their
authors and creation date using the WebDAV methods PROPFIND and PROPPATCH.

Collection and resource management.
You can create sets of documents and retrieve a hierarchical membership listing
(similar to a directory listing in a file system) using the WebDAV methods
GET, PUT, DELETE, and MKCOL.

Locking. You can use WebDAV
to keep more than one person from working on a document at the same time.
The use of mutually exclusive or shared locks using the WebDAV methods LOCK
and UNLOCK, helps to prevent the 'lost updates' (overwriting of changes) problem.

Namespace operations. You
can use WebDAV to instruct the server to copy and move Web resources using
the WebDAV methods COPY and MOVE.

Common WebDAV Terminology

This section outlines the common terms you will encounter as you work
with WebDAV.

URI.
A URI (Uniform Resource Identifier) is a file identifier that provides an
additional layer of security by using an abbreviated URL. The first part of
the URL is substituted with a URL mapping that hides the file’s full
physical pathname from the user.

Source URI. The term,
source URI, refers to the URI at which a resource’s source can be accessed.
To understand the concept of source URI, consider the following example:

A JSP page, foo.jsp, is located at the URI /docs/date.jsp. This page contains HTML markup and Java code which, when executed,
prints today’s date on the client’s browser. When the server receives
a GET request for foo.jsp from a client, before serving
the page it executes the Java code. What the client receives is not foo.jsp as it resides on the server but instead a dynamically generated
page that displays the current date.

If you were to create a source URI, say /publish/docs,
and map it to the /docs directory containing foo.jsp,
then a request for /publish/docs/foo.jsp will be a request
for the source code of the /docs/foo.jsp JSP page. In this
case, the server will serve the page without executing the Java code. The
client will receive the unprocessed page exactly as stored on disk.

A request for the source URI is thus a request for the source of the
resource.

Collection. A WebDAV collection is a resource or a set of resources
that are enabled for WebDAV operations. A collection contains a set of URIs,
termed member URIs, which identify member resources that are WebDAV-enabled.

Member URI.
A URI which is a member of the set of URIs inside a collection.

Internal
Member URI. A Member URI that is immediately relative to the URI of the
collection. For example, if the resource with the URL http://info.sun.com/resources/info is WebDAV-enabled and if the resource with the URL http://info.sun.com/resources/ is also WebDAV-enabled, then the resource with the URL http://info.sun.com/resources/ is a collection and contains http://info.sun.com/resources/info as an internal member.

Property. A name/value pair that contains descriptive information
about a resource. Properties are used for efficient discovery and management
of resources. For example, a ’creationdate’ property might allow
for the indexing of all resources by the date on which the resources were
created, and an ’author’ property, for indexing by author name.

Live Property. A property that is
enforced by the server. For example, the live getcontentlength property
has as its value, the length of the entity returned by a GET request, which
is automatically calculated by the server. Live properties include the following:

The value of a property is read-only, maintained by the server

The value of the property is maintained by the client, but
the server performs syntax checking on submitted values.

Dead Property. A property that is
not enforced by the server. The server only records the value of a dead property;
the client is responsible for maintaining its consistency.

The server supports the following live properties:

creationdate

displayname

getcontentlanguage

getcontentlength

getcontenttype

gettag

getlastmodified

lockdiscovery

resourcetype

supportedlock

executable

Note –

The server supports the live property executable that
allows clients to change the file permissions associated with a resource.

Locking. The ability to lock a resource provides a mechanism to guarantee
that one user will not modify a resource while it is being edited by another.
Locking prevents overwrite conflicts and resolves the "lost updates" problem.

The server supports two types of locking: shared and exclusive.

New HTTP Headers. WebDAV works by extending the HTTP/1.1 protocol.
It defines new HTTP headers by which clients can communicate requests for
WebDAV resources. These headers are:

Destination:

Lock-Token:

Timeout:

DAV:

If:

Depth:

Overwrite:

New HTTP Methods. WebDAV introduces several new HTTP methods that instruct
WebDAV-enabled servers how to handle requests. These methods are used in addition
to existing HTTP methods such as GET, PUT,
and DELETE to carry out WebDAV transactions. The new HTTP
methods are briefly described below:

COPY. Used to copy resources. Copying collections
uses the Depth: header while the Destination: header
specifies the target. The COPY method also uses the Overwrite: header,
as appropriate.

MOVE. Used to move resources. Moving collections
uses the Depth: header while the Destination: header
specifies the target. The MOVE method also uses the Overwrite: header,
as appropriate.

MKCOL. Used to create a new collection. This
method is used to avoid overloading the PUT method.

PROPPATCH. Used to set, change, or delete properties
on a single resource.

PROPFIND. Used to fetch one or more properties
belonging to one or more resources. When a client submits a PROPFIND request
on a collection to the server, the request may include a Depth: header with
a value of 0, 1, or infinity.

0. Specifies that the properties of the
collection at the specified URI will be fetched.

1. Specifies that the properties of the
collection and resources immediately under the specified URI will be fetched.

infinity. Specifies that the properties
of the collection and all member URIs it contains will be fetched. Be aware
that because a request with infinite depth will crawl the entire collection,
it can impose a large burden on the server.

LOCK. Adds
locks on resources. Uses the Lock-Token: header.

UNLOCK. Removes locks from resources. Uses the Lock-Token: header.

Enable WebDAV at Instance Level

You can use the Administration Server to enable WebDAV for the entire
server. When you do so, the following directive is added to the magnus.conf
file that loads the WebDAV plugin:

Modifying WebDAV Parameters

Specify the directory in which the locking database will be maintained.

Minimum Lock Time-out

Specify the minimum lifetime of a lock in seconds. A value of -1 implies that the lock never expires. This value
indicates the amount of time that an element will be locked before the lock
is automatically removed.

Maximum Request Size

Specify the maximum size of the XML request body. You should configure
this value to prevent possible denial of service attacks. The default value
is 8192 (8K).

Maximum Expand Property Depth

Specify the depth of the Expand Property. 0 applies
only to the specified resource. This is the default value. 1 applies to the specified resource and the next
level. infinity applies to the specified resource and all resources it contains.
Also prevent excessive memory consumption by restricting the size of this
parameter.

Default Owner

Default owner for the collection.

URI

Existing root URI on which WebDAV will be enabled.

Maximum PROPFIND Depth

Maximum depth of PROPFIND requests send to collections.

Lock Database Update Interval

Interval at which WebDAV lock databases are synced to disk. Use 0 to
disable caching of WebDAV lock information.

Authentication Database

The ACL authentication database to use.

Authentication Method

The authentication method to use. Default authentication method is Basic.

Authentication Prompt Text

The prompt to display to clients when requesting authentication.

DAV ACL Database

Maximum Entries

Maximum number of ACEs to allow on a single resource. 0–2147.0483647.0.
Specify —1 for no limit.

Maximum Size

Maximum size of the memory representation of the WebDAV ACL database
for a collection. 0–2147.0483647.0. Specify —1 for no limit.

Managing WebDAV Authentication Databases

From the administration console, click WebDAV
tab from the selected configuration to edit WebDAV authentication
database settings. The following table provides a short description of each
field in the page:

Table 10–2 WebDAV Authentication Database Properties

Property

Description

Authentication Database

Authentication Database lets you select a database
the server will use to authenticate users.

The default is keyfile

Authentication Method

Basic — uses the
HTTP Basic method to get authentication information from the client. The username
and password are only encrypted over the network if SSL is turned on for the
server.

SSL — uses the client
certificate to authenticate the user. To use this method, SSL must be turned
on for the server. When encryption is on, you can combine Basic and SSL methods.

Digest — uses an
authentication mechanism that provides a way for a browser to authenticate
based on username and password without sending the username and password as
clear text. The browser uses the MD5 algorithm to create
a digest value using the user’s password and some information provided
by the Web Server. Note that in order to use Digest the underlying auth-db
must support digest as well. This means either a File auth-db using digestfile
or an LDAP auth-db only if the Digest Authentication Plug-in has been installed

Other — uses a custom
method created using the access control API.

Authentication Prompt Text

Prompt for Authentication option
allows you to enter message text that appears in the authentication dialog
box. You can use this text to describe what the user needs to enter. Depending
on the browser, the user will see about the first 40 characters of the prompt.

Web browsers typically cache the username and password, and associate
them with the prompt text. When the user accesses files and directories of
the server having the same prompt, the usernames and passwords won’t
need to be entered again. If you want users to authenticate again for specific
files and directories, you simply need to change the prompt for the ACL on
that resource.

Using Source URI and Translate:f Header on a WebDAV-Enabled
Server

WebDAV methods operate on the source of a resource or a collection.
HTTP methods such as GET and PUT are overloaded by the WebDAV protocol and
therefore, a request with these methods can either be a request to the source
of the resource or a request to the content (output) of the resource.

Microsoft and many other WebDAV vendors have addressed this problem
by sending a Translate:f header with the request to inform
the server that the request is for the source. In order to be interoperable
with the popular WebDAV client Microsoft WebFolders, the server recognizes
the Translate:f header as a request to the source of the
resource. To accommodate clients that do not send the Translate:f header,
the server defines a source URI.

For a WebDAV-enabled collection, the request to the URI retrieves the
content (output) of the resource and a request to the source URI retrieves
the source of the resource. A request to the URI with a Translate:f header
is treated as a request to the source URI.

Note that by default all access to the source of a resource is denied
by the dav-src ACL with the following declaration in the
server instance-specific ACL file:

deny (all) user = "anyone";

An user can enable access to the source to a user by adding access rights
to the source URI.

Locking and Unlocking Resources

The server allows the server administrator to lock a resource so as
to serialize access to that resource. Using a lock, a user accessing a particular
resource is reassured that another user will not modify the same resource.
In this way, the "lost updates" problem is resolved as multiple users share
resources on the server. The lock database maintained by the server keeps
track of the lock tokens issued and in use by clients.

The server supports the opaquelocktoken URI scheme,
which is designed to be unique across all resources for all time. This uses
the Universal Unique Identifier (UUID) mechanism, as described in ISO-1157.08.

The server recognizes two types of locking mechanisms:

Exclusive Locks.

Shared Locks.

Exclusive Locks

An exclusive lock is a lock that grants access
to a resource to only a single user. Another user can access the same resource
only after the exclusive lock on the resource is removed.

Exclusive locking sometimes proves to be too rigid and expensive a mechanism
for locking resources. For example, in the event of a program crash or the
lock owner forgetting to unlock the resource, a lock timeout or the administrator’s
intervention will be required to remove the exclusive lock.

Shared Locks

A shared lock allows multiple users to receive a lock to a resource.
Hence any user with appropriate access can get the lock.

When using shared locks, lock owners may use any other communication
channel to coordinate their work. The intent of a shared lock is to let collaborators
know who else may be working on a resource.

Minimum Lock Timeout

You can control locking by configuring the value of the minlocktimeout attribute of the DAV or DAVCOLLECTION objects
in the server.xml file. The minlocktimeout attribute
specifies the minimum lifetime of a lock in seconds. This value indicates
the amount of time that an element will be locked before the lock is automatically
removed.

This is an optional attribute. If the value is set to -1, the lock will
never expire. Setting the value to 0 allows all the resources
in the collection to be locked with the Timeout header specified in the request.

If no Timeout header is specified, then the resource is locked with
infinite timeout. If a request has a Timeout header set to the value Infinite, then also, the resource is locked with infinite timeout.

If the request for a WebDAV resource has a Timeout header value that
is equal to or greater than the minlocktimeout value specified
in server.xml, then the resource is locked for the period
of time specified in the request.

However, if the request has a Timeout header value that is lower than
the minlocktimeout value specified in server.xml,
then the resource is locked with the minlocktimeout value
specified in server.xml.

The following table illustrates how the server handles locking requests:

Table 10–3 How Sun Java System Web Server
handles locking requests

If Timeout header value in Request is set to:

The resource is:

Infinite

Locked with timeout set to -1 (infinite)

None

Locked with timeout set to -1 (infinite)

Second-xxx

Locked with xxx value, if xxx is
equal to or greater than minlocktimeout value set in server.xml

or

locked with minlocktimeout value specified
in server.xml, if xxx is lower than minlocktimeout value set in server.xml.