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:
-
/dav/users/{username}/path/to/collection/
-
/dav/collection/{uuid of the collection itself}/
-
/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)
Locking
Cosmo does not supporting locking. It does not report support for WebDAV class 2.
Methods
PROPFIND
The server ignores the
DAV:include element which may specified with
DAV:allprop in a
PROPFIND request. (
Bug 10845)
PROPPATCH
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)
MKCOL
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.
GET
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.
DELETE
Since the server does not support locking, it will never return a
207 response to a
DELETE request.
PUT
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.
COPY
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
MOVE
All notes for
COPY apply equally to
MOVE.
Security
The server does not support Digest authentication (
RFC 2617). (
Bug 10852)
Litmus
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.