r17 - 18 Sep 2007 - 07:33:25 - BrianMoseleyYou are here: OSAF >  Projects Web  >  CosmoHome > CosmoDevelopmentHome > CosmoWebdav

WebDAV in Cosmo

This document describes the implementation of WebDAV (RFC 4918) in Cosmo as of version 0.8.

URL Namespace

The DAV subsystem implements this URL namespace (all paths are relative to the context path [e.g. /chandler ]):

URI-path Description
/dav/users/ Principal collection providing the root URL namespace for user principals (see CosmoWebdavAcl)
/dav/users/{username} Principal resource representing a user account (see CosmoWebdavAcl)
/dav/{username}/ "Home collection" providing the root URL namespace for a user account; also acts as a CalDAV calendar home collection (see CosmoCaldav)
/dav/collection/{uuid}/ Collection resource identified by the provided UUID
/dav/collection/{uuid}/foo/bar Descendent resource of the collection identified by the provided UUID
/dav/item/{uuid} Item resource identified by the provided UUID

No resource is defined at /dav/ .

A particular collection is identified by several distinct URLs:

  1. /dav/users/{username}/path/to/collection/
  2. /dav/collection/{uuid of the collection itself}/
  3. /dav/collection/{uuid of an ancestor collection}/path/to/collection/

(Note that there will be one meaningful URL of the final form for each ancestor collection, up to and including the home collection.

Items are similarly identified. Which form is chosen by the server in the content of a response is determined by the form that is specified in the request URI.

MKCOL may be used to create a regular collection at any point within a user's home collection. There are no restrictions on size or media type for resources PUT into a regular collection.

See CosmoCaldav for details on creating calendar collections within a user's home collection.

Resource Properties

Cosmo maps resource properties to item properties and attributes. Some live properties, like DAV:creationdate, are mapped directly to Item instance variables. Others, such as DAV:getetag, are not stored at all but instead are derived from item data when needed to service a request. Dead properties are mapped to instances of XmlAttribute. The XML representing a dead property is normalized and written into the database as a string. The prefixes provided by the client are preserved.

Cosmo ignores the xml:lang attribute for all RFC 4918 live properties and for all dead properties. (Bug 10468)


Cosmo does not supporting locking. It does not report support for WebDAV class 2.



The server ignores the DAV:include element which may specified with DAV:allprop in a PROPFIND request. (Bug 10845)


The server does not guarantee to process the properties listed within each DAV:set or DAV:remove in document order. It does guarantee to process each DAV:set and DAV:remove in document order. (Bug 10846)

When more than one property cannot be set or removed, the server reports the error message for only one of the failed properties (in the DAV:responsedescription element). All other properties report a 424 Dependency Failed status. (Bug 10847)

When a client attempts to set or remove a protected property, the server does not include the precondition code cannot-modify-protected-property in the response body; the status is 403 and the response description is something like Property {DAV:}displayname is protected. (Bug 10849)


The server does not auto-create any resources within a collection.

The server does not support bodies for MKCOL requests. If a body is detected, the server returns a 415 response.


The server responds to GET of an item collection (one located within a user's home collection) with an HTML page listing the members and properties of the collection and links to various other collections and resources of interest.


Since the server does not support locking, it will never return a 207 response to a DELETE request.


When processing a PUT for a resource located in a regular (non-calendar) collection, if the client does not provide a Content-Type header in a PUT request, the server assigns a content type to the resource. The content type is chosen by examining the file type extension, if any, specified in the resource name (the last segment of the request URI). If an extension is found, it is used to look up a corresponding MIME media type (many common extension/media type mappings are supported). If no media type is found, or if the resource name does not include an extension, the server assigns the content type application/octet-stream.


When overwriting an existing destination resource, that resource is first deleted before copying the source resource. This means that after the copy is complete, the destination resource's properties and content match those of the source resource (excluding recomputed live properties) and do not include any properties or content from the overwritten resource.

When copying a collection, the DAV:getlastmodified property is not updated for member resources. (Bug 10843)

When copying a collection, if an error occurs copying an internal member, the server simply aborts the operation altogether and returns a 4xx or 5xx response, not a 207 as specified. (Bug 10851)

The server does not support copying a resource to another server. The destination URI must match the request URI in scheme and authority (if the destination URI is absolute) and absolute-path prefix (context path - /chandler - plus servlet path - /dav ).

Request URI: http://localhost:8080/chandler/dav/bcm/source
OK: http://localhost:8080/chandler/dav/bcm/destination
OK: /chandler/dav/bcm/destination
Not OK: https://localhost:8080/chandler/dav/bcm/destination
Not OK: http://otherhost/chandler/dav/bcm/destination
Not OK: http://localhost:8080/chandler/bcm/destination
Not OK: /bcm/destination


All notes for COPY apply equally to MOVE.


The server does not support Digest authentication (RFC 2617). (Bug 10852)


Litmus is a test suite used to verify servers' WebDAV compliance.

Litmus basic test 12 emits the warning MKCOL with missing intermediate gave 403, should be 409. This happens when the request URI specifies both a resource and at least one ancestor that do not exist. In this case, the server does not have enough information to calculate access priviliges and therefore returns a 403 rather than a 409.

Litmus props tests 15-21,23 fail because the failing PROPPATCH tests omit the Content-Type header and thus cause 400 responses. This is believed to be a bug in litmus 0.11.

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r17 < r16 < r15 < r14 < r13 | More topic actions
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.