Network Working Group | G. Clemm |
Request for Comments: 3253 | Rational Software |
Category: Standards Track | J. Amsden |
T. Ellison | |
IBM | |
C. Kaler | |
Microsoft | |
J. Whitehead | |
U.C. Santa Cruz | |
March 2002 |
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © The Internet Society (2002). All Rights Reserved.
This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.
This document specifies a set of methods, headers, and properties that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. Versioning is concerned with tracking and accessing the history of important states of a web resource, such as a standalone web page. The benefits of versioning in the context of the worldwide web include:¶
WebDAV Versioning defines both basic and advanced versioning functionality.¶
Basic versioning allows users to: ¶
Advanced versioning provides additional functionality for parallel development and configuration management of sets of web resources.¶
This document will first define the properties and method semantics for the basic versioning features, and then define the additional properties and method semantics for the advanced versioning features. An implementer that is only interested in basic versioning should skip the advanced versioning sections (Section 10 to Section 14).¶
To maximize interoperability and the use of existing protocol functionality, versioning support is designed as extensions to the WebDAV protocol [RFC2518], which itself is an extension to the HTTP protocol [RFC2616]. All method marshalling and postconditions defined by RFC 2518 and RFC 2616 continue to hold, to ensure that versioning unaware clients can interoperate successfully with versioning servers. Although the versioning extensions are designed to be orthogonal to most aspects of the WebDAV and HTTP protocols, a clarification to RFC 2518 is required for effective interoperable versioning. This clarification is described in Section 1.7.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.¶
The term "protected" is placed in parentheses following the definition of a protected property (see Section 1.4.2).¶
The term "computed" is placed in parentheses following the definition of a computed property (see Section 1.4.3).¶
When an XML element type in the "DAV:" namespace is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type.¶
When a method is defined in this document, a list of preconditions and postconditions will be defined for that method. If the semantics of an existing method is being extended, a list of additional preconditions and postconditions will be defined. A precondition or postcondition is prefixed by a parenthesized XML element type that identifies that precondition or postcondition (see Section 1.6).¶
This document uses the terms defined in RFC 2616, in RFC 2518, and in this section. Section 2.2 defines the semantic versioning model underlying this terminology.¶
Version Control, Checked-In, Checked-Out ¶
Versionable Resource ¶
Version-Controlled Resource ¶
Checked-Out Resource ¶
Version Resource ¶
Version History Resource ¶
Version Name ¶
Predecessor, Successor, Ancestor, Descendant ¶
Root Version Resource ¶
Workspace Resource ¶
Working Resource ¶
Fork, Merge ¶
The following diagram illustrates several of the previous definitions. Each box represents a version and each line between two boxes represents a predecessor/successor relationship. For example, it shows V3 is a predecessor of V5, V7 is a successor of V5, V1 is an ancestor of V4, and V7 is a descendant of V4. It also shows that there is a fork at version V2 and a merge at version V7.¶
History of foo.html
┌───┐ Root Version -------> │ │ V1 └───┘ ^ | | | | ┌───┐ | Version Name ----> V2 │ │ | Ancestor └───┘ | / \ | / \ | ┌───┐ ┌───┐ │ │ V3 │ │ V4 ^ └───┘ └───┘ | | | | Predecessor | | | | ┌───┐ ┌───┐ | │ │ V5 │ │ V6 | Descendant └───┘ └───┘ | Successor | \ / | | \ / | v ┌───┐ v │ │ V7 └───┘
Label ¶
Unless an initial value of a property of a given type is defined by this document, the initial value of a property of that type is implementation dependent.¶
When a property of a specific kind of resource is "protected", the property value cannot be updated on that kind of resource except by a method explicitly defined as updating that specific property. In particular, a protected property cannot be updated with a PROPPATCH request. Note that a given property can be protected on one kind of resource, but not protected on another kind of resource.¶
When a property is "computed", its value is defined in terms of a computation based on the content and other properties of that resource, or even of some other resource. When the semantics of a method is defined in this document, the effect of that method on non-computed properties will be specified; the effect of that method on computed properties will not be specified, but can be inferred from the computation defined for those properties. A computed property is always a protected property.¶
Some properties take a Boolean value of either "false" or "true".¶
The DAV:href XML element is defined in RFC 2518, Section 12.3.¶
Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the DAV namespace MUST NOT be used in the request or response body of a versioning method unless that XML element is explicitly defined in an IETF RFC.¶
A "precondition" of a method describes the state of the server that must be true for that method to be performed. A "postcondition" of a method describes the state of the server that must be true after that method has been completed. If a method precondition or postcondition for a request is not satisfied, the response status of the request MUST be either 403 (Forbidden) if the request should not be repeated because it will always fail, or 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request.¶
In order to allow better client handling of 403 and 409 responses, a distinct XML element type is associated with each method precondition and postcondition of a request. When a particular precondition is not satisfied or a particular postcondition cannot be achieved, the appropriate XML element MUST be returned as the child of a top-level DAV:error element in the response body, unless otherwise negotiated by the request. In a 207 Multi-Status response, the DAV:error element would appear in the appropriate DAV:responsedescription element.¶
>>REQUEST
CHECKOUT /foo.html HTTP/1.1 Host: www.webdav.org
>>RESPONSE
HTTP/1.1 409 Conflict Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:must-be-checked-in/> </D:error>
In this example, the request to CHECKOUT /foo.html fails because /foo.html is not checked in.¶
RFC 2518, Section 8.8.4 states:¶
"If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource."¶
The purpose of this sentence is to ensure that following a COPY, all destination resources have the same content and dead properties as the corresponding resources identified by the request-URL (where a resource with a given name relative to the Destination URL "corresponds" to a resource with the same name relative to the request-URL). If at the time of the request, there already is a resource at the destination that has the same resource type as the corresponding resource at the request-URL, that resource MUST NOT be deleted, but MUST be updated to have the content and dead properties of its corresponding member. If a client wishes all resources at the destination to be deleted prior to the COPY, it MUST explicitly issue a DELETE request.¶
The difference between updating a resource and replacing a resource with a new resource is especially important when resource history is being maintained (the former adds to an existing history, while the latter creates a new history). In addition, locking and access control constraints might allow you to update a resource, but not allow you to delete it and create a new one in its place.¶
Note that this clarification does not apply to a MOVE request. A MOVE request with Overwrite:T MUST perform the DELETE with "Depth:infinity" on the destination resource prior to performing the MOVE.¶
If a write-locked resource has a non-computed property defined by this document, the property value MUST NOT be changed by a request unless the appropriate lock token is included in the request. Since every method introduced in this document other than REPORT modifies at least one property defined by this document, every versioning method other than REPORT is affected by a write lock. In particular, the method MUST fail with a 423 (Locked) status if the resource is write-locked and the appropriate token is not specified in an If request header.¶
Each basic versioning feature defines extensions to existing HTTP and WebDAV methods, as well as new resource types, live properties, and methods.¶
A server MAY support any combination of versioning features. However, in order to minimize the complexity of a WebDAV basic versioning client, a WebDAV basic versioning server SHOULD support one of the following three "packages" (feature sets):¶
The core-versioning package supports linear versioning by both versioning-aware and versioning-unaware clients. A versioning-aware client can use reports and properties to access previous versions of a version-controlled resource.¶
The basic workspace packages support parallel development of version-controlled resources. Each client has its own configuration of the shared version-controlled resources, and can make changes to its configuration without disturbing that of another client.¶
In the basic-server-workspace package, all persistent state is maintained on the server. Each client has its own workspace resource allocated on the server, where each workspace identifies a configuration of the shared version-controlled resources. Each client makes changes to its workspace, and can transfer changes when appropriate from one workspace to another. The server workspace package is appropriate for clients with no local persistent state, or for clients that wish to expose their working configurations to other clients.¶
In the basic-client-workspace package, each client maintains in local persistent storage the state for its configuration of the shared version-controlled resources. When a client is ready to make its changes visible to other clients, it allocates a set of "working resources" on the server, updates the content and dead properties of these working resources, and then uses the set of working resources to update the version-controlled resources. The working resources are used, instead of directly updating the version-controlled resources, so that sets of consistent updates can be prepared in parallel by multiple clients. Also, a working resource allows a client to prepare a single update that requires multiple server requests (e.g. updating both the content and dead properties of a resource requires both a PUT and a PROPPATCH). The client workspace package simplifies the server implementation by requiring each client to maintain its own namespace, but this requires that the clients have local persistent state, and does not allow clients to expose their working configurations to other clients.¶
A server that supports both basic workspace packages will interoperate with all basic versioning clients.¶
In order to track the history of the content and dead properties of a versionable resource, a user can put the resource under version control with a VERSION-CONTROL request. A VERSION-CONTROL request performs three distinct operations:¶
Note that a versionable resource and a version-controlled resource are not new types of resources (i.e. they introduce no new DAV:resourcetype), but rather they are any type of resource that supports the methods and live properties defined for them in this document, in addition to all the methods and live properties implied by their DAV:resourcetype. For example, a collection (whose DAV:resourcetype is DAV:collection) is a versionable resource if it supports the VERSION-CONTROL method, and is a version-controlled resource if it supports the version-controlled resource methods and live properties.¶
In the following example, foo.html is a versionable resource that is put under version control. After the VERSION-CONTROL request succeeds, there are two additional resources: a new version history resource and a new version resource in that version history. The versionable resource is converted into a version-controlled resource, whose DAV:checked-in property identifies the new version resource. The content and dead properties of a resource are represented by the symbol appearing inside the box for that resource (e.g., "S1" in the following example).¶
===VERSION-CONTROL==> | ┌────┐ version | version- │ │ history versionable | controlled └────┘ resource resource | resource | /foo.html | /foo.html | | v ┌────┐ | ┌────┐ checked-in ┌────┐ version │ S1 │ | │ S1 │----------->│ S1 │ resource └────┘ | └────┘ └────┘ /his/73/ver/1
Thus, whereas before the VERSION-CONTROL request there was only one, non-version-controlled resource, after VERSION-CONTROL there are three separate, distinct resources, each containing its own state and properties: the version-controlled resource, the version resource, and the version history resource. Since the version-controlled resource and the version resource are separate, distinct resources, when a method is applied to a version-controlled resource, it is only applied to that version-controlled resource, and is not applied to the version resource that is currently identified by the DAV:checked-in property of that version-controlled resource. Although the content and dead properties of a checked-in version-controlled resource are required to be the same as those of its current DAV:checked-in version, its live properties may differ. An implementation may optimize storage by retrieving the content and dead properties of a checked-in version-controlled resource from its current DAV:checked-in version rather than storing them in the version-controlled resource, but this is just an implementation optimization.¶
Normally, a resource is placed under version control with an explicit VERSION-CONTROL request. A server MAY automatically place every new versionable resource under version control. In this case, the resulting state on the server MUST be the same as if the client had explicitly applied a VERSION-CONTROL request to the versionable resource.¶
In order to use methods like PUT and PROPPATCH to directly modify the content or dead properties of a version-controlled resource, the version-controlled resource must first be checked out. When the checked-out resource is checked in, a new version is created in the version history of that version-controlled resource. The version that was checked out is remembered as the predecessor of the new version.¶
The DAV:auto-version property (see Section 3.2.2) of a checked-in version-controlled resource determines how it responds to a method that attempts to modify its content or dead properties. Possible responses include:¶
The following diagram illustrates the effect of the checkout/checkin process on a version-controlled resource and its version history. The symbol inside a box (S1, S2, S3) represents the current content and dead properties of the resource represented by that box. The symbol next to a box (V1, V2, V3) represents the URL for that resource.¶
===checkout==> ===PUT==> ===checkin==> /foo.html (version-controlled resource) ┌────┐ | ┌────┐ | ┌────┐ | ┌────┐ │ S2 │ | │ S2 │ | │ S3 │ | │ S3 │ └────┘ | └────┘ | └────┘ | └────┘ Checked-In=V2|Checked-Out=V2|Checked-Out=V2|Checked-In=V3 /his/73 (version history for /foo.html) ┌────┐ | ┌────┐ | ┌────┐ | ┌────┐ │ S1 │ V1 | │ S1 │ V1 | │ S1 │ V1 | │ S1 │ V1 └────┘ | └────┘ | └────┘ | └────┘ | | | | | | | | | | | | | | ┌────┐ | ┌────┐ | ┌────┐ | ┌────┐ │ S2 │ V2 | │ S2 │ V2 | │ S2 │ V2 | │ S2 │ V2 └────┘ | └────┘ | └────┘ | └────┘ | | | | | | | | | | | ┌────┐ | | | │ S3 │ V3 | | | └────┘
Note that a version captures only a defined subset of the state of a resource. In particular, a version of a basic resource captures its content and dead properties, but not its live properties.¶
Some versioning information about a resource requires that parameters be specified along with that request for information. Included in basic versioning is the required support for an extensible reporting mechanism, which includes a REPORT method as well as a live property for determining what reports are supported by a particular resource. The REPORT method is required by versioning, but it can be used in non-versioning WebDAV extensions.¶
To allow a client to query the properties of all versions in the version history of a specified version-controlled resource, basic versioning provides the DAV:version-tree report (see Section 3.7). A more powerful version history reporting mechanism is provided by applying the DAV:expand-property report (see Section 3.8) to a version history resource (see Section 5).¶
The version-control feature provides support for putting a resource under version control, creating an associated version-controlled resource and version history resource as described in Section 2.2.1. A server indicates that it supports the version-control feature by including the string "version-control" as a field in the DAV header in the response to an OPTIONS request. The version-control feature MUST be supported if any other versioning feature is supported.¶
The version-control feature introduces the following REQUIRED properties for any WebDAV resource.¶
This property is used to track a brief comment about a resource that is suitable for presentation to a user. The DAV:comment of a version can be used to indicate why that version was created.¶
<!ELEMENT comment (#PCDATA)> PCDATA value: string
This property contains a description of the creator of the resource that is suitable for presentation to a user. The DAV:creator-displayname of a version can be used to indicate who created that version.¶
<!ELEMENT creator-displayname (#PCDATA)> PCDATA value: string
This property identifies the methods that are supported by the resource. A method is supported by a resource if there is some state of that resource for which an application of that method will successfully satisfy all postconditions of that method, including any additional postconditions added by the features supported by that resource.¶
<!ELEMENT supported-method-set (supported-method*)> <!ELEMENT supported-method ANY> <!ATTLIST supported-method name NMTOKEN #REQUIRED> name value: a method name
This property identifies the live properties that are supported by the resource. A live property is supported by a resource if that property has the semantics defined for that property. The value of this property MUST identify all live properties defined by this document that are supported by the resource, and SHOULD identify all live properties that are supported by the resource.¶
<!ELEMENT supported-live-property-set (supported-live-property*)> <!ELEMENT supported-live-property name> <!ELEMENT prop ANY> ANY value: a property element type
This property identifies the reports that are supported by the resource.¶
<!ELEMENT supported-report-set (supported-report*)> <!ELEMENT supported-report report> <!ELEMENT report ANY> ANY value: a report element type
The version-control feature introduces the following REQUIRED properties for a version-controlled resource.¶
This property appears on a checked-in version-controlled resource, and identifies a version that has the same content and dead properties as the version-controlled resource. This property is removed when the resource is checked out, and then added back (identifying a new version) when the resource is checked back in.¶
<!ELEMENT checked-in (href)>
If the DAV:auto-version value is DAV:checkout-checkin, when a modification request (such as PUT/PROPPATCH) is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout and followed by a checkin operation.¶
If the DAV:auto-version value is DAV:checkout-unlocked-checkin, when a modification request is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout operation. If the resource is not write-locked, the request is automatically followed by a checkin operation.¶
If the DAV:auto-version value is DAV:checkout, when a modification request is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout operation.¶
If the DAV:auto-version value is DAV:locked-checkout, when a modification request is applied to a write-locked checked-in version-controlled resource, the request is automatically preceded by a checkout operation.¶
If an update to a write-locked checked-in resource is automatically preceded by a checkout of that resource, the checkout is associated with the write lock. When this write lock is removed (e.g. from an UNLOCK or a lock timeout), if the resource has not yet been checked in, the removal of the write lock is automatically preceded by a checkin operation.¶
A server MAY refuse to allow the value of the DAV:auto-version property to be modified, or MAY only support values from a subset of the valid values.¶
<!ELEMENT auto-version (checkout-checkin | checkout-unlocked-checkin | checkout | locked-checkout)? > <!ELEMENT checkout-checkin EMPTY> <!ELEMENT checkout-unlocked-checkin EMPTY> <!ELEMENT checkout EMPTY> <!ELEMENT locked-checkout EMPTY>
The version-control feature introduces the following REQUIRED properties for a checked-out resource.¶
This property identifies the version that was identified by the DAV:checked-in property at the time the resource was checked out. This property is removed when the resource is checked in.¶
<!ELEMENT checked-out (href)>
This property determines the DAV:predecessor-set property of the version that results from checking in this resource.¶
A server MAY reject attempts to modify the DAV:predecessor-set of a version-controlled resource.¶
<!ELEMENT predecessor-set (href+)>
The version-control feature introduces the following REQUIRED properties for a version.¶
This property identifies each predecessor of this version. Except for the root version, which has no predecessors, each version has at least one predecessor.¶
<!ELEMENT predecessor-set (href*)>
This property identifies each version whose DAV:predecessor-set identifies this version.¶
<!ELEMENT successor-set (href*)>
This property identifies each checked-out resource whose DAV:checked-out property identifies this version.¶
<!ELEMENT checkout-set (href*)>
This property contains a server-defined string that is different for each version in a given version history. This string is intended for display for a user, unlike the URL of a version, which is normally only used by a client and not displayed for a user.¶
<!ELEMENT version-name (#PCDATA)> PCDATA value: string
A VERSION-CONTROL request can be used to create a version-controlled resource at the request-URL. It can be applied to a versionable resource or to a version-controlled resource.¶
If the request-URL identifies a versionable resource, a new version history resource is created, a new version is created whose content and dead properties are copied from the versionable resource, and the resource is given a DAV:checked-in property that is initialized to identify this new version.¶
If the request-URL identifies a version-controlled resource, the resource just remains under version-control. This allows a client to be unaware of whether or not a server automatically puts a resource under version control when it is created.¶
If a VERSION-CONTROL request fails, the server state preceding the request MUST be restored.¶
Marshalling: ¶
<!ELEMENT version-control ANY>
<!ELEMENT version-control-response ANY>
Postconditions: ¶
>>REQUEST
VERSION-CONTROL /foo.html HTTP/1.1 Host: www.webdav.org Content-Length: 0
>>RESPONSE
HTTP/1.1 200 OK
In this example, /foo.html is put under version control. A new version history is created for it, and a new version is created that has a copy of the content and dead properties of /foo.html. The DAV:checked-in property of /foo.html identifies this new version.¶
A REPORT request is an extensible mechanism for obtaining information about a resource. Unlike a resource property, which has a single value, the value of a report can depend on additional information specified in the REPORT request body and in the REPORT request headers.¶
Marshalling: ¶
Preconditions: ¶
Postconditions: ¶
The DAV:version-tree report describes the requested properties of all the versions in the version history of a version. If the report is requested for a version-controlled resource, it is redirected to its DAV:checked-in or DAV:checked-out version.¶
The DAV:version-tree report MUST be supported by all version resources and all version-controlled resources.¶
Marshalling: ¶
<!ELEMENT version-tree ANY> ANY value: a sequence of zero or more elements, with at most one DAV:prop element. prop: see RFC 2518, Section 12.11
multistatus: see RFC 2518, Section 12.9
The version history drawn below would produce the following version tree report.¶
foo.html History ┌───┐ │ │ V1 └───┘ / \ / \ ┌───┐ ┌───┐ │ │ V2 │ │ V2.1.1 └───┘ └───┘
>>REQUEST
REPORT /foo.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:version-tree xmlns:D="DAV:"> <D:prop> <D:version-name/> <D:creator-displayname/> <D:successor-set/> </D:prop> </D:version-tree>
>>RESPONSE
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://repo.webdav.org/his/23/ver/V1</D:href> <D:propstat> <D:prop> <D:version-name>V1</D:version-name> <D:creator-displayname>Fred</D:creator-displayname> <D:successor-set> <D:href>http://repo.webdav.org/his/23/ver/V2</D:href> <D:href>http://repo.webdav.org/his/23/ver/V2.1.1</D:href> </D:successor-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://repo.webdav.org/his/23/ver/V2</D:href> <D:propstat> <D:prop> <D:version-name>V2</D:version-name> <D:creator-displayname>Fred</D:creator-displayname> <D:successor-set/> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://repo.webdav.org/his/23/ver/V2.1.1</D:href> <D:propstat> <D:prop> <D:version-name>V2.1.1</D:version-name> <D:creator-displayname>Sally</D:creator-displayname> <D:successor-set/> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
Many property values are defined as a DAV:href, or a set of DAV:href elements. The DAV:expand-property report provides a mechanism for retrieving in one request the properties from the resources identified by those DAV:href elements. This report not only decreases the number of requests required, but also allows the server to minimize the number of separate read transactions required on the underlying versioning store.¶
The DAV:expand-property report SHOULD be supported by all resources that support the REPORT method.¶
Marshalling: ¶
<!ELEMENT expand-property (property*)> <!ELEMENT property (property*)> <!ATTLIST property name NMTOKEN #REQUIRED> name value: a property element type <!ATTLIST property namespace NMTOKEN "DAV:"> namespace value: an XML namespace
multistatus: see RFC 2518, Section 12.9
This example describes how to query a version-controlled resource to determine the DAV:creator-display-name and DAV:activity-set of every version in the version history of that version-controlled resource. This example assumes that the server supports the version-history feature (see Section 5).¶
>>REQUEST
REPORT /foo.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:expand-property xmlns:D="DAV:"> <D:property name="version-history"> <D:property name="version-set"> <D:property name="creator-displayname"/> <D:property name="activity-set"/> </D:property> </D:property> </D:expand-property>
>>RESPONSE
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.webdav.org/foo.html</D:href> <D:propstat> <D:prop> <D:version-history> <D:response> <D:href>http://repo.webdav.org/his/23</D:href> <D:propstat> <D:prop> <D:version-set> <D:response> <D:href>http://repo.webdav.org/his/23/ver/1</D:href> <D:propstat> <D:prop> <D:creator-displayname>Fred</D:creator-displayname> <D:activity-set> <D:href> http://www.webdav.org/ws/dev/sally </D:href> </D:activity-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://repo.webdav.org/his/23/ver/2</D:href> <D:propstat> <D:prop> <D:creator-displayname>Sally</D:creator-displayname> <D:activity-set> <D:href>http://repo.webdav.org/act/add-refresh-cmd</D:href> </D:activity-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:version-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:version-history> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
In this example, the DAV:creator-displayname and DAV:activity-set properties of the versions in the DAV:version-set of the DAV:version-history of http://www.webdav.org/foo.html are reported.¶
If the server supports the version-control feature, it MUST include "version-control" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
Additional Preconditions: ¶
Additional Postconditions: ¶
A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined by this document. This allows a versioning server to perform efficiently when a naive client, which does not understand the cost of asking a server to compute all possible live properties, issues a DAV:allprop PROPFIND request.¶
Additional Preconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Note that these semantics apply both to an explicit UNLOCK request, as well as to the removal of a lock because of a lock timeout. If a precondition or postcondition cannot be satisfied, the lock timeout MUST NOT occur.¶
Additional Preconditions: ¶
Additional Postconditions: ¶
With the version-control feature, WebDAV locking can be used to avoid the proliferation of versions that would result if every modification to a version-controlled resource produced a new version. The checkout-in-place feature provides an alternative mechanism that allows a client to explicitly check out and check in a resource to create a new version.¶
The checkout-in-place feature introduces the following REQUIRED properties for a version.¶
This property controls the behavior of CHECKOUT when a version already is checked out or has a successor. If the DAV:checkout-fork of a version is DAV:forbidden, a CHECKOUT request MUST fail if it would result in that version appearing in the DAV:predecessor-set or DAV:checked-out property of more than one version or checked-out resource. If DAV:checkout-fork is DAV:discouraged, such a CHECKOUT request MUST fail unless DAV:fork-ok is specified in the CHECKOUT request body.¶
A server MAY reject attempts to modify the DAV:checkout-fork of a version. ¶
<!ELEMENT checkout-fork ANY> ANY value: A sequence of elements with at most one DAV:discouraged or DAV:forbidden element. <!ELEMENT discouraged EMPTY> <!ELEMENT forbidden EMPTY>
This property controls the behavior of CHECKIN when a version already has a successor. If the DAV:checkin-fork of a version is DAV:forbidden, a CHECKIN request MUST fail if it would result in that version appearing in the DAV:predecessor-set of more than one version. If DAV:checkin-fork is DAV:discouraged, such a CHECKIN request MUST fail unless DAV:fork-ok is specified in the CHECKIN request body.¶
A server MAY reject attempts to modify the DAV:checkout-fork of a version. ¶
<!ELEMENT checkin-fork ANY> ANY value: A sequence of elements with at most one DAV:discouraged or DAV:forbidden element. <!ELEMENT discouraged EMPTY> <!ELEMENT forbidden EMPTY>
The checkout-in-place feature introduces the following REQUIRED properties for a checked-out resource.¶
This property determines the DAV:checkout-fork property of the version that results from checking in this resource.¶
This property determines the DAV:checkin-fork property of the version that results from checking in this resource.¶
A CHECKOUT request can be applied to a checked-in version-controlled resource to allow modifications to the content and dead properties of that version-controlled resource.¶
If a CHECKOUT request fails, the server state preceding the request MUST be restored.¶
Marshalling: ¶
<!ELEMENT checkout ANY>
<!ELEMENT fork-ok EMPTY>
<!ELEMENT checkout-response ANY>
Preconditions: ¶
Postconditions: ¶
>>REQUEST
CHECKOUT /foo.html HTTP/1.1 Host: www.webdav.org Content-Length: 0
>>RESPONSE
HTTP/1.1 200 OK Cache-Control: no-cache
In this example, the version-controlled resource /foo.html is checked out.¶
A CHECKIN request can be applied to a checked-out version-controlled resource to produce a new version whose content and dead properties are copied from the checked-out resource.¶
If a CHECKIN request fails, the server state preceding the request MUST be restored.¶
Marshalling: ¶
<!ELEMENT checkin ANY> ANY value: A sequence of elements with at most one DAV:keep-checked-out element and at most one DAV:fork-ok element. <!ELEMENT keep-checked-out EMPTY> <!ELEMENT fork-ok EMPTY>
<!ELEMENT checkin-response ANY>
Preconditions: ¶
Postconditions: ¶
>>REQUEST
CHECKIN /foo.html HTTP/1.1 Host: www.webdav.org Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created Location: http://repo.webdav.org/his/23/ver/32 Cache-Control: no-cache
In this example, version-controlled resource /foo.html is checked in, and a new version is created at http://repo.webdav.org/his/23/ver/32.¶
An UNCHECKOUT request can be applied to a checked-out version-controlled resource to cancel the CHECKOUT and restore the pre-CHECKOUT state of the version-controlled resource.¶
If an UNCHECKOUT request fails, the server MUST undo any partial effects of the UNCHECKOUT request.¶
Marshalling: ¶
<!ELEMENT uncheckout ANY>
<!ELEMENT uncheckout-response ANY>
Preconditions: ¶
Postconditions: ¶
>>REQUEST
UNCHECKOUT /foo.html HTTP/1.1 Host: www.webdav.org Content-Length: 0
>>RESPONSE
HTTP/1.1 200 OK Cache-Control: no-cache
In this example, the content and dead properties of the version-controlled resource identified by http://www.webdav.org/foo.html are restored to their values preceding the most recent CHECKOUT of that version-controlled resource.¶
If a server supports the checkout-in-place feature, it MUST include "checkout-in-place" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
It is often useful to have access to a version history even after all version-controlled resources for that version history have been deleted. A server can provide this functionality by supporting version history resources. A version history resource is a resource that exists in a server defined namespace and therefore is unaffected by any deletion or movement of version-controlled resources. A version history resource is an appropriate place to add a property that logically applies to all states of a resource. The DAV:expand-property report (see Section 3.8) can be applied to the DAV:version-set of a version history resource to provide a variety of useful reports on all versions in that version history.¶
The DAV:resourcetype of a version history MUST be DAV:version-history.¶
The version-history feature introduces the following REQUIRED properties for a version history.¶
This property identifies each version of this version history. ¶
<!ELEMENT version-set (href+)>
This property identifies the root version of this version history. ¶
<!ELEMENT root-version (href)>
The version-history feature introduces the following REQUIRED property for a version-controlled resource.¶
This property identifies the version history resource for the DAV:checked-in or DAV:checked-out version of this version-controlled resource. ¶
<!ELEMENT version-history (href)>
The version-history feature introduces the following REQUIRED property for a version.¶
This property identifies the version history that contains this version. ¶
<!ELEMENT version-history (href)>
Many properties identify a version from some version history. It is often useful to be able to efficiently locate a version-controlled resource for that version history. The DAV:locate-by-history report can be applied to a collection to locate the collection member that is a version-controlled resource for a specified version history resource.¶
Marshalling: ¶
<!ELEMENT locate-by-history (version-history-set, prop)> <!ELEMENT version-history-set (href+)> prop: see RFC 2518, Section 12.11
Preconditions: ¶
>>REQUEST
REPORT /ws/public HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:locate-by-history xmlns:D="DAV:"> <D:version-history-set> <D:href>http://repo.webdav.org/his/23</D:href> <D:href>http://repo.webdav.org/his/84</D:href> <D:href>http://repo.webdav.org/his/129</D:href> <D:version-history-set/> <D:prop> </D:version-history> </D:prop> </D:locate-by-history>
>>RESPONSE
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.webdav.org/ws/public/x/test.html</D:href> <D:propstat> <D:prop> <D:version-history> <D:href>http://repo.webdav.org/his/23</D:href> </D:version-history> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
In this example, there is only one version-controlled member of /ws/public that is a version-controlled resource for one of the three specified version history resources. In particular, /ws/public/x/test.html is the version-controlled resource for http://repo.webdav.org/his/23.¶
If the server supports the version-history feature, it MUST include "version-history" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
A DAV:version-history-collection-set element MAY be included in the request body to identify collections that may contain version history resources.¶
Additional Marshalling: ¶
<!ELEMENT options ANY> ANY value: A sequence of elements with at most one DAV:version-history-collection-set element.
<!ELEMENT options-response ANY> ANY value: A sequence of elements with at most one DAV:version-history-collection-set element. <!ELEMENT version-history-collection-set (href*)>
Additional Postconditions: ¶
Additional Preconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Additional Postconditions: ¶
In order to allow multiple users to work concurrently on adding versions to the same version history, it is necessary to allocate on the server multiple checked-out resources for the same version history. Even if only one user is making changes to a resource, that user will sometimes wish to create a "private" version, and then to expose that version at a later time. One way to provide this functionality depends on the client keeping track of its current set of checked-out resources. This is the working-resource feature defined in Section 8. The other way to provide this functionality avoids the need for persistent state on the client, and instead has the server maintain a human meaningful namespace for related sets of checked-out resources. This is the workspace feature defined in this section.¶
The workspace feature introduces a "workspace resource". A workspace resource is a collection whose members are related version-controlled and non-version-controlled resources. Multiple workspaces may be used to expose different versions and configurations of a set of version-controlled resources concurrently. In order to make changes to a version-controlled resource in one workspace visible in another workspace, that version-controlled resource must be checked in, and then the corresponding version-controlled resource in the other workspace can be updated to display the content and dead properties of the new version.¶
In order to ensure unambiguous merging (see Section 11) and baselining (see Section 12) semantics, a workspace may contain at most one version-controlled resource for a given version history. This is required for unambiguous merging because the MERGE method must identify which version-controlled resource is to be the merge target of a given version. This is required for unambiguous baselining because a baseline can only select one version for a given version-controlled resource.¶
Initially, an empty workspace can be created. Non-version-controlled resources can then be added to the workspace with standard WebDAV requests such as PUT and MKCOL. Version-controlled resources can be added to the workspace with VERSION-CONTROL requests. If the baseline feature is supported, collections in the workspace can be placed under baseline control, and then initialized by existing baselines.¶
The workspace feature introduces the following REQUIRED property for a workspace.¶
This property identifies each checked-out resource whose DAV:workspace property identifies this workspace. ¶
<!ELEMENT workspace-checkout-set (href*)>
The workspace feature introduces the following REQUIRED property for a WebDAV resource.¶
The DAV:workspace property of a workspace resource MUST identify itself. The DAV:workspace property of any other type of resource MUST be the same as the DAV:workspace of its parent collection. ¶
<!ELEMENT workspace (href)>
A MKWORKSPACE request creates a new workspace resource. A server MAY restrict workspace creation to particular collections, but a client can determine the location of these collections from a DAV:workspace-collection-set OPTIONS request (see Section 6.4).¶
If a MKWORKSPACE request fails, the server state preceding the request MUST be restored.¶
Marshalling: ¶
<!ELEMENT mkworkspace ANY>
<!ELEMENT mkworkspace-response ANY>
Preconditions: ¶
Postconditions: ¶
>>REQUEST
MKWORKSPACE /ws/public HTTP/1.1 Host: www.webdav.org Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created Cache-Control: no-cache
In this example, a new workspace is created at http://www.webdav.org/ws/public.¶
If a server supports the workspace feature, it MUST include "workspace" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
If a server supports the workspace feature, it MUST also support the checkout-in-place feature and the version-history feature.¶
A DAV:workspace-collection-set element MAY be included in the request body to identify collections that may contain workspace resources.¶
Additional Marshalling: ¶
<!ELEMENT options ANY> ANY value: A sequence of elements with at most one DAV:workspace-collection-set element.
<!ELEMENT options-response ANY> ANY value: A sequence of elements with at most one DAV:workspace-collection-set element. <!ELEMENT workspace-collection-set (href*)>
>>REQUEST
OPTIONS /doc HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:options xmlns:D="DAV:"> <D:version-history-collection-set/> <D:workspace-collection-set/> </D:options>
>>RESPONSE
HTTP/1.1 200 OK DAV: 1 DAV: version-control,checkout-in-place,version-history,workspace Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:options-response xmlns:D="DAV:"> <D:version-history-collection-set> <D:href>http://repo.webdav.org/his</D:href> </D:version-history-collection-set> <D:workspace-collection-set> <D:href>http://www.webdav.org/public/ws</D:href> <D:href>http://www.webdav.org/private/ws</D:href> </D:workspace-collection-set> </D:options-response>
In this example, the server indicates that it provides Class 1 DAV support and basic-server-workspace versioning support. In addition, the server indicates the requested locations of the version history resources and the workspace resources.¶
Additional Postconditions: ¶
Additional Postconditions: ¶
A VERSION-CONTROL request can be used to create a new version-controlled resource for an existing version history. This allows the creation of version-controlled resources for the same version history in multiple workspaces.¶
Additional Marshalling: ¶
<!ELEMENT version-control ANY> ANY value: A sequence of elements with at most one DAV:version element. <!ELEMENT version (href)>
Additional Preconditions: ¶
Additional Postconditions: ¶
>>REQUEST
VERSION-CONTROL /ws/public/bar.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:version-control xmlns:D="DAV:"> <D:version> <D:href>http://repo.webdav.org/his/12/ver/V3</D:href> </D:version> </D:version-control>
>>RESPONSE
HTTP/1.1 201 Created Cache-Control: no-cache
In this example, a new version-controlled resource is created at /ws/public/bar.html. The content and dead properties of the new version-controlled resource are initialized to be the same as those of the version identified by http://repo.webdav.org/his/12/ver/V3.¶
The update feature provides a mechanism for changing the state of a checked-in version-controlled resource to be that of another version from the version history of that resource.¶
The UPDATE method modifies the content and dead properties of a checked-in version-controlled resource (the "update target") to be those of a specified version (the "update source") from the version history of that version-controlled resource.¶
The response to an UPDATE request identifies the resources modified by the request, so that a client can efficiently update any cached state it is maintaining. Extensions to the UPDATE method allow multiple resources to be modified from a single UPDATE request (see Section 12.13).¶
Marshalling: ¶
<!ELEMENT update ANY> ANY value: A sequence of elements with at most one DAV:version element and at most one DAV:prop element. <!ELEMENT version (href)> prop: see RFC 2518, Section 12.11
multistatus: see RFC 2518, Section 12.9
Postconditions: ¶
>>REQUEST
UPDATE /foo.html HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:update xmlns:D="DAV:"> <D:version> <D:href>http://repo.webdav.org/his/23/ver/33</D:href> </D:version> </D:update>
>>RESPONSE
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Cache-Control: no-cache <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.webdav.org/foo.html</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response>
In this example, the content and dead properties of http://repo.webdav.org/his/23/ver/33 are copied to the version-controlled resource /foo.html, and the DAV:checked-in property of /foo.html is updated to refer to http://repo.webdav.org/his/23/ver/33.¶
If the server supports the update feature, it MUST include "update" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
A version "label" is a string that distinguishes one version in a version history from all other versions in that version history. A label can automatically be assigned by a server, or it can be assigned by a client in order to provide a meaningful name for that version. A given version label can be assigned to at most one version of a given version history, but client assigned labels can be reassigned to another version at any time. Note that although a given label can be applied to at most one version from the same version history, the same label can be applied to versions from different version histories.¶
For certain methods, if the request-URL identifies a version-controlled resource, a label can be specified in a Label request header (see Section 8.3) to cause the method to be applied to the version selected by that label from the version history of that version-controlled resource.¶
The label feature introduces the following REQUIRED property for a version.¶
This property contains the labels that currently select this version. ¶
<!ELEMENT label-name-set (label-name*)> <!ELEMENT label-name (#PCDATA)> PCDATA value: string
A LABEL request can be applied to a version to modify the labels that select that version. The case of a label name MUST be preserved when it is stored and retrieved. When comparing two label names to decide if they match or not, a server SHOULD use a case-sensitive URL-escaped UTF-8 encoded comparison of the two label names.¶
If a LABEL request is applied to a checked in version-controlled resource, the operation MUST be applied to the DAV:checked-in version of that version-controlled resource.¶
Marshalling: ¶
<!ELEMENT label ANY> ANY value: A sequence of elements with at most one DAV:add, DAV:set, or DAV:remove element. <!ELEMENT add (label-name)> <!ELEMENT set (label-name)> <!ELEMENT remove (label-name)> <!ELEMENT label-name (#PCDATA)> PCDATA value: string
<!ELEMENT label-response ANY>
Preconditions: ¶
Postconditions: ¶
>>REQUEST
LABEL /foo.html HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:label xmlns:D="DAV:"> <D:set> <D:label-name>default</D:label-name> </D:set> </D:label>
>>RESPONSE
HTTP/1.1 200 OK Cache-Control: no-cache
In this example, the label "default" is applied to the DAV:checked-in version of /foo.html.¶
For certain methods (e.g. GET, PROPFIND), if the request-URL identifies a version-controlled resource, a label can be specified in a Label request header to cause the method to be applied to the version selected by that label from the version history of that version-controlled resource.¶
The value of a label header is the name of a label, encoded using URL-escaped UTF-8. For example, the label "release B.3" is identified by the following header:¶
Label: release%20B.3
A Label header MUST have no effect on a request whose request-URL does not identify a version-controlled resource. In particular, it MUST have no effect on a request whose request-URL identifies a version or a version history.¶
A server MUST return an HTTP-1.1 Vary header containing Label in a successful response to a cacheable request (e.g., GET) that includes a Label header.¶
If the server supports the label feature, it MUST include "label" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
Additional Marshalling: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Additional Marshalling: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Additional Marshalling: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
If the server supports the working-resource option, a LABEL header may be included to check out the version selected by the specified label.¶
Additional Marshalling: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
If the request body of an UPDATE request contains a DAV:label-name element, the update target is the resource identified by the request-URL, and the update source is the version selected by the specified label from the version history of the update target.¶
Additional Marshalling: ¶
<!ELEMENT update ANY> ANY value: A sequence of elements with at most one DAV:label-name or DAV:version element (but not both). <!ELEMENT label-name (#PCDATA)> PCDATA value: stringThe request MAY include a Depth header. If no Depth header is included, Depth:0 is assumed. Standard depth semantics apply, and the request is applied to the collection identified by the request-URL and to all members of the collection that satisfy the Depth value. If a Depth header is included and the request fails on any resource, the response MUST be a 207 Multi-Status that identifies all resources for which the request has failed.
Additional Preconditions: ¶
Additional Postconditions: ¶
The working-resource feature provides an alternative to the workspace feature for supporting parallel development. Unlike the workspace feature, where the desired configuration of versions and checked-out resources is maintained on the server, the working-resource feature maintains the configuration on the client. This simplifies the server implementation, but does not allow a user to access the configuration from clients in different physical locations, such as from another office, from home, or while traveling. Another difference is that the workspace feature isolates clients from a logical change that involves renaming shared resources, until that logical change is complete and tested; with the working resource feature, all clients use a common set of shared version-controlled resources and every client sees the result of a MOVE as soon as it occurs.¶
If a server supports the working-resource feature but not the checkout-in-place feature, a CHECKOUT request can only be used to create a working resource, and cannot be used to check out a version-controlled resource. If a server supports the checkout-in-place feature, but not the working-resource feature, a CHECKOUT can only be used to change the state of a version-controlled resource from checked-in to checked-out.¶
The working-resource feature introduces the following REQUIRED properties for a version.¶
This property is defined in Section 4.1.1.¶
This property is defined in Section 4.1.2.¶
The working-resource feature introduces the following REQUIRED properties for a working resource. Since a working resource is a checked-out resource, it also has any property defined in this document for a checked-out resource.¶
This property identifies the version-controlled resource that will be updated when the working resource is checked in. ¶
<!ELEMENT auto-update (href)>
This property is defined in Section 4.1.1.¶
This property is defined in Section 4.1.2.¶
A CHECKOUT request can be applied to a version to create a new working resource. The content and dead properties of the working resource are a copy of the version that was checked out.¶
Marshalling: ¶
<!ELEMENT checkout ANY> ANY value: A sequence of elements with at most one DAV:apply-to-version and at most one DAV:fork-ok element. <!ELEMENT apply-to-version EMPTY> <!ELEMENT fork-ok EMPTY>
<!ELEMENT checkout-response ANY>
Preconditions: ¶
Postconditions: ¶
>>REQUEST
CHECKOUT /his/12/ver/V3 HTTP/1.1 Host: repo.webdav.org Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created Location: http://repo.webdav.org/wr/157 Cache-Control: no-cache
In this example, the version identified by http://repo.webdav.org/his/12/ver/V3 is checked out, and the new working resource is located at http://repo.webdav.org/wr/157.¶
A CHECKIN request can be applied to a working resource to produce a new version whose content and dead properties are a copy of those of the working resource. If the DAV:auto-update property of the working resource was set because the working resource was created by applying a CHECKOUT with the DAV:apply-to-version flag to a version-controlled resource, the CHECKIN request will also update the content and dead properties of that version-controlled resource to be those of the new version.¶
Marshalling: ¶
<!ELEMENT checkin ANY> ANY value: A sequence of elements with at most one DAV:fork-ok element. <!ELEMENT fork-ok EMPTY>
<!ELEMENT checkin-response ANY>The response MUST include a Cache-Control:no-cache header.
Preconditions: ¶
Postconditions: ¶
>>REQUEST
CHECKIN /wr/157 HTTP/1.1 Host: repo.webdav.org Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created Location: http://repo.webdav.org/his/23/ver/15 Cache-Control: no-cache
In this example, the working resource /wr/157 checked in, and a new version is created at http://repo.webdav.org/his/23/ver/15.¶
If the server supports the working-resource feature, it MUST include "working-resource" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
Additional Postconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Advanced versioning addresses the problems of parallel development and configuration management of multiple sets of interrelated resources. Traditionally, artifacts of software development, including requirements, design documents, code, and test cases, have been a focus of configuration management. Web sites, comprising multiple inter-linked resources (HTML, graphics, sound, CGI, and others), are another class of complex information artifacts that benefit from the application of configuration management. The advanced versioning capabilities for coordinating concurrent change provide the infrastructure for efficient and controlled management of large evolving web sites.¶
Although a server MAY support any combination of advanced versioning features, in order to minimize the complexity of a WebDAV advanced versioning client, a WebDAV advanced versioning server SHOULD support one of the following packages:¶
Advanced-Server-Workspace Package: basic-server-workspace package plus all advanced features¶
Advanced-Client-Workspace Package: basic-client-workspace package plus all advanced features¶
The advanced-server-workspace package supports advanced versioning capabilities for a client with no persistent state. The advanced-client-workspace package supports advanced versioning capabilities for a client that maintains configuration state on the client. A server that supports both advanced workspace packages will interoperate with all versioning clients.¶
The following additional terms are used by the advanced versioning features.¶
Collection ¶
Collection Version Resource ¶
Configuration ¶
Baseline Resource ¶
Baseline-Controlled Collection ¶
Version-Controlled Configuration Resource ¶
Activity Resource ¶
When a user wants to accept the changes (new versions) created by someone else, it is important not just to update the version-controlled resources in the user's workspace with those new versions, since this could result in "backing out" changes the user has made to those version-controlled resources. Instead, the versions created in another workspace should be "merged" into the user's version-controlled resources.¶
The version history of a version-controlled resource provides the information needed to determine the result of the merge. In particular, the merge should select whichever version is later in the line of descent from the root version. In case the versions to be merged are on different lines of descent (neither version is a descendant of the other), neither version should be selected, but instead, a new version should be created that contains the logical merge of the content and dead properties of those versions. The MERGE request can be used to check out each version-controlled resource that requires such a merge, and set the DAV:merge-set property of each checked-out resource to identify the version to be merged. The user is responsible for modifying the content and dead properties of the checked-out resource so that it represents the logical merge of that version, and then adding that version to the DAV:predecessor-set of the checked-out resource.¶
If the server is capable of automatically performing the merge, it MAY update the content, dead properties, and DAV:predecessor-set of the checked-out resource itself. Before checking in the automatically merged resource, the user is responsible for verifying that the automatic merge is correct.¶
The merge feature introduces the following REQUIRED properties for a checked-out resource.¶
This property identifies each version that is to be merged into this checked-out resource. ¶
<!ELEMENT merge-set (href*)>
This property identifies each version that the server has merged into this checked-out resource. The client should confirm that the merge has been performed correctly before moving a URL from the DAV:auto-merge-set to the DAV:predecessor-set of a checked-out resource. ¶
<!ELEMENT auto-merge-set (href*)>
The MERGE method performs the logical merge of a specified version (the "merge source") into a specified version-controlled resource (the "merge target"). If the merge source is neither an ancestor nor a descendant of the DAV:checked-in or DAV:checked-out version of the merge target, the MERGE checks out the merge target (if it is not already checked out) and adds the URL of the merge source to the DAV:merge-set of the merge target. It is then the client's responsibility to update the content and dead properties of the checked-out merge target so that it reflects the logical merge of the merge source into the current state of the merge target. The client indicates that it has completed the update of the merge target, by deleting the merge source URL from the DAV:merge-set of the checked-out merge target, and adding it to the DAV:predecessor-set. As an error check for a client forgetting to complete a merge, the server MUST fail an attempt to CHECKIN a version-controlled resource with a non-empty DAV:merge-set.¶
When a server has the ability to automatically update the content and dead properties of the merge target to reflect the logical merge of the merge source, it may do so unless DAV:no-auto-merge is specified in the MERGE request body. In order to notify the client that a merge source has been automatically merged, the MERGE request MUST add the URL of the auto-merged source to the DAV:auto-merge-set property of the merge target, and not to the DAV:merge-set property. The client indicates that it has verified that the auto-merge is valid, by deleting the merge source URL from the DAV:auto-merge-set, and adding it to the DAV:predecessor-set.¶
Multiple merge sources can be specified in a single MERGE request. The set of merge sources for a MERGE request is determined from the DAV:source element of the MERGE request body as follows:¶
The request-URL identifies the set of possible merge targets. If the request-URL identifies a collection, any member of the configuration rooted at the request-URL is a possible merge target. The merge target of a particular merge source is the version-controlled or checked-out resource whose DAV:checked-in or DAV:checked-out version is from the same version history as the merge source. If a merge source has no merge target, that merge source is ignored.¶
The MERGE response identifies the resources that a client must modify to complete the merge. It also identifies the resources modified by the request, so that a client can efficiently update any cached state it is maintaining.¶
Marshalling: ¶
<!ELEMENT merge ANY> ANY value: A sequence of elements with one DAV:source element, at most one DAV:no-auto-merge element, at most one DAV:no-checkout element, at most one DAV:prop element, and any legal set of elements that can occur in a DAV:checkout element. <!ELEMENT source (href+)> <!ELEMENT no-auto-merge EMPTY> <!ELEMENT no-checkout EMPTY> prop: see RFC 2518, Section 12.11
multistatus: see RFC 2518, Section 12.9
Preconditions: ¶
Postconditions: ¶
>>REQUEST
MERGE /ws/public HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:merge xmlns:D="DAV:"> <D:source> <D:href>http://www.webdav.org/ws/dev/sally</D:href> </D:source> </D:merge>
>>RESPONSE
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Cache-Control: no-cache <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.webdav.org/ws/public/src/parse.c</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> <D:response> <D:href>http://www.webdav.org/ws/public/doc/parse.html</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> </D:multistatus>
In this example, the DAV:checked-in versions from the workspace http://www.webdav.org/ws/dev/sally are merged into the version-controlled resources in the workspace http://www.webdav.org/ws/public. The resources /ws/public/src/parse.c and /ws/public/doc/parse.html were modified by the request.¶
A merge preview describes the changes that would result if the versions specified by the DAV:source element in the request body were to be merged into the resource identified by the request-URL (commonly, a collection).¶
Marshalling: ¶
<!ELEMENT merge-preview (source)> <!ELEMENT source (href)>
<!ELEMENT merge-preview-report (update-preview | conflict-preview | ignore-preview)*>
<!ELEMENT update-preview (target, version)> <!ELEMENT target (href)> <!ELEMENT version (href)>
<!ELEMENT conflict-preview (target, common-ancestor, version)>
<!ELEMENT common-ancestor (href)>
<!ELEMENT ignore-preview (version)>
>>REQUEST
REPORT /ws/public HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:merge-preview xmlns:D="DAV:"> <D:source> <D:href>http://www.webdav.org/ws/dev/fred</D:href> </D:source> </D:merge-preview>
>>RESPONSE
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:merge-preview-report xmlns:D="DAV:"> <D:conflict-preview> <D:target> <D:href>http://www.webdav.org/ws/public/foo.html</D:href> </D:target> <D:common-ancestor> <D:href>http://repo.webdav.org/his/23/ver/18</D:href> </D:common-ancestor> <D:version> <D:href>http://repo.webdav.org/his/23/ver/42</D:href> </D:version> </D:conflict-preview> <D:update-preview> <D:target> <D:href>http://www.webdav.org/ws/public/bar.html</D:href> </D:target> <D:version> <D:href>http://www.repo/his/42/ver/3</D:href> </D:version> </D:update-preview> </D:merge-preview-report>
In this example, the merge preview report indicates that version /his/23/ver/42 would be merged in /ws/public/foo.html, and version /his/42/ver/3 would update /ws/public/bar.html if the workspace http://www.webdav.org/ws/dev/fred was merged into the workspace http://www.webdav.org/ws/public.¶
If the server supports the merge feature, it MUST include "merge" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
Additional Postconditions: ¶
Additional Preconditions: ¶
A configuration is a set of resources that consists of a root collection and all members of that root collection except those resources that are members of another configuration. A configuration that contains a large number of resources can consume a large amount of space on a server. This can make it prohibitively expensive to remember the state of an existing configuration by creating a Depth:infinity copy of its root collection.¶
A baseline is a version resource that captures the state of each version-controlled member of a configuration. A baseline history is a version history whose versions are baselines. New baselines are created by checking out and then checking in a special kind of version-controlled resource called a version-controlled configuration.¶
A collection that is under baseline control is called a baseline-controlled collection. In order to allow efficient baseline implementation, the state of a baseline of a collection is limited to be a set of versions and their names relative to the collection, and the operations on a baseline are limited to the creation of a baseline from a collection, and restoring or merging the baseline back into a collection. A server MAY automatically put a collection under baseline control when it is created, or a client can use the BASELINE-CONTROL method to put a specified collection under baseline control.¶
As a configuration gets large, it is often useful to break it up into a set of smaller configurations that form the logical "components" of that configuration. In order to capture the fact that a baseline of a configuration is logically extended by a component configuration baseline, the component configuration baseline is captured as a "subbaseline" of the baseline.¶
The root collection of a configuration is unconstrained with respect to its relationship to the root collection of any of its components. In particular, the root collection of a configuration can have a member that is the root collection of one of its components (e.g., configuration /sys/x can have a component /sys/x/foo), can be a member of the root collection of one of its components (e.g., configuration /sys/y/z can have a component /sys/y), or neither (e.g., configuration /sys/x can have a component /comp/bar).¶
Since a version-controlled configuration is a version-controlled resource, it has all the properties of a version-controlled resource. In addition, the baseline feature introduces the following REQUIRED property for a version-controlled configuration.¶
This property identifies the collection that contains the version-controlled resources whose DAV:checked-in versions are being tracked by this version-controlled configuration. The DAV:version-controlled-configuration of the DAV:baseline-controlled-collection of a version-controlled configuration MUST identify that version-controlled configuration. ¶
<!ELEMENT baseline-controlled-collection (href)>
Since a checked-out configuration is a checked-out resource, it has all the properties of a checked-out resource. In addition, the baseline feature introduces the following REQUIRED property for a checked-out configuration.¶
This property determines the DAV:subbaseline-set property of the baseline that results from checking in this resource.¶
A server MAY reject attempts to modify the DAV:subbaseline-set of a checked-out configuration. ¶
<!ELEMENT subbaseline-set (href*)>
The DAV:resourcetype of a baseline MUST be DAV:baseline. Since a baseline is a version resource, it has all the properties of a version resource. In addition, the baseline feature introduces the following REQUIRED properties for a baseline.¶
This property contains a server-defined URL for a collection, where each member of this collection MUST either be a version-controlled resource with the same DAV:checked-in version and relative name as a version-controlled member of the baseline-controlled collection at the time the baseline was created, or be a collection needed to provide the relative name for a version-controlled resource. ¶
<!ELEMENT baseline-collection (href)>
The URLs in the DAV:subbaseline-set property MUST identify a set of other baselines. The subbaselines of a baseline are the baselines identified by its DAV:subbaseline-set and all subbaselines of the baselines identified by its DAV:subbaseline-set. ¶
<!ELEMENT subbaseline-set (href*)>
The baseline feature introduces the following REQUIRED property for a resource.¶
If the resource is a member of a version-controlled configuration (i.e. the resource is a collection under baseline control or is a member of a collection under baseline control), this property identifies that version-controlled configuration. ¶
<!ELEMENT version-controlled-configuration (href)>
The baseline feature introduces the following REQUIRED property for a workspace.¶
This property identifies each member of the workspace that is a collection under baseline control (as well as the workspace itself, if it is under baseline control). ¶
<!ELEMENT baseline-controlled-collection-set (href*)>
A collection can be placed under baseline control with a BASELINE-CONTROL request. When a collection is placed under baseline control, the DAV:version-controlled-configuration property of the collection is set to identify a new version-controlled configuration. This version-controlled configuration can be checked out and then checked in to create a new baseline for that collection.¶
If a baseline is specified in the request body, the DAV:checked-in version of the new version-controlled configuration will be that baseline, and the collection is initialized to contain version-controlled members whose DAV:checked-in versions and relative names are determined by the specified baseline.¶
If no baseline is specified, a new baseline history is created containing a baseline that captures the state of the version-controlled members of the collection, and the DAV:checked-in version of the version-controlled configuration will be that baseline.¶
Marshalling: ¶
<!ELEMENT baseline-control ANY> ANY value: A sequence of elements with at most one DAV:baseline element. <!ELEMENT baseline (href)>
<!ELEMENT baseline-control-response ANY>
Preconditions: ¶
Postconditions: ¶
>>REQUEST
BASELINE-CONTROL /src HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:baseline-control xmlns:D="DAV:"> <D:href>http://www.webdav.org/repo/blh/13/ver/8</D:href> </D:baseline-control>
>>RESPONSE
HTTP/1.1 200 OK Cache-Control: no-cache Content-Length: 0
In this example, the collection /src is placed under baseline control, and is populated with members from an existing baseline. A new version-controlled configuration (/repo/vcc/128) is created and associated with /src, and /src is initialized with version-controlled members whose DAV:checked-in versions are those selected by the DAV:baseline-collection (/repo/bc/15) of the specified baseline (/repo/blh/13/ver/8). The following diagram illustrates the resulting state on the server.¶
┌─────────────────────────────────────┐ │Baseline-Controlled Collection │<------+ │/src │ | ├─────────────────────────────────────┤ | │DAV:version-controlled-configuration │---+ | └─────────────────────────────────────┘ | | | | | | ┌─────────────────────────────────────┐ | | │Version-Controlled Configuration │<--+ | │/repo/vcc/128 │ | ├─────────────────────────────────────┤ | │DAV:baseline-controlled-collection │-------+ ├─────────────────────────────────────┤ │DAV:checked-in │-------+ ├─────────────────────────────────────┤ | │DAV:version-history │---+ | └─────────────────────────────────────┘ | | | | | | ┌────────────────────────┐ | | │Baseline History │<---------------+ | │/repo/blh/13 │ | ├────────────────────────┤ | │DAV:version-set │----------------+ | └────────────────────────┘ | | | | | v | v v | | | ┌────────────────────────┐ | | │Baseline │<-------+-----------+ │/repo/blh/13/ver/8 │ ├────────────────────────┤ ┌──────────────┐ │DAV:baseline-collection │---->│Collection │ └────────────────────────┘ │/repo/bc/15 │ └──────────────┘
In order to create new baselines of /src, /repo/vcc/128 can be checked out, new versions can be created or selected by the version-controlled members of /src, and then /repo/vcc/128 can be checked in to capture the current state of those version-controlled members.¶
A DAV:compare-baseline report contains the differences between the baseline identified by the request-URL (the "request baseline") and the baseline specified in the request body (the "compare baseline").¶
Marshalling: ¶
<!ELEMENT compare-baseline (href)>
<!ELEMENT compare-baseline-report (added-version | deleted-version | changed-version)*>
<!ELEMENT added-version (href)>
<!ELEMENT deleted-version (href)>
<!ELEMENT changed-version (href, href)>
Preconditions: ¶
>>REQUEST
REPORT /bl-his/12/bl/14 HTTP/1.1 Host: repo.webdav.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:compare-baseline xmlns:D="DAV:"> <D:href>http://repo.webdav.org/bl-his/12/bl/15</D:href> </D:compare-baseline>
>>RESPONSE
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:compare-baseline-report xmlns:D="DAV:"> <D:added-version> <D:href>http://repo.webdav.org/his/23/ver/8</D:href> </D:added-version> <D:changed-version> <D:href>http://repo.webdav.org/his/29/ver/12</D:href> <D:href>http://repo.webdav.org/his/29/ver/19</D:href> </D:changed-version> <D:deleted-version> <D:href>http://repo.webdav.org/his/12/ver/4</D:href> </D:deleted-version> </D:compare-baseline-report>
In this example, the differences between baseline 14 and baseline 15 of http://repo.webdav.org/bl-his/12 are identified.¶
If a server supports the baseline feature, it MUST include "baseline" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
Additional Postconditions: ¶
Additional Postconditions: ¶
Additional Preconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
If the merge source is a baseline, the merge target is a version-controlled configuration for the baseline history of that baseline, where the baseline-controlled collection of that version-controlled configuration is a member of the collection identified by the request-URL.¶
Additional Preconditions: ¶
Additional Postconditions: ¶
An activity is a resource that selects a set of versions that are on a single "line of descent", where a line of descent is a sequence of versions connected by successor relationships. If an activity selects versions from multiple version histories, the versions selected in each version history must be on a single line of descent.¶
A common problem that motivates the use of activities is that it is often desirable to perform several different logical changes in a single workspace, and then selectively merge a subset of those logical changes to other workspaces. An activity can be used to represent a single logical change, where an activity tracks all the resources that were modified to effect that single logical change. When a version-controlled resource is checked out, the user specifies which activity should be associated with a new version that will be created when that version-controlled resource is checked in. It is then possible to select a particular logical change for merging into another workspace, by specifying the appropriate activity in a MERGE request.¶
Another common problem is that although a version-controlled resource may need to have multiple lines of descent, all work done by members of a given team must be on a single line of descent (to avoid merging between team members). An activity resource provides the mechanism for addressing this problem. When a version-controlled resource is checked out, a client can request that an existing activity be used or that a new activity be created. Activity semantics then ensure that all versions in a given version history that are associated with an activity are on a single line of descent. If all members of a team share a common activity (or sub-activities of a common activity), then all changes made by members of that team will be on a single line of descent.¶
The following diagram illustrates activities. Version V5 is the latest version of foo.html selected by activity Act-2, and version V8 is the latest version of bar.html selected by activity Act-2.¶
foo.html History bar.html History ┌───┐ ┌───┐ Act-1│ │V1 Act-1│ │V6 └───┘ └───┘ | | | | ┌───┐ ┌───┐ Act-1│ │V2 Act-2│ │V7 └───┘ └───┘ / \ | / \ | ┌───┐ ┌───┐ ┌───┐ Act-1│ │V3 Act-2│ │V4 Act-2│ │V8 └───┘ └───┘ └───┘ | | | | ┌───┐ ┌───┐ Act-2│ │V5 Act-3│ │V9 └───┘ └───┘
Activities appear under a variety of names in existing versioning systems. When an activity is used to capture a logical change, it is commonly called a "change set". When an activity is used to capture a line of descent, it is commonly called a "branch". When a system supports both branches and change sets, it is often useful to require that a particular change set occur on a particular branch. This relationship can be captured by making the change set activity be a "subactivity" of the branch activity.¶
The DAV:resourcetype of an activity MUST be DAV:activity.¶
The activity feature introduces the following REQUIRED properties for an activity.¶
This property identifies each version whose DAV:activity-set property identifies this activity. Multiple versions of a single version history can be selected by an activity's DAV:activity-version-set property, but all DAV:activity-version-set versions from a given version history must be on a single line of descent from the root version of that version history. ¶
<!ELEMENT activity-version-set (href*)>
This property identifies each checked-out resource whose DAV:activity-set identifies this activity. ¶
<!ELEMENT activity-checkout-set (href*)>
This property identifies each activity that forms a part of the logical change being captured by this activity. An activity behaves as if its DAV:activity-version-set is extended by the DAV:activity-version-set of each activity identified in the DAV:subactivity-set. In particular, the versions in this extended set MUST be on a single line of descent, and when an activity selects a version for merging, the latest version in this extended set is the one that will be merged.¶
A server MAY reject attempts to modify the DAV:subactivity-set of an activity. ¶
<!ELEMENT subactivity-set (href*)>
This property identifies each workspace whose DAV:current-activity-set identifies this activity. ¶
<!ELEMENT current-workspace-set (href*)>
The activity feature introduces the following REQUIRED property for a version.¶
This property identifies the activities that determine to which logical changes this version contributes, and on which lines of descent this version appears. A server MAY restrict the DAV:activity-set to identify a single activity. A server MAY refuse to allow the value of the DAV:activity-set property of a version to be modified. ¶
<!ELEMENT activity-set (href*)>
The activity feature introduces the following REQUIRED properties for a checked-out resource.¶
This property of a checked-out resource indicates whether the DAV:activity-set of another checked-out resource associated with the version history of this version-controlled resource can have an activity that is in the DAV:activity-set property of this checked-out resource.¶
A result of the requirement that an activity must form a single line of descent through a given version history is that if multiple checked-out resources for a given version history are checked out unreserved into a single activity, only the first CHECKIN will succeed. Before another of these checked-out resources can be checked in, the user will first have to merge into that checked-out resource the latest version selected by that activity from that version history, and then modify the DAV:predecessor-set of that checked-out resource to identify that version. ¶
<!ELEMENT unreserved (#PCDATA)> PCDATA value: boolean
This property of a checked-out resource determines the DAV:activity-set property of the version that results from checking in this resource.¶
The activity feature introduces the following REQUIRED property for a workspace.¶
This property identifies the activities that currently are being performed in this workspace. When a member of this workspace is checked out, if no activity is specified in the checkout request, the DAV:current-activity-set will be used. This allows an activity-unaware client to update a workspace in which activity tracking is required. The DAV:current-activity-set MAY be restricted to identify at most one activity. ¶
<!ELEMENT current-activity-set (href*)>
A MKACTIVITY request creates a new activity resource. A server MAY restrict activity creation to particular collections, but a client can determine the location of these collections from a DAV:activity-collection-set OPTIONS request.¶
Marshalling: ¶
<!ELEMENT mkactivity ANY>
<!ELEMENT mkactivity-response ANY>
Preconditions: ¶
Postconditions: ¶
>>REQUEST
MKACTIVITY /act/test-23 HTTP/1.1 Host: repo.webdav.org Content-Length: 0
>>RESPONSE
HTTP/1.1 201 Created Cache-Control: no-cache
In this example, a new activity is created at http://repo.webdav.org/act/test-23.¶
The DAV:latest-activity-version report can be applied to a version history to identify the latest version that is selected from that version history by a given activity.¶
Marshalling: ¶
<!ELEMENT latest-activity-version (href)>
<!ELEMENT latest-activity-version-report (href)>
Preconditions: ¶
If the server supports the activity feature, it MUST include "activity" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
A DAV:activity-collection-set element MAY be included in the request body to identify collections that may contain activity resources.¶
Additional Marshalling: ¶
<!ELEMENT options ANY> ANY value: A sequence of elements with at most one DAV:activity-collection-set element.
<!ELEMENT options-response ANY> ANY value: A sequence of elements with at most one DAV:activity-collection-set element. <!ELEMENT activity-collection-set (href*)>
Additional Postconditions: ¶
Additional Postconditions: ¶
A CHECKOUT request MAY specify the DAV:activity-set for the checked-out resource.¶
Additional Marshalling: ¶
<!ELEMENT checkout ANY> ANY value: A sequence of elements with at most one DAV:activity-set and at most one DAV:unreserved. <!ELEMENT activity-set (href+ | new)> <!ELEMENT new EMPTY> <!ELEMENT unreserved EMPTY>
Additional Preconditions: ¶
Additional Postconditions: ¶
>>REQUEST
CHECKOUT /ws/public/foo.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:checkout xmlns:D="DAV:"> <D:activity-set> <D:href>http://repo.webdav.org/act/fix-bug-23</D:href> </D:activity-set> </D:checkout>
>>RESPONSE
HTTP/1.1 200 OK Cache-Control: no-cache
In this example, the CHECKOUT is being performed in the http://repo.webdav.org/act/fix-bug-23 activity.¶
Additional Preconditions: ¶
Additional Postconditions: ¶
If the DAV:source element of the request body identifies an activity, then for each version history containing a version selected by that activity, the latest version selected by that activity is a merge source. Note that the versions selected by an activity are the versions in its DAV:activity-version-set unioned with the versions selected by the activities in its DAV:subactivity-set.¶
Additional Marshalling: ¶
<!ELEMENT checkin-activity EMPTY>
Additional Postconditions: ¶
As with any versionable resource, when a collection is put under version control, a version history resource is created to contain versions for that version-controlled collection. In order to preserve standard versioning semantics (a version of a collection should not be modifiable), a collection version only records information about the version-controlled bindings of that collection.¶
In order to cleanly separate a modification to the namespace from a modification to content or dead properties, a version of a collection has no members, but instead records in its DAV:version-controlled-binding-set property the binding name and version history resource of each version-controlled internal member of that collection. If, instead, a collection version contained bindings to other versions, creating a new version of a resource would require creating a new version of all the collection versions that contain that resource, which would cause activities to become entangled. For example, suppose a "feature-12" activity created a new version of /x/y/a.html. If a collection version contained bindings to versions of its members, a new version of /x/y would have to be created to contain the new version of /x/y/a.html, and a new version of /x would have to be created to contain the new version of /x/y. Now suppose a "bugfix-47" activity created a new version of /x/z/b.html. Again, a new version of /x/z and a new version of /x would have to be created to contain the new version of /x/y/b.html. But now it is impossible to merge just "bugfix-47" into another workspace without "feature-12", because the version of /x that contains the desired version of /x/z/b.html also contains version of /x/y/a.html created for "feature-12". If, instead, a collection version just records the binding name and version history resource of each version-controlled internal member, changing the version selected by a member of that collection would not require a new version of the collection. The new version is still in the same version history so no new collection version is required, and "feature-12" and "bugfix-47" would not become entangled.¶
In the following example, there are three version histories, named VH14, VH19, and VH24, where VH14 contains versions of a collection. The version-controlled collection /x has version V2 of version history VH14 as its DAV:checked-in version. Since V2 has recorded two version controlled bindings, one with binding name "a" to version history VH19, and the other with binding name "b" to version history VH24, /x MUST have two version-controlled bindings, one named "a" to a version-controlled resource for history VH19, and the other named "b" to a version-controlled resource for history VH24. The version-controlled resource /x/a currently has V4 of VH19 as its DAV:checked-in version, while /x/b has V8 of VH24 as its DAV:checked-in version.¶
VH19 ┌─────────┐ │ ┌───┐ │ │ │ │V4 │ │ └───┘ │ │ | │ │ | │ │ ┌───┐ │ │ │ │V5 │ VH14 │ └───┘ │ ┌─────────┐ │ | │ │ ┌───┐ │ │ | │ a ┌───┐ │ │ │V1 │ │ ┌───┐ │ ---->│ │checked-in=V4 │ └───┘ │ a │ │ │V6 │ / └───┘ │ | --│--->│ └───┘ │ / │ | / │ └─────────┘ ┌───┐ │ ┌───┐ │ /x │ │checked-in=V2 │ │ │V2 │ └───┘ │ └───┘ │ VH24 \ │ | \ │ b ┌─────────┐ \ b ┌───┐ │ | --│--->│ ┌───┐ │ ---->│ │checked-in=V8 │ ┌───┐ │ │ │ │V7 │ └───┘ │ │ │V3 │ │ └───┘ │ │ └───┘ │ │ | │ └─────────┘ │ | │ │ ┌───┐ │ │ │ │V8 │ │ └───┘ │ │ | │ │ | │ │ ┌───┐ │ │ │ │V9 │ │ └───┘ │ └─────────┘
For any request (e.g., DELETE, MOVE, COPY) that modifies a version-controlled binding of a checked-in version-controlled collection, the request MUST fail unless the version-controlled collection has a DAV:auto-version property that will automatically check out the version-controlled collection when it is modified.¶
Although a collection version only records the version-controlled bindings of a collection, a version-controlled collection MAY contain both version-controlled and non-version-controlled bindings. Non-version-controlled bindings are not under version control, and therefore can be added or deleted without checking out the version-controlled collection.¶
Note that a collection version captures only a defined subset of the state of a collection. In particular, a version of a collection captures its dead properties and its bindings to version-controlled resources, but not its live properties or bindings to non-version-controlled resources.¶
When a server supports the working-resource feature, a client can check out a collection version to create a working collection. Unlike a version-controlled collection, which contains bindings to version-controlled resources and non-version-controlled resources, a working collection contains bindings to version history resources and non-version-controlled resources. In particular, a working collection is initialized to contain bindings to the version history resources specified by the DAV:version-controlled-binding-set of the checked out collection version. The members of a working collection can then be deleted or moved to another working collection. Non-version-controlled resources can be added to a working collection with methods such as PUT, COPY, and MKCOL. When a working collection is checked in, a VERSION-CONTROL request is automatically applied to every non-version-controlled member of the working collection, and each non-version-controlled member is replaced by its newly created version history. The DAV:version-controlled-binding-set of the new version resulting from checking in a working collection contains the binding name and version history URL for each member of the working collection.¶
A version-controlled collection has all the properties of a collection and of a version-controlled resource. In addition, the version-controlled-collection feature introduces the following REQUIRED property for a version-controlled collection.¶
This property identifies the non-version-controlled internal members of the collection that currently are eclipsing a version-controlled internal member of the collection. ¶
!ELEMENT eclipsed-set (binding-name*)> <!ELEMENT binding-name (#PCDATA)> PCDATA value: URL segment
An UPDATE or MERGE request can give a version-controlled collection a version-controlled internal member that has the same name as an existing non-version-controlled internal member. In this case, the non-version-controlled internal member takes precedence and is said to "eclipse" the new versioned-controlled internal member. If the non-version-controlled internal member is removed (e.g., by a DELETE or MOVE), the version-controlled internal member is exposed.¶
A collection version has all the properties of a version. In addition, the version-controlled-collection feature introduces the following REQUIRED property for a collection version.¶
This property captures the name and version-history of each version-controlled internal member of a collection. ¶
<!ELEMENT version-controlled-binding-set (version-controlled-binding*)> <!ELEMENT version-controlled-binding (binding-name, version-history)> <!ELEMENT binding-name (#PCDATA)> PCDATA value: URL segment <!ELEMENT version-history (href)>
If the server supports the version-controlled-collection feature, it MUST include "version-controlled-collection" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.¶
Additional Preconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Additional Preconditions: ¶
Additional Preconditions: ¶
Additional Preconditions: ¶
Additional Postconditions: ¶
Additional Postconditions: ¶
Additional Postconditions: ¶
Additional Postconditions: ¶
This specification has been designed to be compliant with the IETF Policy on Character Sets and Languages [RFC2277]. Specifically, where human-readable strings exist in the protocol, either their charset is explicitly stated, or XML mechanisms are used to specify the charset used. Additionally, these human-readable strings all have the ability to express the natural language of the string.¶
Most of the human-readable strings in this protocol appear in properties, such as DAV:creator-displayname. As defined by RFC 2518, properties have their values marshaled as XML. XML has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [RFC2279] encoding of the ISO 10646 multilingual plane. The charset parameter of the Content-Type header, together with the XML "encoding" attribute, provide charset identification information for MIME and XML processors. Proper use of the charset header with XML is described in RFC 3023. XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. XML uses either IANA registered language tags (see RFC 3066) or ISO 639 language tags in the "xml:lang" attribute of an XML element to identify the language of its content and attributes.¶
DeltaV applications, since they build upon WebDAV, are subject to the internationalization requirements specified in RFC 2518, Section 16. In brief, these requirements mandate the use of XML character set tagging, character set encoding, and language tagging capabilities. Additionally, they strongly recommend reading RFC 3023 for instruction on the use of MIME media types for XML transport and the use of the charset header.¶
Within this specification, a label is a human-readable string that is marshaled in the Label header and as XML in request entity bodies. When used in the Label header, the value of the label is URL-escaped and encoded using UTF-8.¶
All of the security considerations of WebDAV discussed in RFC 2518, Section 17 also apply to WebDAV versioning. Some aspects of the versioning protocol help address security risks introduced by WebDAV, but other aspects can increase these security risks. These issues are detailed below.¶
WebDAV increases the ease with which a remote client can modify resources on a web site, but this also increases the risk of important information being overwritten and lost, either through user error or user maliciousness. The use of WebDAV versioning can help address this problem by guaranteeing that previous information is saved in the form of immutable versions, and therefore is easily available for retrieval or restoration. In addition, the version history provides a log of when changes were made, and by whom. When requests are appropriately authenticated, the history mechanism provides a clear audit trail for changes to web resources. This can often significantly improve the ability to identify the source of the security problem, and thereby help guard against it in the future.¶
WebDAV versioning provides a variety of links between related pieces of information. This can increase the risk that authentication or authorization errors allow a client to locate sensitive information. For example, if version history is not appropriately protected by access control, a client can use the version history of a public resource to identify later versions of that resource that the user intended to keep private. This increases the need for reliable authentication and accurate authorization.¶
A WebDAV versioning client should be designed to handle a mixture of 200 (OK) and 403 (Forbidden) responses on attempts to access the properties and reports that are supported by a resource. For example, a particular user may be authorized to access the content and dead properties of a version-controlled resource, but not be authorized to access the DAV:checked-in, DAV:checked-out, or DAV:version-history properties of that resource.¶
While it is acknowledged that "obscurity" is not an effective means of security, it is often a good technique to keep honest people honest. Within this protocol, version URLs, version history URLs, and working resource URLs are generated by the server and can be properly obfuscated so as not to draw attention to them. For example, a version of "http://foobar.com/reviews/salaries.html" might be assigned a URL such as "http://foobar.com/repo/4934943".¶
The auto-versioning mechanism provided by WebDAV can result in a large number of resources being created on the server, since each update to a resource could potentially result in the creation of a new version resource. This increases the risk of a denial of service attack that exhausts the storage capability of a server. This risk is especially significant because it can be an unintentional result of something like an aggressive auto-save feature provided by an editing client. A server can decrease this risk by using delta storage techniques to minimize the cost of additional versions, and by limiting auto-versioning to a locking client, and thereby decreasing the number of inadvertent version creations.¶
This document uses the namespace defined by RFC 2518 for XML elements. All other IANA considerations from RFC 2518 are also applicable to WebDAV Versioning.¶
The following notice is copied from RFC 2026, Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document.¶
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the procedures of the IETF with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.¶
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.¶
This protocol is the collaborative product of the authors and the rest of the DeltaV design team: Boris Bokowski, Bruce Cragun (Novell), Jim Doubek (Macromedia), David Durand (INSO), Lisa Dusseault (Xythos), Chuck Fay (FileNet), Yaron Goland, Mark Hale (Interwoven), Henry Harbury (Merant), James Hunt, Jeff McAffer (OTI), Peter Raymond (Merant), Juergen Reuter, Edgar Schwarz (Marconi), Eric Sedlar (Oracle), Bradley Sergeant, Greg Stein, and John Vasta (Rational). We would like to acknowledge the foundation laid for us by the authors of the WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV and DeltaV working groups.¶
This document introduces several different kinds of versioning resources, such as version-controlled resources, versions, checked- out resources, and version history resources. As clients discover resources on a server, they may find it useful to classify those resources (for example, to make UI decisions on choice of icon and menu options).¶
Clients should classify a resource by examining the values of the DAV:supported-method-set (see Section 3.1.3) and DAV:supported-live-property-set (see Section 3.1.4) properties of that resource.¶
The following list shows the supported live properties and methods for each kind of versioning resource. Where an optional feature introduces a new kind of versioning resource, that feature is noted in parentheses following the name of that kind of versioning resource. If a live property or method is optional for a kind of versioning resource, the feature that introduces that live property or method is noted in parentheses following the live property or method name.¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Supported live properties: ¶
Supported methods: ¶
Copyright © The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Funding for the RFC Editor function is currently provided by the Internet Society.