[CalendarServer-changes] [2333] CalendarServer/trunk/doc/RFC
source_changes at macosforge.org
source_changes at macosforge.org
Mon Apr 21 15:41:11 PDT 2008
Revision: 2333
http://trac.macosforge.org/projects/calendarserver/changeset/2333
Author: wsanchez at apple.com
Date: 2008-04-21 15:41:07 -0700 (Mon, 21 Apr 2008)
Log Message:
-----------
2518 obsoleted by 4918
Added Paths:
-----------
CalendarServer/trunk/doc/RFC/rfc4918-WebDAV.txt
Removed Paths:
-------------
CalendarServer/trunk/doc/RFC/rfc2518-WebDAV.txt
CalendarServer/trunk/doc/RFC/rfc4918-WebDAV Update.txt
Deleted: CalendarServer/trunk/doc/RFC/rfc2518-WebDAV.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/rfc2518-WebDAV.txt 2008-04-21 21:34:22 UTC (rev 2332)
+++ CalendarServer/trunk/doc/RFC/rfc2518-WebDAV.txt 2008-04-21 22:41:07 UTC (rev 2333)
@@ -1,5267 +0,0 @@
-
-
-
-
-
-
-Network Working Group Y. Goland
-Request for Comments: 2518 Microsoft
-Category: Standards Track E. Whitehead
- UC Irvine
- A. Faizi
- Netscape
- S. Carter
- Novell
- D. Jensen
- Novell
- February 1999
-
-
- HTTP Extensions for Distributed Authoring -- WEBDAV
-
-Status of this Memo
-
- 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 Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-Abstract
-
- This document specifies a set of methods, headers, and content-types
- ancillary to HTTP/1.1 for the management of resource properties,
- creation and management of resource collections, namespace
- manipulation, and resource locking (collision avoidance).
-
-Table of Contents
-
- ABSTRACT............................................................1
- 1 INTRODUCTION .....................................................5
- 2 NOTATIONAL CONVENTIONS ...........................................7
- 3 TERMINOLOGY ......................................................7
- 4 DATA MODEL FOR RESOURCE PROPERTIES ...............................8
- 4.1 The Resource Property Model ...................................8
- 4.2 Existing Metadata Proposals ...................................8
- 4.3 Properties and HTTP Headers ...................................9
- 4.4 Property Values ...............................................9
- 4.5 Property Names ...............................................10
- 4.6 Media Independent Links ......................................10
- 5 COLLECTIONS OF WEB RESOURCES ....................................11
-
-
-
-Goland, et al. Standards Track [Page 1]
-
-RFC 2518 WEBDAV February 1999
-
-
- 5.1 HTTP URL Namespace Model .....................................11
- 5.2 Collection Resources .........................................11
- 5.3 Creation and Retrieval of Collection Resources ...............12
- 5.4 Source Resources and Output Resources ........................13
- 6 LOCKING .........................................................14
- 6.1 Exclusive Vs. Shared Locks ...................................14
- 6.2 Required Support .............................................16
- 6.3 Lock Tokens ..................................................16
- 6.4 opaquelocktoken Lock Token URI Scheme ........................16
- 6.4.1 Node Field Generation Without the IEEE 802 Address ........17
- 6.5 Lock Capability Discovery ....................................19
- 6.6 Active Lock Discovery ........................................19
- 6.7 Usage Considerations .........................................19
- 7 WRITE LOCK ......................................................20
- 7.1 Methods Restricted by Write Locks ............................20
- 7.2 Write Locks and Lock Tokens ..................................20
- 7.3 Write Locks and Properties ...................................20
- 7.4 Write Locks and Null Resources ...............................21
- 7.5 Write Locks and Collections ..................................21
- 7.6 Write Locks and the If Request Header ........................22
- 7.6.1 Example - Write Lock ......................................22
- 7.7 Write Locks and COPY/MOVE ....................................23
- 7.8 Refreshing Write Locks .......................................23
- 8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
- 8.1 PROPFIND .....................................................24
- 8.1.1 Example - Retrieving Named Properties .....................25
- 8.1.2 Example - Using allprop to Retrieve All Properties ........26
- 8.1.3 Example - Using propname to Retrieve all Property Names ...29
- 8.2 PROPPATCH ....................................................31
- 8.2.1 Status Codes for use with 207 (Multi-Status) ..............31
- 8.2.2 Example - PROPPATCH .......................................32
- 8.3 MKCOL Method .................................................33
- 8.3.1 Request ...................................................33
- 8.3.2 Status Codes ..............................................33
- 8.3.3 Example - MKCOL ...........................................34
- 8.4 GET, HEAD for Collections ....................................34
- 8.5 POST for Collections .........................................35
- 8.6 DELETE .......................................................35
- 8.6.1 DELETE for Non-Collection Resources .......................35
- 8.6.2 DELETE for Collections ....................................36
- 8.7 PUT ..........................................................36
- 8.7.1 PUT for Non-Collection Resources ..........................36
- 8.7.2 PUT for Collections .......................................37
- 8.8 COPY Method ..................................................37
- 8.8.1 COPY for HTTP/1.1 resources ...............................37
- 8.8.2 COPY for Properties .......................................38
- 8.8.3 COPY for Collections ......................................38
- 8.8.4 COPY and the Overwrite Header .............................39
-
-
-
-Goland, et al. Standards Track [Page 2]
-
-RFC 2518 WEBDAV February 1999
-
-
- 8.8.5 Status Codes ..............................................39
- 8.8.6 Example - COPY with Overwrite .............................40
- 8.8.7 Example - COPY with No Overwrite ..........................40
- 8.8.8 Example - COPY of a Collection ............................41
- 8.9 MOVE Method ..................................................42
- 8.9.1 MOVE for Properties .......................................42
- 8.9.2 MOVE for Collections ......................................42
- 8.9.3 MOVE and the Overwrite Header .............................43
- 8.9.4 Status Codes ..............................................43
- 8.9.5 Example - MOVE of a Non-Collection ........................44
- 8.9.6 Example - MOVE of a Collection ............................44
- 8.10 LOCK Method ..................................................45
- 8.10.1 Operation .................................................46
- 8.10.2 The Effect of Locks on Properties and Collections .........46
- 8.10.3 Locking Replicated Resources ..............................46
- 8.10.4 Depth and Locking .........................................46
- 8.10.5 Interaction with other Methods ............................47
- 8.10.6 Lock Compatibility Table ..................................47
- 8.10.7 Status Codes ..............................................48
- 8.10.8 Example - Simple Lock Request .............................48
- 8.10.9 Example - Refreshing a Write Lock .........................49
- 8.10.10 Example - Multi-Resource Lock Request ....................50
- 8.11 UNLOCK Method ................................................51
- 8.11.1 Example - UNLOCK ..........................................52
- 9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
- 9.1 DAV Header ...................................................52
- 9.2 Depth Header .................................................52
- 9.3 Destination Header ...........................................54
- 9.4 If Header ....................................................54
- 9.4.1 No-tag-list Production ....................................55
- 9.4.2 Tagged-list Production ....................................55
- 9.4.3 not Production ............................................56
- 9.4.4 Matching Function .........................................56
- 9.4.5 If Header and Non-DAV Compliant Proxies ...................57
- 9.5 Lock-Token Header ............................................57
- 9.6 Overwrite Header .............................................57
- 9.7 Status-URI Response Header ...................................57
- 9.8 Timeout Request Header .......................................58
- 10 STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
- 10.1 102 Processing ...............................................59
- 10.2 207 Multi-Status .............................................59
- 10.3 422 Unprocessable Entity .....................................60
- 10.4 423 Locked ...................................................60
- 10.5 424 Failed Dependency ........................................60
- 10.6 507 Insufficient Storage .....................................60
- 11 MULTI-STATUS RESPONSE .........................................60
- 12 XML ELEMENT DEFINITIONS .......................................61
- 12.1 activelock XML Element .......................................61
-
-
-
-Goland, et al. Standards Track [Page 3]
-
-RFC 2518 WEBDAV February 1999
-
-
- 12.1.1 depth XML Element .........................................61
- 12.1.2 locktoken XML Element .....................................61
- 12.1.3 timeout XML Element .......................................61
- 12.2 collection XML Element .......................................62
- 12.3 href XML Element .............................................62
- 12.4 link XML Element .............................................62
- 12.4.1 dst XML Element ...........................................62
- 12.4.2 src XML Element ...........................................62
- 12.5 lockentry XML Element ........................................63
- 12.6 lockinfo XML Element .........................................63
- 12.7 lockscope XML Element ........................................63
- 12.7.1 exclusive XML Element .....................................63
- 12.7.2 shared XML Element ........................................63
- 12.8 locktype XML Element .........................................64
- 12.8.1 write XML Element .........................................64
- 12.9 multistatus XML Element ......................................64
- 12.9.1 response XML Element ......................................64
- 12.9.2 responsedescription XML Element ...........................65
- 12.10 owner XML Element ...........................................65
- 12.11 prop XML element ............................................66
- 12.12 propertybehavior XML element ................................66
- 12.12.1 keepalive XML element ....................................66
- 12.12.2 omit XML element .........................................67
- 12.13 propertyupdate XML element ..................................67
- 12.13.1 remove XML element .......................................67
- 12.13.2 set XML element ..........................................67
- 12.14 propfind XML Element ........................................68
- 12.14.1 allprop XML Element ......................................68
- 12.14.2 propname XML Element .....................................68
- 13 DAV PROPERTIES ................................................68
- 13.1 creationdate Property ........................................69
- 13.2 displayname Property .........................................69
- 13.3 getcontentlanguage Property ..................................69
- 13.4 getcontentlength Property ....................................69
- 13.5 getcontenttype Property ......................................70
- 13.6 getetag Property .............................................70
- 13.7 getlastmodified Property .....................................70
- 13.8 lockdiscovery Property .......................................71
- 13.8.1 Example - Retrieving the lockdiscovery Property ...........71
- 13.9 resourcetype Property ........................................72
- 13.10 source Property .............................................72
- 13.10.1 Example - A source Property ..............................72
- 13.11 supportedlock Property ......................................73
- 13.11.1 Example - Retrieving the supportedlock Property ..........73
- 14 INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
- 15 DAV COMPLIANCE CLASSES ........................................75
- 15.1 Class 1 ......................................................75
- 15.2 Class 2 ......................................................75
-
-
-
-Goland, et al. Standards Track [Page 4]
-
-RFC 2518 WEBDAV February 1999
-
-
- 16 INTERNATIONALIZATION CONSIDERATIONS ...........................76
- 17 SECURITY CONSIDERATIONS .......................................77
- 17.1 Authentication of Clients ....................................77
- 17.2 Denial of Service ............................................78
- 17.3 Security through Obscurity ...................................78
- 17.4 Privacy Issues Connected to Locks ............................78
- 17.5 Privacy Issues Connected to Properties .......................79
- 17.6 Reduction of Security due to Source Link .....................79
- 17.7 Implications of XML External Entities ........................79
- 17.8 Risks Connected with Lock Tokens .............................80
- 18 IANA CONSIDERATIONS ...........................................80
- 19 INTELLECTUAL PROPERTY .........................................81
- 20 ACKNOWLEDGEMENTS ..............................................82
- 21 REFERENCES ....................................................82
- 21.1 Normative References .........................................82
- 21.2 Informational References .....................................83
- 22 AUTHORS' ADDRESSES ............................................84
- 23 APPENDICES ....................................................86
- 23.1 Appendix 1 - WebDAV Document Type Definition .................86
- 23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
- 23.3 Appendix 3 - Notes on Processing XML Elements ................89
- 23.3.1 Notes on Empty XML Elements ...............................89
- 23.3.2 Notes on Illegal XML Processing ...........................89
- 23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
- 23.4.1 Introduction ..............................................92
- 23.4.2 Meaning of Qualified Names ................................92
- 24 FULL COPYRIGHT STATEMENT ......................................94
-
-
-
-1 Introduction
-
- This document describes an extension to the HTTP/1.1 protocol that
- allows clients to perform remote web content authoring operations.
- This extension provides a coherent set of methods, headers, request
- entity body formats, and response entity body formats that provide
- operations for:
-
- Properties: The ability to create, remove, and query information
- about Web pages, such as their authors, creation dates, etc. Also,
- the ability to link pages of any media type to related pages.
-
- Collections: The ability to create sets of documents and to retrieve
- a hierarchical membership listing (like a directory listing in a file
- system).
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 5]
-
-RFC 2518 WEBDAV February 1999
-
-
- Locking: The ability to keep more than one person from working on a
- document at the same time. This prevents the "lost update problem,"
- in which modifications are lost as first one author then another
- writes changes without merging the other author's changes.
-
- Namespace Operations: The ability to instruct the server to copy and
- move Web resources.
-
- Requirements and rationale for these operations are described in a
- companion document, "Requirements for a Distributed Authoring and
- Versioning Protocol for the World Wide Web" [RFC2291].
-
- The sections below provide a detailed introduction to resource
- properties (section 4), collections of resources (section 5), and
- locking operations (section 6). These sections introduce the
- abstractions manipulated by the WebDAV-specific HTTP methods
- described in section 8, "HTTP Methods for Distributed Authoring".
-
- In HTTP/1.1, method parameter information was exclusively encoded in
- HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
- information either in an Extensible Markup Language (XML) [REC-XML]
- request entity body, or in an HTTP header. The use of XML to encode
- method parameters was motivated by the ability to add extra XML
- elements to existing structures, providing extensibility; and by
- XML's ability to encode information in ISO 10646 character sets,
- providing internationalization support. As a rule of thumb,
- parameters are encoded in XML entity bodies when they have unbounded
- length, or when they may be shown to a human user and hence require
- encoding in an ISO 10646 character set. Otherwise, parameters are
- encoded within HTTP headers. Section 9 describes the new HTTP
- headers used with WebDAV methods.
-
- In addition to encoding method parameters, XML is used in WebDAV to
- encode the responses from methods, providing the extensibility and
- internationalization advantages of XML for method output, as well as
- input.
-
- XML elements used in this specification are defined in section 12.
-
- The XML namespace extension (Appendix 4) is also used in this
- specification in order to allow for new XML elements to be added
- without fear of colliding with other element names.
-
- While the status codes provided by HTTP/1.1 are sufficient to
- describe most error conditions encountered by WebDAV methods, there
- are some errors that do not fall neatly into the existing categories.
- New status codes developed for the WebDAV methods are defined in
- section 10. Since some WebDAV methods may operate over many
-
-
-
-Goland, et al. Standards Track [Page 6]
-
-RFC 2518 WEBDAV February 1999
-
-
- resources, the Multi-Status response has been introduced to return
- status information for multiple resources. The Multi-Status response
- is described in section 11.
-
- WebDAV employs the property mechanism to store information about the
- current state of the resource. For example, when a lock is taken out
- on a resource, a lock information property describes the current
- state of the lock. Section 13 defines the properties used within the
- WebDAV specification.
-
- Finishing off the specification are sections on what it means to be
- compliant with this specification (section 15), on
- internationalization support (section 16), and on security (section
- 17).
-
-2 Notational Conventions
-
- Since this document describes a set of extensions to the HTTP/1.1
- protocol, the augmented BNF used herein to describe protocol elements
- is exactly the same as described in section 2.1 of [RFC2068]. Since
- this augmented BNF uses the basic production rules provided in
- section 2.2 of [RFC2068], these rules apply to this document as well.
-
- 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 [RFC2119].
-
-3 Terminology
-
- URI/URL - A Uniform Resource Identifier and Uniform Resource Locator,
- respectively. These terms (and the distinction between them) are
- defined in [RFC2396].
-
- Collection - A resource that contains a set of URIs, termed member
- URIs, which identify member resources and meets the requirements in
- section 5 of this specification.
-
- Member URI - A URI which is a member of the set of URIs contained by
- a collection.
-
- Internal Member URI - A Member URI that is immediately relative to
- the URI of the collection (the definition of immediately relative is
- given in section 5.2).
-
- Property - A name/value pair that contains descriptive information
- about a resource.
-
-
-
-
-
-Goland, et al. Standards Track [Page 7]
-
-RFC 2518 WEBDAV February 1999
-
-
- Live Property - A property whose semantics and syntax are enforced by
- the server. For example, the live "getcontentlength" property has
- its value, the length of the entity returned by a GET request,
- automatically calculated by the server.
-
- Dead Property - A property whose semantics and syntax are not
- enforced by the server. The server only records the value of a dead
- property; the client is responsible for maintaining the consistency
- of the syntax and semantics of a dead property.
-
- Null Resource - A resource which responds with a 404 (Not Found) to
- any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK.
- A NULL resource MUST NOT appear as a member of its parent collection.
-
-4 Data Model for Resource Properties
-
-4.1 The Resource Property Model
-
- Properties are pieces of data that describe the state of a resource.
- Properties are data about data.
-
- Properties are used in distributed authoring environments to provide
- for efficient discovery and management of resources. For example, a
- 'subject' property might allow for the indexing of all resources by
- their subject, and an 'author' property might allow for the discovery
- of what authors have written which documents.
-
- The DAV property model consists of name/value pairs. The name of a
- property identifies the property's syntax and semantics, and provides
- an address by which to refer to its syntax and semantics.
-
- There are two categories of properties: "live" and "dead". A live
- property has its syntax and semantics enforced by the server. Live
- properties include cases where a) the value of a property is read-
- only, maintained by the server, and b) the value of the property is
- maintained by the client, but the server performs syntax checking on
- submitted values. All instances of a given live property MUST comply
- with the definition associated with that property name. A dead
- property has its syntax and semantics enforced by the client; the
- server merely records the value of the property verbatim.
-
-4.2 Existing Metadata Proposals
-
- Properties have long played an essential role in the maintenance of
- large document repositories, and many current proposals contain some
- notion of a property, or discuss web metadata more generally. These
- include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several
- proposals on representing relationships within HTML. Work on PICS-NG
-
-
-
-Goland, et al. Standards Track [Page 8]
-
-RFC 2518 WEBDAV February 1999
-
-
- and Web Collections has been subsumed by the Resource Description
- Framework (RDF) metadata activity of the World Wide Web Consortium.
- RDF consists of a network-based data model and an XML representation
- of that model.
-
- Some proposals come from a digital library perspective. These
- include the Dublin Core [RFC2413] metadata set and the Warwick
- Framework [WF], a container architecture for different metadata
- schemas. The literature includes many examples of metadata,
- including MARC [USMARC], a bibliographic metadata format, and a
- technical report bibliographic format employed by the Dienst system
- [RFC1807]. Additionally, the proceedings from the first IEEE Metadata
- conference describe many community-specific metadata sets.
-
- Participants of the 1996 Metadata II Workshop in Warwick, UK [WF],
- noted that "new metadata sets will develop as the networked
- infrastructure matures" and "different communities will propose,
- design, and be responsible for different types of metadata." These
- observations can be corroborated by noting that many community-
- specific sets of metadata already exist, and there is significant
- motivation for the development of new forms of metadata as many
- communities increasingly make their data available in digital form,
- requiring a metadata format to assist data location and cataloging.
-
-4.3 Properties and HTTP Headers
-
- Properties already exist, in a limited sense, in HTTP message
- headers. However, in distributed authoring environments a relatively
- large number of properties are needed to describe the state of a
- resource, and setting/returning them all through HTTP headers is
- inefficient. Thus a mechanism is needed which allows a principal to
- identify a set of properties in which the principal is interested and
- to set or retrieve just those properties.
-
-4.4 Property Values
-
- The value of a property when expressed in XML MUST be well formed.
-
- XML has been chosen because it is a flexible, self-describing,
- structured data format that supports rich schema definitions, and
- because of its support for multiple character sets. XML's self-
- describing nature allows any property's value to be extended by
- adding new elements. Older clients will not break when they
- encounter extensions because they will still have the data specified
- in the original schema and will ignore elements they do not
- understand. XML's support for multiple character sets allows any
- human-readable property to be encoded and read in a character set
- familiar to the user. XML's support for multiple human languages,
-
-
-
-Goland, et al. Standards Track [Page 9]
-
-RFC 2518 WEBDAV February 1999
-
-
- using the "xml:lang" attribute, handles cases where the same
- character set is employed by multiple human languages.
-
-4.5 Property Names
-
- A property name is a universally unique identifier that is associated
- with a schema that provides information about the syntax and
- semantics of the property.
-
- Because a property's name is universally unique, clients can depend
- upon consistent behavior for a particular property across multiple
- resources, on the same and across different servers, so long as that
- property is "live" on the resources in question, and the
- implementation of the live property is faithful to its definition.
-
- The XML namespace mechanism, which is based on URIs [RFC2396], is
- used to name properties because it prevents namespace collisions and
- provides for varying degrees of administrative control.
-
- The property namespace is flat; that is, no hierarchy of properties
- is explicitly recognized. Thus, if a property A and a property A/B
- exist on a resource, there is no recognition of any relationship
- between the two properties. It is expected that a separate
- specification will eventually be produced which will address issues
- relating to hierarchical properties.
-
- Finally, it is not possible to define the same property twice on a
- single resource, as this would cause a collision in the resource's
- property namespace.
-
-4.6 Media Independent Links
-
- Although HTML resources support links to other resources, the Web
- needs more general support for links between resources of any media
- type (media types are also known as MIME types, or content types).
- WebDAV provides such links. A WebDAV link is a special type of
- property value, formally defined in section 12.4, that allows typed
- connections to be established between resources of any media type.
- The property value consists of source and destination Uniform
- Resource Identifiers (URIs); the property name identifies the link
- type.
-
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 10]
-
-RFC 2518 WEBDAV February 1999
-
-
-5 Collections of Web Resources
-
- This section provides a description of a new type of Web resource,
- the collection, and discusses its interactions with the HTTP URL
- namespace. The purpose of a collection resource is to model
- collection-like objects (e.g., file system directories) within a
- server's namespace.
-
- All DAV compliant resources MUST support the HTTP URL namespace model
- specified herein.
-
-5.1 HTTP URL Namespace Model
-
- The HTTP URL namespace is a hierarchical namespace where the
- hierarchy is delimited with the "/" character.
-
- An HTTP URL namespace is said to be consistent if it meets the
- following conditions: for every URL in the HTTP hierarchy there
- exists a collection that contains that URL as an internal member.
- The root, or top-level collection of the namespace under
- consideration is exempt from the previous rule.
-
- Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL
- namespace be consistent. However, certain WebDAV methods are
- prohibited from producing results that cause namespace
- inconsistencies.
-
- Although implicit in [RFC2068] and [RFC2396], any resource, including
- collection resources, MAY be identified by more than one URI. For
- example, a resource could be identified by multiple HTTP URLs.
-
-5.2 Collection Resources
-
- A collection is a resource whose state consists of at least a list of
- internal member URIs and a set of properties, but which may have
- additional state such as entity bodies returned by GET. An internal
- member URI MUST be immediately relative to a base URI of the
- collection. That is, the internal member URI is equal to a
- containing collection's URI plus an additional segment for non-
- collection resources, or additional segment plus trailing slash "/"
- for collection resources, where segment is defined in section 3.3 of
- [RFC2396].
-
- Any given internal member URI MUST only belong to the collection
- once, i.e., it is illegal to have multiple instances of the same URI
- in a collection. Properties defined on collections behave exactly as
- do properties on non-collection resources.
-
-
-
-
-Goland, et al. Standards Track [Page 11]
-
-RFC 2518 WEBDAV February 1999
-
-
- For all WebDAV compliant resources A and B, identified by URIs U and
- V, for which U is immediately relative to V, B MUST be a collection
- that has U as an internal member URI. So, if the resource with URL
- http://foo.com/bar/blah is WebDAV compliant and if the resource with
- URL http://foo.com/bar/ is WebDAV compliant then the resource with
- URL http://foo.com/bar/ must be a collection and must contain URL
- http://foo.com/bar/blah as an internal member.
-
- Collection resources MAY list the URLs of non-WebDAV compliant
- children in the HTTP URL namespace hierarchy as internal members but
- are not required to do so. For example, if the resource with URL
- http://foo.com/bar/blah is not WebDAV compliant and the URL
- http://foo.com/bar/ identifies a collection then URL
- http://foo.com/bar/blah may or may not be an internal member of the
- collection with URL http://foo.com/bar/.
-
- If a WebDAV compliant resource has no WebDAV compliant children in
- the HTTP URL namespace hierarchy then the WebDAV compliant resource
- is not required to be a collection.
-
- There is a standing convention that when a collection is referred to
- by its name without a trailing slash, the trailing slash is
- automatically appended. Due to this, a resource may accept a URI
- without a trailing "/" to point to a collection. In this case it
- SHOULD return a content-location header in the response pointing to
- the URI ending with the "/". For example, if a client invokes a
- method on http://foo.bar/blah (no trailing slash), the resource
- http://foo.bar/blah/ (trailing slash) may respond as if the operation
- were invoked on it, and should return a content-location header with
- http://foo.bar/blah/ in it. In general clients SHOULD use the "/"
- form of collection names.
-
- A resource MAY be a collection but not be WebDAV compliant. That is,
- the resource may comply with all the rules set out in this
- specification regarding how a collection is to behave without
- necessarily supporting all methods that a WebDAV compliant resource
- is required to support. In such a case the resource may return the
- DAV:resourcetype property with the value DAV:collection but MUST NOT
- return a DAV header containing the value "1" on an OPTIONS response.
-
-5.3 Creation and Retrieval of Collection Resources
-
- This document specifies the MKCOL method to create new collection
- resources, rather than using the existing HTTP/1.1 PUT or POST
- method, for the following reasons:
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 12]
-
-RFC 2518 WEBDAV February 1999
-
-
- In HTTP/1.1, the PUT method is defined to store the request body at
- the location specified by the Request-URI. While a description
- format for a collection can readily be constructed for use with PUT,
- the implications of sending such a description to the server are
- undesirable. For example, if a description of a collection that
- omitted some existing resources were PUT to a server, this might be
- interpreted as a command to remove those members. This would extend
- PUT to perform DELETE functionality, which is undesirable since it
- changes the semantics of PUT, and makes it difficult to control
- DELETE functionality with an access control scheme based on methods.
-
- While the POST method is sufficiently open-ended that a "create a
- collection" POST command could be constructed, this is undesirable
- because it would be difficult to separate access control for
- collection creation from other uses of POST.
-
- The exact definition of the behavior of GET and PUT on collections is
- defined later in this document.
-
-5.4 Source Resources and Output Resources
-
- For many resources, the entity returned by a GET method exactly
- matches the persistent state of the resource, for example, a GIF file
- stored on a disk. For this simple case, the URI at which a resource
- is accessed is identical to the URI at which the source (the
- persistent state) of the resource is accessed. This is also the case
- for HTML source files that are not processed by the server prior to
- transmission.
-
- However, the server can sometimes process HTML resources before they
- are transmitted as a return entity body. For example, a server-
- side-include directive within an HTML file might instruct a server to
- replace the directive with another value, such as the current date.
- In this case, what is returned by GET (HTML plus date) differs from
- the persistent state of the resource (HTML plus directive).
- Typically there is no way to access the HTML resource containing the
- unprocessed directive.
-
- Sometimes the entity returned by GET is the output of a data-
- producing process that is described by one or more source resources
- (that may not even have a location in the URI namespace). A single
- data-producing process may dynamically generate the state of a
- potentially large number of output resources. An example of this is
- a CGI script that describes a "finger" gateway process that maps part
- of the namespace of a server into finger requests, such as
- http://www.foo.bar.org/finger_gateway/user@host.
-
-
-
-
-
-Goland, et al. Standards Track [Page 13]
-
-RFC 2518 WEBDAV February 1999
-
-
- In the absence of distributed authoring capabilities, it is
- acceptable to have no mapping of source resource(s) to the URI
- namespace. In fact, preventing access to the source resource(s) has
- desirable security benefits. However, if remote editing of the
- source resource(s) is desired, the source resource(s) should be given
- a location in the URI namespace. This source location should not be
- one of the locations at which the generated output is retrievable,
- since in general it is impossible for the server to differentiate
- requests for source resources from requests for process output
- resources. There is often a many-to-many relationship between source
- resources and output resources.
-
- On WebDAV compliant servers the URI of the source resource(s) may be
- stored in a link on the output resource with type DAV:source (see
- section 13.10 for a description of the source link property).
- Storing the source URIs in links on the output resources places the
- burden of discovering the source on the authoring client. Note that
- the value of a source link is not guaranteed to point to the correct
- source. Source links may break or incorrect values may be entered.
- Also note that not all servers will allow the client to set the
- source link value. For example a server which generates source links
- on the fly for its CGI files will most likely not allow a client to
- set the source link value.
-
-6 Locking
-
- The ability to lock a resource provides a mechanism for serializing
- access to that resource. Using a lock, an authoring client can
- provide a reasonable guarantee that another principal will not modify
- a resource while it is being edited. In this way, a client can
- prevent the "lost update" problem.
-
- This specification allows locks to vary over two client-specified
- parameters, the number of principals involved (exclusive vs. shared)
- and the type of access to be granted. This document defines locking
- for only one access type, write. However, the syntax is extensible,
- and permits the eventual specification of locking for other access
- types.
-
-6.1 Exclusive Vs. Shared Locks
-
- The most basic form of lock is an exclusive lock. This is a lock
- where the access right in question is only granted to a single
- principal. The need for this arbitration results from a desire to
- avoid having to merge results.
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 14]
-
-RFC 2518 WEBDAV February 1999
-
-
- However, there are times when the goal of a lock is not to exclude
- others from exercising an access right but rather to provide a
- mechanism for principals to indicate that they intend to exercise
- their access rights. Shared locks are provided for this case. A
- shared lock allows multiple principals to receive a lock. Hence any
- principal with appropriate access can get the lock.
-
- With shared locks there are two trust sets that affect a resource.
- The first trust set is created by access permissions. Principals who
- are trusted, for example, may have permission to write to the
- resource. Among those who have access permission to write to the
- resource, the set of principals who have taken out a shared lock also
- must trust each other, creating a (typically) smaller trust set
- within the access permission write set.
-
- Starting with every possible principal on the Internet, in most
- situations the vast majority of these principals will not have write
- access to a given resource. Of the small number who do have write
- access, some principals may decide to guarantee their edits are free
- from overwrite conflicts by using exclusive write locks. Others may
- decide they trust their collaborators will not overwrite their work
- (the potential set of collaborators being the set of principals who
- have write permission) and use a shared lock, which informs their
- collaborators that a principal may be working on the resource.
-
- The WebDAV extensions to HTTP do not need to provide all of the
- communications paths necessary for principals to coordinate their
- activities. When using shared locks, principals may use any out of
- band communication channel to coordinate their work (e.g., face-to-
- face interaction, written notes, post-it notes on the screen,
- telephone conversation, Email, etc.) The intent of a shared lock is
- to let collaborators know who else may be working on a resource.
-
- Shared locks are included because experience from web distributed
- authoring systems has indicated that exclusive locks are often too
- rigid. An exclusive lock is used to enforce a particular editing
- process: take out an exclusive lock, read the resource, perform
- edits, write the resource, release the lock. This editing process
- has the problem that locks are not always properly released, for
- example when a program crashes, or when a lock owner leaves without
- unlocking a resource. While both timeouts and administrative action
- can be used to remove an offending lock, neither mechanism may be
- available when needed; the timeout may be long or the administrator
- may not be available.
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 15]
-
-RFC 2518 WEBDAV February 1999
-
-
-6.2 Required Support
-
- A WebDAV compliant server is not required to support locking in any
- form. If the server does support locking it may choose to support
- any combination of exclusive and shared locks for any access types.
-
- The reason for this flexibility is that locking policy strikes to the
- very heart of the resource management and versioning systems employed
- by various storage repositories. These repositories require control
- over what sort of locking will be made available. For example, some
- repositories only support shared write locks while others only
- provide support for exclusive write locks while yet others use no
- locking at all. As each system is sufficiently different to merit
- exclusion of certain locking features, this specification leaves
- locking as the sole axis of negotiation within WebDAV.
-
-6.3 Lock Tokens
-
- A lock token is a type of state token, represented as a URI, which
- identifies a particular lock. A lock token is returned by every
- successful LOCK operation in the lockdiscovery property in the
- response body, and can also be found through lock discovery on a
- resource.
-
- Lock token URIs MUST be unique across all resources for all time.
- This uniqueness constraint allows lock tokens to be submitted across
- resources and servers without fear of confusion.
-
- This specification provides a lock token URI scheme called
- opaquelocktoken that meets the uniqueness requirements. However
- resources are free to return any URI scheme so long as it meets the
- uniqueness requirements.
-
- Having a lock token provides no special access rights. Anyone can
- find out anyone else's lock token by performing lock discovery.
- Locks MUST be enforced based upon whatever authentication mechanism
- is used by the server, not based on the secrecy of the token values.
-
-6.4 opaquelocktoken Lock Token URI Scheme
-
- The opaquelocktoken URI scheme is designed to be unique across all
- resources for all time. Due to this uniqueness quality, a client may
- submit an opaque lock token in an If header on a resource other than
- the one that returned it.
-
- All resources MUST recognize the opaquelocktoken scheme and, at
- minimum, recognize that the lock token does not refer to an
- outstanding lock on the resource.
-
-
-
-Goland, et al. Standards Track [Page 16]
-
-RFC 2518 WEBDAV February 1999
-
-
- In order to guarantee uniqueness across all resources for all time
- the opaquelocktoken requires the use of the Universal Unique
- Identifier (UUID) mechanism, as described in [ISO-11578].
-
- Opaquelocktoken generators, however, have a choice of how they create
- these tokens. They can either generate a new UUID for every lock
- token they create or they can create a single UUID and then add
- extension characters. If the second method is selected then the
- program generating the extensions MUST guarantee that the same
- extension will never be used twice with the associated UUID.
-
- OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID
- production is the string representation of a UUID, as defined in
- [ISO-11578]. Note that white space (LWS) is not allowed between
- elements of this production.
-
- Extension = path ; path is defined in section 3.2.1 of RFC 2068
- [RFC2068]
-
-6.4.1 Node Field Generation Without the IEEE 802 Address
-
- UUIDs, as defined in [ISO-11578], contain a "node" field that
- contains one of the IEEE 802 addresses for the server machine. As
- noted in section 17.8, there are several security risks associated
- with exposing a machine's IEEE 802 address. This section provides an
- alternate mechanism for generating the "node" field of a UUID which
- does not employ an IEEE 802 address. WebDAV servers MAY use this
- algorithm for creating the node field when generating UUIDs. The
- text in this section is originally from an Internet-Draft by Paul
- Leach and Rich Salz, who are noted here to properly attribute their
- work.
-
- The ideal solution is to obtain a 47 bit cryptographic quality random
- number, and use it as the low 47 bits of the node ID, with the most
- significant bit of the first octet of the node ID set to 1. This bit
- is the unicast/multicast bit, which will never be set in IEEE 802
- addresses obtained from network cards; hence, there can never be a
- conflict between UUIDs generated by machines with and without network
- cards.
-
- If a system does not have a primitive to generate cryptographic
- quality random numbers, then in most systems there are usually a
- fairly large number of sources of randomness available from which one
- can be generated. Such sources are system specific, but often
- include:
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 17]
-
-RFC 2518 WEBDAV February 1999
-
-
- - the percent of memory in use
- - the size of main memory in bytes
- - the amount of free main memory in bytes
- - the size of the paging or swap file in bytes
- - free bytes of paging or swap file
- - the total size of user virtual address space in bytes
- - the total available user address space bytes
- - the size of boot disk drive in bytes
- - the free disk space on boot drive in bytes
- - the current time
- - the amount of time since the system booted
- - the individual sizes of files in various system directories
- - the creation, last read, and modification times of files in
- various system directories
- - the utilization factors of various system resources (heap, etc.)
- - current mouse cursor position
- - current caret position
- - current number of running processes, threads
- - handles or IDs of the desktop window and the active window
- - the value of stack pointer of the caller
- - the process and thread ID of caller
- - various processor architecture specific performance counters
- (instructions executed, cache misses, TLB misses)
-
- (Note that it is precisely the above kinds of sources of randomness
- that are used to seed cryptographic quality random number generators
- on systems without special hardware for their construction.)
-
- In addition, items such as the computer's name and the name of the
- operating system, while not strictly speaking random, will help
- differentiate the results from those obtained by other systems.
-
- The exact algorithm to generate a node ID using these data is system
- specific, because both the data available and the functions to obtain
- them are often very system specific. However, assuming that one can
- concatenate all the values from the randomness sources into a buffer,
- and that a cryptographic hash function such as MD5 is available, then
- any 6 bytes of the MD5 hash of the buffer, with the multicast bit
- (the high bit of the first byte) set will be an appropriately random
- node ID.
-
- Other hash functions, such as SHA-1, can also be used. The only
- requirement is that the result be suitably random _ in the sense that
- the outputs from a set uniformly distributed inputs are themselves
- uniformly distributed, and that a single bit change in the input can
- be expected to cause half of the output bits to change.
-
-
-
-
-
-Goland, et al. Standards Track [Page 18]
-
-RFC 2518 WEBDAV February 1999
-
-
-6.5 Lock Capability Discovery
-
- Since server lock support is optional, a client trying to lock a
- resource on a server can either try the lock and hope for the best,
- or perform some form of discovery to determine what lock capabilities
- the server supports. This is known as lock capability discovery.
- Lock capability discovery differs from discovery of supported access
- control types, since there may be access control types without
- corresponding lock types. A client can determine what lock types the
- server supports by retrieving the supportedlock property.
-
- Any DAV compliant resource that supports the LOCK method MUST support
- the supportedlock property.
-
-6.6 Active Lock Discovery
-
- If another principal locks a resource that a principal wishes to
- access, it is useful for the second principal to be able to find out
- who the first principal is. For this purpose the lockdiscovery
- property is provided. This property lists all outstanding locks,
- describes their type, and where available, provides their lock token.
-
- Any DAV compliant resource that supports the LOCK method MUST support
- the lockdiscovery property.
-
-6.7 Usage Considerations
-
- Although the locking mechanisms specified here provide some help in
- preventing lost updates, they cannot guarantee that updates will
- never be lost. Consider the following scenario:
-
- Two clients A and B are interested in editing the resource '
- index.html'. Client A is an HTTP client rather than a WebDAV client,
- and so does not know how to perform locking.
- Client A doesn't lock the document, but does a GET and begins
- editing.
- Client B does LOCK, performs a GET and begins editing.
- Client B finishes editing, performs a PUT, then an UNLOCK.
- Client A performs a PUT, overwriting and losing all of B's changes.
-
- There are several reasons why the WebDAV protocol itself cannot
- prevent this situation. First, it cannot force all clients to use
- locking because it must be compatible with HTTP clients that do not
- comprehend locking. Second, it cannot require servers to support
- locking because of the variety of repository implementations, some of
- which rely on reservations and merging rather than on locking.
- Finally, being stateless, it cannot enforce a sequence of operations
- like LOCK / GET / PUT / UNLOCK.
-
-
-
-Goland, et al. Standards Track [Page 19]
-
-RFC 2518 WEBDAV February 1999
-
-
- WebDAV servers that support locking can reduce the likelihood that
- clients will accidentally overwrite each other's changes by requiring
- clients to lock resources before modifying them. Such servers would
- effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
- resources.
-
- WebDAV clients can be good citizens by using a lock / retrieve /
- write /unlock sequence of operations (at least by default) whenever
- they interact with a WebDAV server that supports locking.
-
- HTTP 1.1 clients can be good citizens, avoiding overwriting other
- clients' changes, by using entity tags in If-Match headers with any
- requests that would modify resources.
-
- Information managers may attempt to prevent overwrites by
- implementing client-side procedures requiring locking before
- modifying WebDAV resources.
-
-7 Write Lock
-
- This section describes the semantics specific to the write lock type.
- The write lock is a specific instance of a lock type, and is the only
- lock type described in this specification.
-
-7.1 Methods Restricted by Write Locks
-
- A write lock MUST prevent a principal without the lock from
- successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,
- DELETE, or MKCOL on the locked resource. All other current methods,
- GET in particular, function independently of the lock.
-
- Note, however, that as new methods are created it will be necessary
- to specify how they interact with a write lock.
-
-7.2 Write Locks and Lock Tokens
-
- A successful request for an exclusive or shared write lock MUST
- result in the generation of a unique lock token associated with the
- requesting principal. Thus if five principals have a shared write
- lock on the same resource there will be five lock tokens, one for
- each principal.
-
-7.3 Write Locks and Properties
-
- While those without a write lock may not alter a property on a
- resource it is still possible for the values of live properties to
- change, even while locked, due to the requirements of their schemas.
-
-
-
-
-Goland, et al. Standards Track [Page 20]
-
-RFC 2518 WEBDAV February 1999
-
-
- Only dead properties and live properties defined to respect locks are
- guaranteed not to change while write locked.
-
-7.4 Write Locks and Null Resources
-
- It is possible to assert a write lock on a null resource in order to
- lock the name.
-
- A write locked null resource, referred to as a lock-null resource,
- MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to
- any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND,
- LOCK, and UNLOCK. A lock-null resource MUST appear as a member of
- its parent collection. Additionally the lock-null resource MUST have
- defined on it all mandatory DAV properties. Most of these
- properties, such as all the get* properties, will have no value as a
- lock-null resource does not support the GET method. Lock-Null
- resources MUST have defined values for lockdiscovery and
- supportedlock properties.
-
- Until a method such as PUT or MKCOL is successfully executed on the
- lock-null resource the resource MUST stay in the lock-null state.
- However, once a PUT or MKCOL is successfully executed on a lock-null
- resource the resource ceases to be in the lock-null state.
-
- If the resource is unlocked, for any reason, without a PUT, MKCOL, or
- similar method having been successfully executed upon it then the
- resource MUST return to the null state.
-
-7.5 Write Locks and Collections
-
- A write lock on a collection, whether created by a "Depth: 0" or
- "Depth: infinity" lock request, prevents the addition or removal of
- member URIs of the collection by non-lock owners. As a consequence,
- when a principal issues a PUT or POST request to create a new
- resource under a URI which needs to be an internal member of a write
- locked collection to maintain HTTP namespace consistency, or issues a
- DELETE to remove a resource which has a URI which is an existing
- internal member URI of a write locked collection, this request MUST
- fail if the principal does not have a write lock on the collection.
-
- However, if a write lock request is issued to a collection containing
- member URIs identifying resources that are currently locked in a
- manner which conflicts with the write lock, the request MUST fail
- with a 423 (Locked) status code.
-
- If a lock owner causes the URI of a resource to be added as an
- internal member URI of a locked collection then the new resource MUST
- be automatically added to the lock. This is the only mechanism that
-
-
-
-Goland, et al. Standards Track [Page 21]
-
-RFC 2518 WEBDAV February 1999
-
-
- allows a resource to be added to a write lock. Thus, for example, if
- the collection /a/b/ is write locked and the resource /c is moved to
- /a/b/c then resource /a/b/c will be added to the write lock.
-
-7.6 Write Locks and the If Request Header
-
- If a user agent is not required to have knowledge about a lock when
- requesting an operation on a locked resource, the following scenario
- might occur. Program A, run by User A, takes out a write lock on a
- resource. Program B, also run by User A, has no knowledge of the
- lock taken out by Program A, yet performs a PUT to the locked
- resource. In this scenario, the PUT succeeds because locks are
- associated with a principal, not a program, and thus program B,
- because it is acting with principal A's credential, is allowed to
- perform the PUT. However, had program B known about the lock, it
- would not have overwritten the resource, preferring instead to
- present a dialog box describing the conflict to the user. Due to
- this scenario, a mechanism is needed to prevent different programs
- from accidentally ignoring locks taken out by other programs with the
- same authorization.
-
- In order to prevent these collisions a lock token MUST be submitted
- by an authorized principal in the If header for all locked resources
- that a method may interact with or the method MUST fail. For
- example, if a resource is to be moved and both the source and
- destination are locked then two lock tokens must be submitted, one
- for the source and the other for the destination.
-
-7.6.1 Example - Write Lock
-
- >>Request
-
- COPY /~fielding/index.html HTTP/1.1
- Host: www.ics.uci.edu
- Destination: http://www.ics.uci.edu/users/f/fielding/index.html
- If: <http://www.ics.uci.edu/users/f/fielding/index.html>
- (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
-
- >>Response
-
- HTTP/1.1 204 No Content
-
- In this example, even though both the source and destination are
- locked, only one lock token must be submitted, for the lock on the
- destination. This is because the source resource is not modified by
- a COPY, and hence unaffected by the write lock. In this example, user
- agent authentication has previously occurred via a mechanism outside
- the scope of the HTTP protocol, in the underlying transport layer.
-
-
-
-Goland, et al. Standards Track [Page 22]
-
-RFC 2518 WEBDAV February 1999
-
-
-7.7 Write Locks and COPY/MOVE
-
- A COPY method invocation MUST NOT duplicate any write locks active on
- the source. However, as previously noted, if the COPY copies the
- resource into a collection that is locked with "Depth: infinity",
- then the resource will be added to the lock.
-
- A successful MOVE request on a write locked resource MUST NOT move
- the write lock with the resource. However, the resource is subject to
- being added to an existing lock at the destination, as specified in
- section 7.5. For example, if the MOVE makes the resource a child of a
- collection that is locked with "Depth: infinity", then the resource
- will be added to that collection's lock. Additionally, if a resource
- locked with "Depth: infinity" is moved to a destination that is
- within the scope of the same lock (e.g., within the namespace tree
- covered by the lock), the moved resource will again be a added to the
- lock. In both these examples, as specified in section 7.6, an If
- header must be submitted containing a lock token for both the source
- and destination.
-
-7.8 Refreshing Write Locks
-
- A client MUST NOT submit the same write lock request twice. Note
- that a client is always aware it is resubmitting the same lock
- request because it must include the lock token in the If header in
- order to make the request for a resource that is already locked.
-
- However, a client may submit a LOCK method with an If header but
- without a body. This form of LOCK MUST only be used to "refresh" a
- lock. Meaning, at minimum, that any timers associated with the lock
- MUST be re-set.
-
- A server may return a Timeout header with a lock refresh that is
- different than the Timeout header returned when the lock was
- originally requested. Additionally clients may submit Timeout
- headers of arbitrary value with their lock refresh requests.
- Servers, as always, may ignore Timeout headers submitted by the
- client.
-
- If an error is received in response to a refresh LOCK request the
- client SHOULD assume that the lock was not refreshed.
-
-8 HTTP Methods for Distributed Authoring
-
- The following new HTTP methods use XML as a request and response
- format. All DAV compliant clients and resources MUST use XML parsers
- that are compliant with [REC-XML]. All XML used in either requests
- or responses MUST be, at minimum, well formed. If a server receives
-
-
-
-Goland, et al. Standards Track [Page 23]
-
-RFC 2518 WEBDAV February 1999
-
-
- ill-formed XML in a request it MUST reject the entire request with a
- 400 (Bad Request). If a client receives ill-formed XML in a response
- then it MUST NOT assume anything about the outcome of the executed
- method and SHOULD treat the server as malfunctioning.
-
-8.1 PROPFIND
-
- The PROPFIND method retrieves properties defined on the resource
- identified by the Request-URI, if the resource does not have any
- internal members, or on the resource identified by the Request-URI
- and potentially its member resources, if the resource is a collection
- that has internal member URIs. All DAV compliant resources MUST
- support the PROPFIND method and the propfind XML element (section
- 12.14) along with all XML elements defined for use with that element.
-
- A client may submit a Depth header with a value of "0", "1", or
- "infinity" with a PROPFIND on a collection resource with internal
- member URIs. DAV compliant servers MUST support the "0", "1" and
- "infinity" behaviors. By default, the PROPFIND method without a Depth
- header MUST act as if a "Depth: infinity" header was included.
-
- A client may submit a propfind XML element in the body of the request
- method describing what information is being requested. It is
- possible to request particular property values, all property values,
- or a list of the names of the resource's properties. A client may
- choose not to submit a request body. An empty PROPFIND request body
- MUST be treated as a request for the names and values of all
- properties.
-
- All servers MUST support returning a response of content type
- text/xml or application/xml that contains a multistatus XML element
- that describes the results of the attempts to retrieve the various
- properties.
-
- If there is an error retrieving a property then a proper error result
- MUST be included in the response. A request to retrieve the value of
- a property which does not exist is an error and MUST be noted, if the
- response uses a multistatus XML element, with a response XML element
- which contains a 404 (Not Found) status value.
-
- Consequently, the multistatus XML element for a collection resource
- with member URIs MUST include a response XML element for each member
- URI of the collection, to whatever depth was requested. Each response
- XML element MUST contain an href XML element that gives the URI of
- the resource on which the properties in the prop XML element are
- defined. Results for a PROPFIND on a collection resource with
- internal member URIs are returned as a flat list whose order of
- entries is not significant.
-
-
-
-Goland, et al. Standards Track [Page 24]
-
-RFC 2518 WEBDAV February 1999
-
-
- In the case of allprop and propname, if a principal does not have the
- right to know whether a particular property exists then the property
- should be silently excluded from the response.
-
- The results of this method SHOULD NOT be cached.
-
-8.1.1 Example - Retrieving Named Properties
-
- >>Request
-
- PROPFIND /file HTTP/1.1
- Host: www.foo.bar
- Content-type: text/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:">
- <D:prop xmlns:R="http://www.foo.bar/boxschema/">
- <R:bigbox/>
- <R:author/>
- <R:DingALing/>
- <R:Random/>
- </D:prop>
- </D:propfind>
-
- >>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.foo.bar/file</D:href>
- <D:propstat>
- <D:prop xmlns:R="http://www.foo.bar/boxschema/">
- <R:bigbox>
- <R:BoxType>Box type A</R:BoxType>
- </R:bigbox>
- <R:author>
- <R:Name>J.J. Johnson</R:Name>
- </R:author>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- <D:propstat>
- <D:prop><R:DingALing/><R:Random/></D:prop>
-
-
-
-Goland, et al. Standards Track [Page 25]
-
-RFC 2518 WEBDAV February 1999
-
-
- <D:status>HTTP/1.1 403 Forbidden</D:status>
- <D:responsedescription> The user does not have access to
- the DingALing property.
- </D:responsedescription>
- </D:propstat>
- </D:response>
- <D:responsedescription> There has been an access violation error.
- </D:responsedescription>
- </D:multistatus>
-
- In this example, PROPFIND is executed on a non-collection resource
- http://www.foo.bar/file. The propfind XML element specifies the name
- of four properties whose values are being requested. In this case
- only two properties were returned, since the principal issuing the
- request did not have sufficient access rights to see the third and
- fourth properties.
-
-8.1.2 Example - Using allprop to Retrieve All Properties
-
- >>Request
-
- PROPFIND /container/ HTTP/1.1
- Host: www.foo.bar
- Depth: 1
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:">
- <D:allprop/>
- </D:propfind>
-
- >>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.foo.bar/container/</D:href>
- <D:propstat>
- <D:prop xmlns:R="http://www.foo.bar/boxschema/">
- <R:bigbox>
- <R:BoxType>Box type A</R:BoxType>
- </R:bigbox>
- <R:author>
-
-
-
-Goland, et al. Standards Track [Page 26]
-
-RFC 2518 WEBDAV February 1999
-
-
- <R:Name>Hadrian</R:Name>
- </R:author>
- <D:creationdate>
- 1997-12-01T17:42:21-08:00
- </D:creationdate>
- <D:displayname>
- Example collection
- </D:displayname>
- <D:resourcetype><D:collection/></D:resourcetype>
- <D:supportedlock>
- <D:lockentry>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- <D:lockentry>
- <D:lockscope><D:shared/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- </D:supportedlock>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
- <D:response>
- <D:href>http://www.foo.bar/container/front.html</D:href>
- <D:propstat>
- <D:prop xmlns:R="http://www.foo.bar/boxschema/">
- <R:bigbox>
- <R:BoxType>Box type B</R:BoxType>
- </R:bigbox>
- <D:creationdate>
- 1997-12-01T18:27:21-08:00
- </D:creationdate>
- <D:displayname>
- Example HTML resource
- </D:displayname>
- <D:getcontentlength>
- 4525
- </D:getcontentlength>
- <D:getcontenttype>
- text/html
- </D:getcontenttype>
- <D:getetag>
- zzyzx
- </D:getetag>
- <D:getlastmodified>
- Monday, 12-Jan-98 09:25:56 GMT
- </D:getlastmodified>
-
-
-
-Goland, et al. Standards Track [Page 27]
-
-RFC 2518 WEBDAV February 1999
-
-
- <D:resourcetype/>
- <D:supportedlock>
- <D:lockentry>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- <D:lockentry>
- <D:lockscope><D:shared/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- </D:supportedlock>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
- </D:multistatus>
-
- In this example, PROPFIND was invoked on the resource
- http://www.foo.bar/container/ with a Depth header of 1, meaning the
- request applies to the resource and its children, and a propfind XML
- element containing the allprop XML element, meaning the request
- should return the name and value of all properties defined on each
- resource.
-
- The resource http://www.foo.bar/container/ has six properties defined
- on it:
-
- http://www.foo.bar/boxschema/bigbox,
- http://www.foo.bar/boxschema/author, DAV:creationdate,
- DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
-
- The last four properties are WebDAV-specific, defined in section 13.
- Since GET is not supported on this resource, the get* properties
- (e.g., getcontentlength) are not defined on this resource. The DAV-
- specific properties assert that "container" was created on December
- 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT
- (creationdate), has a name of "Example collection" (displayname), a
- collection resource type (resourcetype), and supports exclusive write
- and shared write locks (supportedlock).
-
- The resource http://www.foo.bar/container/front.html has nine
- properties defined on it:
-
- http://www.foo.bar/boxschema/bigbox (another instance of the "bigbox"
- property type), DAV:creationdate, DAV:displayname,
- DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
- DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
-
-
-
-
-Goland, et al. Standards Track [Page 28]
-
-RFC 2518 WEBDAV February 1999
-
-
- The DAV-specific properties assert that "front.html" was created on
- December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT
- (creationdate), has a name of "Example HTML resource" (displayname),
- a content length of 4525 bytes (getcontentlength), a MIME type of
- "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was
- last modified on Monday, January 12, 1998, at 09:25:56 GMT
- (getlastmodified), has an empty resource type, meaning that it is not
- a collection (resourcetype), and supports both exclusive write and
- shared write locks (supportedlock).
-
-8.1.3 Example - Using propname to Retrieve all Property Names
-
- >>Request
-
- PROPFIND /container/ HTTP/1.1
- Host: www.foo.bar
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <propfind xmlns="DAV:">
- <propname/>
- </propfind>
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <multistatus xmlns="DAV:">
- <response>
- <href>http://www.foo.bar/container/</href>
- <propstat>
- <prop xmlns:R="http://www.foo.bar/boxschema/">
- <R:bigbox/>
- <R:author/>
- <creationdate/>
- <displayname/>
- <resourcetype/>
- <supportedlock/>
- </prop>
- <status>HTTP/1.1 200 OK</status>
- </propstat>
- </response>
- <response>
- <href>http://www.foo.bar/container/front.html</href>
-
-
-
-Goland, et al. Standards Track [Page 29]
-
-RFC 2518 WEBDAV February 1999
-
-
- <propstat>
- <prop xmlns:R="http://www.foo.bar/boxschema/">
- <R:bigbox/>
- <creationdate/>
- <displayname/>
- <getcontentlength/>
- <getcontenttype/>
- <getetag/>
- <getlastmodified/>
- <resourcetype/>
- <supportedlock/>
- </prop>
- <status>HTTP/1.1 200 OK</status>
- </propstat>
- </response>
- </multistatus>
-
-
- In this example, PROPFIND is invoked on the collection resource
- http://www.foo.bar/container/, with a propfind XML element containing
- the propname XML element, meaning the name of all properties should
- be returned. Since no Depth header is present, it assumes its
- default value of "infinity", meaning the name of the properties on
- the collection and all its progeny should be returned.
-
- Consistent with the previous example, resource
- http://www.foo.bar/container/ has six properties defined on it,
- http://www.foo.bar/boxschema/bigbox,
- http://www.foo.bar/boxschema/author, DAV:creationdate,
- DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
-
- The resource http://www.foo.bar/container/index.html, a member of the
- "container" collection, has nine properties defined on it,
- http://www.foo.bar/boxschema/bigbox, DAV:creationdate,
- DAV:displayname, DAV:getcontentlength, DAV:getcontenttype,
- DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and
- DAV:supportedlock.
-
- This example also demonstrates the use of XML namespace scoping, and
- the default namespace. Since the "xmlns" attribute does not contain
- an explicit "shorthand name" (prefix) letter, the namespace applies
- by default to all enclosed elements. Hence, all elements which do
- not explicitly state the namespace to which they belong are members
- of the "DAV:" namespace schema.
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 30]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.2 PROPPATCH
-
- The PROPPATCH method processes instructions specified in the request
- body to set and/or remove properties defined on the resource
- identified by the Request-URI.
-
- All DAV compliant resources MUST support the PROPPATCH method and
- MUST process instructions that are specified using the
- propertyupdate, set, and remove XML elements of the DAV schema.
- Execution of the directives in this method is, of course, subject to
- access control constraints. DAV compliant resources SHOULD support
- the setting of arbitrary dead properties.
-
- The request message body of a PROPPATCH method MUST contain the
- propertyupdate XML element. Instruction processing MUST occur in the
- order instructions are received (i.e., from top to bottom).
- Instructions MUST either all be executed or none executed. Thus if
- any error occurs during processing all executed instructions MUST be
- undone and a proper error result returned. Instruction processing
- details can be found in the definition of the set and remove
- instructions in section 12.13.
-
-8.2.1 Status Codes for use with 207 (Multi-Status)
-
- The following are examples of response codes one would expect to be
- used in a 207 (Multi-Status) response for this method. Note,
- however, that unless explicitly prohibited any 2/3/4/5xx series
- response code may be used in a 207 (Multi-Status) response.
-
- 200 (OK) - The command succeeded. As there can be a mixture of sets
- and removes in a body, a 201 (Created) seems inappropriate.
-
- 403 (Forbidden) - The client, for reasons the server chooses not to
- specify, cannot alter one of the properties.
-
- 409 (Conflict) - The client has provided a value whose semantics are
- not appropriate for the property. This includes trying to set read-
- only properties.
-
- 423 (Locked) - The specified resource is locked and the client either
- is not a lock owner or the lock type requires a lock token to be
- submitted and the client did not submit it.
-
- 507 (Insufficient Storage) - The server did not have sufficient space
- to record the property.
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 31]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.2.2 Example - PROPPATCH
-
- >>Request
-
- PROPPATCH /bar.html HTTP/1.1
- Host: www.foo.com
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propertyupdate xmlns:D="DAV:"
- xmlns:Z="http://www.w3.com/standards/z39.50/">
- <D:set>
- <D:prop>
- <Z:authors>
- <Z:Author>Jim Whitehead</Z:Author>
- <Z:Author>Roy Fielding</Z:Author>
- </Z:authors>
- </D:prop>
- </D:set>
- <D:remove>
- <D:prop><Z:Copyright-Owner/></D:prop>
- </D:remove>
- </D:propertyupdate>
-
- >>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:"
- xmlns:Z="http://www.w3.com/standards/z39.50">
- <D:response>
- <D:href>http://www.foo.com/bar.html</D:href>
- <D:propstat>
- <D:prop><Z:Authors/></D:prop>
- <D:status>HTTP/1.1 424 Failed Dependency</D:status>
- </D:propstat>
- <D:propstat>
- <D:prop><Z:Copyright-Owner/></D:prop>
- <D:status>HTTP/1.1 409 Conflict</D:status>
- </D:propstat>
- <D:responsedescription> Copyright Owner can not be deleted or
- altered.</D:responsedescription>
- </D:response>
- </D:multistatus>
-
-
-
-Goland, et al. Standards Track [Page 32]
-
-RFC 2518 WEBDAV February 1999
-
-
- In this example, the client requests the server to set the value of
- the http://www.w3.com/standards/z39.50/Authors property, and to
- remove the property http://www.w3.com/standards/z39.50/Copyright-
- Owner. Since the Copyright-Owner property could not be removed, no
- property modifications occur. The 424 (Failed Dependency) status
- code for the Authors property indicates this action would have
- succeeded if it were not for the conflict with removing the
- Copyright-Owner property.
-
-8.3 MKCOL Method
-
- The MKCOL method is used to create a new collection. All DAV
- compliant resources MUST support the MKCOL method.
-
-8.3.1 Request
-
- MKCOL creates a new collection resource at the location specified by
- the Request-URI. If the resource identified by the Request-URI is
- non-null then the MKCOL MUST fail. During MKCOL processing, a server
- MUST make the Request-URI a member of its parent collection, unless
- the Request-URI is "/". If no such ancestor exists, the method MUST
- fail. When the MKCOL operation creates a new collection resource,
- all ancestors MUST already exist, or the method MUST fail with a 409
- (Conflict) status code. For example, if a request to create
- collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ exists,
- the request must fail.
-
- When MKCOL is invoked without a request body, the newly created
- collection SHOULD have no members.
-
- A MKCOL request message may contain a message body. The behavior of
- a MKCOL request when the body is present is limited to creating
- collections, members of a collection, bodies of members and
- properties on the collections or members. If the server receives a
- MKCOL request entity type it does not support or understand it MUST
- respond with a 415 (Unsupported Media Type) status code. The exact
- behavior of MKCOL for various request media types is undefined in
- this document, and will be specified in separate documents.
-
-8.3.2 Status Codes
-
- Responses from a MKCOL request MUST NOT be cached as MKCOL has non-
- idempotent semantics.
-
- 201 (Created) - The collection or structured resource was created in
- its entirety.
-
-
-
-
-
-Goland, et al. Standards Track [Page 33]
-
-RFC 2518 WEBDAV February 1999
-
-
- 403 (Forbidden) - This indicates at least one of two conditions: 1)
- the server does not allow the creation of collections at the given
- location in its namespace, or 2) the parent collection of the
- Request-URI exists but cannot accept members.
-
- 405 (Method Not Allowed) - MKCOL can only be executed on a
- deleted/non-existent resource.
-
- 409 (Conflict) - A collection cannot be made at the Request-URI until
- one or more intermediate collections have been created.
-
- 415 (Unsupported Media Type)- The server does not support the request
- type of the body.
-
- 507 (Insufficient Storage) - The resource does not have sufficient
- space to record the state of the resource after the execution of this
- method.
-
-8.3.3 Example - MKCOL
-
- This example creates a collection called /webdisc/xfiles/ on the
- server www.server.org.
-
- >>Request
-
- MKCOL /webdisc/xfiles/ HTTP/1.1
- Host: www.server.org
-
- >>Response
-
- HTTP/1.1 201 Created
-
-8.4 GET, HEAD for Collections
-
- The semantics of GET are unchanged when applied to a collection,
- since GET is defined as, "retrieve whatever information (in the form
- of an entity) is identified by the Request-URI" [RFC2068]. GET when
- applied to a collection may return the contents of an "index.html"
- resource, a human-readable view of the contents of the collection, or
- something else altogether. Hence it is possible that the result of a
- GET on a collection will bear no correlation to the membership of the
- collection.
-
- Similarly, since the definition of HEAD is a GET without a response
- message body, the semantics of HEAD are unmodified when applied to
- collection resources.
-
-
-
-
-
-Goland, et al. Standards Track [Page 34]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.5 POST for Collections
-
- Since by definition the actual function performed by POST is
- determined by the server and often depends on the particular
- resource, the behavior of POST when applied to collections cannot be
- meaningfully modified because it is largely undefined. Thus the
- semantics of POST are unmodified when applied to a collection.
-
-8.6 DELETE
-
- 8.6.1 DELETE for Non-Collection Resources
-
- If the DELETE method is issued to a non-collection resource whose
- URIs are an internal member of one or more collections, then during
- DELETE processing a server MUST remove any URI for the resource
- identified by the Request-URI from collections which contain it as a
- member.
-
-8.6.2 DELETE for Collections
-
- The DELETE method on a collection MUST act as if a "Depth: infinity"
- header was used on it. A client MUST NOT submit a Depth header with
- a DELETE on a collection with any value but infinity.
-
- DELETE instructs that the collection specified in the Request-URI and
- all resources identified by its internal member URIs are to be
- deleted.
-
- If any resource identified by a member URI cannot be deleted then all
- of the member's ancestors MUST NOT be deleted, so as to maintain
- namespace consistency.
-
- Any headers included with DELETE MUST be applied in processing every
- resource to be deleted.
-
- When the DELETE method has completed processing it MUST result in a
- consistent namespace.
-
- If an error occurs with a resource other than the resource identified
- in the Request-URI then the response MUST be a 207 (Multi-Status).
- 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-
- Status). They can be safely left out because the client will know
- that the ancestors of a resource could not be deleted when the client
- receives an error for the ancestor's progeny. Additionally 204 (No
- Content) errors SHOULD NOT be returned in the 207 (Multi-Status).
- The reason for this prohibition is that 204 (No Content) is the
- default success code.
-
-
-
-
-Goland, et al. Standards Track [Page 35]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.6.2.1 Example - DELETE
-
- >>Request
-
- DELETE /container/ HTTP/1.1
- Host: www.foo.bar
-
- >>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.foo.bar/container/resource3</d:href>
- <d:status>HTTP/1.1 423 Locked</d:status>
- </d:response>
- </d:multistatus>
-
- In this example the attempt to delete
- http://www.foo.bar/container/resource3 failed because it is locked,
- and no lock token was submitted with the request. Consequently, the
- attempt to delete http://www.foo.bar/container/ also failed. Thus the
- client knows that the attempt to delete http://www.foo.bar/container/
- must have also failed since the parent can not be deleted unless its
- child has also been deleted. Even though a Depth header has not been
- included, a depth of infinity is assumed because the method is on a
- collection.
-
-8.7 PUT
-
-8.7.1 PUT for Non-Collection Resources
-
- A PUT performed on an existing resource replaces the GET response
- entity of the resource. Properties defined on the resource may be
- recomputed during PUT processing but are not otherwise affected. For
- example, if a server recognizes the content type of the request body,
- it may be able to automatically extract information that could be
- profitably exposed as properties.
-
- A PUT that would result in the creation of a resource without an
- appropriately scoped parent collection MUST fail with a 409
- (Conflict).
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 36]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.7.2 PUT for Collections
-
- As defined in the HTTP/1.1 specification [RFC2068], the "PUT method
- requests that the enclosed entity be stored under the supplied
- Request-URI." Since submission of an entity representing a
- collection would implicitly encode creation and deletion of
- resources, this specification intentionally does not define a
- transmission format for creating a collection using PUT. Instead,
- the MKCOL method is defined to create collections.
-
- When the PUT operation creates a new non-collection resource all
- ancestors MUST already exist. If all ancestors do not exist, the
- method MUST fail with a 409 (Conflict) status code. For example, if
- resource /a/b/c/d.html is to be created and /a/b/c/ does not exist,
- then the request must fail.
-
-8.8 COPY Method
-
- The COPY method creates a duplicate of the source resource,
- identified by the Request-URI, in the destination resource,
- identified by the URI in the Destination header. The Destination
- header MUST be present. The exact behavior of the COPY method
- depends on the type of the source resource.
-
- All WebDAV compliant resources MUST support the COPY method.
- However, support for the COPY method does not guarantee the ability
- to copy a resource. For example, separate programs may control
- resources on the same server. As a result, it may not be possible to
- copy a resource to a location that appears to be on the same server.
-
-8.8.1 COPY for HTTP/1.1 resources
-
- When the source resource is not a collection the result of the COPY
- method is the creation of a new resource at the destination whose
- state and behavior match that of the source resource as closely as
- possible. After a successful COPY invocation, all properties on the
- source resource MUST be duplicated on the destination resource,
- subject to modifying headers and XML elements, following the
- definition for copying properties. Since the environment at the
- destination may be different than at the source due to factors
- outside the scope of control of the server, such as the absence of
- resources required for correct operation, it may not be possible to
- completely duplicate the behavior of the resource at the destination.
- Subsequent alterations to the destination resource will not modify
- the source resource. Subsequent alterations to the source resource
- will not modify the destination resource.
-
-
-
-
-
-Goland, et al. Standards Track [Page 37]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.8.2. COPY for Properties
-
- The following section defines how properties on a resource are
- handled during a COPY operation.
-
- Live properties SHOULD be duplicated as identically behaving live
- properties at the destination resource. If a property cannot be
- copied live, then its value MUST be duplicated, octet-for-octet, in
- an identically named, dead property on the destination resource
- subject to the effects of the propertybehavior XML element.
-
- The propertybehavior XML element can specify that properties are
- copied on best effort, that all live properties must be successfully
- copied or the method must fail, or that a specified list of live
- properties must be successfully copied or the method must fail. The
- propertybehavior XML element is defined in section 12.12.
-
-8.8.3 COPY for Collections
-
- The COPY method on a collection without a Depth header MUST act as if
- a Depth header with value "infinity" was included. A client may
- submit a Depth header on a COPY on a collection with a value of "0"
- or "infinity". DAV compliant servers MUST support the "0" and
- "infinity" Depth header behaviors.
-
- A COPY of depth infinity instructs that the collection resource
- identified by the Request-URI is to be copied to the location
- identified by the URI in the Destination header, and all its internal
- member resources are to be copied to a location relative to it,
- recursively through all levels of the collection hierarchy.
-
- A COPY of "Depth: 0" only instructs that the collection and its
- properties but not resources identified by its internal member URIs,
- are to be copied.
-
- Any headers included with a COPY MUST be applied in processing every
- resource to be copied with the exception of the Destination header.
-
- The Destination header only specifies the destination URI for the
- Request-URI. When applied to members of the collection identified by
- the Request-URI the value of Destination is to be modified to reflect
- the current location in the hierarchy. So, if the Request- URI is
- /a/ with Host header value http://fun.com/ and the Destination is
- http://fun.com/b/ then when http://fun.com/a/c/d is processed it must
- use a Destination of http://fun.com/b/c/d.
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 38]
-
-RFC 2518 WEBDAV February 1999
-
-
- When the COPY method has completed processing it MUST have created a
- consistent namespace at the destination (see section 5.1 for the
- definition of namespace consistency). However, if an error occurs
- while copying an internal collection, the server MUST NOT copy any
- resources identified by members of this collection (i.e., the server
- must skip this subtree), as this would create an inconsistent
- namespace. After detecting an error, the COPY operation SHOULD try to
- finish as much of the original copy operation as possible (i.e., the
- server should still attempt to copy other subtrees and their members,
- that are not descendents of an error-causing collection). So, for
- example, if an infinite depth copy operation is performed on
- collection /a/, which contains collections /a/b/ and /a/c/, and an
- error occurs copying /a/b/, an attempt should still be made to copy
- /a/c/. Similarly, after encountering an error copying a non-
- collection resource as part of an infinite depth copy, the server
- SHOULD try to finish as much of the original copy operation as
- possible.
-
- If an error in executing the COPY method occurs with a resource other
- than the resource identified in the Request-URI then the response
- MUST be a 207 (Multi-Status).
-
- The 424 (Failed Dependency) status code SHOULD NOT be returned in the
- 207 (Multi-Status) response from a COPY method. These responses can
- be safely omitted because the client will know that the progeny of a
- resource could not be copied when the client receives an error for
- the parent. Additionally 201 (Created)/204 (No Content) status codes
- SHOULD NOT be returned as values in 207 (Multi-Status) responses from
- COPY methods. They, too, can be safely omitted because they are the
- default success codes.
-
-8.8.4 COPY and the Overwrite Header
-
- 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. If the
- Overwrite header is set to "F" then the operation will fail.
-
-8.8.5 Status Codes
-
- 201 (Created) - The source resource was successfully copied. The
- copy operation resulted in the creation of a new resource.
-
- 204 (No Content) - The source resource was successfully copied to a
- pre-existing destination resource.
-
- 403 (Forbidden) _ The source and destination URIs are the same.
-
-
-
-
-Goland, et al. Standards Track [Page 39]
-
-RFC 2518 WEBDAV February 1999
-
-
- 409 (Conflict) _ A resource cannot be created at the destination
- until one or more intermediate collections have been created.
-
- 412 (Precondition Failed) - The server was unable to maintain the
- liveness of the properties listed in the propertybehavior XML element
- or the Overwrite header is "F" and the state of the destination
- resource is non-null.
-
- 423 (Locked) - The destination resource was locked.
-
- 502 (Bad Gateway) - This may occur when the destination is on another
- server and the destination server refuses to accept the resource.
-
- 507 (Insufficient Storage) - The destination resource does not have
- sufficient space to record the state of the resource after the
- execution of this method.
-
-8.8.6 Example - COPY with Overwrite
-
- This example shows resource
- http://www.ics.uci.edu/~fielding/index.html being copied to the
- location http://www.ics.uci.edu/users/f/fielding/index.html. The 204
- (No Content) status code indicates the existing resource at the
- destination was overwritten.
-
- >>Request
-
- COPY /~fielding/index.html HTTP/1.1
- Host: www.ics.uci.edu
- Destination: http://www.ics.uci.edu/users/f/fielding/index.html
-
- >>Response
-
- HTTP/1.1 204 No Content
-
-8.8.7 Example - COPY with No Overwrite
-
- The following example shows the same copy operation being performed,
- but with the Overwrite header set to "F." A response of 412
- (Precondition Failed) is returned because the destination resource
- has a non-null state.
-
- >>Request
-
- COPY /~fielding/index.html HTTP/1.1
- Host: www.ics.uci.edu
- Destination: http://www.ics.uci.edu/users/f/fielding/index.html
- Overwrite: F
-
-
-
-Goland, et al. Standards Track [Page 40]
-
-RFC 2518 WEBDAV February 1999
-
-
- >>Response
-
- HTTP/1.1 412 Precondition Failed
-
-8.8.8 Example - COPY of a Collection
-
- >>Request
-
- COPY /container/ HTTP/1.1
- Host: www.foo.bar
- Destination: http://www.foo.bar/othercontainer/
- Depth: infinity
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <d:propertybehavior xmlns:d="DAV:">
- <d:keepalive>*</d:keepalive>
- </d:propertybehavior>
-
- >>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.foo.bar/othercontainer/R2/</d:href>
- <d:status>HTTP/1.1 412 Precondition Failed</d:status>
- </d:response>
- </d:multistatus>
-
- The Depth header is unnecessary as the default behavior of COPY on a
- collection is to act as if a "Depth: infinity" header had been
- submitted. In this example most of the resources, along with the
- collection, were copied successfully. However the collection R2
- failed, most likely due to a problem with maintaining the liveness of
- properties (this is specified by the propertybehavior XML element).
- Because there was an error copying R2, none of R2's members were
- copied. However no errors were listed for those members due to the
- error minimization rules given in section 8.8.3.
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 41]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.9 MOVE Method
-
- The MOVE operation on a non-collection resource is the logical
- equivalent of a copy (COPY), followed by consistency maintenance
- processing, followed by a delete of the source, where all three
- actions are performed atomically. The consistency maintenance step
- allows the server to perform updates caused by the move, such as
- updating all URIs other than the Request-URI which identify the
- source resource, to point to the new destination resource.
- Consequently, the Destination header MUST be present on all MOVE
- methods and MUST follow all COPY requirements for the COPY part of
- the MOVE method. All DAV compliant resources MUST support the MOVE
- method. However, support for the MOVE method does not guarantee the
- ability to move a resource to a particular destination.
-
- For example, separate programs may actually control different sets of
- resources on the same server. Therefore, it may not be possible to
- move a resource within a namespace that appears to belong to the same
- server.
-
- If a resource exists at the destination, the destination resource
- will be DELETEd as a side-effect of the MOVE operation, subject to
- the restrictions of the Overwrite header.
-
-8.9.1 MOVE for Properties
-
- The behavior of properties on a MOVE, including the effects of the
- propertybehavior XML element, MUST be the same as specified in
- section 8.8.2.
-
-8.9.2 MOVE for Collections
-
- A MOVE with "Depth: infinity" instructs that the collection
- identified by the Request-URI be moved to the URI specified in the
- Destination header, and all resources identified by its internal
- member URIs are to be moved to locations relative to it, recursively
- through all levels of the collection hierarchy.
-
- The MOVE method on a collection MUST act as if a "Depth: infinity"
- header was used on it. A client MUST NOT submit a Depth header on a
- MOVE on a collection with any value but "infinity".
-
- Any headers included with MOVE MUST be applied in processing every
- resource to be moved with the exception of the Destination header.
-
- The behavior of the Destination header is the same as given for COPY
- on collections.
-
-
-
-
-Goland, et al. Standards Track [Page 42]
-
-RFC 2518 WEBDAV February 1999
-
-
- When the MOVE method has completed processing it MUST have created a
- consistent namespace at both the source and destination (see section
- 5.1 for the definition of namespace consistency). However, if an
- error occurs while moving an internal collection, the server MUST NOT
- move any resources identified by members of the failed collection
- (i.e., the server must skip the error-causing subtree), as this would
- create an inconsistent namespace. In this case, after detecting the
- error, the move operation SHOULD try to finish as much of the
- original move as possible (i.e., the server should still attempt to
- move other subtrees and the resources identified by their members,
- that are not descendents of an error-causing collection). So, for
- example, if an infinite depth move is performed on collection /a/,
- which contains collections /a/b/ and /a/c/, and an error occurs
- moving /a/b/, an attempt should still be made to try moving /a/c/.
- Similarly, after encountering an error moving a non-collection
- resource as part of an infinite depth move, the server SHOULD try to
- finish as much of the original move operation as possible.
-
- If an error occurs with a resource other than the resource identified
- in the Request-URI then the response MUST be a 207 (Multi-Status).
-
- The 424 (Failed Dependency) status code SHOULD NOT be returned in the
- 207 (Multi-Status) response from a MOVE method. These errors can be
- safely omitted because the client will know that the progeny of a
- resource could not be moved when the client receives an error for the
- parent. Additionally 201 (Created)/204 (No Content) responses SHOULD
- NOT be returned as values in 207 (Multi-Status) responses from a
- MOVE. These responses can be safely omitted because they are the
- default success codes.
-
-8.9.3 MOVE and the Overwrite Header
-
- If a resource exists at the destination and the Overwrite header is
- "T" then prior to performing the move the server MUST perform a
- DELETE with "Depth: infinity" on the destination resource. If the
- Overwrite header is set to "F" then the operation will fail.
-
-8.9.4 Status Codes
-
- 201 (Created) - The source resource was successfully moved, and a new
- resource was created at the destination.
-
- 204 (No Content) - The source resource was successfully moved to a
- pre-existing destination resource.
-
- 403 (Forbidden) _ The source and destination URIs are the same.
-
-
-
-
-
-Goland, et al. Standards Track [Page 43]
-
-RFC 2518 WEBDAV February 1999
-
-
- 409 (Conflict) _ A resource cannot be created at the destination
- until one or more intermediate collections have been created.
-
- 412 (Precondition Failed) - The server was unable to maintain the
- liveness of the properties listed in the propertybehavior XML element
- or the Overwrite header is "F" and the state of the destination
- resource is non-null.
-
- 423 (Locked) - The source or the destination resource was locked.
-
- 502 (Bad Gateway) - This may occur when the destination is on another
- server and the destination server refuses to accept the resource.
-
-8.9.5 Example - MOVE of a Non-Collection
-
- This example shows resource
- http://www.ics.uci.edu/~fielding/index.html being moved to the
- location http://www.ics.uci.edu/users/f/fielding/index.html. The
- contents of the destination resource would have been overwritten if
- the destination resource had been non-null. In this case, since
- there was nothing at the destination resource, the response code is
- 201 (Created).
-
- >>Request
-
- MOVE /~fielding/index.html HTTP/1.1
- Host: www.ics.uci.edu
- Destination: http://www.ics.uci.edu/users/f/fielding/index.html
-
- >>Response
-
- HTTP/1.1 201 Created
- Location: http://www.ics.uci.edu/users/f/fielding/index.html
-
-
-8.9.6 Example - MOVE of a Collection
-
- >>Request
-
- MOVE /container/ HTTP/1.1
- Host: www.foo.bar
- Destination: http://www.foo.bar/othercontainer/
- Overwrite: F
- If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
- (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
-
-
-
-
-Goland, et al. Standards Track [Page 44]
-
-RFC 2518 WEBDAV February 1999
-
-
- <?xml version="1.0" encoding="utf-8" ?>
- <d:propertybehavior xmlns:d='DAV:'>
- <d:keepalive>*</d:keepalive>
- </d:propertybehavior>
-
- >>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.foo.bar/othercontainer/C2/</d:href>
- <d:status>HTTP/1.1 423 Locked</d:status>
- </d:response>
- </d:multistatus>
-
- In this example the client has submitted a number of lock tokens with
- the request. A lock token will need to be submitted for every
- resource, both source and destination, anywhere in the scope of the
- method, that is locked. In this case the proper lock token was not
- submitted for the destination http://www.foo.bar/othercontainer/C2/.
- This means that the resource /container/C2/ could not be moved.
- Because there was an error copying /container/C2/, none of
- /container/C2's members were copied. However no errors were listed
- for those members due to the error minimization rules given in
- section 8.8.3. User agent authentication has previously occurred via
- a mechanism outside the scope of the HTTP protocol, in an underlying
- transport layer.
-
-8.10 LOCK Method
-
- The following sections describe the LOCK method, which is used to
- take out a lock of any access type. These sections on the LOCK
- method describe only those semantics that are specific to the LOCK
- method and are independent of the access type of the lock being
- requested.
-
- Any resource which supports the LOCK method MUST, at minimum, support
- the XML request and response formats defined herein.
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 45]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.10.1 Operation
-
- A LOCK method invocation creates the lock specified by the lockinfo
- XML element on the Request-URI. Lock method requests SHOULD have a
- XML request body which contains an owner XML element for this lock
- request, unless this is a refresh request. The LOCK request may have
- a Timeout header.
-
- Clients MUST assume that locks may arbitrarily disappear at any time,
- regardless of the value given in the Timeout header. The Timeout
- header only indicates the behavior of the server if "extraordinary"
- circumstances do not occur. For example, an administrator may remove
- a lock at any time or the system may crash in such a way that it
- loses the record of the lock's existence. The response MUST contain
- the value of the lockdiscovery property in a prop XML element.
-
- In order to indicate the lock token associated with a newly created
- lock, a Lock-Token response header MUST be included in the response
- for every successful LOCK request for a new lock. Note that the
- Lock-Token header would not be returned in the response for a
- successful refresh LOCK request because a new lock was not created.
-
-8.10.2 The Effect of Locks on Properties and Collections
-
- The scope of a lock is the entire state of the resource, including
- its body and associated properties. As a result, a lock on a
- resource MUST also lock the resource's properties.
-
- For collections, a lock also affects the ability to add or remove
- members. The nature of the effect depends upon the type of access
- control involved.
-
-8.10.3 Locking Replicated Resources
-
- A resource may be made available through more than one URI. However
- locks apply to resources, not URIs. Therefore a LOCK request on a
- resource MUST NOT succeed if can not be honored by all the URIs
- through which the resource is addressable.
-
-8.10.4 Depth and Locking
-
- The Depth header may be used with the LOCK method. Values other than
- 0 or infinity MUST NOT be used with the Depth header on a LOCK
- method. All resources that support the LOCK method MUST support the
- Depth header.
-
- A Depth header of value 0 means to just lock the resource specified
- by the Request-URI.
-
-
-
-Goland, et al. Standards Track [Page 46]
-
-RFC 2518 WEBDAV February 1999
-
-
- If the Depth header is set to infinity then the resource specified in
- the Request-URI along with all its internal members, all the way down
- the hierarchy, are to be locked. A successful result MUST return a
- single lock token which represents all the resources that have been
- locked. If an UNLOCK is successfully executed on this token, all
- associated resources are unlocked. If the lock cannot be granted to
- all resources, a 409 (Conflict) status code MUST be returned with a
- response entity body containing a multistatus XML element describing
- which resource(s) prevented the lock from being granted. Hence,
- partial success is not an option. Either the entire hierarchy is
- locked or no resources are locked.
-
- If no Depth header is submitted on a LOCK request then the request
- MUST act as if a "Depth:infinity" had been submitted.
-
-8.10.5 Interaction with other Methods
-
- The interaction of a LOCK with various methods is dependent upon the
- lock type. However, independent of lock type, a successful DELETE of
- a resource MUST cause all of its locks to be removed.
-
-8.10.6 Lock Compatibility Table
-
- The table below describes the behavior that occurs when a lock
- request is made on a resource.
-
- Current lock state/ | Shared Lock | Exclusive
- Lock request | | Lock
- =====================+=================+==============
- None | True | True
- ---------------------+-----------------+--------------
- Shared Lock | True | False
- ---------------------+-----------------+--------------
- Exclusive Lock | False | False*
- ------------------------------------------------------
-
- Legend: True = lock may be granted. False = lock MUST NOT be
- granted. *=It is illegal for a principal to request the same lock
- twice.
-
- The current lock state of a resource is given in the leftmost column,
- and lock requests are listed in the first row. The intersection of a
- row and column gives the result of a lock request. For example, if a
- shared lock is held on a resource, and an exclusive lock is
- requested, the table entry is "false", indicating the lock must not
- be granted.
-
-
-
-
-
-Goland, et al. Standards Track [Page 47]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.10.7 Status Codes
-
- 200 (OK) - The lock request succeeded and the value of the
- lockdiscovery property is included in the body.
-
- 412 (Precondition Failed) - The included lock token was not
- enforceable on this resource or the server could not satisfy the
- request in the lockinfo XML element.
-
- 423 (Locked) - The resource is locked, so the method has been
- rejected.
-
-8.10.8 Example - Simple Lock Request
-
- >>Request
-
- LOCK /workspace/webdav/proposal.doc HTTP/1.1
- Host: webdav.sb.aol.com
- Timeout: Infinite, Second-4100000000
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
- Authorization: Digest username="ejw",
- realm="ejw at webdav.sb.aol.com", nonce="...",
- uri="/workspace/webdav/proposal.doc",
- response="...", opaque="..."
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:lockinfo xmlns:D='DAV:'>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- <D:owner>
- <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
- </D:owner>
- </D:lockinfo>
-
- >>Response
-
- HTTP/1.1 200 OK
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:prop xmlns:D="DAV:">
- <D:lockdiscovery>
- <D:activelock>
- <D:locktype><D:write/></D:locktype>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:depth>Infinity</D:depth>
-
-
-
-Goland, et al. Standards Track [Page 48]
-
-RFC 2518 WEBDAV February 1999
-
-
- <D:owner>
- <D:href>
- http://www.ics.uci.edu/~ejw/contact.html
- </D:href>
- </D:owner>
- <D:timeout>Second-604800</D:timeout>
- <D:locktoken>
- <D:href>
- opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
- </D:href>
- </D:locktoken>
- </D:activelock>
- </D:lockdiscovery>
- </D:prop>
-
- This example shows the successful creation of an exclusive write lock
- on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc.
- The resource http://www.ics.uci.edu/~ejw/contact.html contains
- contact information for the owner of the lock. The server has an
- activity-based timeout policy in place on this resource, which causes
- the lock to automatically be removed after 1 week (604800 seconds).
- Note that the nonce, response, and opaque fields have not been
- calculated in the Authorization request header.
-
-8.10.9 Example - Refreshing a Write Lock
-
- >>Request
-
- LOCK /workspace/webdav/proposal.doc HTTP/1.1
- Host: webdav.sb.aol.com
- Timeout: Infinite, Second-4100000000
- If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
- Authorization: Digest username="ejw",
- realm="ejw at webdav.sb.aol.com", nonce="...",
- uri="/workspace/webdav/proposal.doc",
- response="...", opaque="..."
-
- >>Response
-
- HTTP/1.1 200 OK
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:prop xmlns:D="DAV:">
- <D:lockdiscovery>
- <D:activelock>
- <D:locktype><D:write/></D:locktype>
-
-
-
-Goland, et al. Standards Track [Page 49]
-
-RFC 2518 WEBDAV February 1999
-
-
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:depth>Infinity</D:depth>
- <D:owner>
- <D:href>
- http://www.ics.uci.edu/~ejw/contact.html
- </D:href>
- </D:owner>
- <D:timeout>Second-604800</D:timeout>
- <D:locktoken>
- <D:href>
- opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
- </D:href>
- </D:locktoken>
- </D:activelock>
- </D:lockdiscovery>
- </D:prop>
-
- This request would refresh the lock, resetting any time outs. Notice
- that the client asked for an infinite time out but the server choose
- to ignore the request. In this example, the nonce, response, and
- opaque fields have not been calculated in the Authorization request
- header.
-
-8.10.10 Example - Multi-Resource Lock Request
-
- >>Request
-
- LOCK /webdav/ HTTP/1.1
- Host: webdav.sb.aol.com
- Timeout: Infinite, Second-4100000000
- Depth: infinity
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
- Authorization: Digest username="ejw",
- realm="ejw at webdav.sb.aol.com", nonce="...",
- uri="/workspace/webdav/proposal.doc",
- response="...", opaque="..."
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:lockinfo xmlns:D="DAV:">
- <D:locktype><D:write/></D:locktype>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:owner>
- <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
- </D:owner>
- </D:lockinfo>
-
- >>Response
-
-
-
-Goland, et al. Standards Track [Page 50]
-
-RFC 2518 WEBDAV February 1999
-
-
- 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://webdav.sb.aol.com/webdav/secret</D:href>
- <D:status>HTTP/1.1 403 Forbidden</D:status>
- </D:response>
- <D:response>
- <D:href>http://webdav.sb.aol.com/webdav/</D:href>
- <D:propstat>
- <D:prop><D:lockdiscovery/></D:prop>
- <D:status>HTTP/1.1 424 Failed Dependency</D:status>
- </D:propstat>
- </D:response>
- </D:multistatus>
-
- This example shows a request for an exclusive write lock on a
- collection and all its children. In this request, the client has
- specified that it desires an infinite length lock, if available,
- otherwise a timeout of 4.1 billion seconds, if available. The request
- entity body contains the contact information for the principal taking
- out the lock, in this case a web page URL.
-
- The error is a 403 (Forbidden) response on the resource
- http://webdav.sb.aol.com/webdav/secret. Because this resource could
- not be locked, none of the resources were locked. Note also that the
- lockdiscovery property for the Request-URI has been included as
- required. In this example the lockdiscovery property is empty which
- means that there are no outstanding locks on the resource.
-
- In this example, the nonce, response, and opaque fields have not been
- calculated in the Authorization request header.
-
-8.11 UNLOCK Method
-
- The UNLOCK method removes the lock identified by the lock token in
- the Lock-Token request header from the Request-URI, and all other
- resources included in the lock. If all resources which have been
- locked under the submitted lock token can not be unlocked then the
- UNLOCK request MUST fail.
-
- Any DAV compliant resource which supports the LOCK method MUST
- support the UNLOCK method.
-
-
-
-
-
-Goland, et al. Standards Track [Page 51]
-
-RFC 2518 WEBDAV February 1999
-
-
-8.11.1 Example - UNLOCK
-
- >>Request
-
- UNLOCK /workspace/webdav/info.doc HTTP/1.1
- Host: webdav.sb.aol.com
- Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
- Authorization: Digest username="ejw",
- realm="ejw at webdav.sb.aol.com", nonce="...",
- uri="/workspace/webdav/proposal.doc",
- response="...", opaque="..."
-
- >>Response
-
- HTTP/1.1 204 No Content
-
- In this example, the lock identified by the lock token
- "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
- successfully removed from the resource
- http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock
- included more than just one resource, the lock is removed from all
- resources included in the lock. The 204 (No Content) status code is
- used instead of 200 (OK) because there is no response entity body.
-
- In this example, the nonce, response, and opaque fields have not been
- calculated in the Authorization request header.
-
-9 HTTP Headers for Distributed Authoring
-
-9.1 DAV Header
-
- DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
-
- This header indicates that the resource supports the DAV schema and
- protocol as specified. All DAV compliant resources MUST return the
- DAV header on all OPTIONS responses.
-
- The value is a list of all compliance classes that the resource
- supports. Note that above a comma has already been added to the 2.
- This is because a resource can not be level 2 compliant unless it is
- also level 1 compliant. Please refer to section 15 for more details.
- In general, however, support for one compliance class does not entail
- support for any other.
-
-9.2 Depth Header
-
- Depth = "Depth" ":" ("0" | "1" | "infinity")
-
-
-
-
-Goland, et al. Standards Track [Page 52]
-
-RFC 2518 WEBDAV February 1999
-
-
- The Depth header is used with methods executed on resources which
- could potentially have internal members to indicate whether the
- method is to be applied only to the resource ("Depth: 0"), to the
- resource and its immediate children, ("Depth: 1"), or the resource
- and all its progeny ("Depth: infinity").
-
- The Depth header is only supported if a method's definition
- explicitly provides for such support.
-
- The following rules are the default behavior for any method that
- supports the Depth header. A method may override these defaults by
- defining different behavior in its definition.
-
- Methods which support the Depth header may choose not to support all
- of the header's values and may define, on a case by case basis, the
- behavior of the method if a Depth header is not present. For example,
- the MOVE method only supports "Depth: infinity" and if a Depth header
- is not present will act as if a "Depth: infinity" header had been
- applied.
-
- Clients MUST NOT rely upon methods executing on members of their
- hierarchies in any particular order or on the execution being atomic
- unless the particular method explicitly provides such guarantees.
-
- Upon execution, a method with a Depth header will perform as much of
- its assigned task as possible and then return a response specifying
- what it was able to accomplish and what it failed to do.
-
- So, for example, an attempt to COPY a hierarchy may result in some of
- the members being copied and some not.
-
- Any headers on a method that has a defined interaction with the Depth
- header MUST be applied to all resources in the scope of the method
- except where alternative behavior is explicitly defined. For example,
- an If-Match header will have its value applied against every resource
- in the method's scope and will cause the method to fail if the header
- fails to match.
-
- If a resource, source or destination, within the scope of the method
- with a Depth header is locked in such a way as to prevent the
- successful execution of the method, then the lock token for that
- resource MUST be submitted with the request in the If request header.
-
- The Depth header only specifies the behavior of the method with
- regards to internal children. If a resource does not have internal
- children then the Depth header MUST be ignored.
-
-
-
-
-
-Goland, et al. Standards Track [Page 53]
-
-RFC 2518 WEBDAV February 1999
-
-
- Please note, however, that it is always an error to submit a value
- for the Depth header that is not allowed by the method's definition.
- Thus submitting a "Depth: 1" on a COPY, even if the resource does not
- have internal members, will result in a 400 (Bad Request). The method
- should fail not because the resource doesn't have internal members,
- but because of the illegal value in the header.
-
-9.3 Destination Header
-
- Destination = "Destination" ":" absoluteURI
-
- The Destination header specifies the URI which identifies a
- destination resource for methods such as COPY and MOVE, which take
- two URIs as parameters. Note that the absoluteURI production is
- defined in [RFC2396].
-
-9.4 If Header
-
- If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
- No-tag-list = List
- Tagged-list = Resource 1*List
- Resource = Coded-URL
- List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
- State-token = Coded-URL
- Coded-URL = "<" absoluteURI ">"
-
- The If header is intended to have similar functionality to the If-
- Match header defined in section 14.25 of [RFC2068]. However the If
- header is intended for use with any URI which represents state
- information, referred to as a state token, about a resource as well
- as ETags. A typical example of a state token is a lock token, and
- lock tokens are the only state tokens defined in this specification.
-
- All DAV compliant resources MUST honor the If header.
-
- The If header's purpose is to describe a series of state lists. If
- the state of the resource to which the header is applied does not
- match any of the specified state lists then the request MUST fail
- with a 412 (Precondition Failed). If one of the described state
- lists matches the state of the resource then the request may succeed.
-
- Note that the absoluteURI production is defined in [RFC2396].
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 54]
-
-RFC 2518 WEBDAV February 1999
-
-
-9.4.1 No-tag-list Production
-
- The No-tag-list production describes a series of state tokens and
- ETags. If multiple No-tag-list productions are used then one only
- needs to match the state of the resource for the method to be allowed
- to continue.
-
- If a method, due to the presence of a Depth or Destination header, is
- applied to multiple resources then the No-tag-list production MUST be
- applied to each resource the method is applied to.
-
-9.4.1.1 Example - No-tag-list If Header
-
- If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another
- ETag"])
-
- The previous header would require that any resources within the scope
- of the method must either be locked with the specified lock token and
- in the state identified by the "I am an ETag" ETag or in the state
- identified by the second ETag "I am another ETag". To put the matter
- more plainly one can think of the previous If header as being in the
- form (or (and <locktoken:a-write-lock-token> ["I am an ETag"]) (and
- ["I am another ETag"])).
-
-9.4.2 Tagged-list Production
-
- The tagged-list production scopes a list production. That is, it
- specifies that the lists following the resource specification only
- apply to the specified resource. The scope of the resource
- production begins with the list production immediately following the
- resource production and ends with the next resource production, if
- any.
-
- When the If header is applied to a particular resource, the Tagged-
- list productions MUST be searched to determine if any of the listed
- resources match the operand resource(s) for the current method. If
- none of the resource productions match the current resource then the
- header MUST be ignored. If one of the resource productions does
- match the name of the resource under consideration then the list
- productions following the resource production MUST be applied to the
- resource in the manner specified in the previous section.
-
- The same URI MUST NOT appear more than once in a resource production
- in an If header.
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 55]
-
-RFC 2518 WEBDAV February 1999
-
-
-9.4.2.1 Example - Tagged List If header
-
- COPY /resource1 HTTP/1.1
- Host: www.foo.bar
- Destination: http://www.foo.bar/resource2
- If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>
- [W/"A weak ETag"]) (["strong ETag"])
- <http://www.bar.bar/random>(["another strong ETag"])
-
- In this example http://www.foo.bar/resource1 is being copied to
- http://www.foo.bar/resource2. When the method is first applied to
- http://www.foo.bar/resource1, resource1 must be in the state
- specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"])
- (["strong ETag"])", that is, it either must be locked with a lock
- token of "locktoken:a-write-lock-token" and have a weak entity tag
- W/"A weak ETag" or it must have a strong entity tag "strong ETag".
-
- That is the only success condition since the resource
- http://www.bar.bar/random never has the method applied to it (the
- only other resource listed in the If header) and
- http://www.foo.bar/resource2 is not listed in the If header.
-
-9.4.3 not Production
-
- Every state token or ETag is either current, and hence describes the
- state of a resource, or is not current, and does not describe the
- state of a resource. The boolean operation of matching a state token
- or ETag to the current state of a resource thus resolves to a true or
- false value. The not production is used to reverse that value. The
- scope of the not production is the state-token or entity-tag
- immediately following it.
-
- If: (Not <locktoken:write1> <locktoken:write2>)
-
- When submitted with a request, this If header requires that all
- operand resources must not be locked with locktoken:write1 and must
- be locked with locktoken:write2.
-
-9.4.4 Matching Function
-
- When performing If header processing, the definition of a matching
- state token or entity tag is as follows.
-
- Matching entity tag: Where the entity tag matches an entity tag
- associated with that resource.
-
- Matching state token: Where there is an exact match between the state
- token in the If header and any state token on the resource.
-
-
-
-Goland, et al. Standards Track [Page 56]
-
-RFC 2518 WEBDAV February 1999
-
-
-9.4.5 If Header and Non-DAV Compliant Proxies
-
- Non-DAV compliant proxies will not honor the If header, since they
- will not understand the If header, and HTTP requires non-understood
- headers to be ignored. When communicating with HTTP/1.1 proxies, the
- "Cache-Control: no-cache" request header MUST be used so as to
- prevent the proxy from improperly trying to service the request from
- its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache"
- request header MUST be used for the same reason.
-
-9.5 Lock-Token Header
-
- Lock-Token = "Lock-Token" ":" Coded-URL
-
- The Lock-Token request header is used with the UNLOCK method to
- identify the lock to be removed. The lock token in the Lock-Token
- request header MUST identify a lock that contains the resource
- identified by Request-URI as a member.
-
- The Lock-Token response header is used with the LOCK method to
- indicate the lock token created as a result of a successful LOCK
- request to create a new lock.
-
-9.6 Overwrite Header
-
- Overwrite = "Overwrite" ":" ("T" | "F")
-
- The Overwrite header specifies whether the server should overwrite
- the state of a non-null destination resource during a COPY or MOVE.
- A value of "F" states that the server must not perform the COPY or
- MOVE operation if the state of the destination resource is non-null.
- If the overwrite header is not included in a COPY or MOVE request
- then the resource MUST treat the request as if it has an overwrite
- header of value "T". While the Overwrite header appears to duplicate
- the functionality of the If-Match: * header of HTTP/1.1, If-Match
- applies only to the Request-URI, and not to the Destination of a COPY
- or MOVE.
-
- If a COPY or MOVE is not performed due to the value of the Overwrite
- header, the method MUST fail with a 412 (Precondition Failed) status
- code.
-
- All DAV compliant resources MUST support the Overwrite header.
-
-9.7 Status-URI Response Header
-
- The Status-URI response header may be used with the 102 (Processing)
- status code to inform the client as to the status of a method.
-
-
-
-Goland, et al. Standards Track [Page 57]
-
-RFC 2518 WEBDAV February 1999
-
-
- Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
- is defined in 6.1.1 of [RFC2068]
-
- The URIs listed in the header are source resources which have been
- affected by the outstanding method. The status code indicates the
- resolution of the method on the identified resource. So, for
- example, if a MOVE method on a collection is outstanding and a 102
- (Processing) response with a Status-URI response header is returned,
- the included URIs will indicate resources that have had move
- attempted on them and what the result was.
-
-9.8 Timeout Request Header
-
- TimeOut = "Timeout" ":" 1#TimeType
- TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
- DAVTimeOutVal = 1*digit
- Other = "Extend" field-value ; See section 4.2 of [RFC2068]
-
- Clients may include Timeout headers in their LOCK requests. However,
- the server is not required to honor or even consider these requests.
- Clients MUST NOT submit a Timeout request header with any method
- other than a LOCK method.
-
- A Timeout request header MUST contain at least one TimeType and may
- contain multiple TimeType entries. The purpose of listing multiple
- TimeType entries is to indicate multiple different values and value
- types that are acceptable to the client. The client lists the
- TimeType entries in order of preference.
-
- Timeout response values MUST use a Second value, Infinite, or a
- TimeType the client has indicated familiarity with. The server may
- assume a client is familiar with any TimeType submitted in a Timeout
- header.
-
- The "Second" TimeType specifies the number of seconds that will
- elapse between granting of the lock at the server, and the automatic
- removal of the lock. The timeout value for TimeType "Second" MUST
- NOT be greater than 2^32-1.
-
- The timeout counter SHOULD be restarted any time an owner of the lock
- sends a method to any member of the lock, including unsupported
- methods, or methods which are unsuccessful. However the lock MUST be
- refreshed if a refresh LOCK method is successfully received.
-
- If the timeout expires then the lock may be lost. Specifically, if
- the server wishes to harvest the lock upon time-out, the server
- SHOULD act as if an UNLOCK method was executed by the server on the
- resource using the lock token of the timed-out lock, performed with
-
-
-
-Goland, et al. Standards Track [Page 58]
-
-RFC 2518 WEBDAV February 1999
-
-
- its override authority. Thus logs should be updated with the
- disposition of the lock, notifications should be sent, etc., just as
- they would be for an UNLOCK request.
-
- Servers are advised to pay close attention to the values submitted by
- clients, as they will be indicative of the type of activity the
- client intends to perform. For example, an applet running in a
- browser may need to lock a resource, but because of the instability
- of the environment within which the applet is running, the applet may
- be turned off without warning. As a result, the applet is likely to
- ask for a relatively small timeout value so that if the applet dies,
- the lock can be quickly harvested. However, a document management
- system is likely to ask for an extremely long timeout because its
- user may be planning on going off-line.
-
- A client MUST NOT assume that just because the time-out has expired
- the lock has been lost.
-
-10 Status Code Extensions to HTTP/1.1
-
- The following status codes are added to those defined in HTTP/1.1
- [RFC2068].
-
-10.1 102 Processing
-
- The 102 (Processing) status code is an interim response used to
- inform the client that the server has accepted the complete request,
- but has not yet completed it. This status code SHOULD only be sent
- when the server has a reasonable expectation that the request will
- take significant time to complete. As guidance, if a method is taking
- longer than 20 seconds (a reasonable, but arbitrary value) to process
- the server SHOULD return a 102 (Processing) response. The server MUST
- send a final response after the request has been completed.
-
- Methods can potentially take a long period of time to process,
- especially methods that support the Depth header. In such cases the
- client may time-out the connection while waiting for a response. To
- prevent this the server may return a 102 (Processing) status code to
- indicate to the client that the server is still processing the
- method.
-
-10.2 207 Multi-Status
-
- The 207 (Multi-Status) status code provides status for multiple
- independent operations (see section 11 for more information).
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 59]
-
-RFC 2518 WEBDAV February 1999
-
-
-10.3 422 Unprocessable Entity
-
- The 422 (Unprocessable Entity) status code means the server
- understands the content type of the request entity (hence a
- 415(Unsupported Media Type) status code is inappropriate), and the
- syntax of the request entity is correct (thus a 400 (Bad Request)
- status code is inappropriate) but was unable to process the contained
- instructions. For example, this error condition may occur if an XML
- request body contains well-formed (i.e., syntactically correct), but
- semantically erroneous XML instructions.
-
-10.4 423 Locked
-
- The 423 (Locked) status code means the source or destination resource
- of a method is locked.
-
-10.5 424 Failed Dependency
-
- The 424 (Failed Dependency) status code means that the method could
- not be performed on the resource because the requested action
- depended on another action and that action failed. For example, if a
- command in a PROPPATCH method fails then, at minimum, the rest of the
- commands will also fail with 424 (Failed Dependency).
-
-10.6 507 Insufficient Storage
-
- The 507 (Insufficient Storage) status code means the method could not
- be performed on the resource because the server is unable to store
- the representation needed to successfully complete the request. This
- condition is considered to be temporary. If the request which
- received this status code was the result of a user action, the
- request MUST NOT be repeated until it is requested by a separate user
- action.
-
-11 Multi-Status Response
-
- The default 207 (Multi-Status) response body is a text/xml or
- application/xml HTTP entity that contains a single XML element called
- multistatus, which contains a set of XML elements called response
- which contain 200, 300, 400, and 500 series status codes generated
- during the method invocation. 100 series status codes SHOULD NOT be
- recorded in a response XML element.
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 60]
-
-RFC 2518 WEBDAV February 1999
-
-
-12 XML Element Definitions
-
- In the section below, the final line of each section gives the
- element type declaration using the format defined in [REC-XML]. The
- "Value" field, where present, specifies further restrictions on the
- allowable contents of the XML element using BNF (i.e., to further
- restrict the values of a PCDATA element).
-
-12.1 activelock XML Element
-
- Name: activelock
- Namespace: DAV:
- Purpose: Describes a lock on a resource.
-
- <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
- locktoken?) >
-
-12.1.1 depth XML Element
-
- Name: depth
- Namespace: DAV:
- Purpose: The value of the Depth header.
- Value: "0" | "1" | "infinity"
-
- <!ELEMENT depth (#PCDATA) >
-
-12.1.2 locktoken XML Element
-
- Name: locktoken
- Namespace: DAV:
- Purpose: The lock token associated with a lock.
- Description: The href contains one or more opaque lock token URIs
- which all refer to the same lock (i.e., the OpaqueLockToken-URI
- production in section 6.4).
-
- <!ELEMENT locktoken (href+) >
-
-12.1.3 timeout XML Element
-
- Name: timeout
- Namespace: DAV:
- Purpose: The timeout associated with a lock
- Value: TimeType ;Defined in section 9.8
-
- <!ELEMENT timeout (#PCDATA) >
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 61]
-
-RFC 2518 WEBDAV February 1999
-
-
-12.2 collection XML Element
-
- Name: collection
- Namespace: DAV:
- Purpose: Identifies the associated resource as a collection. The
- resourcetype property of a collection resource MUST have this value.
-
- <!ELEMENT collection EMPTY >
-
-12.3 href XML Element
-
- Name: href
- Namespace: DAV:
- Purpose: Identifies the content of the element as a URI.
- Value: URI ; See section 3.2.1 of [RFC2068]
-
- <!ELEMENT href (#PCDATA)>
-
-12.4 link XML Element
-
- Name: link
- Namespace: DAV:
- Purpose: Identifies the property as a link and contains the source
- and destination of that link.
- Description: The link XML element is used to provide the sources and
- destinations of a link. The name of the property containing the link
- XML element provides the type of the link. Link is a multi-valued
- element, so multiple links may be used together to indicate multiple
- links with the same type. The values in the href XML elements inside
- the src and dst XML elements of the link XML element MUST NOT be
- rejected if they point to resources which do not exist.
-
- <!ELEMENT link (src+, dst+) >
-
-12.4.1 dst XML Element
-
- Name: dst
- Namespace: DAV:
- Purpose: Indicates the destination of a link
- Value: URI
-
- <!ELEMENT dst (#PCDATA) >
-
-12.4.2 src XML Element
-
- Name: src
- Namespace: DAV:
- Purpose: Indicates the source of a link.
-
-
-
-Goland, et al. Standards Track [Page 62]
-
-RFC 2518 WEBDAV February 1999
-
-
- Value: URI
-
- <!ELEMENT src (#PCDATA) >
-
-12.5 lockentry XML Element
-
- Name: lockentry
- Namespace: DAV:
- Purpose: Defines the types of locks that can be used with the
- resource.
-
- <!ELEMENT lockentry (lockscope, locktype) >
-
-12.6 lockinfo XML Element
-
- Name: lockinfo
- Namespace: DAV:
- Purpose: The lockinfo XML element is used with a LOCK method to
- specify the type of lock the client wishes to have created.
-
- <!ELEMENT lockinfo (lockscope, locktype, owner?) >
-
-12.7 lockscope XML Element
-
- Name: lockscope
- Namespace: DAV:
- Purpose: Specifies whether a lock is an exclusive lock, or a
- shared lock.
-
- <!ELEMENT lockscope (exclusive | shared) >
-
-12.7.1 exclusive XML Element
-
- Name: exclusive
- Namespace: DAV:
- Purpose: Specifies an exclusive lock
-
- <!ELEMENT exclusive EMPTY >
-
-12.7.2 shared XML Element
-
- Name: shared
- Namespace: DAV:
- Purpose: Specifies a shared lock
-
- <!ELEMENT shared EMPTY >
-
-
-
-
-
-Goland, et al. Standards Track [Page 63]
-
-RFC 2518 WEBDAV February 1999
-
-
-12.8 locktype XML Element
-
- Name: locktype
- Namespace: DAV:
- Purpose: Specifies the access type of a lock. At present, this
- specification only defines one lock type, the write lock.
-
- <!ELEMENT locktype (write) >
-
-12.8.1 write XML Element
-
- Name: write
- Namespace: DAV:
- Purpose: Specifies a write lock.
-
- <!ELEMENT write EMPTY >
-
-12.9 multistatus XML Element
-
- Name: multistatus
- Namespace: DAV:
- Purpose: Contains multiple response messages.
- Description: The responsedescription at the top level is used to
- provide a general message describing the overarching nature of the
- response. If this value is available an application may use it
- instead of presenting the individual response descriptions contained
- within the responses.
-
- <!ELEMENT multistatus (response+, responsedescription?) >
-
-12.9.1 response XML Element
-
- Name: response
- Namespace: DAV:
- Purpose: Holds a single response describing the effect of a
- method on resource and/or its properties.
- Description: A particular href MUST NOT appear more than once as the
- child of a response XML element under a multistatus XML element.
- This requirement is necessary in order to keep processing costs for a
- response to linear time. Essentially, this prevents having to search
- in order to group together all the responses by href. There are,
- however, no requirements regarding ordering based on href values.
-
- <!ELEMENT response (href, ((href*, status)|(propstat+)),
- responsedescription?) >
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 64]
-
-RFC 2518 WEBDAV February 1999
-
-
-12.9.1.1 propstat XML Element
-
- Name: propstat
- Namespace: DAV:
- Purpose: Groups together a prop and status element that is
- associated with a particular href element.
- Description: The propstat XML element MUST contain one prop XML
- element and one status XML element. The contents of the prop XML
- element MUST only list the names of properties to which the result in
- the status element applies.
-
- <!ELEMENT propstat (prop, status, responsedescription?) >
-
-12.9.1.2 status XML Element
-
- Name: status
- Namespace: DAV:
- Purpose: Holds a single HTTP status-line
- Value: status-line ;status-line defined in [RFC2068]
-
- <!ELEMENT status (#PCDATA) >
-
-12.9.2 responsedescription XML Element
-
- Name: responsedescription
- Namespace: DAV:
- Purpose: Contains a message that can be displayed to the user
- explaining the nature of the response.
- Description: This XML element provides information suitable to be
- presented to a user.
-
- <!ELEMENT responsedescription (#PCDATA) >
-
-12.10 owner XML Element
-
- Name: owner
- Namespace: DAV:
- Purpose: Provides information about the principal taking out a
- lock.
- Description: The owner XML element provides information sufficient
- for either directly contacting a principal (such as a telephone
- number or Email URI), or for discovering the principal (such as the
- URL of a homepage) who owns a lock.
-
- <!ELEMENT owner ANY>
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 65]
-
-RFC 2518 WEBDAV February 1999
-
-
-12.11 prop XML element
-
- Name: prop
- Namespace: DAV:
- Purpose: Contains properties related to a resource.
- Description: The prop XML element is a generic container for
- properties defined on resources. All elements inside a prop XML
- element MUST define properties related to the resource. No other
- elements may be used inside of a prop element.
-
- <!ELEMENT prop ANY>
-
-12.12 propertybehavior XML element
-
- Name: propertybehavior Namespace: DAV: Purpose: Specifies
- how properties are handled during a COPY or MOVE.
- Description: The propertybehavior XML element specifies how
- properties are handled during a COPY or MOVE. If this XML element is
- not included in the request body then the server is expected to act
- as defined by the default property handling behavior of the
- associated method. All WebDAV compliant resources MUST support the
- propertybehavior XML element.
-
- <!ELEMENT propertybehavior (omit | keepalive) >
-
-12.12.1 keepalive XML element
-
- Name: keepalive
- Namespace: DAV:
- Purpose: Specifies requirements for the copying/moving of live
- properties.
- Description: If a list of URIs is included as the value of keepalive
- then the named properties MUST be "live" after they are copied
- (moved) to the destination resource of a COPY (or MOVE). If the
- value "*" is given for the keepalive XML element, this designates
- that all live properties on the source resource MUST be live on the
- destination. If the requirements specified by the keepalive element
- can not be honored then the method MUST fail with a 412 (Precondition
- Failed). All DAV compliant resources MUST support the keepalive XML
- element for use with the COPY and MOVE methods.
- Value: "*" ; #PCDATA value can only be "*"
-
- <!ELEMENT keepalive (#PCDATA | href+) >
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 66]
-
-RFC 2518 WEBDAV February 1999
-
-
-12.12.2 omit XML element
-
- Name: omit
- Namespace: DAV:
- Purpose: The omit XML element instructs the server that it should
- use best effort to copy properties but a failure to copy a property
- MUST NOT cause the method to fail. Description: The default behavior
- for a COPY or MOVE is to copy/move all properties or fail the method.
- In certain circumstances, such as when a server copies a resource
- over another protocol such as FTP, it may not be possible to
- copy/move the properties associated with the resource. Thus any
- attempt to copy/move over FTP would always have to fail because
- properties could not be moved over, even as dead properties. All DAV
- compliant resources MUST support the omit XML element on COPY/MOVE
- methods.
-
- <!ELEMENT omit EMPTY >
-
-12.13 propertyupdate XML element
-
- Name: propertyupdate
- Namespace: DAV:
- Purpose: Contains a request to alter the properties on a
- resource.
- Description: This XML element is a container for the information
- required to modify the properties on the resource. This XML element
- is multi-valued.
-
- <!ELEMENT propertyupdate (remove | set)+ >
-
-12.13.1 remove XML element
-
- Name: remove
- Namespace: DAV:
- Purpose: Lists the DAV properties to be removed from a resource.
- Description: Remove instructs that the properties specified in prop
- should be removed. Specifying the removal of a property that does
- not exist is not an error. All the XML elements in a prop XML
- element inside of a remove XML element MUST be empty, as only the
- names of properties to be removed are required.
-
- <!ELEMENT remove (prop) >
-
-12.13.2 set XML element
-
- Name: set
- Namespace: DAV:
- Purpose: Lists the DAV property values to be set for a resource.
-
-
-
-Goland, et al. Standards Track [Page 67]
-
-RFC 2518 WEBDAV February 1999
-
-
- Description: The set XML element MUST contain only a prop XML
- element. The elements contained by the prop XML element inside the
- set XML element MUST specify the name and value of properties that
- are set on the resource identified by Request-URI. If a property
- already exists then its value is replaced. Language tagging
- information in the property's value (in the "xml:lang" attribute, if
- present) MUST be persistently stored along with the property, and
- MUST be subsequently retrievable using PROPFIND.
-
- <!ELEMENT set (prop) >
-
-12.14 propfind XML Element
-
- Name: propfind
- Namespace: DAV:
- Purpose: Specifies the properties to be returned from a PROPFIND
- method. Two special elements are specified for use with propfind,
- allprop and propname. If prop is used inside propfind it MUST only
- contain property names, not values.
-
- <!ELEMENT propfind (allprop | propname | prop) >
-
-12.14.1 allprop XML Element
-
- Name: allprop Namespace: DAV: Purpose: The allprop XML
- element specifies that all property names and values on the resource
- are to be returned.
-
- <!ELEMENT allprop EMPTY >
-
-12.14.2 propname XML Element
-
- Name: propname Namespace: DAV: Purpose: The propname XML
- element specifies that only a list of property names on the resource
- is to be returned.
-
- <!ELEMENT propname EMPTY >
-
-13 DAV Properties
-
- For DAV properties, the name of the property is also the same as the
- name of the XML element that contains its value. In the section
- below, the final line of each section gives the element type
- declaration using the format defined in [REC-XML]. The "Value" field,
- where present, specifies further restrictions on the allowable
- contents of the XML element using BNF (i.e., to further restrict the
- values of a PCDATA element).
-
-
-
-
-Goland, et al. Standards Track [Page 68]
-
-RFC 2518 WEBDAV February 1999
-
-
-13.1 creationdate Property
-
- Name: creationdate
- Namespace: DAV:
- Purpose: Records the time and date the resource was created.
- Value: date-time ; See Appendix 2
- Description: The creationdate property should be defined on all DAV
- compliant resources. If present, it contains a timestamp of the
- moment when the resource was created (i.e., the moment it had non-
- null state).
-
- <!ELEMENT creationdate (#PCDATA) >
-
-13.2 displayname Property
-
- Name: displayname
- Namespace: DAV:
- Purpose: Provides a name for the resource that is suitable for
- presentation to a user.
- Description: The displayname property should be defined on all DAV
- compliant resources. If present, the property contains a description
- of the resource that is suitable for presentation to a user.
-
- <!ELEMENT displayname (#PCDATA) >
-
-13.3 getcontentlanguage Property
-
- Name: getcontentlanguage
- Namespace: DAV:
- Purpose: Contains the Content-Language header returned by a GET
- without accept headers
- Description: The getcontentlanguage property MUST be defined on any
- DAV compliant resource that returns the Content-Language header on a
- GET.
- Value: language-tag ;language-tag is defined in section 14.13
- of [RFC2068]
-
- <!ELEMENT getcontentlanguage (#PCDATA) >
-
-13.4 getcontentlength Property
-
- Name: getcontentlength
- Namespace: DAV:
- Purpose: Contains the Content-Length header returned by a GET
- without accept headers.
- Description: The getcontentlength property MUST be defined on any
- DAV compliant resource that returns the Content-Length header in
- response to a GET.
-
-
-
-Goland, et al. Standards Track [Page 69]
-
-RFC 2518 WEBDAV February 1999
-
-
- Value: content-length ; see section 14.14 of [RFC2068]
-
- <!ELEMENT getcontentlength (#PCDATA) >
-
-13.5 getcontenttype Property
-
- Name: getcontenttype
- Namespace: DAV:
- Purpose: Contains the Content-Type header returned by a GET
- without accept headers.
- Description: This getcontenttype property MUST be defined on any DAV
- compliant resource that returns the Content-Type header in response
- to a GET.
- Value: media-type ; defined in section 3.7 of [RFC2068]
-
- <!ELEMENT getcontenttype (#PCDATA) >
-
-13.6 getetag Property
-
- Name: getetag
- Namespace: DAV:
- Purpose: Contains the ETag header returned by a GET without
- accept headers.
- Description: The getetag property MUST be defined on any DAV
- compliant resource that returns the Etag header.
- Value: entity-tag ; defined in section 3.11 of [RFC2068]
-
- <!ELEMENT getetag (#PCDATA) >
-
-13.7 getlastmodified Property
-
- Name: getlastmodified
- Namespace: DAV:
- Purpose: Contains the Last-Modified header returned by a GET
- method without accept headers.
- Description: Note that the last-modified date on a resource may
- reflect changes in any part of the state of the resource, not
- necessarily just a change to the response to the GET method. For
- example, a change in a property may cause the last-modified date to
- change. The getlastmodified property MUST be defined on any DAV
- compliant resource that returns the Last-Modified header in response
- to a GET.
- Value: HTTP-date ; defined in section 3.3.1 of [RFC2068]
-
- <!ELEMENT getlastmodified (#PCDATA) >
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 70]
-
-RFC 2518 WEBDAV February 1999
-
-
-13.8 lockdiscovery Property
-
- Name: lockdiscovery
- Namespace: DAV:
- Purpose: Describes the active locks on a resource
- Description: The lockdiscovery property returns a listing of who has
- a lock, what type of lock he has, the timeout type and the time
- remaining on the timeout, and the associated lock token. The server
- is free to withhold any or all of this information if the requesting
- principal does not have sufficient access rights to see the requested
- data.
-
- <!ELEMENT lockdiscovery (activelock)* >
-
-13.8.1 Example - Retrieving the lockdiscovery Property
-
- >>Request
-
- PROPFIND /container/ HTTP/1.1
- Host: www.foo.bar
- Content-Length: xxxx
- Content-Type: text/xml; charset="utf-8"
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D='DAV:'>
- <D:prop><D:lockdiscovery/></D:prop>
- </D:propfind>
-
- >>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.foo.bar/container/</D:href>
- <D:propstat>
- <D:prop>
- <D:lockdiscovery>
- <D:activelock>
- <D:locktype><D:write/></D:locktype>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:depth>0</D:depth>
- <D:owner>Jane Smith</D:owner>
- <D:timeout>Infinite</D:timeout>
- <D:locktoken>
-
-
-
-Goland, et al. Standards Track [Page 71]
-
-RFC 2518 WEBDAV February 1999
-
-
- <D:href>
- opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
- </D:href>
- </D:locktoken>
- </D:activelock>
- </D:lockdiscovery>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
- </D:multistatus>
-
- This resource has a single exclusive write lock on it, with an
- infinite timeout.
-
-13.9 resourcetype Property
-
- Name: resourcetype
- Namespace: DAV:
- Purpose: Specifies the nature of the resource.
- Description: The resourcetype property MUST be defined on all DAV
- compliant resources. The default value is empty.
-
- <!ELEMENT resourcetype ANY >
-
-13.10 source Property
-
- Name: source
- Namespace: DAV:
- Purpose: The destination of the source link identifies the
- resource that contains the unprocessed source of the link's source.
- Description: The source of the link (src) is typically the URI of the
- output resource on which the link is defined, and there is typically
- only one destination (dst) of the link, which is the URI where the
- unprocessed source of the resource may be accessed. When more than
- one link destination exists, this specification asserts no policy on
- ordering.
-
- <!ELEMENT source (link)* >
-
-13.10.1 Example - A source Property
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
- <D:source>
- <D:link>
- <F:projfiles>Source</F:projfiles>
- <D:src>http://foo.bar/program</D:src>
-
-
-
-Goland, et al. Standards Track [Page 72]
-
-RFC 2518 WEBDAV February 1999
-
-
- <D:dst>http://foo.bar/src/main.c</D:dst>
- </D:link>
- <D:link>
- <F:projfiles>Library</F:projfiles>
- <D:src>http://foo.bar/program</D:src>
- <D:dst>http://foo.bar/src/main.lib</D:dst>
- </D:link>
- <D:link>
- <F:projfiles>Makefile</F:projfiles>
- <D:src>http://foo.bar/program</D:src>
- <D:dst>http://foo.bar/src/makefile</D:dst>
- </D:link>
- </D:source>
- </D:prop>
-
- In this example the resource http://foo.bar/program has a source
- property that contains three links. Each link contains three
- elements, two of which, src and dst, are part of the DAV schema
- defined in this document, and one which is defined by the schema
- http://www.foocorp.com/project/ (Source, Library, and Makefile). A
- client which only implements the elements in the DAV spec will not
- understand the foocorp elements and will ignore them, thus seeing the
- expected source and destination links. An enhanced client may know
- about the foocorp elements and be able to present the user with
- additional information about the links. This example demonstrates
- the power of XML markup, allowing element values to be enhanced
- without breaking older clients.
-
-13.11 supportedlock Property
-
- Name: supportedlock
- Namespace: DAV:
- Purpose: To provide a listing of the lock capabilities supported
- by the resource.
- Description: The supportedlock property of a resource returns a
- listing of the combinations of scope and access types which may be
- specified in a lock request on the resource. Note that the actual
- contents are themselves controlled by access controls so a server is
- not required to provide information the client is not authorized to
- see.
-
- <!ELEMENT supportedlock (lockentry)* >
-
-13.11.1 Example - Retrieving the supportedlock Property
-
- >>Request
-
- PROPFIND /container/ HTTP/1.1
-
-
-
-Goland, et al. Standards Track [Page 73]
-
-RFC 2518 WEBDAV February 1999
-
-
- Host: www.foo.bar
- Content-Length: xxxx
- Content-Type: text/xml; charset="utf-8"
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:">
- <D:prop><D:supportedlock/></D:prop>
- </D:propfind>
-
- >>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.foo.bar/container/</D:href>
- <D:propstat>
- <D:prop>
- <D:supportedlock>
- <D:lockentry>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- <D:lockentry>
- <D:lockscope><D:shared/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- </D:supportedlock>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
- </D:multistatus>
-
-14 Instructions for Processing XML in DAV
-
- All DAV compliant resources MUST ignore any unknown XML element and
- all its children encountered while processing a DAV method that uses
- XML as its command language.
-
- This restriction also applies to the processing, by clients, of DAV
- property values where unknown XML elements SHOULD be ignored unless
- the property's schema declares otherwise.
-
-
-
-
-
-Goland, et al. Standards Track [Page 74]
-
-RFC 2518 WEBDAV February 1999
-
-
- This restriction does not apply to setting dead DAV properties on the
- server where the server MUST record unknown XML elements.
-
- Additionally, this restriction does not apply to the use of XML where
- XML happens to be the content type of the entity body, for example,
- when used as the body of a PUT.
-
- Since XML can be transported as text/xml or application/xml, a DAV
- server MUST accept DAV method requests with XML parameters
- transported as either text/xml or application/xml, and DAV client
- MUST accept XML responses using either text/xml or application/xml.
-
-15 DAV Compliance Classes
-
- A DAV compliant resource can choose from two classes of compliance.
- A client can discover the compliance classes of a resource by
- executing OPTIONS on the resource, and examining the "DAV" header
- which is returned.
-
- Since this document describes extensions to the HTTP/1.1 protocol,
- minimally all DAV compliant resources, clients, and proxies MUST be
- compliant with [RFC2068].
-
- Compliance classes are not necessarily sequential. A resource that is
- class 2 compliant must also be class 1 compliant; but if additional
- compliance classes are defined later, a resource that is class 1, 2,
- and 4 compliant might not be class 3 compliant. Also note that
- identifiers other than numbers may be used as compliance class
- identifiers.
-
-15.1 Class 1
-
- A class 1 compliant resource MUST meet all "MUST" requirements in all
- sections of this document.
-
- Class 1 compliant resources MUST return, at minimum, the value "1" in
- the DAV header on all responses to the OPTIONS method.
-
-15.2 Class 2
-
- A class 2 compliant resource MUST meet all class 1 requirements and
- support the LOCK method, the supportedlock property, the
- lockdiscovery property, the Time-Out response header and the Lock-
- Token request header. A class "2" compliant resource SHOULD also
- support the Time-Out request header and the owner XML element.
-
- Class 2 compliant resources MUST return, at minimum, the values "1"
- and "2" in the DAV header on all responses to the OPTIONS method.
-
-
-
-Goland, et al. Standards Track [Page 75]
-
-RFC 2518 WEBDAV February 1999
-
-
-16 Internationalization Considerations
-
- In the realm of internationalization, this specification complies
- with the IETF Character Set Policy [RFC2277]. In this specification,
- human-readable fields can be found either in the value of a property,
- or in an error message returned in a response entity body. In both
- cases, the human-readable content is encoded using XML, which has
- explicit provisions for character set tagging and encoding, and
- requires that XML processors read XML elements encoded, at minimum,
- using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane.
- XML examples in this specification demonstrate use of the charset
- parameter of the Content-Type header, as defined in [RFC2376], as
- well as the XML "encoding" attribute, which together provide charset
- identification information for MIME and XML processors.
-
- 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 [RFC1766]) or ISO 639
- language tags [ISO-639] in the "xml:lang" attribute of an XML element
- to identify the language of its content and attributes.
-
- WebDAV applications MUST support the character set tagging, character
- set encoding, and the language tagging functionality of the XML
- specification. Implementors of WebDAV applications are strongly
- encouraged to read "XML Media Types" [RFC2376] for instruction on
- which MIME media type to use for XML transport, and on use of the
- charset parameter of the Content-Type header.
-
- Names used within this specification fall into three categories:
- names of protocol elements such as methods and headers, names of XML
- elements, and names of properties. Naming of protocol elements
- follows the precedent of HTTP, using English names encoded in USASCII
- for methods and headers. Since these protocol elements are not
- visible to users, and are in fact simply long token identifiers, they
- do not need to support encoding in multiple character sets.
- Similarly, though the names of XML elements used in this
- specification are English names encoded in UTF-8, these names are not
- visible to the user, and hence do not need to support multiple
- character set encodings.
-
- The name of a property defined on a resource is a URI. Although some
- applications (e.g., a generic property viewer) will display property
- URIs directly to their users, it is expected that the typical
- application will use a fixed set of properties, and will provide a
- mapping from the property name URI to a human-readable field when
- displaying the property name to a user. It is only in the case where
-
-
-
-
-
-Goland, et al. Standards Track [Page 76]
-
-RFC 2518 WEBDAV February 1999
-
-
- the set of properties is not known ahead of time that an application
- need display a property name URI to a user. We recommend that
- applications provide human-readable property names wherever feasible.
-
- For error reporting, we follow the convention of HTTP/1.1 status
- codes, including with each status code a short, English description
- of the code (e.g., 423 (Locked)). While the possibility exists that
- a poorly crafted user agent would display this message to a user,
- internationalized applications will ignore this message, and display
- an appropriate message in the user's language and character set.
-
- Since interoperation of clients and servers does not require locale
- information, this specification does not specify any mechanism for
- transmission of this information.
-
-17 Security Considerations
-
- This section is provided to detail issues concerning security
- implications of which WebDAV applications need to be aware.
-
- All of the security considerations of HTTP/1.1 (discussed in
- [RFC2068]) and XML (discussed in [RFC2376]) also apply to WebDAV. In
- addition, the security risks inherent in remote authoring require
- stronger authentication technology, introduce several new privacy
- concerns, and may increase the hazards from poor server design.
- These issues are detailed below.
-
-17.1 Authentication of Clients
-
- Due to their emphasis on authoring, WebDAV servers need to use
- authentication technology to protect not just access to a network
- resource, but the integrity of the resource as well. Furthermore,
- the introduction of locking functionality requires support for
- authentication.
-
- A password sent in the clear over an insecure channel is an
- inadequate means for protecting the accessibility and integrity of a
- resource as the password may be intercepted. Since Basic
- authentication for HTTP/1.1 performs essentially clear text
- transmission of a password, Basic authentication MUST NOT be used to
- authenticate a WebDAV client to a server unless the connection is
- secure. Furthermore, a WebDAV server MUST NOT send Basic
- authentication credentials in a WWW-Authenticate header unless the
- connection is secure. Examples of secure connections include a
- Transport Layer Security (TLS) connection employing a strong cipher
- suite with mutual authentication of client and server, or a
- connection over a network which is physically secure, for example, an
- isolated network in a building with restricted access.
-
-
-
-Goland, et al. Standards Track [Page 77]
-
-RFC 2518 WEBDAV February 1999
-
-
- WebDAV applications MUST support the Digest authentication scheme
- [RFC2069]. Since Digest authentication verifies that both parties to
- a communication know a shared secret, a password, without having to
- send that secret in the clear, Digest authentication avoids the
- security problems inherent in Basic authentication while providing a
- level of authentication which is useful in a wide range of scenarios.
-
-17.2 Denial of Service
-
- Denial of service attacks are of special concern to WebDAV servers.
- WebDAV plus HTTP enables denial of service attacks on every part of a
- system's resources.
-
- The underlying storage can be attacked by PUTting extremely large
- files.
-
- Asking for recursive operations on large collections can attack
- processing time.
-
- Making multiple pipelined requests on multiple connections can attack
- network connections.
-
- WebDAV servers need to be aware of the possibility of a denial of
- service attack at all levels.
-
-17.3 Security through Obscurity
-
- WebDAV provides, through the PROPFIND method, a mechanism for listing
- the member resources of a collection. This greatly diminishes the
- effectiveness of security or privacy techniques that rely only on the
- difficulty of discovering the names of network resources. Users of
- WebDAV servers are encouraged to use access control techniques to
- prevent unwanted access to resources, rather than depending on the
- relative obscurity of their resource names.
-
-17.4 Privacy Issues Connected to Locks
-
- When submitting a lock request a user agent may also submit an owner
- XML field giving contact information for the person taking out the
- lock (for those cases where a person, rather than a robot, is taking
- out the lock). This contact information is stored in a lockdiscovery
- property on the resource, and can be used by other collaborators to
- begin negotiation over access to the resource. However, in many
- cases this contact information can be very private, and should not be
- widely disseminated. Servers SHOULD limit read access to the
- lockdiscovery property as appropriate. Furthermore, user agents
-
-
-
-
-
-Goland, et al. Standards Track [Page 78]
-
-RFC 2518 WEBDAV February 1999
-
-
- SHOULD provide control over whether contact information is sent at
- all, and if contact information is sent, control over exactly what
- information is sent.
-
-17.5 Privacy Issues Connected to Properties
-
- Since property values are typically used to hold information such as
- the author of a document, there is the possibility that privacy
- concerns could arise stemming from widespread access to a resource's
- property data. To reduce the risk of inadvertent release of private
- information via properties, servers are encouraged to develop access
- control mechanisms that separate read access to the resource body and
- read access to the resource's properties. This allows a user to
- control the dissemination of their property data without overly
- restricting access to the resource's contents.
-
-17.6 Reduction of Security due to Source Link
-
- HTTP/1.1 warns against providing read access to script code because
- it may contain sensitive information. Yet WebDAV, via its source
- link facility, can potentially provide a URI for script resources so
- they may be authored. For HTTP/1.1, a server could reasonably
- prevent access to source resources due to the predominance of read-
- only access. WebDAV, with its emphasis on authoring, encourages read
- and write access to source resources, and provides the source link
- facility to identify the source. This reduces the security benefits
- of eliminating access to source resources. Users and administrators
- of WebDAV servers should be very cautious when allowing remote
- authoring of scripts, limiting read and write access to the source
- resources to authorized principals.
-
-17.7 Implications of XML External Entities
-
- XML supports a facility known as "external entities", defined in
- section 4.2.2 of [REC-XML], which instruct an XML processor to
- retrieve and perform an inline include of XML located at a particular
- URI. An external XML entity can be used to append or modify the
- document type declaration (DTD) associated with an XML document. An
- external XML entity can also be used to include XML within the
- content of an XML document. For non-validating XML, such as the XML
- used in this specification, including an external XML entity is not
- required by [REC-XML]. However, [REC-XML] does state that an XML
- processor may, at its discretion, include the external XML entity.
-
- External XML entities have no inherent trustworthiness and are
- subject to all the attacks that are endemic to any HTTP GET request.
- Furthermore, it is possible for an external XML entity to modify the
- DTD, and hence affect the final form of an XML document, in the worst
-
-
-
-Goland, et al. Standards Track [Page 79]
-
-RFC 2518 WEBDAV February 1999
-
-
- case significantly modifying its semantics, or exposing the XML
- processor to the security risks discussed in [RFC2376]. Therefore,
- implementers must be aware that external XML entities should be
- treated as untrustworthy.
-
- There is also the scalability risk that would accompany a widely
- deployed application which made use of external XML entities. In
- this situation, it is possible that there would be significant
- numbers of requests for one external XML entity, potentially
- overloading any server which fields requests for the resource
- containing the external XML entity.
-
-17.8 Risks Connected with Lock Tokens
-
- This specification, in section 6.4, requires the use of Universal
- Unique Identifiers (UUIDs) for lock tokens, in order to guarantee
- their uniqueness across space and time. UUIDs, as defined in [ISO-
- 11578], contain a "node" field which "consists of the IEEE address,
- usually the host address. For systems with multiple IEEE 802 nodes,
- any available node address can be used." Since a WebDAV server will
- issue many locks over its lifetime, the implication is that it will
- also be publicly exposing its IEEE 802 address.
-
- There are several risks associated with exposure of IEEE 802
- addresses. Using the IEEE 802 address:
-
- * It is possible to track the movement of hardware from subnet to
- subnet.
-
- * It may be possible to identify the manufacturer of the hardware
- running a WebDAV server.
-
- * It may be possible to determine the number of each type of computer
- running WebDAV.
-
- Section 6.4.1 of this specification details an alternate mechanism
- for generating the "node" field of a UUID without using an IEEE 802
- address, which alleviates the risks associated with exposure of IEEE
- 802 addresses by using an alternate source of uniqueness.
-
-18 IANA Considerations
-
- This document defines two namespaces, the namespace of property
- names, and the namespace of WebDAV-specific XML elements used within
- property values.
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 80]
-
-RFC 2518 WEBDAV February 1999
-
-
- URIs are used for both names, for several reasons. Assignment of a
- URI does not require a request to a central naming authority, and
- hence allow WebDAV property names and XML elements to be quickly
- defined by any WebDAV user or application. URIs also provide a
- unique address space, ensuring that the distributed users of WebDAV
- will not have collisions among the property names and XML elements
- they create.
-
- This specification defines a distinguished set of property names and
- XML elements that are understood by all WebDAV applications. The
- property names and XML elements in this specification are all derived
- from the base URI DAV: by adding a suffix to this URI, for example,
- DAV:creationdate for the "creationdate" property.
-
- This specification also defines a URI scheme for the encoding of lock
- tokens, the opaquelocktoken URI scheme described in section 6.4.
-
- To ensure correct interoperation based on this specification, IANA
- must reserve the URI namespaces starting with "DAV:" and with
- "opaquelocktoken:" for use by this specification, its revisions, and
- related WebDAV specifications.
-
-19 Intellectual Property
-
- The following notice is copied from RFC 2026 [RFC2026], 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
- 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.
-
-
-
-
-Goland, et al. Standards Track [Page 81]
-
-RFC 2518 WEBDAV February 1999
-
-
-20 Acknowledgements
-
- A specification such as this thrives on piercing critical review and
- withers from apathetic neglect. The authors gratefully acknowledge
- the contributions of the following people, whose insights were so
- valuable at every stage of our work.
-
- Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
- Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
- Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
- Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
- Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
- Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
- Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der
- Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven
- Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten,
- Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff,
- Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike
- Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi,
- Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran,
- Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
-
- Two from this list deserve special mention. The contributions by
- Larry Masinter have been invaluable, both in helping the formation of
- the working group and in patiently coaching the authors along the
- way. In so many ways he has set high standards we have toiled to
- meet. The contributions of Judith Slein in clarifying the
- requirements, and in patiently reviewing draft after draft, both
- improved this specification and expanded our minds on document
- management.
-
- We would also like to thank John Turner for developing the XML DTD.
-
-21 References
-
-21.1 Normative References
-
- [RFC1766] Alvestrand, H., "Tags for the Identification of
- Languages", RFC 1766, March 1995.
-
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
- Languages", BCP 18, RFC 2277, January 1998.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 82]
-
-RFC 2518 WEBDAV February 1999
-
-
- [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
- "Uniform Resource Identifiers (URI): Generic Syntax",
- RFC 2396, August 1998.
-
- [REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen,
- "Extensible Markup Language (XML)." World Wide Web
- Consortium Recommendation REC-xml-19980210.
- http://www.w3.org/TR/1998/REC-xml-19980210.
-
- [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
- XML". World Wide Web Consortium Recommendation REC-
- xml-names-19990114. http://www.w3.org/TR/1999/REC-
- xml-names-19990114/
-
- [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach,
- P, Luotonen, A., Sink, E. and L. Stewart, "An
- Extension to HTTP : Digest Access Authentication",
- RFC 2069, January 1997.
-
- [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
- T. Berners-Lee, "Hypertext Transfer Protocol --
- HTTP/1.1", RFC 2068, January 1997.
-
- [ISO-639] ISO (International Organization for Standardization).
- ISO 639:1988. "Code for the representation of names
- of languages."
-
- [ISO-8601] ISO (International Organization for Standardization).
- ISO 8601:1988. "Data elements and interchange formats
- - Information interchange - Representation of dates
- and times."
-
- [ISO-11578] ISO (International Organization for Standardization).
- ISO/IEC 11578:1996. "Information technology - Open
- Systems Interconnection - Remote Procedure Call
- (RPC)"
-
- [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of
- Unicode and ISO 10646", RFC 2279, January 1998.
-
-21.2 Informational References
-
- [RFC2026] Bradner, S., "The Internet Standards Process - Revision
- 3", BCP 9, RFC 2026, October 1996.
-
-
-
-
-
-Goland, et al. Standards Track [Page 83]
-
-RFC 2518 WEBDAV February 1999
-
-
- [RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic
- Records", RFC 1807, June 1995.
-
- [WF] C. Lagoze, "The Warwick Framework: A Container
- Architecture for Diverse Sets of Metadata", D-Lib
- Magazine, July/August 1996.
- http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
-
- [USMARC] Network Development and MARC Standards, Office, ed. 1994.
- "USMARC Format for Bibliographic Data", 1994. Washington,
- DC: Cataloging Distribution Service, Library of Congress.
-
- [REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS
- Label Distribution Label Syntax and Communication
- Protocols" Version 1.1, World Wide Web Consortium
- Recommendation REC-PICS-labels-961031.
- http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
-
- [RFC2291] Slein, J., Vitali, F., Whitehead, E. and D. Durand,
- "Requirements for Distributed Authoring and Versioning
- Protocol for the World Wide Web", RFC 2291, February 1998.
-
- [RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin
- Core Metadata for Resource Discovery", RFC 2413, September
- 1998.
-
- [RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
- July 1998.
-
-22 Authors' Addresses
-
- Y. Y. Goland
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052-6399
-
- EMail: yarong at microsoft.com
-
-
- E. J. Whitehead, Jr.
- Dept. Of Information and Computer Science
- University of California, Irvine
- Irvine, CA 92697-3425
-
- EMail: ejw at ics.uci.edu
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 84]
-
-RFC 2518 WEBDAV February 1999
-
-
- A. Faizi
- Netscape
- 685 East Middlefield Road
- Mountain View, CA 94043
-
- EMail: asad at netscape.com
-
-
- S. R. Carter
- Novell
- 1555 N. Technology Way
- M/S ORM F111
- Orem, UT 84097-2399
-
- EMail: srcarter at novell.com
-
-
- D. Jensen
- Novell
- 1555 N. Technology Way
- M/S ORM F111
- Orem, UT 84097-2399
-
- EMail: dcjensen at novell.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 85]
-
-RFC 2518 WEBDAV February 1999
-
-
-23 Appendices
-
-23.1 Appendix 1 - WebDAV Document Type Definition
-
- This section provides a document type definition, following the rules
- in [REC-XML], for the XML elements used in the protocol stream and in
- the values of properties. It collects the element definitions given
- in sections 12 and 13.
-
- <!DOCTYPE webdav-1.0 [
-
- <!--============ XML Elements from Section 12 ==================-->
-
- <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
- locktoken?) >
-
- <!ELEMENT lockentry (lockscope, locktype) >
- <!ELEMENT lockinfo (lockscope, locktype, owner?) >
-
- <!ELEMENT locktype (write) >
- <!ELEMENT write EMPTY >
-
- <!ELEMENT lockscope (exclusive | shared) >
- <!ELEMENT exclusive EMPTY >
- <!ELEMENT shared EMPTY >
-
- <!ELEMENT depth (#PCDATA) >
-
- <!ELEMENT owner ANY >
-
- <!ELEMENT timeout (#PCDATA) >
-
- <!ELEMENT locktoken (href+) >
-
- <!ELEMENT href (#PCDATA) >
-
- <!ELEMENT link (src+, dst+) >
- <!ELEMENT dst (#PCDATA) >
- <!ELEMENT src (#PCDATA) >
-
- <!ELEMENT multistatus (response+, responsedescription?) >
-
- <!ELEMENT response (href, ((href*, status)|(propstat+)),
- responsedescription?) >
- <!ELEMENT status (#PCDATA) >
- <!ELEMENT propstat (prop, status, responsedescription?) >
- <!ELEMENT responsedescription (#PCDATA) >
-
-
-
-
-Goland, et al. Standards Track [Page 86]
-
-RFC 2518 WEBDAV February 1999
-
-
- <!ELEMENT prop ANY >
-
- <!ELEMENT propertybehavior (omit | keepalive) >
- <!ELEMENT omit EMPTY >
-
- <!ELEMENT keepalive (#PCDATA | href+) >
-
- <!ELEMENT propertyupdate (remove | set)+ >
- <!ELEMENT remove (prop) >
- <!ELEMENT set (prop) >
-
- <!ELEMENT propfind (allprop | propname | prop) >
- <!ELEMENT allprop EMPTY >
- <!ELEMENT propname EMPTY >
-
- <!ELEMENT collection EMPTY >
-
- <!--=========== Property Elements from Section 13 ===============-->
- <!ELEMENT creationdate (#PCDATA) >
- <!ELEMENT displayname (#PCDATA) >
- <!ELEMENT getcontentlanguage (#PCDATA) >
- <!ELEMENT getcontentlength (#PCDATA) >
- <!ELEMENT getcontenttype (#PCDATA) >
- <!ELEMENT getetag (#PCDATA) >
- <!ELEMENT getlastmodified (#PCDATA) >
- <!ELEMENT lockdiscovery (activelock)* >
- <!ELEMENT resourcetype ANY >
- <!ELEMENT source (link)* >
- <!ELEMENT supportedlock (lockentry)* >
- ]>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 87]
-
-RFC 2518 WEBDAV February 1999
-
-
-23.2 Appendix 2 - ISO 8601 Date and Time Profile
-
- The creationdate property specifies the use of the ISO 8601 date
- format [ISO-8601]. This section defines a profile of the ISO 8601
- date format for use with this specification. This profile is quoted
- from an Internet-Draft by Chris Newman, and is mentioned here to
- properly attribute his work.
-
- date-time = full-date "T" full-time
-
- full-date = date-fullyear "-" date-month "-" date-mday
- full-time = partial-time time-offset
-
- date-fullyear = 4DIGIT
- date-month = 2DIGIT ; 01-12
- date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
- month/year
- time-hour = 2DIGIT ; 00-23
- time-minute = 2DIGIT ; 00-59
- time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules
- time-secfrac = "." 1*DIGIT
- time-numoffset = ("+" / "-") time-hour ":" time-minute
- time-offset = "Z" / time-numoffset
-
- partial-time = time-hour ":" time-minute ":" time-second
- [time-secfrac]
-
- Numeric offsets are calculated as local time minus UTC (Coordinated
- Universal Time). So the equivalent time in UTC can be determined by
- subtracting the offset from the local time. For example, 18:50:00-
- 04:00 is the same time as 22:58:00Z.
-
- If the time in UTC is known, but the offset to local time is unknown,
- this can be represented with an offset of "-00:00". This differs
- from an offset of "Z" which implies that UTC is the preferred
- reference point for the specified time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 88]
-
-RFC 2518 WEBDAV February 1999
-
-
-23.3 Appendix 3 - Notes on Processing XML Elements
-
-23.3.1 Notes on Empty XML Elements
-
- XML supports two mechanisms for indicating that an XML element does
- not have any content. The first is to declare an XML element of the
- form <A></A>. The second is to declare an XML element of the form
- <A/>. The two XML elements are semantically identical.
-
- It is a violation of the XML specification to use the <A></A> form if
- the associated DTD declares the element to be EMPTY (e.g., <!ELEMENT
- A EMPTY>). If such a statement is included, then the empty element
- format, <A/> must be used. If the element is not declared to be
- EMPTY, then either form <A></A> or <A/> may be used for empty
- elements.
-
- 23.3.2 Notes on Illegal XML Processing
-
- XML is a flexible data format that makes it easy to submit data that
- appears legal but in fact is not. The philosophy of "Be flexible in
- what you accept and strict in what you send" still applies, but it
- must not be applied inappropriately. XML is extremely flexible in
- dealing with issues of white space, element ordering, inserting new
- elements, etc. This flexibility does not require extension,
- especially not in the area of the meaning of elements.
-
- There is no kindness in accepting illegal combinations of XML
- elements. At best it will cause an unwanted result and at worst it
- can cause real damage.
-
-23.3.2.1 Example - XML Syntax Error
-
- The following request body for a PROPFIND method is illegal.
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:">
- <D:allprop/>
- <D:propname/>
- </D:propfind>
-
- The definition of the propfind element only allows for the allprop or
- the propname element, not both. Thus the above is an error and must
- be responded to with a 400 (Bad Request).
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 89]
-
-RFC 2518 WEBDAV February 1999
-
-
- Imagine, however, that a server wanted to be "kind" and decided to
- pick the allprop element as the true element and respond to it. A
- client running over a bandwidth limited line who intended to execute
- a propname would be in for a big surprise if the server treated the
- command as an allprop.
-
- Additionally, if a server were lenient and decided to reply to this
- request, the results would vary randomly from server to server, with
- some servers executing the allprop directive, and others executing
- the propname directive. This reduces interoperability rather than
- increasing it.
-
-23.3.2.2 Example - Unknown XML Element
-
- The previous example was illegal because it contained two elements
- that were explicitly banned from appearing together in the propfind
- element. However, XML is an extensible language, so one can imagine
- new elements being defined for use with propfind. Below is the
- request body of a PROPFIND and, like the previous example, must be
- rejected with a 400 (Bad Request) by a server that does not
- understand the expired-props element.
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:"
- xmlns:E="http://www.foo.bar/standards/props/">
- <E:expired-props/>
- </D:propfind>
-
- To understand why a 400 (Bad Request) is returned let us look at the
- request body as the server unfamiliar with expired-props sees it.
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:"
- xmlns:E="http://www.foo.bar/standards/props/">
- </D:propfind>
-
- As the server does not understand the expired-props element,
- according to the WebDAV-specific XML processing rules specified in
- section 14, it must ignore it. Thus the server sees an empty
- propfind, which by the definition of the propfind element is illegal.
-
- Please note that had the extension been additive it would not
- necessarily have resulted in a 400 (Bad Request). For example,
- imagine the following request body for a PROPFIND:
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:"
- xmlns:E="http://www.foo.bar/standards/props/">
-
-
-
-Goland, et al. Standards Track [Page 90]
-
-RFC 2518 WEBDAV February 1999
-
-
- <D:propname/>
- <E:leave-out>*boss*</E:leave-out>
- </D:propfind>
-
- The previous example contains the fictitious element leave-out. Its
- purpose is to prevent the return of any property whose name matches
- the submitted pattern. If the previous example were submitted to a
- server unfamiliar with leave-out, the only result would be that the
- leave-out element would be ignored and a propname would be executed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 91]
-
-RFC 2518 WEBDAV February 1999
-
-
-23.4 Appendix 4 -- XML Namespaces for WebDAV
-
-23.4.1 Introduction
-
- All DAV compliant systems MUST support the XML namespace extensions
- as specified in [REC-XML-NAMES].
-
-23.4.2 Meaning of Qualified Names
-
- [Note to the reader: This section does not appear in [REC-XML-NAMES],
- but is necessary to avoid ambiguity for WebDAV XML processors.]
-
- WebDAV compliant XML processors MUST interpret a qualified name as a
- URI constructed by appending the LocalPart to the namespace name URI.
-
- Example
-
- <del:glider xmlns:del="http://www.del.jensen.org/">
- <del:glidername>
- Johnny Updraft
- </del:glidername>
- <del:glideraccidents/>
- </del:glider>
-
- In this example, the qualified element name "del:glider" is
- interpreted as the URL "http://www.del.jensen.org/glider".
-
- <bar:glider xmlns:del="http://www.del.jensen.org/">
- <bar:glidername>
- Johnny Updraft
- </bar:glidername>
- <bar:glideraccidents/>
- </bar:glider>
-
- Even though this example is syntactically different from the previous
- example, it is semantically identical. Each instance of the
- namespace name "bar" is replaced with "http://www.del.jensen.org/"
- and then appended to the local name for each element tag. The
- resulting tag names in this example are exactly the same as for the
- previous example.
-
- <foo:r xmlns:foo="http://www.del.jensen.org/glide">
- <foo:rname>
- Johnny Updraft
- </foo:rname>
- <foo:raccidents/>
- </foo:r>
-
-
-
-
-Goland, et al. Standards Track [Page 92]
-
-RFC 2518 WEBDAV February 1999
-
-
- This example is semantically identical to the two previous ones.
- Each instance of the namespace name "foo" is replaced with
- "http://www.del.jensen.org/glide" which is then appended to the local
- name for each element tag, the resulting tag names are identical to
- those in the previous examples.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 93]
-
-RFC 2518 WEBDAV February 1999
-
-
-24. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Goland, et al. Standards Track [Page 94]
-
Deleted: CalendarServer/trunk/doc/RFC/rfc4918-WebDAV Update.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/rfc4918-WebDAV Update.txt 2008-04-21 21:34:22 UTC (rev 2332)
+++ CalendarServer/trunk/doc/RFC/rfc4918-WebDAV Update.txt 2008-04-21 22:41:07 UTC (rev 2333)
@@ -1,7115 +0,0 @@
-
-
-
-
-
-
-Network Working Group L. Dusseault, Ed.
-Request for Comments: 4918 CommerceNet
-Obsoletes: 2518 June 2007
-Category: Standards Track
-
-
- HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
-
-Status of This Memo
-
- 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 Notice
-
- Copyright (C) The IETF Trust (2007).
-
-Abstract
-
- Web Distributed Authoring and Versioning (WebDAV) consists of a set
- of methods, headers, and content-types ancillary to HTTP/1.1 for the
- management of resource properties, creation and management of
- resource collections, URL namespace manipulation, and resource
- locking (collision avoidance).
-
- RFC 2518 was published in February 1999, and this specification
- obsoletes RFC 2518 with minor revisions mostly due to
- interoperability experience.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 1]
-
-RFC 4918 WebDAV June 2007
-
-
-Table of Contents
-
- 1. Introduction ....................................................7
- 2. Notational Conventions ..........................................8
- 3. Terminology .....................................................8
- 4. Data Model for Resource Properties .............................10
- 4.1. The Resource Property Model ...............................10
- 4.2. Properties and HTTP Headers ...............................10
- 4.3. Property Values ...........................................10
- 4.3.1. Example - Property with Mixed Content ..............12
- 4.4. Property Names ............................................14
- 4.5. Source Resources and Output Resources .....................14
- 5. Collections of Web Resources ...................................14
- 5.1. HTTP URL Namespace Model ..................................15
- 5.2. Collection Resources ......................................15
- 6. Locking ........................................................17
- 6.1. Lock Model ................................................18
- 6.2. Exclusive vs. Shared Locks ................................19
- 6.3. Required Support ..........................................20
- 6.4. Lock Creator and Privileges ...............................20
- 6.5. Lock Tokens ...............................................21
- 6.6. Lock Timeout ..............................................21
- 6.7. Lock Capability Discovery .................................22
- 6.8. Active Lock Discovery .....................................22
- 7. Write Lock .....................................................23
- 7.1. Write Locks and Properties ................................24
- 7.2. Avoiding Lost Updates .....................................24
- 7.3. Write Locks and Unmapped URLs .............................25
- 7.4. Write Locks and Collections ...............................26
- 7.5. Write Locks and the If Request Header .....................28
- 7.5.1. Example - Write Lock and COPY ......................28
- 7.5.2. Example - Deleting a Member of a Locked
- Collection .........................................29
- 7.6. Write Locks and COPY/MOVE .................................30
- 7.7. Refreshing Write Locks ....................................30
- 8. General Request and Response Handling ..........................31
- 8.1. Precedence in Error Handling ..............................31
- 8.2. Use of XML ................................................31
- 8.3. URL Handling ..............................................32
- 8.3.1. Example - Correct URL Handling .....................32
- 8.4. Required Bodies in Requests ...............................33
- 8.5. HTTP Headers for Use in WebDAV ............................33
- 8.6. ETag ......................................................33
- 8.7. Including Error Response Bodies ...........................34
- 8.8. Impact of Namespace Operations on Cache Validators ........34
- 9. HTTP Methods for Distributed Authoring .........................35
- 9.1. PROPFIND Method ...........................................35
- 9.1.1. PROPFIND Status Codes ..............................37
-
-
-
-Dusseault Standards Track [Page 2]
-
-RFC 4918 WebDAV June 2007
-
-
- 9.1.2. Status Codes for Use in 'propstat' Element .........37
- 9.1.3. Example - Retrieving Named Properties ..............38
- 9.1.4. Example - Using 'propname' to Retrieve All
- Property Names .....................................39
- 9.1.5. Example - Using So-called 'allprop' ................41
- 9.1.6. Example - Using 'allprop' with 'include' ...........43
- 9.2. PROPPATCH Method ..........................................44
- 9.2.1. Status Codes for Use in 'propstat' Element .........44
- 9.2.2. Example - PROPPATCH ................................45
- 9.3. MKCOL Method ..............................................46
- 9.3.1. MKCOL Status Codes .................................47
- 9.3.2. Example - MKCOL ....................................47
- 9.4. GET, HEAD for Collections .................................48
- 9.5. POST for Collections ......................................48
- 9.6. DELETE Requirements .......................................48
- 9.6.1. DELETE for Collections .............................49
- 9.6.2. Example - DELETE ...................................49
- 9.7. PUT Requirements ..........................................50
- 9.7.1. PUT for Non-Collection Resources ...................50
- 9.7.2. PUT for Collections ................................51
- 9.8. COPY Method ...............................................51
- 9.8.1. COPY for Non-collection Resources ..................51
- 9.8.2. COPY for Properties ................................52
- 9.8.3. COPY for Collections ...............................52
- 9.8.4. COPY and Overwriting Destination Resources .........53
- 9.8.5. Status Codes .......................................54
- 9.8.6. Example - COPY with Overwrite ......................55
- 9.8.7. Example - COPY with No Overwrite ...................55
- 9.8.8. Example - COPY of a Collection .....................56
- 9.9. MOVE Method ...............................................56
- 9.9.1. MOVE for Properties ................................57
- 9.9.2. MOVE for Collections ...............................57
- 9.9.3. MOVE and the Overwrite Header ......................58
- 9.9.4. Status Codes .......................................59
- 9.9.5. Example - MOVE of a Non-Collection .................60
- 9.9.6. Example - MOVE of a Collection .....................60
- 9.10. LOCK Method ..............................................61
- 9.10.1. Creating a Lock on an Existing Resource ...........61
- 9.10.2. Refreshing Locks ..................................62
- 9.10.3. Depth and Locking .................................62
- 9.10.4. Locking Unmapped URLs .............................63
- 9.10.5. Lock Compatibility Table ..........................63
- 9.10.6. LOCK Responses ....................................63
- 9.10.7. Example - Simple Lock Request .....................64
- 9.10.8. Example - Refreshing a Write Lock .................65
- 9.10.9. Example - Multi-Resource Lock Request .............66
- 9.11. UNLOCK Method ............................................68
- 9.11.1. Status Codes ......................................68
-
-
-
-Dusseault Standards Track [Page 3]
-
-RFC 4918 WebDAV June 2007
-
-
- 9.11.2. Example - UNLOCK ..................................69
- 10. HTTP Headers for Distributed Authoring ........................69
- 10.1. DAV Header ...............................................69
- 10.2. Depth Header .............................................70
- 10.3. Destination Header .......................................71
- 10.4. If Header ................................................72
- 10.4.1. Purpose ...........................................72
- 10.4.2. Syntax ............................................72
- 10.4.3. List Evaluation ...................................73
- 10.4.4. Matching State Tokens and ETags ...................74
- 10.4.5. If Header and Non-DAV-Aware Proxies ...............74
- 10.4.6. Example - No-tag Production .......................75
- 10.4.7. Example - Using "Not" with No-tag Production ......75
- 10.4.8. Example - Causing a Condition to Always
- Evaluate to True ..................................75
- 10.4.9. Example - Tagged List If Header in COPY ...........76
- 10.4.10. Example - Matching Lock Tokens with
- Collection Locks .................................76
- 10.4.11. Example - Matching ETags on Unmapped URLs ........76
- 10.5. Lock-Token Header ........................................77
- 10.6. Overwrite Header .........................................77
- 10.7. Timeout Request Header ...................................78
- 11. Status Code Extensions to HTTP/1.1 ............................78
- 11.1. 207 Multi-Status .........................................78
- 11.2. 422 Unprocessable Entity .................................78
- 11.3. 423 Locked ...............................................78
- 11.4. 424 Failed Dependency ....................................79
- 11.5. 507 Insufficient Storage .................................79
- 12. Use of HTTP Status Codes ......................................79
- 12.1. 412 Precondition Failed ..................................79
- 12.2. 414 Request-URI Too Long .................................79
- 13. Multi-Status Response .........................................80
- 13.1. Response Headers .........................................80
- 13.2. Handling Redirected Child Resources ......................81
- 13.3. Internal Status Codes ....................................81
- 14. XML Element Definitions .......................................81
- 14.1. activelock XML Element ...................................81
- 14.2. allprop XML Element ......................................82
- 14.3. collection XML Element ...................................82
- 14.4. depth XML Element ........................................82
- 14.5. error XML Element ........................................82
- 14.6. exclusive XML Element ....................................83
- 14.7. href XML Element .........................................83
- 14.8. include XML Element ......................................83
- 14.9. location XML Element .....................................83
- 14.10. lockentry XML Element ...................................84
- 14.11. lockinfo XML Element ....................................84
- 14.12. lockroot XML Element ....................................84
-
-
-
-Dusseault Standards Track [Page 4]
-
-RFC 4918 WebDAV June 2007
-
-
- 14.13. lockscope XML Element ...................................84
- 14.14. locktoken XML Element ...................................85
- 14.15. locktype XML Element ....................................85
- 14.16. multistatus XML Element .................................85
- 14.17. owner XML Element .......................................85
- 14.18. prop XML Element ........................................86
- 14.19. propertyupdate XML Element ..............................86
- 14.20. propfind XML Element ....................................86
- 14.21. propname XML Element ....................................87
- 14.22. propstat XML Element ....................................87
- 14.23. remove XML Element ......................................87
- 14.24. response XML Element ....................................88
- 14.25. responsedescription XML Element .........................88
- 14.26. set XML Element .........................................88
- 14.27. shared XML Element ......................................89
- 14.28. status XML Element ......................................89
- 14.29. timeout XML Element .....................................89
- 14.30. write XML Element .......................................89
- 15. DAV Properties ................................................90
- 16. Precondition/Postcondition XML Elements .......................98
- 17. XML Extensibility in DAV .....................................101
- 18. DAV Compliance Classes .......................................103
- 18.1. Class 1 .................................................103
- 18.2. Class 2 .................................................103
- 18.3. Class 3 .................................................103
- 19. Internationalization Considerations ..........................104
- 20. Security Considerations ......................................105
- 20.1. Authentication of Clients ...............................105
- 20.2. Denial of Service .......................................106
- 20.3. Security through Obscurity ..............................106
- 20.4. Privacy Issues Connected to Locks .......................106
- 20.5. Privacy Issues Connected to Properties ..................107
- 20.6. Implications of XML Entities ............................107
- 20.7. Risks Connected with Lock Tokens ........................108
- 20.8. Hosting Malicious Content ...............................108
- 21. IANA Considerations ..........................................109
- 21.1. New URI Schemes .........................................109
- 21.2. XML Namespaces ..........................................109
- 21.3. Message Header Fields ...................................109
- 21.3.1. DAV ..............................................109
- 21.3.2. Depth ............................................110
- 21.3.3. Destination ......................................110
- 21.3.4. If ...............................................110
- 21.3.5. Lock-Token .......................................110
- 21.3.6. Overwrite ........................................111
- 21.3.7. Timeout ..........................................111
- 21.4. HTTP Status Codes .......................................111
- 22. Acknowledgements .............................................112
-
-
-
-Dusseault Standards Track [Page 5]
-
-RFC 4918 WebDAV June 2007
-
-
- 23. Contributors to This Specification ...........................113
- 24. Authors of RFC 2518 ..........................................113
- 25. References ...................................................114
- 25.1. Normative References.....................................114
- 25.2. Informative References ..................................115
- Appendix A. Notes on Processing XML Elements ....................117
- A.1. Notes on Empty XML Elements ..............................117
- A.2. Notes on Illegal XML Processing ..........................117
- A.3. Example - XML Syntax Error ...............................117
- A.4. Example - Unexpected XML Element .........................118
- Appendix B. Notes on HTTP Client Compatibility ...................119
- Appendix C. The 'opaquelocktoken' Scheme and URIs ................120
- Appendix D. Lock-null Resources ..................................120
- D.1. Guidance for Clients Using LOCK to Create Resources ......121
- Appendix E. Guidance for Clients Desiring to Authenticate ........121
- Appendix F. Summary of Changes from RFC 2518 .....................123
- F.1. Changes for Both Client and Server Implementations .......123
- F.2. Changes for Server Implementations .......................125
- F.3. Other Changes ............................................126
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 6]
-
-RFC 4918 WebDAV June 2007
-
-
-1. Introduction
-
- This document describes an extension to the HTTP/1.1 protocol that
- allows clients to perform remote Web content authoring operations.
- This extension provides a coherent set of methods, headers, request
- entity body formats, and response entity body formats that provide
- operations for:
-
- Properties: The ability to create, remove, and query information
- about Web pages, such as their authors, creation dates, etc.
-
- Collections: The ability to create sets of documents and to retrieve
- a hierarchical membership listing (like a directory listing in a file
- system).
-
- Locking: The ability to keep more than one person from working on a
- document at the same time. This prevents the "lost update problem",
- in which modifications are lost as first one author, then another,
- writes changes without merging the other author's changes.
-
- Namespace Operations: The ability to instruct the server to copy and
- move Web resources, operations that change the mapping from URLs to
- resources.
-
- Requirements and rationale for these operations are described in a
- companion document, "Requirements for a Distributed Authoring and
- Versioning Protocol for the World Wide Web" [RFC2291].
-
- This document does not specify the versioning operations suggested by
- [RFC2291]. That work was done in a separate document, "Versioning
- Extensions to WebDAV" [RFC3253].
-
- The sections below provide a detailed introduction to various WebDAV
- abstractions: resource properties (Section 4), collections of
- resources (Section 5), locks (Section 6) in general, and write locks
- (Section 7) specifically.
-
- These abstractions are manipulated by the WebDAV-specific HTTP
- methods (Section 9) and the extra HTTP headers (Section 10) used with
- WebDAV methods. General considerations for handling HTTP requests
- and responses in WebDAV are found in Section 8.
-
- While the status codes provided by HTTP/1.1 are sufficient to
- describe most error conditions encountered by WebDAV methods, there
- are some errors that do not fall neatly into the existing categories.
- This specification defines extra status codes developed for WebDAV
- methods (Section 11) and describes existing HTTP status codes
- (Section 12) as used in WebDAV. Since some WebDAV methods may
-
-
-
-Dusseault Standards Track [Page 7]
-
-RFC 4918 WebDAV June 2007
-
-
- operate over many resources, the Multi-Status response (Section 13)
- has been introduced to return status information for multiple
- resources. Finally, this version of WebDAV introduces precondition
- and postcondition (Section 16) XML elements in error response bodies.
-
- WebDAV uses XML ([REC-XML]) for property names and some values, and
- also uses XML to marshal complicated requests and responses. This
- specification contains DTD and text definitions of all properties
- (Section 15) and all other XML elements (Section 14) used in
- marshalling. WebDAV includes a few special rules on extending WebDAV
- XML marshalling in backwards-compatible ways (Section 17).
-
- Finishing off the specification are sections on what it means for a
- resource to be compliant with this specification (Section 18), on
- internationalization support (Section 19), and on security
- (Section 20).
-
-2. Notational Conventions
-
- Since this document describes a set of extensions to the HTTP/1.1
- protocol, the augmented BNF used herein to describe protocol elements
- is exactly the same as described in Section 2.1 of [RFC2616],
- including the rules about implied linear whitespace. Since this
- augmented BNF uses the basic production rules provided in Section 2.2
- of [RFC2616], these rules apply to this document as well. Note this
- is not the standard BNF syntax used in other RFCs.
-
- 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 [RFC2119].
-
- Note that in natural language, a property like the "creationdate"
- property in the "DAV:" XML namespace is sometimes referred to as
- "DAV:creationdate" for brevity.
-
-3. Terminology
-
- URI/URL - A Uniform Resource Identifier and Uniform Resource Locator,
- respectively. These terms (and the distinction between them) are
- defined in [RFC3986].
-
- URI/URL Mapping - A relation between an absolute URI and a resource.
- Since a resource can represent items that are not network
- retrievable, as well as those that are, it is possible for a resource
- to have zero, one, or many URI mappings. Mapping a resource to an
- "http" scheme URI makes it possible to submit HTTP protocol requests
- to the resource using the URI.
-
-
-
-
-Dusseault Standards Track [Page 8]
-
-RFC 4918 WebDAV June 2007
-
-
- Path Segment - Informally, the characters found between slashes ("/")
- in a URI. Formally, as defined in Section 3.3 of [RFC3986].
-
- Collection - Informally, a resource that also acts as a container of
- references to child resources. Formally, a resource that contains a
- set of mappings between path segments and resources and meets the
- requirements defined in Section 5.
-
- Internal Member (of a Collection) - Informally, a child resource of a
- collection. Formally, a resource referenced by a path segment
- mapping contained in the collection.
-
- Internal Member URL (of a Collection) - A URL of an internal member,
- consisting of the URL of the collection (including trailing slash)
- plus the path segment identifying the internal member.
-
- Member (of a Collection) - Informally, a "descendant" of a
- collection. Formally, an internal member of the collection, or,
- recursively, a member of an internal member.
-
- Member URL (of a Collection) - A URL that is either an internal
- member URL of the collection itself, or is an internal member URL of
- a member of that collection.
-
- Property - A name/value pair that contains descriptive information
- about a resource.
-
- Live Property - A property whose semantics and syntax are enforced by
- the server. For example, the live property DAV:getcontentlength has
- its value, the length of the entity returned by a GET request,
- automatically calculated by the server.
-
- Dead Property - A property whose semantics and syntax are not
- enforced by the server. The server only records the value of a dead
- property; the client is responsible for maintaining the consistency
- of the syntax and semantics of a dead property.
-
- Principal - A distinct human or computational actor that initiates
- access to network resources.
-
- State Token - A URI that represents a state of a resource. Lock
- tokens are the only state tokens defined in this specification.
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 9]
-
-RFC 4918 WebDAV June 2007
-
-
-4. Data Model for Resource Properties
-
-4.1. The Resource Property Model
-
- Properties are pieces of data that describe the state of a resource.
- Properties are data about data.
-
- Properties are used in distributed authoring environments to provide
- for efficient discovery and management of resources. For example, a
- 'subject' property might allow for the indexing of all resources by
- their subject, and an 'author' property might allow for the discovery
- of what authors have written which documents.
-
- The DAV property model consists of name/value pairs. The name of a
- property identifies the property's syntax and semantics, and provides
- an address by which to refer to its syntax and semantics.
-
- There are two categories of properties: "live" and "dead". A live
- property has its syntax and semantics enforced by the server. Live
- properties include cases where a) the value of a property is
- protected and maintained by the server, and b) the value of the
- property is maintained by the client, but the server performs syntax
- checking on submitted values. All instances of a given live property
- MUST comply with the definition associated with that property name.
- A dead property has its syntax and semantics enforced by the client;
- the server merely records the value of the property verbatim.
-
-4.2. Properties and HTTP Headers
-
- Properties already exist, in a limited sense, in HTTP message
- headers. However, in distributed authoring environments, a
- relatively large number of properties are needed to describe the
- state of a resource, and setting/returning them all through HTTP
- headers is inefficient. Thus, a mechanism is needed that allows a
- principal to identify a set of properties in which the principal is
- interested and to set or retrieve just those properties.
-
-4.3. Property Values
-
- The value of a property is always a (well-formed) XML fragment.
-
- XML has been chosen because it is a flexible, self-describing,
- structured data format that supports rich schema definitions, and
- because of its support for multiple character sets. XML's self-
- describing nature allows any property's value to be extended by
- adding elements. Clients will not break when they encounter
- extensions because they will still have the data specified in the
- original schema and MUST ignore elements they do not understand.
-
-
-
-Dusseault Standards Track [Page 10]
-
-RFC 4918 WebDAV June 2007
-
-
- XML's support for multiple character sets allows any human-readable
- property to be encoded and read in a character set familiar to the
- user. XML's support for multiple human languages, using the "xml:
- lang" attribute, handles cases where the same character set is
- employed by multiple human languages. Note that xml:lang scope is
- recursive, so an xml:lang attribute on any element containing a
- property name element applies to the property value unless it has
- been overridden by a more locally scoped attribute. Note that a
- property only has one value, in one language (or language MAY be left
- undefined); a property does not have multiple values in different
- languages or a single value in multiple languages.
-
- A property is always represented with an XML element consisting of
- the property name, called the "property name element". The simplest
- example is an empty property, which is different from a property that
- does not exist:
-
- <R:title xmlns:R="http://www.example.com/ns/"></R:title>
-
- The value of the property appears inside the property name element.
- The value may be any kind of well-formed XML content, including both
- text-only and mixed content. Servers MUST preserve the following XML
- Information Items (using the terminology from [REC-XML-INFOSET]) in
- storage and transmission of dead properties:
-
- For the property name Element Information Item itself:
-
- [namespace name]
-
- [local name]
-
- [attributes] named "xml:lang" or any such attribute in scope
-
- [children] of type element or character
-
- On all Element Information Items in the property value:
-
- [namespace name]
-
- [local name]
-
- [attributes]
-
- [children] of type element or character
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 11]
-
-RFC 4918 WebDAV June 2007
-
-
- On Attribute Information Items in the property value:
-
- [namespace name]
-
- [local name]
-
- [normalized value]
-
- On Character Information Items in the property value:
-
- [character code]
-
- Since prefixes are used in some XML vocabularies (XPath and XML
- Schema, for example), servers SHOULD preserve, for any Information
- Item in the value:
-
- [prefix]
-
- XML Infoset attributes not listed above MAY be preserved by the
- server, but clients MUST NOT rely on them being preserved. The above
- rules would also apply by default to live properties, unless defined
- otherwise.
-
- Servers MUST ignore the XML attribute xml:space if present and never
- use it to change whitespace handling. Whitespace in property values
- is significant.
-
-4.3.1. Example - Property with Mixed Content
-
- Consider a dead property 'author' created by the client as follows:
-
- <D:prop xml:lang="en" xmlns:D="DAV:">
- <x:author xmlns:x='http://example.com/ns'>
- <x:name>Jane Doe</x:name>
- <!-- Jane's contact info -->
- <x:uri type='email'
- added='2005-11-26'>mailto:jane.doe at example.com</x:uri>
- <x:uri type='web'
- added='2005-11-27'>http://www.example.com</x:uri>
- <x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
- Jane has been working way <h:em>too</h:em> long on the
- long-awaited revision of <![CDATA[<RFC2518>]]>.
- </x:notes>
- </x:author>
- </D:prop>
-
-
-
-
-
-
-Dusseault Standards Track [Page 12]
-
-RFC 4918 WebDAV June 2007
-
-
- When this property is requested, a server might return:
-
- <D:prop xmlns:D='DAV:'><author
- xml:lang='en'
- xmlns:x='http://example.com/ns'
- xmlns='http://example.com/ns'
- xmlns:h='http://www.w3.org/1999/xhtml'>
- <x:name>Jane Doe</x:name>
- <x:uri added="2005-11-26" type="email"
- >mailto:jane.doe at example.com</x:uri>
- <x:uri added="2005-11-27" type="web"
- >http://www.example.com</x:uri>
- <x:notes>
- Jane has been working way <h:em>too</h:em> long on the
- long-awaited revision of <RFC2518>.
- </x:notes>
- </author>
- </D:prop>
-
- Note in this example:
-
- o The [prefix] for the property name itself was not preserved, being
- non-significant, whereas all other [prefix] values have been
- preserved,
-
- o attribute values have been rewritten with double quotes instead of
- single quotes (quoting style is not significant), and attribute
- order has not been preserved,
-
- o the xml:lang attribute has been returned on the property name
- element itself (it was in scope when the property was set, but the
- exact position in the response is not considered significant as
- long as it is in scope),
-
- o whitespace between tags has been preserved everywhere (whitespace
- between attributes not so),
-
- o CDATA encapsulation was replaced with character escaping (the
- reverse would also be legal),
-
- o the comment item was stripped (as would have been a processing
- instruction item).
-
- Implementation note: there are cases such as editing scenarios where
- clients may require that XML content is preserved character by
- character (such as attribute ordering or quoting style). In this
- case, clients should consider using a text-only property value by
- escaping all characters that have a special meaning in XML parsing.
-
-
-
-Dusseault Standards Track [Page 13]
-
-RFC 4918 WebDAV June 2007
-
-
-4.4. Property Names
-
- A property name is a universally unique identifier that is associated
- with a schema that provides information about the syntax and
- semantics of the property.
-
- Because a property's name is universally unique, clients can depend
- upon consistent behavior for a particular property across multiple
- resources, on the same and across different servers, so long as that
- property is "live" on the resources in question, and the
- implementation of the live property is faithful to its definition.
-
- The XML namespace mechanism, which is based on URIs ([RFC3986]), is
- used to name properties because it prevents namespace collisions and
- provides for varying degrees of administrative control.
-
- The property namespace is flat; that is, no hierarchy of properties
- is explicitly recognized. Thus, if a property A and a property A/B
- exist on a resource, there is no recognition of any relationship
- between the two properties. It is expected that a separate
- specification will eventually be produced that will address issues
- relating to hierarchical properties.
-
- Finally, it is not possible to define the same property twice on a
- single resource, as this would cause a collision in the resource's
- property namespace.
-
-4.5. Source Resources and Output Resources
-
- Some HTTP resources are dynamically generated by the server. For
- these resources, there presumably exists source code somewhere
- governing how that resource is generated. The relationship of source
- files to output HTTP resources may be one to one, one to many, many
- to one, or many to many. There is no mechanism in HTTP to determine
- whether a resource is even dynamic, let alone where its source files
- exist or how to author them. Although this problem would usefully be
- solved, interoperable WebDAV implementations have been widely
- deployed without actually solving this problem, by dealing only with
- static resources. Thus, the source vs. output problem is not solved
- in this specification and has been deferred to a separate document.
-
-5. Collections of Web Resources
-
- This section provides a description of a type of Web resource, the
- collection, and discusses its interactions with the HTTP URL
- namespace and with HTTP methods. The purpose of a collection
- resource is to model collection-like objects (e.g., file system
- directories) within a server's namespace.
-
-
-
-Dusseault Standards Track [Page 14]
-
-RFC 4918 WebDAV June 2007
-
-
- All DAV-compliant resources MUST support the HTTP URL namespace model
- specified herein.
-
-5.1. HTTP URL Namespace Model
-
- The HTTP URL namespace is a hierarchical namespace where the
- hierarchy is delimited with the "/" character.
-
- An HTTP URL namespace is said to be consistent if it meets the
- following conditions: for every URL in the HTTP hierarchy there
- exists a collection that contains that URL as an internal member URL.
- The root, or top-level collection of the namespace under
- consideration, is exempt from the previous rule. The top-level
- collection of the namespace under consideration is not necessarily
- the collection identified by the absolute path '/' -- it may be
- identified by one or more path segments (e.g., /servlets/webdav/...)
-
- Neither HTTP/1.1 nor WebDAV requires that the entire HTTP URL
- namespace be consistent -- a WebDAV-compatible resource may not have
- a parent collection. However, certain WebDAV methods are prohibited
- from producing results that cause namespace inconsistencies.
-
- As is implicit in [RFC2616] and [RFC3986], any resource, including
- collection resources, MAY be identified by more than one URI. For
- example, a resource could be identified by multiple HTTP URLs.
-
-5.2. Collection Resources
-
- Collection resources differ from other resources in that they also
- act as containers. Some HTTP methods apply only to a collection, but
- some apply to some or all of the resources inside the container
- defined by the collection. When the scope of a method is not clear,
- the client can specify what depth to apply. Depth can be either zero
- levels (only the collection), one level (the collection and directly
- contained resources), or infinite levels (the collection and all
- contained resources recursively).
-
- A collection's state consists of at least a set of mappings between
- path segments and resources, and a set of properties on the
- collection itself. In this document, a resource B will be said to be
- contained in the collection resource A if there is a path segment
- mapping that maps to B and that is contained in A. A collection MUST
- contain at most one mapping for a given path segment, i.e., it is
- illegal to have the same path segment mapped to more than one
- resource.
-
-
-
-
-
-
-Dusseault Standards Track [Page 15]
-
-RFC 4918 WebDAV June 2007
-
-
- Properties defined on collections behave exactly as do properties on
- non-collection resources. A collection MAY have additional state
- such as entity bodies returned by GET.
-
- For all WebDAV-compliant resources A and B, identified by URLs "U"
- and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST
- be a collection that contains a mapping from "SEGMENT" to B. So, if
- resource B with URL "http://example.com/bar/blah" is WebDAV compliant
- and if resource A with URL "http://example.com/bar/" is WebDAV
- compliant, then resource A must be a collection and must contain
- exactly one mapping from "blah" to B.
-
- Although commonly a mapping consists of a single segment and a
- resource, in general, a mapping consists of a set of segments and a
- resource. This allows a server to treat a set of segments as
- equivalent (i.e., either all of the segments are mapped to the same
- resource, or none of the segments are mapped to a resource). For
- example, a server that performs case-folding on segments will treat
- the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can
- then use any of these segments to identify the resource. Note that a
- PROPFIND result will select one of these equivalent segments to
- identify the mapping, so there will be one PROPFIND response element
- per mapping, not one per segment in the mapping.
-
- Collection resources MAY have mappings to non-WebDAV-compliant
- resources in the HTTP URL namespace hierarchy but are not required to
- do so. For example, if resource X with URL
- "http://example.com/bar/blah" is not WebDAV compliant and resource A
- with "URL http://example.com/bar/" identifies a WebDAV collection,
- then A may or may not have a mapping from "blah" to X.
-
- If a WebDAV-compliant resource has no WebDAV-compliant internal
- members in the HTTP URL namespace hierarchy, then the WebDAV-
- compliant resource is not required to be a collection.
-
- There is a standing convention that when a collection is referred to
- by its name without a trailing slash, the server MAY handle the
- request as if the trailing slash were present. In this case, it
- SHOULD return a Content-Location header in the response, pointing to
- the URL ending with the "/". For example, if a client invokes a
- method on http://example.com/blah (no trailing slash), the server may
- respond as if the operation were invoked on http://example.com/blah/
- (trailing slash), and should return a Content-Location header with
- the value http://example.com/blah/. Wherever a server produces a URL
- referring to a collection, the server SHOULD include the trailing
- slash. In general, clients SHOULD use the trailing slash form of
- collection names. If clients do not use the trailing slash form the
- client needs to be prepared to see a redirect response. Clients will
-
-
-
-Dusseault Standards Track [Page 16]
-
-RFC 4918 WebDAV June 2007
-
-
- find the DAV:resourcetype property more reliable than the URL to find
- out if a resource is a collection.
-
- Clients MUST be able to support the case where WebDAV resources are
- contained inside non-WebDAV resources. For example, if an OPTIONS
- response from "http://example.com/servlet/dav/collection" indicates
- WebDAV support, the client cannot assume that
- "http://example.com/servlet/dav/" or its parent necessarily are
- WebDAV collections.
-
- A typical scenario in which mapped URLs do not appear as members of
- their parent collection is the case where a server allows links or
- redirects to non-WebDAV resources. For instance, "/col/link" might
- not appear as a member of "/col/", although the server would respond
- with a 302 status to a GET request to "/col/link"; thus, the URL
- "/col/link" would indeed be mapped. Similarly, a dynamically-
- generated page might have a URL mapping from "/col/index.html", thus
- this resource might respond with a 200 OK to a GET request yet not
- appear as a member of "/col/".
-
- Some mappings to even WebDAV-compliant resources might not appear in
- the parent collection. An example for this case are servers that
- support multiple alias URLs for each WebDAV-compliant resource. A
- server may implement case-insensitive URLs, thus "/col/a" and
- "/col/A" identify the same resource, yet only either "a" or "A" is
- reported upon listing the members of "/col". In cases where a server
- treats a set of segments as equivalent, the server MUST expose only
- one preferred segment per mapping, consistently chosen, in PROPFIND
- responses.
-
-6. Locking
-
- The ability to lock a resource provides a mechanism for serializing
- access to that resource. Using a lock, an authoring client can
- provide a reasonable guarantee that another principal will not modify
- a resource while it is being edited. In this way, a client can
- prevent the "lost update" problem.
-
- This specification allows locks to vary over two client-specified
- parameters, the number of principals involved (exclusive vs. shared)
- and the type of access to be granted. This document defines locking
- for only one access type, write. However, the syntax is extensible,
- and permits the eventual specification of locking for other access
- types.
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 17]
-
-RFC 4918 WebDAV June 2007
-
-
-6.1. Lock Model
-
- This section provides a concise model for how locking behaves. Later
- sections will provide more detail on some of the concepts and refer
- back to these model statements. Normative statements related to LOCK
- and UNLOCK method handling can be found in the sections on those
- methods, whereas normative statements that cover any method are
- gathered here.
-
- 1. A lock either directly or indirectly locks a resource.
-
- 2. A resource becomes directly locked when a LOCK request to a URL
- of that resource creates a new lock. The "lock-root" of the new
- lock is that URL. If at the time of the request, the URL is not
- mapped to a resource, a new empty resource is created and
- directly locked.
-
- 3. An exclusive lock (Section 6.2) conflicts with any other kind of
- lock on the same resource, whether either lock is direct or
- indirect. A server MUST NOT create conflicting locks on a
- resource.
-
- 4. For a collection that is locked with a depth-infinity lock L, all
- member resources are indirectly locked. Changes in membership of
- such a collection affect the set of indirectly locked resources:
-
- * If a member resource is added to the collection, the new
- member resource MUST NOT already have a conflicting lock,
- because the new resource MUST become indirectly locked by L.
-
- * If a member resource stops being a member of the collection,
- then the resource MUST no longer be indirectly locked by L.
-
- 5. Each lock is identified by a single globally unique lock token
- (Section 6.5).
-
- 6. An UNLOCK request deletes the lock with the specified lock token.
- After a lock is deleted, no resource is locked by that lock.
-
- 7. A lock token is "submitted" in a request when it appears in an
- "If" header (Section 7, "Write Lock", discusses when token
- submission is required for write locks).
-
- 8. If a request causes the lock-root of any lock to become an
- unmapped URL, then the lock MUST also be deleted by that request.
-
-
-
-
-
-
-Dusseault Standards Track [Page 18]
-
-RFC 4918 WebDAV June 2007
-
-
-6.2. Exclusive vs. Shared Locks
-
- The most basic form of lock is an exclusive lock. Exclusive locks
- avoid having to deal with content change conflicts, without requiring
- any coordination other than the methods described in this
- specification.
-
- However, there are times when the goal of a lock is not to exclude
- others from exercising an access right but rather to provide a
- mechanism for principals to indicate that they intend to exercise
- their access rights. Shared locks are provided for this case. A
- shared lock allows multiple principals to receive a lock. Hence any
- principal that has both access privileges and a valid lock can use
- the locked resource.
-
- With shared locks, there are two trust sets that affect a resource.
- The first trust set is created by access permissions. Principals who
- are trusted, for example, may have permission to write to the
- resource. Among those who have access permission to write to the
- resource, the set of principals who have taken out a shared lock also
- must trust each other, creating a (typically) smaller trust set
- within the access permission write set.
-
- Starting with every possible principal on the Internet, in most
- situations the vast majority of these principals will not have write
- access to a given resource. Of the small number who do have write
- access, some principals may decide to guarantee their edits are free
- from overwrite conflicts by using exclusive write locks. Others may
- decide they trust their collaborators will not overwrite their work
- (the potential set of collaborators being the set of principals who
- have write permission) and use a shared lock, which informs their
- collaborators that a principal may be working on the resource.
-
- The WebDAV extensions to HTTP do not need to provide all of the
- communications paths necessary for principals to coordinate their
- activities. When using shared locks, principals may use any out-of-
- band communication channel to coordinate their work (e.g., face-to-
- face interaction, written notes, post-it notes on the screen,
- telephone conversation, email, etc.) The intent of a shared lock is
- to let collaborators know who else may be working on a resource.
-
- Shared locks are included because experience from Web-distributed
- authoring systems has indicated that exclusive locks are often too
- rigid. An exclusive lock is used to enforce a particular editing
- process: take out an exclusive lock, read the resource, perform
- edits, write the resource, release the lock. This editing process
- has the problem that locks are not always properly released, for
- example, when a program crashes or when a lock creator leaves without
-
-
-
-Dusseault Standards Track [Page 19]
-
-RFC 4918 WebDAV June 2007
-
-
- unlocking a resource. While both timeouts (Section 6.6) and
- administrative action can be used to remove an offending lock,
- neither mechanism may be available when needed; the timeout may be
- long or the administrator may not be available.
-
- A successful request for a new shared lock MUST result in the
- generation of a unique lock associated with the requesting principal.
- Thus, if five principals have taken out shared write locks on the
- same resource, there will be five locks and five lock tokens, one for
- each principal.
-
-6.3. Required Support
-
- A WebDAV-compliant resource is not required to support locking in any
- form. If the resource does support locking, it may choose to support
- any combination of exclusive and shared locks for any access types.
-
- The reason for this flexibility is that locking policy strikes to the
- very heart of the resource management and versioning systems employed
- by various storage repositories. These repositories require control
- over what sort of locking will be made available. For example, some
- repositories only support shared write locks, while others only
- provide support for exclusive write locks, while yet others use no
- locking at all. As each system is sufficiently different to merit
- exclusion of certain locking features, this specification leaves
- locking as the sole axis of negotiation within WebDAV.
-
-6.4. Lock Creator and Privileges
-
- The creator of a lock has special privileges to use the lock to
- modify the resource. When a locked resource is modified, a server
- MUST check that the authenticated principal matches the lock creator
- (in addition to checking for valid lock token submission).
-
- The server MAY allow privileged users other than the lock creator to
- destroy a lock (for example, the resource owner or an administrator).
- The 'unlock' privilege in [RFC3744] was defined to provide that
- permission.
-
- There is no requirement for servers to accept LOCK requests from all
- users or from anonymous users.
-
- Note that having a lock does not confer full privilege to modify the
- locked resource. Write access and other privileges MUST be enforced
- through normal privilege or authentication mechanisms, not based on
- the possible obscurity of lock token values.
-
-
-
-
-
-Dusseault Standards Track [Page 20]
-
-RFC 4918 WebDAV June 2007
-
-
-6.5. Lock Tokens
-
- A lock token is a type of state token that identifies a particular
- lock. Each lock has exactly one unique lock token generated by the
- server. Clients MUST NOT attempt to interpret lock tokens in any
- way.
-
- Lock token URIs MUST be unique across all resources for all time.
- This uniqueness constraint allows lock tokens to be submitted across
- resources and servers without fear of confusion. Since lock tokens
- are unique, a client MAY submit a lock token in an If header on a
- resource other than the one that returned it.
-
- When a LOCK operation creates a new lock, the new lock token is
- returned in the Lock-Token response header defined in Section 10.5,
- and also in the body of the response.
-
- Servers MAY make lock tokens publicly readable (e.g., in the DAV:
- lockdiscovery property). One use case for making lock tokens
- readable is so that a long-lived lock can be removed by the resource
- owner (the client that obtained the lock might have crashed or
- disconnected before cleaning up the lock). Except for the case of
- using UNLOCK under user guidance, a client SHOULD NOT use a lock
- token created by another client instance.
-
- This specification encourages servers to create Universally Unique
- Identifiers (UUIDs) for lock tokens, and to use the URI form defined
- by "A Universally Unique Identifier (UUID) URN Namespace"
- ([RFC4122]). However, servers are free to use any URI (e.g., from
- another scheme) so long as it meets the uniqueness requirements. For
- example, a valid lock token might be constructed using the
- "opaquelocktoken" scheme defined in Appendix C.
-
- Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
-
-6.6. Lock Timeout
-
- A lock MAY have a limited lifetime. The lifetime is suggested by the
- client when creating or refreshing the lock, but the server
- ultimately chooses the timeout value. Timeout is measured in seconds
- remaining until lock expiration.
-
- The timeout counter MUST be restarted if a refresh lock request is
- successful (see Section 9.10.2). The timeout counter SHOULD NOT be
- restarted at any other time.
-
- If the timeout expires, then the lock SHOULD be removed. In this
- case the server SHOULD act as if an UNLOCK method was executed by the
-
-
-
-Dusseault Standards Track [Page 21]
-
-RFC 4918 WebDAV June 2007
-
-
- server on the resource using the lock token of the timed-out lock,
- performed with its override authority.
-
- Servers are advised to pay close attention to the values submitted by
- clients, as they will be indicative of the type of activity the
- client intends to perform. For example, an applet running in a
- browser may need to lock a resource, but because of the instability
- of the environment within which the applet is running, the applet may
- be turned off without warning. As a result, the applet is likely to
- ask for a relatively small timeout value so that if the applet dies,
- the lock can be quickly harvested. However, a document management
- system is likely to ask for an extremely long timeout because its
- user may be planning on going offline.
-
- A client MUST NOT assume that just because the timeout has expired,
- the lock has immediately been removed.
-
- Likewise, a client MUST NOT assume that just because the timeout has
- not expired, the lock still exists. Clients MUST assume that locks
- can arbitrarily disappear at any time, regardless of the value given
- in the Timeout header. The Timeout header only indicates the
- behavior of the server if extraordinary circumstances do not occur.
- For example, a sufficiently privileged user may remove a lock at any
- time, or the system may crash in such a way that it loses the record
- of the lock's existence.
-
-6.7. Lock Capability Discovery
-
- Since server lock support is optional, a client trying to lock a
- resource on a server can either try the lock and hope for the best,
- or perform some form of discovery to determine what lock capabilities
- the server supports. This is known as lock capability discovery. A
- client can determine what lock types the server supports by
- retrieving the DAV:supportedlock property.
-
- Any DAV-compliant resource that supports the LOCK method MUST support
- the DAV:supportedlock property.
-
-6.8. Active Lock Discovery
-
- If another principal locks a resource that a principal wishes to
- access, it is useful for the second principal to be able to find out
- who the first principal is. For this purpose the DAV:lockdiscovery
- property is provided. This property lists all outstanding locks,
- describes their type, and MAY even provide the lock tokens.
-
- Any DAV-compliant resource that supports the LOCK method MUST support
- the DAV:lockdiscovery property.
-
-
-
-Dusseault Standards Track [Page 22]
-
-RFC 4918 WebDAV June 2007
-
-
-7. Write Lock
-
- This section describes the semantics specific to the write lock type.
- The write lock is a specific instance of a lock type, and is the only
- lock type described in this specification.
-
- An exclusive write lock protects a resource: it prevents changes by
- any principal other than the lock creator and in any case where the
- lock token is not submitted (e.g., by a client process other than the
- one holding the lock).
-
- Clients MUST submit a lock-token they are authorized to use in any
- request that modifies a write-locked resource. The list of
- modifications covered by a write-lock include:
-
- 1. A change to any of the following aspects of any write-locked
- resource:
-
- * any variant,
-
- * any dead property,
-
- * any live property that is lockable (a live property is
- lockable unless otherwise defined.)
-
- 2. For collections, any modification of an internal member URI. An
- internal member URI of a collection is considered to be modified
- if it is added, removed, or identifies a different resource.
- More discussion on write locks and collections is found in
- Section 7.4.
-
- 3. A modification of the mapping of the root of the write lock,
- either to another resource or to no resource (e.g., DELETE).
-
- Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH,
- LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and
- MKCOL are affected by write locks. All other HTTP/WebDAV methods
- defined so far -- GET in particular -- function independently of a
- write lock.
-
- The next few sections describe in more specific terms how write locks
- interact with various operations.
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 23]
-
-RFC 4918 WebDAV June 2007
-
-
-7.1. Write Locks and Properties
-
- While those without a write lock may not alter a property on a
- resource it is still possible for the values of live properties to
- change, even while locked, due to the requirements of their schemas.
- Only dead properties and live properties defined as lockable are
- guaranteed not to change while write locked.
-
-7.2. Avoiding Lost Updates
-
- Although the write locks provide some help in preventing lost
- updates, they cannot guarantee that updates will never be lost.
- Consider the following scenario:
-
- Two clients A and B are interested in editing the resource
- 'index.html'. Client A is an HTTP client rather than a WebDAV
- client, and so does not know how to perform locking.
-
- Client A doesn't lock the document, but does a GET, and begins
- editing.
-
- Client B does LOCK, performs a GET and begins editing.
-
- Client B finishes editing, performs a PUT, then an UNLOCK.
-
- Client A performs a PUT, overwriting and losing all of B's changes.
-
- There are several reasons why the WebDAV protocol itself cannot
- prevent this situation. First, it cannot force all clients to use
- locking because it must be compatible with HTTP clients that do not
- comprehend locking. Second, it cannot require servers to support
- locking because of the variety of repository implementations, some of
- which rely on reservations and merging rather than on locking.
- Finally, being stateless, it cannot enforce a sequence of operations
- like LOCK / GET / PUT / UNLOCK.
-
- WebDAV servers that support locking can reduce the likelihood that
- clients will accidentally overwrite each other's changes by requiring
- clients to lock resources before modifying them. Such servers would
- effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
- resources.
-
- WebDAV clients can be good citizens by using a lock / retrieve /
- write /unlock sequence of operations (at least by default) whenever
- they interact with a WebDAV server that supports locking.
-
-
-
-
-
-
-Dusseault Standards Track [Page 24]
-
-RFC 4918 WebDAV June 2007
-
-
- HTTP 1.1 clients can be good citizens, avoiding overwriting other
- clients' changes, by using entity tags in If-Match headers with any
- requests that would modify resources.
-
- Information managers may attempt to prevent overwrites by
- implementing client-side procedures requiring locking before
- modifying WebDAV resources.
-
-7.3. Write Locks and Unmapped URLs
-
- WebDAV provides the ability to send a LOCK request to an unmapped URL
- in order to reserve the name for use. This is a simple way to avoid
- the lost-update problem on the creation of a new resource (another
- way is to use If-None-Match header specified in Section 14.26 of
- [RFC2616]). It has the side benefit of locking the new resource
- immediately for use of the creator.
-
- Note that the lost-update problem is not an issue for collections
- because MKCOL can only be used to create a collection, not to
- overwrite an existing collection. When trying to lock a collection
- upon creation, clients can attempt to increase the likelihood of
- getting the lock by pipelining the MKCOL and LOCK requests together
- (but because this doesn't convert two separate operations into one
- atomic operation, there's no guarantee this will work).
-
- A successful lock request to an unmapped URL MUST result in the
- creation of a locked (non-collection) resource with empty content.
- Subsequently, a successful PUT request (with the correct lock token)
- provides the content for the resource. Note that the LOCK request
- has no mechanism for the client to provide Content-Type or Content-
- Language, thus the server will use defaults or empty values and rely
- on the subsequent PUT request for correct values.
-
- A resource created with a LOCK is empty but otherwise behaves in
- every way as a normal resource. It behaves the same way as a
- resource created by a PUT request with an empty body (and where a
- Content-Type and Content-Language was not specified), followed by a
- LOCK request to the same resource. Following from this model, a
- locked empty resource:
-
- o Can be read, deleted, moved, and copied, and in all ways behaves
- as a regular non-collection resource.
-
- o Appears as a member of its parent collection.
-
- o SHOULD NOT disappear when its lock goes away (clients must
- therefore be responsible for cleaning up their own mess, as with
- any other operation or any non-empty resource).
-
-
-
-Dusseault Standards Track [Page 25]
-
-RFC 4918 WebDAV June 2007
-
-
- o MAY NOT have values for properties like DAV:getcontentlanguage
- that haven't been specified yet by the client.
-
- o Can be updated (have content added) with a PUT request.
-
- o MUST NOT be converted into a collection. The server MUST fail a
- MKCOL request (as it would with a MKCOL request to any existing
- non-collection resource).
-
- o MUST have defined values for DAV:lockdiscovery and DAV:
- supportedlock properties.
-
- o The response MUST indicate that a resource was created, by use of
- the "201 Created" response code (a LOCK request to an existing
- resource instead will result in 200 OK). The body must still
- include the DAV:lockdiscovery property, as with a LOCK request to
- an existing resource.
-
- The client is expected to update the locked empty resource shortly
- after locking it, using PUT and possibly PROPPATCH.
-
- Alternatively and for backwards compatibility to [RFC2518], servers
- MAY implement Lock-Null Resources (LNRs) instead (see definition in
- Appendix D). Clients can easily interoperate both with servers that
- support the old model LNRs and the recommended model of "locked empty
- resources" by only attempting PUT after a LOCK to an unmapped URL,
- not MKCOL or GET, and by not relying on specific properties of LNRs.
-
-7.4. Write Locks and Collections
-
- There are two kinds of collection write locks. A depth-0 write lock
- on a collection protects the collection properties plus the internal
- member URLs of that one collection, while not protecting the content
- or properties of member resources (if the collection itself has any
- entity bodies, those are also protected). A depth-infinity write
- lock on a collection provides the same protection on that collection
- and also provides write lock protection on every member resource.
-
- Expressed otherwise, a write lock of either kind protects any request
- that would create a new resource in a write locked collection, any
- request that would remove an internal member URL of a write locked
- collection, and any request that would change the segment name of any
- internal member.
-
- Thus, a collection write lock protects all the following actions:
-
- o DELETE a collection's direct internal member,
-
-
-
-
-Dusseault Standards Track [Page 26]
-
-RFC 4918 WebDAV June 2007
-
-
- o MOVE an internal member out of the collection,
-
- o MOVE an internal member into the collection,
-
- o MOVE to rename an internal member within a collection,
-
- o COPY an internal member into a collection, and
-
- o PUT or MKCOL request that would create a new internal member.
-
- The collection's lock token is required in addition to the lock token
- on the internal member itself, if it is locked separately.
-
- In addition, a depth-infinity lock affects all write operations to
- all members of the locked collection. With a depth-infinity lock,
- the resource identified by the root of the lock is directly locked,
- and all its members are indirectly locked.
-
- o Any new resource added as a descendant of a depth-infinity locked
- collection becomes indirectly locked.
-
- o Any indirectly locked resource moved out of the locked collection
- into an unlocked collection is thereafter unlocked.
-
- o Any indirectly locked resource moved out of a locked source
- collection into a depth-infinity locked target collection remains
- indirectly locked but is now protected by the lock on the target
- collection (the target collection's lock token will thereafter be
- required to make further changes).
-
- If a depth-infinity write LOCK request is issued to a collection
- containing member URLs identifying resources that are currently
- locked in a manner that conflicts with the new lock (see Section 6.1,
- point 3), the request MUST fail with a 423 (Locked) status code, and
- the response SHOULD contain the 'no-conflicting-lock' precondition.
-
- If a lock request causes the URL of a resource to be added as an
- internal member URL of a depth-infinity locked collection, then the
- new resource MUST be automatically protected by the lock. For
- example, if the collection /a/b/ is write locked and the resource /c
- is moved to /a/b/c, then resource /a/b/c will be added to the write
- lock.
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 27]
-
-RFC 4918 WebDAV June 2007
-
-
-7.5. Write Locks and the If Request Header
-
- A user agent has to demonstrate knowledge of a lock when requesting
- an operation on a locked resource. Otherwise, the following scenario
- might occur. In the scenario, program A, run by User A, takes out a
- write lock on a resource. Program B, also run by User A, has no
- knowledge of the lock taken out by program A, yet performs a PUT to
- the locked resource. In this scenario, the PUT succeeds because
- locks are associated with a principal, not a program, and thus
- program B, because it is acting with principal A's credential, is
- allowed to perform the PUT. However, had program B known about the
- lock, it would not have overwritten the resource, preferring instead
- to present a dialog box describing the conflict to the user. Due to
- this scenario, a mechanism is needed to prevent different programs
- from accidentally ignoring locks taken out by other programs with the
- same authorization.
-
- In order to prevent these collisions, a lock token MUST be submitted
- by an authorized principal for all locked resources that a method may
- change or the method MUST fail. A lock token is submitted when it
- appears in an If header. For example, if a resource is to be moved
- and both the source and destination are locked, then two lock tokens
- must be submitted in the If header, one for the source and the other
- for the destination.
-
-7.5.1. Example - Write Lock and COPY
-
- >>Request
-
- COPY /~fielding/index.html HTTP/1.1
- Host: www.example.com
- Destination: http://www.example.com/users/f/fielding/index.html
- If: <http://www.example.com/users/f/fielding/index.html>
- (<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
-
- >>Response
-
- HTTP/1.1 204 No Content
-
- In this example, even though both the source and destination are
- locked, only one lock token must be submitted (the one for the lock
- on the destination). This is because the source resource is not
- modified by a COPY, and hence unaffected by the write lock. In this
- example, user agent authentication has previously occurred via a
- mechanism outside the scope of the HTTP protocol, in the underlying
- transport layer.
-
-
-
-
-
-Dusseault Standards Track [Page 28]
-
-RFC 4918 WebDAV June 2007
-
-
-7.5.2. Example - Deleting a Member of a Locked Collection
-
- Consider a collection "/locked" with an exclusive, depth-infinity
- write lock, and an attempt to delete an internal member "/locked/
- member":
-
- >>Request
-
- DELETE /locked/member HTTP/1.1
- Host: example.com
-
- >>Response
-
- HTTP/1.1 423 Locked
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:error xmlns:D="DAV:">
- <D:lock-token-submitted>
- <D:href>/locked/</D:href>
- </D:lock-token-submitted>
- </D:error>
-
- Thus, the client would need to submit the lock token with the request
- to make it succeed. To do that, various forms of the If header (see
- Section 10.4) could be used.
-
- "No-Tag-List" format:
-
- If: (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
-
- "Tagged-List" format, for "http://example.com/locked/":
-
- If: <http://example.com/locked/>
- (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
-
- "Tagged-List" format, for "http://example.com/locked/member":
-
- If: <http://example.com/locked/member>
- (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
-
- Note that, for the purpose of submitting the lock token, the actual
- form doesn't matter; what's relevant is that the lock token appears
- in the If header, and that the If header itself evaluates to true.
-
-
-
-
-
-
-Dusseault Standards Track [Page 29]
-
-RFC 4918 WebDAV June 2007
-
-
-7.6. Write Locks and COPY/MOVE
-
- A COPY method invocation MUST NOT duplicate any write locks active on
- the source. However, as previously noted, if the COPY copies the
- resource into a collection that is locked with a depth-infinity lock,
- then the resource will be added to the lock.
-
- A successful MOVE request on a write locked resource MUST NOT move
- the write lock with the resource. However, if there is an existing
- lock at the destination, the server MUST add the moved resource to
- the destination lock scope. For example, if the MOVE makes the
- resource a child of a collection that has a depth-infinity lock, then
- the resource will be added to that collection's lock. Additionally,
- if a resource with a depth-infinity lock is moved to a destination
- that is within the scope of the same lock (e.g., within the URL
- namespace tree covered by the lock), the moved resource will again be
- added to the lock. In both these examples, as specified in
- Section 7.5, an If header must be submitted containing a lock token
- for both the source and destination.
-
-7.7. Refreshing Write Locks
-
- A client MUST NOT submit the same write lock request twice. Note
- that a client is always aware it is resubmitting the same lock
- request because it must include the lock token in the If header in
- order to make the request for a resource that is already locked.
-
- However, a client may submit a LOCK request with an If header but
- without a body. A server receiving a LOCK request with no body MUST
- NOT create a new lock -- this form of the LOCK request is only to be
- used to "refresh" an existing lock (meaning, at minimum, that any
- timers associated with the lock MUST be reset).
-
- Clients may submit Timeout headers of arbitrary value with their lock
- refresh requests. Servers, as always, may ignore Timeout headers
- submitted by the client, and a server MAY refresh a lock with a
- timeout period that is different than the previous timeout period
- used for the lock, provided it advertises the new value in the LOCK
- refresh response.
-
- If an error is received in response to a refresh LOCK request, the
- client MUST NOT assume that the lock was refreshed.
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 30]
-
-RFC 4918 WebDAV June 2007
-
-
-8. General Request and Response Handling
-
-8.1. Precedence in Error Handling
-
- Servers MUST return authorization errors in preference to other
- errors. This avoids leaking information about protected resources
- (e.g., a client that finds that a hidden resource exists by seeing a
- 423 Locked response to an anonymous request to the resource).
-
-8.2. Use of XML
-
- In HTTP/1.1, method parameter information was exclusively encoded in
- HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
- information either in an XML ([REC-XML]) request entity body, or in
- an HTTP header. The use of XML to encode method parameters was
- motivated by the ability to add extra XML elements to existing
- structures, providing extensibility; and by XML's ability to encode
- information in ISO 10646 character sets, providing
- internationalization support.
-
- In addition to encoding method parameters, XML is used in WebDAV to
- encode the responses from methods, providing the extensibility and
- internationalization advantages of XML for method output, as well as
- input.
-
- When XML is used for a request or response body, the Content-Type
- type SHOULD be application/xml. Implementations MUST accept both
- text/xml and application/xml in request and response bodies. Use of
- text/xml is deprecated.
-
- All DAV-compliant clients and resources MUST use XML parsers that are
- compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either
- requests or responses MUST be, at minimum, well formed and use
- namespaces correctly. If a server receives XML that is not well-
- formed, then the server MUST reject the entire request with a 400
- (Bad Request). If a client receives XML that is not well-formed in a
- response, then the client MUST NOT assume anything about the outcome
- of the executed method and SHOULD treat the server as malfunctioning.
-
- Note that processing XML submitted by an untrusted source may cause
- risks connected to privacy, security, and service quality (see
- Section 20). Servers MAY reject questionable requests (even though
- they consist of well-formed XML), for instance, with a 400 (Bad
- Request) status code and an optional response body explaining the
- problem.
-
-
-
-
-
-
-Dusseault Standards Track [Page 31]
-
-RFC 4918 WebDAV June 2007
-
-
-8.3. URL Handling
-
- URLs appear in many places in requests and responses.
- Interoperability experience with [RFC2518] showed that many clients
- parsing Multi-Status responses did not fully implement the full
- Reference Resolution defined in Section 5 of [RFC3986]. Thus,
- servers in particular need to be careful in handling URLs in
- responses, to ensure that clients have enough context to be able to
- interpret all the URLs. The rules in this section apply not only to
- resource URLs in the 'href' element in Multi-Status responses, but
- also to the Destination and If header resource URLs.
-
- The sender has a choice between two approaches: using a relative
- reference, which is resolved against the Request-URI, or a full URI.
- A server MUST ensure that every 'href' value within a Multi-Status
- response uses the same format.
-
- WebDAV only uses one form of relative reference in its extensions,
- the absolute path.
-
- Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )
-
- The absolute-URI, path-absolute and query productions are defined in
- Sections 4.3, 3.3, and 3.4 of [RFC3986].
-
- Within Simple-ref productions, senders MUST NOT:
-
- o use dot-segments ("." or ".."), or
-
- o have prefixes that do not match the Request-URI (using the
- comparison rules defined in Section 3.2.3 of [RFC2616]).
-
- Identifiers for collections SHOULD end in a '/' character.
-
-8.3.1. Example - Correct URL Handling
-
- Consider the collection http://example.com/sample/ with the internal
- member URL http://example.com/sample/a%20test and the PROPFIND
- request below:
-
- >>Request:
-
- PROPFIND /sample/ HTTP/1.1
- Host: example.com
- Depth: 1
-
-
-
-
-
-
-Dusseault Standards Track [Page 32]
-
-RFC 4918 WebDAV June 2007
-
-
- In this case, the server should return two 'href' elements containing
- either
-
- o 'http://example.com/sample/' and
- 'http://example.com/sample/a%20test', or
-
- o '/sample/' and '/sample/a%20test'
-
- Note that even though the server may be storing the member resource
- internally as 'a test', it has to be percent-encoded when used inside
- a URI reference (see Section 2.1 of [RFC3986]). Also note that a
- legal URI may still contain characters that need to be escaped within
- XML character data, such as the ampersand character.
-
-8.4. Required Bodies in Requests
-
- Some of these new methods do not define bodies. Servers MUST examine
- all requests for a body, even when a body was not expected. In cases
- where a request body is present but would be ignored by a server, the
- server MUST reject the request with 415 (Unsupported Media Type).
- This informs the client (which may have been attempting to use an
- extension) that the body could not be processed as the client
- intended.
-
-8.5. HTTP Headers for Use in WebDAV
-
- HTTP defines many headers that can be used in WebDAV requests and
- responses. Not all of these are appropriate in all situations and
- some interactions may be undefined. Note that HTTP 1.1 requires the
- Date header in all responses if possible (see Section 14.18,
- [RFC2616]).
-
- The server MUST do authorization checks before checking any HTTP
- conditional header.
-
-8.6. ETag
-
- HTTP 1.1 recommends the use of ETags rather than modification dates,
- for cache control, and there are even stronger reasons to prefer
- ETags for authoring. Correct use of ETags is even more important in
- a distributed authoring environment, because ETags are necessary
- along with locks to avoid the lost-update problem. A client might
- fail to renew a lock, for example, when the lock times out and the
- client is accidentally offline or in the middle of a long upload.
- When a client fails to renew the lock, it's quite possible the
- resource can still be relocked and the user can go on editing, as
- long as no changes were made in the meantime. ETags are required for
- the client to be able to distinguish this case. Otherwise, the
-
-
-
-Dusseault Standards Track [Page 33]
-
-RFC 4918 WebDAV June 2007
-
-
- client is forced to ask the user whether to overwrite the resource on
- the server without even being able to tell the user if it has
- changed. Timestamps do not solve this problem nearly as well as
- ETags.
-
- Strong ETags are much more useful for authoring use cases than weak
- ETags (see Section 13.3.3 of [RFC2616]). Semantic equivalence can be
- a useful concept but that depends on the document type and the
- application type, and interoperability might require some agreement
- or standard outside the scope of this specification and HTTP. Note
- also that weak ETags have certain restrictions in HTTP, e.g., these
- cannot be used in If-Match headers.
-
- Note that the meaning of an ETag in a PUT response is not clearly
- defined either in this document or in RFC 2616 (i.e., whether the
- ETag means that the resource is octet-for-octet equivalent to the
- body of the PUT request, or whether the server could have made minor
- changes in the formatting or content of the document upon storage).
- This is an HTTP issue, not purely a WebDAV issue.
-
- Because clients may be forced to prompt users or throw away changed
- content if the ETag changes, a WebDAV server SHOULD NOT change the
- ETag (or the Last-Modified time) for a resource that has an unchanged
- body and location. The ETag represents the state of the body or
- contents of the resource. There is no similar way to tell if
- properties have changed.
-
-8.7. Including Error Response Bodies
-
- HTTP and WebDAV did not use the bodies of most error responses for
- machine-parsable information until the specification for Versioning
- Extensions to WebDAV introduced a mechanism to include more specific
- information in the body of an error response (Section 1.6 of
- [RFC3253]). The error body mechanism is appropriate to use with any
- error response that may take a body but does not already have a body
- defined. The mechanism is particularly appropriate when a status
- code can mean many things (for example, 400 Bad Request can mean
- required headers are missing, headers are incorrectly formatted, or
- much more). This error body mechanism is covered in Section 16.
-
-8.8. Impact of Namespace Operations on Cache Validators
-
- Note that the HTTP response headers "Etag" and "Last-Modified" (see
- [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per
- resource), and are used by clients for caching. Therefore servers
- must ensure that executing any operation that affects the URL
- namespace (such as COPY, MOVE, DELETE, PUT, or MKCOL) does preserve
- their semantics, in particular:
-
-
-
-Dusseault Standards Track [Page 34]
-
-RFC 4918 WebDAV June 2007
-
-
- o For any given URL, the "Last-Modified" value MUST increment every
- time the representation returned upon GET changes (within the
- limits of timestamp resolution).
-
- o For any given URL, an "ETag" value MUST NOT be reused for
- different representations returned by GET.
-
- In practice this means that servers
-
- o might have to increment "Last-Modified" timestamps for every
- resource inside the destination namespace of a namespace operation
- unless it can do so more selectively, and
-
- o similarly, might have to re-assign "ETag" values for these
- resources (unless the server allocates entity tags in a way so
- that they are unique across the whole URL namespace managed by the
- server).
-
- Note that these considerations also apply to specific use cases, such
- as using PUT to create a new resource at a URL that has been mapped
- before, but has been deleted since then.
-
- Finally, WebDAV properties (such as DAV:getetag and DAV:
- getlastmodified) that inherit their semantics from HTTP headers must
- behave accordingly.
-
-9. HTTP Methods for Distributed Authoring
-
-9.1. PROPFIND Method
-
- The PROPFIND method retrieves properties defined on the resource
- identified by the Request-URI, if the resource does not have any
- internal members, or on the resource identified by the Request-URI
- and potentially its member resources, if the resource is a collection
- that has internal member URLs. All DAV-compliant resources MUST
- support the PROPFIND method and the propfind XML element
- (Section 14.20) along with all XML elements defined for use with that
- element.
-
- A client MUST submit a Depth header with a value of "0", "1", or
- "infinity" with a PROPFIND request. Servers MUST support "0" and "1"
- depth requests on WebDAV-compliant resources and SHOULD support
- "infinity" requests. In practice, support for infinite-depth
- requests MAY be disabled, due to the performance and security
- concerns associated with this behavior. Servers SHOULD treat a
- request without a Depth header as if a "Depth: infinity" header was
- included.
-
-
-
-
-Dusseault Standards Track [Page 35]
-
-RFC 4918 WebDAV June 2007
-
-
- A client may submit a 'propfind' XML element in the body of the
- request method describing what information is being requested. It is
- possible to:
-
- o Request particular property values, by naming the properties
- desired within the 'prop' element (the ordering of properties in
- here MAY be ignored by the server),
-
- o Request property values for those properties defined in this
- specification (at a minimum) plus dead properties, by using the
- 'allprop' element (the 'include' element can be used with
- 'allprop' to instruct the server to also include additional live
- properties that may not have been returned otherwise),
-
- o Request a list of names of all the properties defined on the
- resource, by using the 'propname' element.
-
- A client may choose not to submit a request body. An empty PROPFIND
- request body MUST be treated as if it were an 'allprop' request.
-
- Note that 'allprop' does not return values for all live properties.
- WebDAV servers increasingly have expensively-calculated or lengthy
- properties (see [RFC3253] and [RFC3744]) and do not return all
- properties already. Instead, WebDAV clients can use propname
- requests to discover what live properties exist, and request named
- properties when retrieving values. For a live property defined
- elsewhere, that definition can specify whether or not that live
- property would be returned in 'allprop' requests.
-
- All servers MUST support returning a response of content type text/
- xml or application/xml that contains a multistatus XML element that
- describes the results of the attempts to retrieve the various
- properties.
-
- If there is an error retrieving a property, then a proper error
- result MUST be included in the response. A request to retrieve the
- value of a property that does not exist is an error and MUST be noted
- with a 'response' XML element that contains a 404 (Not Found) status
- value.
-
- Consequently, the 'multistatus' XML element for a collection resource
- MUST include a 'response' XML element for each member URL of the
- collection, to whatever depth was requested. It SHOULD NOT include
- any 'response' elements for resources that are not WebDAV-compliant.
- Each 'response' element MUST contain an 'href' element that contains
- the URL of the resource on which the properties in the prop XML
- element are defined. Results for a PROPFIND on a collection resource
- are returned as a flat list whose order of entries is not
-
-
-
-Dusseault Standards Track [Page 36]
-
-RFC 4918 WebDAV June 2007
-
-
- significant. Note that a resource may have only one value for a
- property of a given name, so the property may only show up once in
- PROPFIND responses.
-
- Properties may be subject to access control. In the case of
- 'allprop' and 'propname' requests, if a principal does not have the
- right to know whether a particular property exists, then the property
- MAY be silently excluded from the response.
-
- Some PROPFIND results MAY be cached, with care, as there is no cache
- validation mechanism for most properties. This method is both safe
- and idempotent (see Section 9.1 of [RFC2616]).
-
-9.1.1. PROPFIND Status Codes
-
- This section, as with similar sections for other methods, provides
- some guidance on error codes and preconditions or postconditions
- (defined in Section 16) that might be particularly useful with
- PROPFIND.
-
- 403 Forbidden - A server MAY reject PROPFIND requests on collections
- with depth header of "Infinity", in which case it SHOULD use this
- error with the precondition code 'propfind-finite-depth' inside the
- error body.
-
-9.1.2. Status Codes for Use in 'propstat' Element
-
- In PROPFIND responses, information about individual properties is
- returned inside 'propstat' elements (see Section 14.22), each
- containing an individual 'status' element containing information
- about the properties appearing in it. The list below summarizes the
- most common status codes used inside 'propstat'; however, clients
- should be prepared to handle other 2/3/4/5xx series status codes as
- well.
-
- 200 OK - A property exists and/or its value is successfully returned.
-
- 401 Unauthorized - The property cannot be viewed without appropriate
- authorization.
-
- 403 Forbidden - The property cannot be viewed regardless of
- authentication.
-
- 404 Not Found - The property does not exist.
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 37]
-
-RFC 4918 WebDAV June 2007
-
-
-9.1.3. Example - Retrieving Named Properties
-
- >>Request
-
- PROPFIND /file HTTP/1.1
- Host: www.example.com
- Content-type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:">
- <D:prop xmlns:R="http://ns.example.com/boxschema/">
- <R:bigbox/>
- <R:author/>
- <R:DingALing/>
- <R:Random/>
- </D:prop>
- </D:propfind>
-
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:multistatus xmlns:D="DAV:">
- <D:response xmlns:R="http://ns.example.com/boxschema/">
- <D:href>http://www.example.com/file</D:href>
- <D:propstat>
- <D:prop>
- <R:bigbox>
- <R:BoxType>Box type A</R:BoxType>
- </R:bigbox>
- <R:author>
- <R:Name>J.J. Johnson</R:Name>
- </R:author>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- <D:propstat>
- <D:prop><R:DingALing/><R:Random/></D:prop>
- <D:status>HTTP/1.1 403 Forbidden</D:status>
- <D:responsedescription> The user does not have access to the
- DingALing property.
- </D:responsedescription>
- </D:propstat>
-
-
-
-Dusseault Standards Track [Page 38]
-
-RFC 4918 WebDAV June 2007
-
-
- </D:response>
- <D:responsedescription> There has been an access violation error.
- </D:responsedescription>
- </D:multistatus>
-
-
- In this example, PROPFIND is executed on a non-collection resource
- http://www.example.com/file. The propfind XML element specifies the
- name of four properties whose values are being requested. In this
- case, only two properties were returned, since the principal issuing
- the request did not have sufficient access rights to see the third
- and fourth properties.
-
-9.1.4. Example - Using 'propname' to Retrieve All Property Names
-
- >>Request
-
- PROPFIND /container/ HTTP/1.1
- Host: www.example.com
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <propfind xmlns="DAV:">
- <propname/>
- </propfind>
-
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <multistatus xmlns="DAV:">
- <response>
- <href>http://www.example.com/container/</href>
- <propstat>
- <prop xmlns:R="http://ns.example.com/boxschema/">
- <R:bigbox/>
- <R:author/>
- <creationdate/>
- <displayname/>
- <resourcetype/>
- <supportedlock/>
- </prop>
- <status>HTTP/1.1 200 OK</status>
-
-
-
-Dusseault Standards Track [Page 39]
-
-RFC 4918 WebDAV June 2007
-
-
- </propstat>
- </response>
- <response>
- <href>http://www.example.com/container/front.html</href>
- <propstat>
- <prop xmlns:R="http://ns.example.com/boxschema/">
- <R:bigbox/>
- <creationdate/>
- <displayname/>
- <getcontentlength/>
- <getcontenttype/>
- <getetag/>
- <getlastmodified/>
- <resourcetype/>
- <supportedlock/>
- </prop>
- <status>HTTP/1.1 200 OK</status>
- </propstat>
- </response>
- </multistatus>
-
- In this example, PROPFIND is invoked on the collection resource
- http://www.example.com/container/, with a propfind XML element
- containing the propname XML element, meaning the name of all
- properties should be returned. Since no Depth header is present, it
- assumes its default value of "infinity", meaning the name of the
- properties on the collection and all its descendants should be
- returned.
-
- Consistent with the previous example, resource
- http://www.example.com/container/ has six properties defined on it:
- bigbox and author in the "http://ns.example.com/boxschema/"
- namespace, and creationdate, displayname, resourcetype, and
- supportedlock in the "DAV:" namespace.
-
- The resource http://www.example.com/container/index.html, a member of
- the "container" collection, has nine properties defined on it, bigbox
- in the "http://ns.example.com/boxschema/" namespace and creationdate,
- displayname, getcontentlength, getcontenttype, getetag,
- getlastmodified, resourcetype, and supportedlock in the "DAV:"
- namespace.
-
- This example also demonstrates the use of XML namespace scoping and
- the default namespace. Since the "xmlns" attribute does not contain
- a prefix, the namespace applies by default to all enclosed elements.
- Hence, all elements that do not explicitly state the namespace to
- which they belong are members of the "DAV:" namespace.
-
-
-
-
-Dusseault Standards Track [Page 40]
-
-RFC 4918 WebDAV June 2007
-
-
-9.1.5. Example - Using So-called 'allprop'
-
- Note that 'allprop', despite its name, which remains for backward-
- compatibility, does not return every property, but only dead
- properties and the live properties defined in this specification.
-
- >>Request
-
- PROPFIND /container/ HTTP/1.1
- Host: www.example.com
- Depth: 1
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:">
- <D:allprop/>
- </D:propfind>
-
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:multistatus xmlns:D="DAV:">
- <D:response>
- <D:href>/container/</D:href>
- <D:propstat>
- <D:prop xmlns:R="http://ns.example.com/boxschema/">
- <R:bigbox><R:BoxType>Box type A</R:BoxType></R:bigbox>
- <R:author><R:Name>Hadrian</R:Name></R:author>
- <D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
- <D:displayname>Example collection</D:displayname>
- <D:resourcetype><D:collection/></D:resourcetype>
- <D:supportedlock>
- <D:lockentry>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- <D:lockentry>
- <D:lockscope><D:shared/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- </D:supportedlock>
- </D:prop>
-
-
-
-Dusseault Standards Track [Page 41]
-
-RFC 4918 WebDAV June 2007
-
-
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
- <D:response>
- <D:href>/container/front.html</D:href>
- <D:propstat>
- <D:prop xmlns:R="http://ns.example.com/boxschema/">
- <R:bigbox><R:BoxType>Box type B</R:BoxType>
- </R:bigbox>
- <D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate>
- <D:displayname>Example HTML resource</D:displayname>
- <D:getcontentlength>4525</D:getcontentlength>
- <D:getcontenttype>text/html</D:getcontenttype>
- <D:getetag>"zzyzx"</D:getetag>
- <D:getlastmodified
- >Mon, 12 Jan 1998 09:25:56 GMT</D:getlastmodified>
- <D:resourcetype/>
- <D:supportedlock>
- <D:lockentry>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- <D:lockentry>
- <D:lockscope><D:shared/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- </D:supportedlock>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
- </D:multistatus>
-
- In this example, PROPFIND was invoked on the resource
- http://www.example.com/container/ with a Depth header of 1, meaning
- the request applies to the resource and its children, and a propfind
- XML element containing the allprop XML element, meaning the request
- should return the name and value of all the dead properties defined
- on the resources, plus the name and value of all the properties
- defined in this specification. This example illustrates the use of
- relative references in the 'href' elements of the response.
-
- The resource http://www.example.com/container/ has six properties
- defined on it: 'bigbox' and 'author in the
- "http://ns.example.com/boxschema/" namespace, DAV:creationdate, DAV:
- displayname, DAV:resourcetype, and DAV:supportedlock.
-
-
-
-
-
-Dusseault Standards Track [Page 42]
-
-RFC 4918 WebDAV June 2007
-
-
- The last four properties are WebDAV-specific, defined in Section 15.
- Since GET is not supported on this resource, the get* properties
- (e.g., DAV:getcontentlength) are not defined on this resource. The
- WebDAV-specific properties assert that "container" was created on
- December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT
- (DAV:creationdate), has a name of "Example collection" (DAV:
- displayname), a collection resource type (DAV:resourcetype), and
- supports exclusive write and shared write locks (DAV:supportedlock).
-
- The resource http://www.example.com/container/front.html has nine
- properties defined on it:
-
- 'bigbox' in the "http://ns.example.com/boxschema/" namespace (another
- instance of the "bigbox" property type), DAV:creationdate, DAV:
- displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
- DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
-
- The DAV-specific properties assert that "front.html" was created on
- December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT
- (DAV:creationdate), has a name of "Example HTML resource" (DAV:
- displayname), a content length of 4525 bytes (DAV:getcontentlength),
- a MIME type of "text/html" (DAV:getcontenttype), an entity tag of
- "zzyzx" (DAV:getetag), was last modified on Monday, January 12, 1998,
- at 09:25:56 GMT (DAV:getlastmodified), has an empty resource type,
- meaning that it is not a collection (DAV:resourcetype), and supports
- both exclusive write and shared write locks (DAV:supportedlock).
-
-9.1.6. Example - Using 'allprop' with 'include'
-
- >>Request
-
- PROPFIND /mycol/ HTTP/1.1
- Host: www.example.com
- Depth: 1
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:">
- <D:allprop/>
- <D:include>
- <D:supported-live-property-set/>
- <D:supported-report-set/>
- </D:include>
- </D:propfind>
-
-
-
-
-
-
-Dusseault Standards Track [Page 43]
-
-RFC 4918 WebDAV June 2007
-
-
- In this example, PROPFIND is executed on the resource
- http://www.example.com/mycol/ and its internal member resources. The
- client requests the values of all live properties defined in this
- specification, plus all dead properties, plus two more live
- properties defined in [RFC3253]. The response is not shown.
-
-9.2. PROPPATCH Method
-
- The PROPPATCH method processes instructions specified in the request
- body to set and/or remove properties defined on the resource
- identified by the Request-URI.
-
- All DAV-compliant resources MUST support the PROPPATCH method and
- MUST process instructions that are specified using the
- propertyupdate, set, and remove XML elements. Execution of the
- directives in this method is, of course, subject to access control
- constraints. DAV-compliant resources SHOULD support the setting of
- arbitrary dead properties.
-
- The request message body of a PROPPATCH method MUST contain the
- propertyupdate XML element.
-
- Servers MUST process PROPPATCH instructions in document order (an
- exception to the normal rule that ordering is irrelevant).
- Instructions MUST either all be executed or none executed. Thus, if
- any error occurs during processing, all executed instructions MUST be
- undone and a proper error result returned. Instruction processing
- details can be found in the definition of the set and remove
- instructions in Sections 14.23 and 14.26.
-
- If a server attempts to make any of the property changes in a
- PROPPATCH request (i.e., the request is not rejected for high-level
- errors before processing the body), the response MUST be a Multi-
- Status response as described in Section 9.2.1.
-
- This method is idempotent, but not safe (see Section 9.1 of
- [RFC2616]). Responses to this method MUST NOT be cached.
-
-9.2.1. Status Codes for Use in 'propstat' Element
-
- In PROPPATCH responses, information about individual properties is
- returned inside 'propstat' elements (see Section 14.22), each
- containing an individual 'status' element containing information
- about the properties appearing in it. The list below summarizes the
- most common status codes used inside 'propstat'; however, clients
- should be prepared to handle other 2/3/4/5xx series status codes as
- well.
-
-
-
-
-Dusseault Standards Track [Page 44]
-
-RFC 4918 WebDAV June 2007
-
-
- 200 (OK) - The property set or change succeeded. Note that if this
- appears for one property, it appears for every property in the
- response, due to the atomicity of PROPPATCH.
-
- 403 (Forbidden) - The client, for reasons the server chooses not to
- specify, cannot alter one of the properties.
-
- 403 (Forbidden): The client has attempted to set a protected
- property, such as DAV:getetag. If returning this error, the server
- SHOULD use the precondition code 'cannot-modify-protected-property'
- inside the response body.
-
- 409 (Conflict) - The client has provided a value whose semantics are
- not appropriate for the property.
-
- 424 (Failed Dependency) - The property change could not be made
- because of another property change that failed.
-
- 507 (Insufficient Storage) - The server did not have sufficient space
- to record the property.
-
-9.2.2. Example - PROPPATCH
-
- >>Request
-
- PROPPATCH /bar.html HTTP/1.1
- Host: www.example.com
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propertyupdate xmlns:D="DAV:"
- xmlns:Z="http://ns.example.com/standards/z39.50/">
- <D:set>
- <D:prop>
- <Z:Authors>
- <Z:Author>Jim Whitehead</Z:Author>
- <Z:Author>Roy Fielding</Z:Author>
- </Z:Authors>
- </D:prop>
- </D:set>
- <D:remove>
- <D:prop><Z:Copyright-Owner/></D:prop>
- </D:remove>
- </D:propertyupdate>
-
-
-
-
-
-
-Dusseault Standards Track [Page 45]
-
-RFC 4918 WebDAV June 2007
-
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:multistatus xmlns:D="DAV:"
- xmlns:Z="http://ns.example.com/standards/z39.50/">
- <D:response>
- <D:href>http://www.example.com/bar.html</D:href>
- <D:propstat>
- <D:prop><Z:Authors/></D:prop>
- <D:status>HTTP/1.1 424 Failed Dependency</D:status>
- </D:propstat>
- <D:propstat>
- <D:prop><Z:Copyright-Owner/></D:prop>
- <D:status>HTTP/1.1 409 Conflict</D:status>
- </D:propstat>
- <D:responsedescription> Copyright Owner cannot be deleted or
- altered.</D:responsedescription>
- </D:response>
- </D:multistatus>
-
- In this example, the client requests the server to set the value of
- the "Authors" property in the
- "http://ns.example.com/standards/z39.50/" namespace, and to remove
- the property "Copyright-Owner" in the same namespace. Since the
- Copyright-Owner property could not be removed, no property
- modifications occur. The 424 (Failed Dependency) status code for the
- Authors property indicates this action would have succeeded if it
- were not for the conflict with removing the Copyright-Owner property.
-
-9.3. MKCOL Method
-
- MKCOL creates a new collection resource at the location specified by
- the Request-URI. If the Request-URI is already mapped to a resource,
- then the MKCOL MUST fail. During MKCOL processing, a server MUST
- make the Request-URI an internal member of its parent collection,
- unless the Request-URI is "/". If no such ancestor exists, the
- method MUST fail. When the MKCOL operation creates a new collection
- resource, all ancestors MUST already exist, or the method MUST fail
- with a 409 (Conflict) status code. For example, if a request to
- create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the
- request must fail.
-
- When MKCOL is invoked without a request body, the newly created
- collection SHOULD have no members.
-
-
-
-Dusseault Standards Track [Page 46]
-
-RFC 4918 WebDAV June 2007
-
-
- A MKCOL request message may contain a message body. The precise
- behavior of a MKCOL request when the body is present is undefined,
- but limited to creating collections, members of a collection, bodies
- of members, and properties on the collections or members. If the
- server receives a MKCOL request entity type it does not support or
- understand, it MUST respond with a 415 (Unsupported Media Type)
- status code. If the server decides to reject the request based on
- the presence of an entity or the type of an entity, it should use the
- 415 (Unsupported Media Type) status code.
-
- This method is idempotent, but not safe (see Section 9.1 of
- [RFC2616]). Responses to this method MUST NOT be cached.
-
-9.3.1. MKCOL Status Codes
-
- In addition to the general status codes possible, the following
- status codes have specific applicability to MKCOL:
-
- 201 (Created) - The collection was created.
-
- 403 (Forbidden) - This indicates at least one of two conditions: 1)
- the server does not allow the creation of collections at the given
- location in its URL namespace, or 2) the parent collection of the
- Request-URI exists but cannot accept members.
-
- 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped
- URL.
-
- 409 (Conflict) - A collection cannot be made at the Request-URI until
- one or more intermediate collections have been created. The server
- MUST NOT create those intermediate collections automatically.
-
- 415 (Unsupported Media Type) - The server does not support the
- request body type (although bodies are legal on MKCOL requests, since
- this specification doesn't define any, the server is likely not to
- support any given body type).
-
- 507 (Insufficient Storage) - The resource does not have sufficient
- space to record the state of the resource after the execution of this
- method.
-
-9.3.2. Example - MKCOL
-
- This example creates a collection called /webdisc/xfiles/ on the
- server www.example.com.
-
-
-
-
-
-
-Dusseault Standards Track [Page 47]
-
-RFC 4918 WebDAV June 2007
-
-
- >>Request
-
- MKCOL /webdisc/xfiles/ HTTP/1.1
- Host: www.example.com
-
-
- >>Response
-
- HTTP/1.1 201 Created
-
-9.4. GET, HEAD for Collections
-
- The semantics of GET are unchanged when applied to a collection,
- since GET is defined as, "retrieve whatever information (in the form
- of an entity) is identified by the Request-URI" [RFC2616]. GET, when
- applied to a collection, may return the contents of an "index.html"
- resource, a human-readable view of the contents of the collection, or
- something else altogether. Hence, it is possible that the result of
- a GET on a collection will bear no correlation to the membership of
- the collection.
-
- Similarly, since the definition of HEAD is a GET without a response
- message body, the semantics of HEAD are unmodified when applied to
- collection resources.
-
-9.5. POST for Collections
-
- Since by definition the actual function performed by POST is
- determined by the server and often depends on the particular
- resource, the behavior of POST when applied to collections cannot be
- meaningfully modified because it is largely undefined. Thus, the
- semantics of POST are unmodified when applied to a collection.
-
-9.6. DELETE Requirements
-
- DELETE is defined in [RFC2616], Section 9.7, to "delete the resource
- identified by the Request-URI". However, WebDAV changes some DELETE
- handling requirements.
-
- A server processing a successful DELETE request:
-
- MUST destroy locks rooted on the deleted resource
-
- MUST remove the mapping from the Request-URI to any resource.
-
- Thus, after a successful DELETE operation (and in the absence of
- other actions), a subsequent GET/HEAD/PROPFIND request to the target
- Request-URI MUST return 404 (Not Found).
-
-
-
-Dusseault Standards Track [Page 48]
-
-RFC 4918 WebDAV June 2007
-
-
-9.6.1. DELETE for Collections
-
- The DELETE method on a collection MUST act as if a "Depth: infinity"
- header was used on it. A client MUST NOT submit a Depth header with
- a DELETE on a collection with any value but infinity.
-
- DELETE instructs that the collection specified in the Request-URI and
- all resources identified by its internal member URLs are to be
- deleted.
-
- If any resource identified by a member URL cannot be deleted, then
- all of the member's ancestors MUST NOT be deleted, so as to maintain
- URL namespace consistency.
-
- Any headers included with DELETE MUST be applied in processing every
- resource to be deleted.
-
- When the DELETE method has completed processing, it MUST result in a
- consistent URL namespace.
-
- If an error occurs deleting a member resource (a resource other than
- the resource identified in the Request-URI), then the response can be
- a 207 (Multi-Status). Multi-Status is used here to indicate which
- internal resources could NOT be deleted, including an error code,
- which should help the client understand which resources caused the
- failure. For example, the Multi-Status body could include a response
- with status 423 (Locked) if an internal resource was locked.
-
- The server MAY return a 4xx status response, rather than a 207, if
- the request failed completely.
-
- 424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi-
- Status) response for DELETE. They can be safely left out because the
- client will know that the ancestors of a resource could not be
- deleted when the client receives an error for the ancestor's progeny.
- Additionally, 204 (No Content) errors SHOULD NOT be returned in the
- 207 (Multi-Status). The reason for this prohibition is that 204 (No
- Content) is the default success code.
-
-9.6.2. Example - DELETE
-
- >>Request
-
- DELETE /container/ HTTP/1.1
- Host: www.example.com
-
-
-
-
-
-
-Dusseault Standards Track [Page 49]
-
-RFC 4918 WebDAV June 2007
-
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/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.example.com/container/resource3</d:href>
- <d:status>HTTP/1.1 423 Locked</d:status>
- <d:error><d:lock-token-submitted/></d:error>
- </d:response>
- </d:multistatus>
-
- In this example, the attempt to delete
- http://www.example.com/container/resource3 failed because it is
- locked, and no lock token was submitted with the request.
- Consequently, the attempt to delete http://www.example.com/container/
- also failed. Thus, the client knows that the attempt to delete
- http://www.example.com/container/ must have also failed since the
- parent cannot be deleted unless its child has also been deleted.
- Even though a Depth header has not been included, a depth of infinity
- is assumed because the method is on a collection.
-
-9.7. PUT Requirements
-
-9.7.1. PUT for Non-Collection Resources
-
- A PUT performed on an existing resource replaces the GET response
- entity of the resource. Properties defined on the resource may be
- recomputed during PUT processing but are not otherwise affected. For
- example, if a server recognizes the content type of the request body,
- it may be able to automatically extract information that could be
- profitably exposed as properties.
-
- A PUT that would result in the creation of a resource without an
- appropriately scoped parent collection MUST fail with a 409
- (Conflict).
-
- A PUT request allows a client to indicate what media type an entity
- body has, and whether it should change if overwritten. Thus, a
- client SHOULD provide a Content-Type for a new resource if any is
- known. If the client does not provide a Content-Type for a new
- resource, the server MAY create a resource with no Content-Type
- assigned, or it MAY attempt to assign a Content-Type.
-
-
-
-
-
-Dusseault Standards Track [Page 50]
-
-RFC 4918 WebDAV June 2007
-
-
- Note that although a recipient ought generally to treat metadata
- supplied with an HTTP request as authoritative, in practice there's
- no guarantee that a server will accept client-supplied metadata
- (e.g., any request header beginning with "Content-"). Many servers
- do not allow configuring the Content-Type on a per-resource basis in
- the first place. Thus, clients can't always rely on the ability to
- directly influence the content type by including a Content-Type
- request header.
-
-9.7.2. PUT for Collections
-
- This specification does not define the behavior of the PUT method for
- existing collections. A PUT request to an existing collection MAY be
- treated as an error (405 Method Not Allowed).
-
- The MKCOL method is defined to create collections.
-
-9.8. COPY Method
-
- The COPY method creates a duplicate of the source resource identified
- by the Request-URI, in the destination resource identified by the URI
- in the Destination header. The Destination header MUST be present.
- The exact behavior of the COPY method depends on the type of the
- source resource.
-
- All WebDAV-compliant resources MUST support the COPY method.
- However, support for the COPY method does not guarantee the ability
- to copy a resource. For example, separate programs may control
- resources on the same server. As a result, it may not be possible to
- copy a resource to a location that appears to be on the same server.
-
- This method is idempotent, but not safe (see Section 9.1 of
- [RFC2616]). Responses to this method MUST NOT be cached.
-
-9.8.1. COPY for Non-collection Resources
-
- When the source resource is not a collection, the result of the COPY
- method is the creation of a new resource at the destination whose
- state and behavior match that of the source resource as closely as
- possible. Since the environment at the destination may be different
- than at the source due to factors outside the scope of control of the
- server, such as the absence of resources required for correct
- operation, it may not be possible to completely duplicate the
- behavior of the resource at the destination. Subsequent alterations
- to the destination resource will not modify the source resource.
- Subsequent alterations to the source resource will not modify the
- destination resource.
-
-
-
-
-Dusseault Standards Track [Page 51]
-
-RFC 4918 WebDAV June 2007
-
-
-9.8.2. COPY for Properties
-
- After a successful COPY invocation, all dead properties on the source
- resource SHOULD be duplicated on the destination resource. Live
- properties described in this document SHOULD be duplicated as
- identically behaving live properties at the destination resource, but
- not necessarily with the same values. Servers SHOULD NOT convert
- live properties into dead properties on the destination resource,
- because clients may then draw incorrect conclusions about the state
- or functionality of a resource. Note that some live properties are
- defined such that the absence of the property has a specific meaning
- (e.g., a flag with one meaning if present, and the opposite if
- absent), and in these cases, a successful COPY might result in the
- property being reported as "Not Found" in subsequent requests.
-
- When the destination is an unmapped URL, a COPY operation creates a
- new resource much like a PUT operation does. Live properties that
- are related to resource creation (such as DAV:creationdate) should
- have their values set accordingly.
-
-9.8.3. COPY for Collections
-
- The COPY method on a collection without a Depth header MUST act as if
- a Depth header with value "infinity" was included. A client may
- submit a Depth header on a COPY on a collection with a value of "0"
- or "infinity". Servers MUST support the "0" and "infinity" Depth
- header behaviors on WebDAV-compliant resources.
-
- An infinite-depth COPY instructs that the collection resource
- identified by the Request-URI is to be copied to the location
- identified by the URI in the Destination header, and all its internal
- member resources are to be copied to a location relative to it,
- recursively through all levels of the collection hierarchy. Note
- that an infinite-depth COPY of /A/ into /A/B/ could lead to infinite
- recursion if not handled correctly.
-
- A COPY of "Depth: 0" only instructs that the collection and its
- properties, but not resources identified by its internal member URLs,
- are to be copied.
-
- Any headers included with a COPY MUST be applied in processing every
- resource to be copied with the exception of the Destination header.
-
- The Destination header only specifies the destination URI for the
- Request-URI. When applied to members of the collection identified by
- the Request-URI, the value of Destination is to be modified to
- reflect the current location in the hierarchy. So, if the Request-
- URI is /a/ with Host header value http://example.com/ and the
-
-
-
-Dusseault Standards Track [Page 52]
-
-RFC 4918 WebDAV June 2007
-
-
- Destination is http://example.com/b/, then when
- http://example.com/a/c/d is processed, it must use a Destination of
- http://example.com/b/c/d.
-
- When the COPY method has completed processing, it MUST have created a
- consistent URL namespace at the destination (see Section 5.1 for the
- definition of namespace consistency). However, if an error occurs
- while copying an internal collection, the server MUST NOT copy any
- resources identified by members of this collection (i.e., the server
- must skip this subtree), as this would create an inconsistent
- namespace. After detecting an error, the COPY operation SHOULD try
- to finish as much of the original copy operation as possible (i.e.,
- the server should still attempt to copy other subtrees and their
- members that are not descendants of an error-causing collection).
-
- So, for example, if an infinite-depth copy operation is performed on
- collection /a/, which contains collections /a/b/ and /a/c/, and an
- error occurs copying /a/b/, an attempt should still be made to copy
- /a/c/. Similarly, after encountering an error copying a non-
- collection resource as part of an infinite-depth copy, the server
- SHOULD try to finish as much of the original copy operation as
- possible.
-
- If an error in executing the COPY method occurs with a resource other
- than the resource identified in the Request-URI, then the response
- MUST be a 207 (Multi-Status), and the URL of the resource causing the
- failure MUST appear with the specific error.
-
- The 424 (Failed Dependency) status code SHOULD NOT be returned in the
- 207 (Multi-Status) response from a COPY method. These responses can
- be safely omitted because the client will know that the progeny of a
- resource could not be copied when the client receives an error for
- the parent. Additionally, 201 (Created)/204 (No Content) status
- codes SHOULD NOT be returned as values in 207 (Multi-Status)
- responses from COPY methods. They, too, can be safely omitted
- because they are the default success codes.
-
-9.8.4. COPY and Overwriting Destination Resources
-
- If a COPY request has an Overwrite header with a value of "F", and a
- resource exists at the Destination URL, the server MUST fail the
- request.
-
- When a server executes a COPY request and overwrites a destination
- resource, the exact behavior MAY depend on many factors, including
- WebDAV extension capabilities (see particularly [RFC3253]). For
-
-
-
-
-
-Dusseault Standards Track [Page 53]
-
-RFC 4918 WebDAV June 2007
-
-
- example, when an ordinary resource is overwritten, the server could
- delete the target resource before doing the copy, or could do an in-
- place overwrite to preserve live properties.
-
- When a collection is overwritten, the membership of the destination
- collection after the successful COPY request MUST be the same
- membership as the source collection immediately before the COPY.
- Thus, merging the membership of the source and destination
- collections together in the destination is not a compliant behavior.
-
- In general, if clients require the state of the destination URL to be
- wiped out prior to a COPY (e.g., to force live properties to be
- reset), then the client could send a DELETE to the destination before
- the COPY request to ensure this reset.
-
-9.8.5. Status Codes
-
- In addition to the general status codes possible, the following
- status codes have specific applicability to COPY:
-
- 201 (Created) - The source resource was successfully copied. The
- COPY operation resulted in the creation of a new resource.
-
- 204 (No Content) - The source resource was successfully copied to a
- preexisting destination resource.
-
- 207 (Multi-Status) - Multiple resources were to be affected by the
- COPY, but errors on some of them prevented the operation from taking
- place. Specific error messages, together with the most appropriate
- of the source and destination URLs, appear in the body of the multi-
- status response. For example, if a destination resource was locked
- and could not be overwritten, then the destination resource URL
- appears with the 423 (Locked) status.
-
- 403 (Forbidden) - The operation is forbidden. A special case for
- COPY could be that the source and destination resources are the same
- resource.
-
- 409 (Conflict) - A resource cannot be created at the destination
- until one or more intermediate collections have been created. The
- server MUST NOT create those intermediate collections automatically.
-
- 412 (Precondition Failed) - A precondition header check failed, e.g.,
- the Overwrite header is "F" and the destination URL is already mapped
- to a resource.
-
-
-
-
-
-
-Dusseault Standards Track [Page 54]
-
-RFC 4918 WebDAV June 2007
-
-
- 423 (Locked) - The destination resource, or resource within the
- destination collection, was locked. This response SHOULD contain the
- 'lock-token-submitted' precondition element.
-
- 502 (Bad Gateway) - This may occur when the destination is on another
- server, repository, or URL namespace. Either the source namespace
- does not support copying to the destination namespace, or the
- destination namespace refuses to accept the resource. The client may
- wish to try GET/PUT and PROPFIND/PROPPATCH instead.
-
- 507 (Insufficient Storage) - The destination resource does not have
- sufficient space to record the state of the resource after the
- execution of this method.
-
-9.8.6. Example - COPY with Overwrite
-
- This example shows resource
- http://www.example.com/~fielding/index.html being copied to the
- location http://www.example.com/users/f/fielding/index.html. The 204
- (No Content) status code indicates that the existing resource at the
- destination was overwritten.
-
- >>Request
-
- COPY /~fielding/index.html HTTP/1.1
- Host: www.example.com
- Destination: http://www.example.com/users/f/fielding/index.html
-
- >>Response
-
- HTTP/1.1 204 No Content
-
-9.8.7. Example - COPY with No Overwrite
-
- The following example shows the same copy operation being performed,
- but with the Overwrite header set to "F." A response of 412
- (Precondition Failed) is returned because the destination URL is
- already mapped to a resource.
-
- >>Request
-
- COPY /~fielding/index.html HTTP/1.1
- Host: www.example.com
- Destination: http://www.example.com/users/f/fielding/index.html
- Overwrite: F
-
-
-
-
-
-
-Dusseault Standards Track [Page 55]
-
-RFC 4918 WebDAV June 2007
-
-
- >>Response
-
- HTTP/1.1 412 Precondition Failed
-
-9.8.8. Example - COPY of a Collection
-
- >>Request
-
- COPY /container/ HTTP/1.1
- Host: www.example.com
- Destination: http://www.example.com/othercontainer/
- Depth: infinity
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/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.example.com/othercontainer/R2/</d:href>
- <d:status>HTTP/1.1 423 Locked</d:status>
- <d:error><d:lock-token-submitted/></d:error>
- </d:response>
- </d:multistatus>
-
- The Depth header is unnecessary as the default behavior of COPY on a
- collection is to act as if a "Depth: infinity" header had been
- submitted. In this example, most of the resources, along with the
- collection, were copied successfully. However, the collection R2
- failed because the destination R2 is locked. Because there was an
- error copying R2, none of R2's members were copied. However, no
- errors were listed for those members due to the error minimization
- rules.
-
-9.9. MOVE Method
-
- The MOVE operation on a non-collection resource is the logical
- equivalent of a copy (COPY), followed by consistency maintenance
- processing, followed by a delete of the source, where all three
- actions are performed in a single operation. The consistency
- maintenance step allows the server to perform updates caused by the
- move, such as updating all URLs, other than the Request-URI that
- identifies the source resource, to point to the new destination
- resource.
-
-
-
-Dusseault Standards Track [Page 56]
-
-RFC 4918 WebDAV June 2007
-
-
- The Destination header MUST be present on all MOVE methods and MUST
- follow all COPY requirements for the COPY part of the MOVE method.
- All WebDAV-compliant resources MUST support the MOVE method.
-
- Support for the MOVE method does not guarantee the ability to move a
- resource to a particular destination. For example, separate programs
- may actually control different sets of resources on the same server.
- Therefore, it may not be possible to move a resource within a
- namespace that appears to belong to the same server.
-
- If a resource exists at the destination, the destination resource
- will be deleted as a side-effect of the MOVE operation, subject to
- the restrictions of the Overwrite header.
-
- This method is idempotent, but not safe (see Section 9.1 of
- [RFC2616]). Responses to this method MUST NOT be cached.
-
-9.9.1. MOVE for Properties
-
- Live properties described in this document SHOULD be moved along with
- the resource, such that the resource has identically behaving live
- properties at the destination resource, but not necessarily with the
- same values. Note that some live properties are defined such that
- the absence of the property has a specific meaning (e.g., a flag with
- one meaning if present, and the opposite if absent), and in these
- cases, a successful MOVE might result in the property being reported
- as "Not Found" in subsequent requests. If the live properties will
- not work the same way at the destination, the server MAY fail the
- request.
-
- MOVE is frequently used by clients to rename a file without changing
- its parent collection, so it's not appropriate to reset all live
- properties that are set at resource creation. For example, the DAV:
- creationdate property value SHOULD remain the same after a MOVE.
-
- Dead properties MUST be moved along with the resource.
-
-9.9.2. MOVE for Collections
-
- A MOVE with "Depth: infinity" instructs that the collection
- identified by the Request-URI be moved to the address specified in
- the Destination header, and all resources identified by its internal
- member URLs are to be moved to locations relative to it, recursively
- through all levels of the collection hierarchy.
-
- The MOVE method on a collection MUST act as if a "Depth: infinity"
- header was used on it. A client MUST NOT submit a Depth header on a
- MOVE on a collection with any value but "infinity".
-
-
-
-Dusseault Standards Track [Page 57]
-
-RFC 4918 WebDAV June 2007
-
-
- Any headers included with MOVE MUST be applied in processing every
- resource to be moved with the exception of the Destination header.
- The behavior of the Destination header is the same as given for COPY
- on collections.
-
- When the MOVE method has completed processing, it MUST have created a
- consistent URL namespace at both the source and destination (see
- Section 5.1 for the definition of namespace consistency). However,
- if an error occurs while moving an internal collection, the server
- MUST NOT move any resources identified by members of the failed
- collection (i.e., the server must skip the error-causing subtree), as
- this would create an inconsistent namespace. In this case, after
- detecting the error, the move operation SHOULD try to finish as much
- of the original move as possible (i.e., the server should still
- attempt to move other subtrees and the resources identified by their
- members that are not descendants of an error-causing collection).
- So, for example, if an infinite-depth move is performed on collection
- /a/, which contains collections /a/b/ and /a/c/, and an error occurs
- moving /a/b/, an attempt should still be made to try moving /a/c/.
- Similarly, after encountering an error moving a non-collection
- resource as part of an infinite-depth move, the server SHOULD try to
- finish as much of the original move operation as possible.
-
- If an error occurs with a resource other than the resource identified
- in the Request-URI, then the response MUST be a 207 (Multi-Status),
- and the errored resource's URL MUST appear with the specific error.
-
- The 424 (Failed Dependency) status code SHOULD NOT be returned in the
- 207 (Multi-Status) response from a MOVE method. These errors can be
- safely omitted because the client will know that the progeny of a
- resource could not be moved when the client receives an error for the
- parent. Additionally, 201 (Created)/204 (No Content) responses
- SHOULD NOT be returned as values in 207 (Multi-Status) responses from
- a MOVE. These responses can be safely omitted because they are the
- default success codes.
-
-9.9.3. MOVE and the Overwrite Header
-
- If a resource exists at the destination and the Overwrite header is
- "T", then prior to performing the move, the server MUST perform a
- DELETE with "Depth: infinity" on the destination resource. If the
- Overwrite header is set to "F", then the operation will fail.
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 58]
-
-RFC 4918 WebDAV June 2007
-
-
-9.9.4. Status Codes
-
- In addition to the general status codes possible, the following
- status codes have specific applicability to MOVE:
-
- 201 (Created) - The source resource was successfully moved, and a new
- URL mapping was created at the destination.
-
- 204 (No Content) - The source resource was successfully moved to a
- URL that was already mapped.
-
- 207 (Multi-Status) - Multiple resources were to be affected by the
- MOVE, but errors on some of them prevented the operation from taking
- place. Specific error messages, together with the most appropriate
- of the source and destination URLs, appear in the body of the multi-
- status response. For example, if a source resource was locked and
- could not be moved, then the source resource URL appears with the 423
- (Locked) status.
-
- 403 (Forbidden) - Among many possible reasons for forbidding a MOVE
- operation, this status code is recommended for use when the source
- and destination resources are the same.
-
- 409 (Conflict) - A resource cannot be created at the destination
- until one or more intermediate collections have been created. The
- server MUST NOT create those intermediate collections automatically.
- Or, the server was unable to preserve the behavior of the live
- properties and still move the resource to the destination (see
- 'preserved-live-properties' postcondition).
-
- 412 (Precondition Failed) - A condition header failed. Specific to
- MOVE, this could mean that the Overwrite header is "F" and the
- destination URL is already mapped to a resource.
-
- 423 (Locked) - The source or the destination resource, the source or
- destination resource parent, or some resource within the source or
- destination collection, was locked. This response SHOULD contain the
- 'lock-token-submitted' precondition element.
-
- 502 (Bad Gateway) - This may occur when the destination is on another
- server and the destination server refuses to accept the resource.
- This could also occur when the destination is on another sub-section
- of the same server namespace.
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 59]
-
-RFC 4918 WebDAV June 2007
-
-
-9.9.5. Example - MOVE of a Non-Collection
-
- This example shows resource
- http://www.example.com/~fielding/index.html being moved to the
- location http://www.example.com/users/f/fielding/index.html. The
- contents of the destination resource would have been overwritten if
- the destination URL was already mapped to a resource. In this case,
- since there was nothing at the destination resource, the response
- code is 201 (Created).
-
- >>Request
-
- MOVE /~fielding/index.html HTTP/1.1
- Host: www.example.com
- Destination: http://www.example/users/f/fielding/index.html
-
- >>Response
-
- HTTP/1.1 201 Created
- Location: http://www.example.com/users/f/fielding/index.html
-
-9.9.6. Example - MOVE of a Collection
-
- >>Request
-
- MOVE /container/ HTTP/1.1
- Host: www.example.com
- Destination: http://www.example.com/othercontainer/
- Overwrite: F
- If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
- (<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/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.example.com/othercontainer/C2/</d:href>
- <d:status>HTTP/1.1 423 Locked</d:status>
- <d:error><d:lock-token-submitted/></d:error>
- </d:response>
- </d:multistatus>
-
-
-
-
-
-Dusseault Standards Track [Page 60]
-
-RFC 4918 WebDAV June 2007
-
-
- In this example, the client has submitted a number of lock tokens
- with the request. A lock token will need to be submitted for every
- resource, both source and destination, anywhere in the scope of the
- method, that is locked. In this case, the proper lock token was not
- submitted for the destination
- http://www.example.com/othercontainer/C2/. This means that the
- resource /container/C2/ could not be moved. Because there was an
- error moving /container/C2/, none of /container/C2's members were
- moved. However, no errors were listed for those members due to the
- error minimization rules. User agent authentication has previously
- occurred via a mechanism outside the scope of the HTTP protocol, in
- an underlying transport layer.
-
-9.10. LOCK Method
-
- The following sections describe the LOCK method, which is used to
- take out a lock of any access type and to refresh an existing lock.
- These sections on the LOCK method describe only those semantics that
- are specific to the LOCK method and are independent of the access
- type of the lock being requested.
-
- Any resource that supports the LOCK method MUST, at minimum, support
- the XML request and response formats defined herein.
-
- This method is neither idempotent nor safe (see Section 9.1 of
- [RFC2616]). Responses to this method MUST NOT be cached.
-
-9.10.1. Creating a Lock on an Existing Resource
-
- A LOCK request to an existing resource will create a lock on the
- resource identified by the Request-URI, provided the resource is not
- already locked with a conflicting lock. The resource identified in
- the Request-URI becomes the root of the lock. LOCK method requests
- to create a new lock MUST have an XML request body. The server MUST
- preserve the information provided by the client in the 'owner'
- element in the LOCK request. The LOCK request MAY have a Timeout
- header.
-
- When a new lock is created, the LOCK response:
-
- o MUST contain a body with the value of the DAV:lockdiscovery
- property in a prop XML element. This MUST contain the full
- information about the lock just granted, while information about
- other (shared) locks is OPTIONAL.
-
- o MUST include the Lock-Token response header with the token
- associated with the new lock.
-
-
-
-
-Dusseault Standards Track [Page 61]
-
-RFC 4918 WebDAV June 2007
-
-
-9.10.2. Refreshing Locks
-
- A lock is refreshed by sending a LOCK request to the URL of a
- resource within the scope of the lock. This request MUST NOT have a
- body and it MUST specify which lock to refresh by using the 'If'
- header with a single lock token (only one lock may be refreshed at a
- time). The request MAY contain a Timeout header, which a server MAY
- accept to change the duration remaining on the lock to the new value.
- A server MUST ignore the Depth header on a LOCK refresh.
-
- If the resource has other (shared) locks, those locks are unaffected
- by a lock refresh. Additionally, those locks do not prevent the
- named lock from being refreshed.
-
- The Lock-Token header is not returned in the response for a
- successful refresh LOCK request, but the LOCK response body MUST
- contain the new value for the DAV:lockdiscovery property.
-
-9.10.3. Depth and Locking
-
- The Depth header may be used with the LOCK method. Values other than
- 0 or infinity MUST NOT be used with the Depth header on a LOCK
- method. All resources that support the LOCK method MUST support the
- Depth header.
-
- A Depth header of value 0 means to just lock the resource specified
- by the Request-URI.
-
- If the Depth header is set to infinity, then the resource specified
- in the Request-URI along with all its members, all the way down the
- hierarchy, are to be locked. A successful result MUST return a
- single lock token. Similarly, if an UNLOCK is successfully executed
- on this token, all associated resources are unlocked. Hence, partial
- success is not an option for LOCK or UNLOCK. Either the entire
- hierarchy is locked or no resources are locked.
-
- If the lock cannot be granted to all resources, the server MUST
- return a Multi-Status response with a 'response' element for at least
- one resource that prevented the lock from being granted, along with a
- suitable status code for that failure (e.g., 403 (Forbidden) or 423
- (Locked)). Additionally, if the resource causing the failure was not
- the resource requested, then the server SHOULD include a 'response'
- element for the Request-URI as well, with a 'status' element
- containing 424 Failed Dependency.
-
- If no Depth header is submitted on a LOCK request, then the request
- MUST act as if a "Depth:infinity" had been submitted.
-
-
-
-
-Dusseault Standards Track [Page 62]
-
-RFC 4918 WebDAV June 2007
-
-
-9.10.4. Locking Unmapped URLs
-
- A successful LOCK method MUST result in the creation of an empty
- resource that is locked (and that is not a collection) when a
- resource did not previously exist at that URL. Later on, the lock
- may go away but the empty resource remains. Empty resources MUST
- then appear in PROPFIND responses including that URL in the response
- scope. A server MUST respond successfully to a GET request to an
- empty resource, either by using a 204 No Content response, or by
- using 200 OK with a Content-Length header indicating zero length
-
-9.10.5. Lock Compatibility Table
-
- The table below describes the behavior that occurs when a lock
- request is made on a resource.
-
- +--------------------------+----------------+-------------------+
- | Current State | Shared Lock OK | Exclusive Lock OK |
- +--------------------------+----------------+-------------------+
- | None | True | True |
- | Shared Lock | True | False |
- | Exclusive Lock | False | False* |
- +--------------------------+----------------+-------------------+
-
- Legend: True = lock may be granted. False = lock MUST NOT be
- granted. *=It is illegal for a principal to request the same lock
- twice.
-
- The current lock state of a resource is given in the leftmost column,
- and lock requests are listed in the first row. The intersection of a
- row and column gives the result of a lock request. For example, if a
- shared lock is held on a resource, and an exclusive lock is
- requested, the table entry is "false", indicating that the lock must
- not be granted.
-
-9.10.6. LOCK Responses
-
- In addition to the general status codes possible, the following
- status codes have specific applicability to LOCK:
-
- 200 (OK) - The LOCK request succeeded and the value of the DAV:
- lockdiscovery property is included in the response body.
-
- 201 (Created) - The LOCK request was to an unmapped URL, the request
- succeeded and resulted in the creation of a new resource, and the
- value of the DAV:lockdiscovery property is included in the response
- body.
-
-
-
-
-Dusseault Standards Track [Page 63]
-
-RFC 4918 WebDAV June 2007
-
-
- 409 (Conflict) - A resource cannot be created at the destination
- until one or more intermediate collections have been created. The
- server MUST NOT create those intermediate collections automatically.
-
- 423 (Locked), potentially with 'no-conflicting-lock' precondition
- code - There is already a lock on the resource that is not compatible
- with the requested lock (see lock compatibility table above).
-
- 412 (Precondition Failed), with 'lock-token-matches-request-uri'
- precondition code - The LOCK request was made with an If header,
- indicating that the client wishes to refresh the given lock.
- However, the Request-URI did not fall within the scope of the lock
- identified by the token. The lock may have a scope that does not
- include the Request-URI, or the lock could have disappeared, or the
- token may be invalid.
-
-9.10.7. Example - Simple Lock Request
-
- >>Request
-
- LOCK /workspace/webdav/proposal.doc HTTP/1.1
- Host: example.com
- Timeout: Infinite, Second-4100000000
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
- Authorization: Digest username="ejw",
- realm="ejw at example.com", nonce="...",
- uri="/workspace/webdav/proposal.doc",
- response="...", opaque="..."
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:lockinfo xmlns:D='DAV:'>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- <D:owner>
- <D:href>http://example.org/~ejw/contact.html</D:href>
- </D:owner>
- </D:lockinfo>
-
- >>Response
-
- HTTP/1.1 200 OK
- Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:prop xmlns:D="DAV:">
-
-
-
-Dusseault Standards Track [Page 64]
-
-RFC 4918 WebDAV June 2007
-
-
- <D:lockdiscovery>
- <D:activelock>
- <D:locktype><D:write/></D:locktype>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:depth>infinity</D:depth>
- <D:owner>
- <D:href>http://example.org/~ejw/contact.html</D:href>
- </D:owner>
- <D:timeout>Second-604800</D:timeout>
- <D:locktoken>
- <D:href
- >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
- </D:locktoken>
- <D:lockroot>
- <D:href
- >http://example.com/workspace/webdav/proposal.doc</D:href>
- </D:lockroot>
- </D:activelock>
- </D:lockdiscovery>
- </D:prop>
-
-
- This example shows the successful creation of an exclusive write lock
- on resource http://example.com/workspace/webdav/proposal.doc. The
- resource http://example.org/~ejw/contact.html contains contact
- information for the creator of the lock. The server has an activity-
- based timeout policy in place on this resource, which causes the lock
- to automatically be removed after 1 week (604800 seconds). Note that
- the nonce, response, and opaque fields have not been calculated in
- the Authorization request header.
-
-9.10.8. Example - Refreshing a Write Lock
-
- >>Request
-
- LOCK /workspace/webdav/proposal.doc HTTP/1.1
- Host: example.com
- Timeout: Infinite, Second-4100000000
- If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
- Authorization: Digest username="ejw",
- realm="ejw at example.com", nonce="...",
- uri="/workspace/webdav/proposal.doc",
- response="...", opaque="..."
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 65]
-
-RFC 4918 WebDAV June 2007
-
-
- >>Response
-
- HTTP/1.1 200 OK
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:prop xmlns:D="DAV:">
- <D:lockdiscovery>
- <D:activelock>
- <D:locktype><D:write/></D:locktype>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:depth>infinity</D:depth>
- <D:owner>
- <D:href>http://example.org/~ejw/contact.html</D:href>
- </D:owner>
- <D:timeout>Second-604800</D:timeout>
- <D:locktoken>
- <D:href
- >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
- </D:locktoken>
- <D:lockroot>
- <D:href
- >http://example.com/workspace/webdav/proposal.doc</D:href>
- </D:lockroot>
- </D:activelock>
- </D:lockdiscovery>
- </D:prop>
-
-
- This request would refresh the lock, attempting to reset the timeout
- to the new value specified in the timeout header. Notice that the
- client asked for an infinite time out but the server choose to ignore
- the request. In this example, the nonce, response, and opaque fields
- have not been calculated in the Authorization request header.
-
-9.10.9. Example - Multi-Resource Lock Request
-
- >>Request
-
- LOCK /webdav/ HTTP/1.1
- Host: example.com
- Timeout: Infinite, Second-4100000000
- Depth: infinity
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
- Authorization: Digest username="ejw",
- realm="ejw at example.com", nonce="...",
-
-
-
-Dusseault Standards Track [Page 66]
-
-RFC 4918 WebDAV June 2007
-
-
- uri="/workspace/webdav/proposal.doc",
- response="...", opaque="..."
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:lockinfo xmlns:D="DAV:">
- <D:locktype><D:write/></D:locktype>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:owner>
- <D:href>http://example.org/~ejw/contact.html</D:href>
- </D:owner>
- </D:lockinfo>
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:multistatus xmlns:D="DAV:">
- <D:response>
- <D:href>http://example.com/webdav/secret</D:href>
- <D:status>HTTP/1.1 403 Forbidden</D:status>
- </D:response>
- <D:response>
- <D:href>http://example.com/webdav/</D:href>
- <D:status>HTTP/1.1 424 Failed Dependency</D:status>
- </D:response>
- </D:multistatus>
-
-
- This example shows a request for an exclusive write lock on a
- collection and all its children. In this request, the client has
- specified that it desires an infinite-length lock, if available,
- otherwise a timeout of 4.1 billion seconds, if available. The
- request entity body contains the contact information for the
- principal taking out the lock -- in this case, a Web page URL.
-
- The error is a 403 (Forbidden) response on the resource
- http://example.com/webdav/secret. Because this resource could not be
- locked, none of the resources were locked. Note also that the a
- 'response' element for the Request-URI itself has been included as
- required.
-
- In this example, the nonce, response, and opaque fields have not been
- calculated in the Authorization request header.
-
-
-
-
-
-Dusseault Standards Track [Page 67]
-
-RFC 4918 WebDAV June 2007
-
-
-9.11. UNLOCK Method
-
- The UNLOCK method removes the lock identified by the lock token in
- the Lock-Token request header. The Request-URI MUST identify a
- resource within the scope of the lock.
-
- Note that use of the Lock-Token header to provide the lock token is
- not consistent with other state-changing methods, which all require
- an If header with the lock token. Thus, the If header is not needed
- to provide the lock token. Naturally, when the If header is present,
- it has its normal meaning as a conditional header.
-
- For a successful response to this method, the server MUST delete the
- lock entirely.
-
- If all resources that have been locked under the submitted lock token
- cannot be unlocked, then the UNLOCK request MUST fail.
-
- A successful response to an UNLOCK method does not mean that the
- resource is necessarily unlocked. It means that the specific lock
- corresponding to the specified token no longer exists.
-
- Any DAV-compliant resource that supports the LOCK method MUST support
- the UNLOCK method.
-
- This method is idempotent, but not safe (see Section 9.1 of
- [RFC2616]). Responses to this method MUST NOT be cached.
-
-9.11.1. Status Codes
-
- In addition to the general status codes possible, the following
- status codes have specific applicability to UNLOCK:
-
- 204 (No Content) - Normal success response (rather than 200 OK, since
- 200 OK would imply a response body, and an UNLOCK success response
- does not normally contain a body).
-
- 400 (Bad Request) - No lock token was provided.
-
- 403 (Forbidden) - The currently authenticated principal does not have
- permission to remove the lock.
-
- 409 (Conflict), with 'lock-token-matches-request-uri' precondition -
- The resource was not locked, or the request was made to a Request-URI
- that was not within the scope of the lock.
-
-
-
-
-
-
-Dusseault Standards Track [Page 68]
-
-RFC 4918 WebDAV June 2007
-
-
-9.11.2. Example - UNLOCK
-
- >>Request
-
- UNLOCK /workspace/webdav/info.doc HTTP/1.1
- Host: example.com
- Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
- Authorization: Digest username="ejw"
- realm="ejw at example.com", nonce="...",
- uri="/workspace/webdav/proposal.doc",
- response="...", opaque="..."
-
- >>Response
-
- HTTP/1.1 204 No Content
-
- In this example, the lock identified by the lock token
- "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully
- removed from the resource
- http://example.com/workspace/webdav/info.doc. If this lock included
- more than just one resource, the lock is removed from all resources
- included in the lock.
-
- In this example, the nonce, response, and opaque fields have not been
- calculated in the Authorization request header.
-
-10. HTTP Headers for Distributed Authoring
-
- All DAV headers follow the same basic formatting rules as HTTP
- headers. This includes rules like line continuation and how to
- combine (or separate) multiple instances of the same header using
- commas.
-
- WebDAV adds two new conditional headers to the set defined in HTTP:
- the If and Overwrite headers.
-
-10.1. DAV Header
-
- DAV = "DAV" ":" #( compliance-class )
- compliance-class = ( "1" | "2" | "3" | extend )
- extend = Coded-URL | token
- ; token is defined in RFC 2616, Section 2.2
- Coded-URL = "<" absolute-URI ">"
- ; No linear whitespace (LWS) allowed in Coded-URL
- ; absolute-URI defined in RFC 3986, Section 4.3
-
-
-
-
-
-
-Dusseault Standards Track [Page 69]
-
-RFC 4918 WebDAV June 2007
-
-
- This general-header appearing in the response indicates that the
- resource supports the DAV schema and protocol as specified. All DAV-
- compliant resources MUST return the DAV header with compliance-class
- "1" on all OPTIONS responses. In cases where WebDAV is only
- supported in part of the server namespace, an OPTIONS request to non-
- WebDAV resources (including "/") SHOULD NOT advertise WebDAV support.
-
- The value is a comma-separated list of all compliance class
- identifiers that the resource supports. Class identifiers may be
- Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can
- appear in any order. Identifiers that are standardized through the
- IETF RFC process are tokens, but other identifiers SHOULD be Coded-
- URLs to encourage uniqueness.
-
- A resource must show class 1 compliance if it shows class 2 or 3
- compliance. In general, support for one compliance class does not
- entail support for any other, and in particular, support for
- compliance class 3 does not require support for compliance class 2.
- Please refer to Section 18 for more details on compliance classes
- defined in this specification.
-
- Note that many WebDAV servers do not advertise WebDAV support in
- response to "OPTIONS *".
-
- As a request header, this header allows the client to advertise
- compliance with named features when the server needs that
- information. Clients SHOULD NOT send this header unless a standards
- track specification requires it. Any extension that makes use of
- this as a request header will need to carefully consider caching
- implications.
-
-10.2. Depth Header
-
- Depth = "Depth" ":" ("0" | "1" | "infinity")
-
- The Depth request header is used with methods executed on resources
- that could potentially have internal members to indicate whether the
- method is to be applied only to the resource ("Depth: 0"), to the
- resource and its internal members only ("Depth: 1"), or the resource
- and all its members ("Depth: infinity").
-
- The Depth header is only supported if a method's definition
- explicitly provides for such support.
-
- The following rules are the default behavior for any method that
- supports the Depth header. A method may override these defaults by
- defining different behavior in its definition.
-
-
-
-
-Dusseault Standards Track [Page 70]
-
-RFC 4918 WebDAV June 2007
-
-
- Methods that support the Depth header may choose not to support all
- of the header's values and may define, on a case-by-case basis, the
- behavior of the method if a Depth header is not present. For
- example, the MOVE method only supports "Depth: infinity", and if a
- Depth header is not present, it will act as if a "Depth: infinity"
- header had been applied.
-
- Clients MUST NOT rely upon methods executing on members of their
- hierarchies in any particular order or on the execution being atomic
- unless the particular method explicitly provides such guarantees.
-
- Upon execution, a method with a Depth header will perform as much of
- its assigned task as possible and then return a response specifying
- what it was able to accomplish and what it failed to do.
-
- So, for example, an attempt to COPY a hierarchy may result in some of
- the members being copied and some not.
-
- By default, the Depth header does not interact with other headers.
- That is, each header on a request with a Depth header MUST be applied
- only to the Request-URI if it applies to any resource, unless
- specific Depth behavior is defined for that header.
-
- If a source or destination resource within the scope of the Depth
- header is locked in such a way as to prevent the successful execution
- of the method, then the lock token for that resource MUST be
- submitted with the request in the If request header.
-
- The Depth header only specifies the behavior of the method with
- regards to internal members. If a resource does not have internal
- members, then the Depth header MUST be ignored.
-
-10.3. Destination Header
-
- The Destination request header specifies the URI that identifies a
- destination resource for methods such as COPY and MOVE, which take
- two URIs as parameters.
-
- Destination = "Destination" ":" Simple-ref
-
-
- If the Destination value is an absolute-URI (Section 4.3 of
- [RFC3986]), it may name a different server (or different port or
- scheme). If the source server cannot attempt a copy to the remote
- server, it MUST fail the request. Note that copying and moving
- resources to remote servers is not fully defined in this
- specification (e.g., specific error conditions).
-
-
-
-
-Dusseault Standards Track [Page 71]
-
-RFC 4918 WebDAV June 2007
-
-
- If the Destination value is too long or otherwise unacceptable, the
- server SHOULD return 400 (Bad Request), ideally with helpful
- information in an error body.
-
-10.4. If Header
-
- The If request header is intended to have similar functionality to
- the If-Match header defined in Section 14.24 of [RFC2616]. However,
- the If header handles any state token as well as ETags. A typical
- example of a state token is a lock token, and lock tokens are the
- only state tokens defined in this specification.
-
-10.4.1. Purpose
-
- The If header has two distinct purposes:
-
- o The first purpose is to make a request conditional by supplying a
- series of state lists with conditions that match tokens and ETags
- to a specific resource. If this header is evaluated and all state
- lists fail, then the request MUST fail with a 412 (Precondition
- Failed) status. On the other hand, the request can succeed only
- if one of the described state lists succeeds. The success
- criteria for state lists and matching functions are defined in
- Sections 10.4.3 and 10.4.4.
-
- o Additionally, the mere fact that a state token appears in an If
- header means that it has been "submitted" with the request. In
- general, this is used to indicate that the client has knowledge of
- that state token. The semantics for submitting a state token
- depend on its type (for lock tokens, please refer to Section 6).
-
- Note that these two purposes need to be treated distinctly: a state
- token counts as being submitted independently of whether the server
- actually has evaluated the state list it appears in, and also
- independently of whether or not the condition it expressed was found
- to be true.
-
-10.4.2. Syntax
-
- If = "If" ":" ( 1*No-tag-list | 1*Tagged-list )
-
- No-tag-list = List
- Tagged-list = Resource-Tag 1*List
-
- List = "(" 1*Condition ")"
- Condition = ["Not"] (State-token | "[" entity-tag "]")
- ; entity-tag: see Section 3.11 of [RFC2616]
- ; No LWS allowed between "[", entity-tag and "]"
-
-
-
-Dusseault Standards Track [Page 72]
-
-RFC 4918 WebDAV June 2007
-
-
- State-token = Coded-URL
-
- Resource-Tag = "<" Simple-ref ">"
- ; Simple-ref: see Section 8.3
- ; No LWS allowed in Resource-Tag
-
- The syntax distinguishes between untagged lists ("No-tag-list") and
- tagged lists ("Tagged-list"). Untagged lists apply to the resource
- identified by the Request-URI, while tagged lists apply to the
- resource identified by the preceding Resource-Tag.
-
- A Resource-Tag applies to all subsequent Lists, up to the next
- Resource-Tag.
-
- Note that the two list types cannot be mixed within an If header.
- This is not a functional restriction because the No-tag-list syntax
- is just a shorthand notation for a Tagged-list production with a
- Resource-Tag referring to the Request-URI.
-
- Each List consists of one or more Conditions. Each Condition is
- defined in terms of an entity-tag or state-token, potentially negated
- by the prefix "Not".
-
- Note that the If header syntax does not allow multiple instances of
- If headers in a single request. However, the HTTP header syntax
- allows extending single header values across multiple lines, by
- inserting a line break followed by whitespace (see [RFC2616], Section
- 4.2).
-
-10.4.3. List Evaluation
-
- A Condition that consists of a single entity-tag or state-token
- evaluates to true if the resource matches the described state (where
- the individual matching functions are defined below in
- Section 10.4.4). Prefixing it with "Not" reverses the result of the
- evaluation (thus, the "Not" applies only to the subsequent entity-tag
- or state-token).
-
- Each List production describes a series of conditions. The whole
- list evaluates to true if and only if each condition evaluates to
- true (that is, the list represents a logical conjunction of
- Conditions).
-
- Each No-tag-list and Tagged-list production may contain one or more
- Lists. They evaluate to true if and only if any of the contained
- lists evaluates to true (that is, if there's more than one List, that
- List sequence represents a logical disjunction of the Lists).
-
-
-
-
-Dusseault Standards Track [Page 73]
-
-RFC 4918 WebDAV June 2007
-
-
- Finally, the whole If header evaluates to true if and only if at
- least one of the No-tag-list or Tagged-list productions evaluates to
- true. If the header evaluates to false, the server MUST reject the
- request with a 412 (Precondition Failed) status. Otherwise,
- execution of the request can proceed as if the header wasn't present.
-
-10.4.4. Matching State Tokens and ETags
-
- When performing If header processing, the definition of a matching
- state token or entity tag is as follows:
-
- Identifying a resource: The resource is identified by the URI along
- with the token, in tagged list production, or by the Request-URI in
- untagged list production.
-
- Matching entity tag: Where the entity tag matches an entity tag
- associated with the identified resource. Servers MUST use either the
- weak or the strong comparison function defined in Section 13.3.3 of
- [RFC2616].
-
- Matching state token: Where there is an exact match between the state
- token in the If header and any state token on the identified
- resource. A lock state token is considered to match if the resource
- is anywhere in the scope of the lock.
-
- Handling unmapped URLs: For both ETags and state tokens, treat as if
- the URL identified a resource that exists but does not have the
- specified state.
-
-10.4.5. If Header and Non-DAV-Aware Proxies
-
- Non-DAV-aware proxies will not honor the If header, since they will
- not understand the If header, and HTTP requires non-understood
- headers to be ignored. When communicating with HTTP/1.1 proxies, the
- client MUST use the "Cache-Control: no-cache" request header so as to
- prevent the proxy from improperly trying to service the request from
- its cache. When dealing with HTTP/1.0 proxies, the "Pragma: no-
- cache" request header MUST be used for the same reason.
-
- Because in general clients may not be able to reliably detect non-
- DAV-aware intermediates, they are advised to always prevent caching
- using the request directives mentioned above.
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 74]
-
-RFC 4918 WebDAV June 2007
-
-
-10.4.6. Example - No-tag Production
-
- If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
- ["I am an ETag"])
- (["I am another ETag"])
-
- The previous header would require that the resource identified in the
- Request-URI be locked with the specified lock token and be in the
- state identified by the "I am an ETag" ETag or in the state
- identified by the second ETag "I am another ETag".
-
- To put the matter more plainly one can think of the previous If
- header as expressing the condition below:
-
- (
- is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND
- matches-etag("I am an ETag")
- )
- OR
- (
- matches-etag("I am another ETag")
- )
-
-10.4.7. Example - Using "Not" with No-tag Production
-
- If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
- <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
-
- This If header requires that the resource must not be locked with a
- lock having the lock token
- urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a
- lock with the lock token
- urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
-
-10.4.8. Example - Causing a Condition to Always Evaluate to True
-
- There may be cases where a client wishes to submit state tokens, but
- doesn't want the request to fail just because the state token isn't
- current anymore. One simple way to do this is to include a Condition
- that is known to always evaluate to true, such as in:
-
- If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
- (Not <DAV:no-lock>)
-
- "DAV:no-lock" is known to never represent a current lock token. Lock
- tokens are assigned by the server, following the uniqueness
- requirements described in Section 6.5, therefore cannot use the
- "DAV:" scheme. Thus, by applying "Not" to a state token that is
-
-
-
-Dusseault Standards Track [Page 75]
-
-RFC 4918 WebDAV June 2007
-
-
- known not to be current, the Condition always evaluates to true.
- Consequently, the whole If header will always evaluate to true, and
- the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 will be
- submitted in any case.
-
-10.4.9. Example - Tagged List If Header in COPY
-
- >>Request
-
- COPY /resource1 HTTP/1.1
- Host: www.example.com
- Destination: /resource2
- If: </resource1>
- (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
- [W/"A weak ETag"]) (["strong ETag"])
-
- In this example, http://www.example.com/resource1 is being copied to
- http://www.example.com/resource2. When the method is first applied
- to http://www.example.com/resource1, resource1 must be in the state
- specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A
- weak ETag"]) (["strong ETag"])". That is, either it must be locked
- with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2"
- and have a weak entity tag W/"A weak ETag" or it must have a strong
- entity tag "strong ETag".
-
-10.4.10. Example - Matching Lock Tokens with Collection Locks
-
- DELETE /specs/rfc2518.txt HTTP/1.1
- Host: www.example.com
- If: <http://www.example.com/specs/>
- (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
-
- For this example, the lock token must be compared to the identified
- resource, which is the 'specs' collection identified by the URL in
- the tagged list production. If the 'specs' collection is not locked
- by a lock with the specified lock token, the request MUST fail.
- Otherwise, this request could succeed, because the If header
- evaluates to true, and because the lock token for the lock affecting
- the affected resource has been submitted.
-
-10.4.11. Example - Matching ETags on Unmapped URLs
-
- Consider a collection "/specs" that does not contain the member
- "/specs/rfc2518.doc". In this case, the If header
-
- If: </specs/rfc2518.doc> (["4217"])
-
-
-
-
-
-Dusseault Standards Track [Page 76]
-
-RFC 4918 WebDAV June 2007
-
-
- will evaluate to false (the URI isn't mapped, thus the resource
- identified by the URI doesn't have an entity matching the ETag
- "4217").
-
- On the other hand, an If header of
-
- If: </specs/rfc2518.doc> (Not ["4217"])
-
- will consequently evaluate to true.
-
- Note that, as defined above in Section 10.4.4, the same
- considerations apply to matching state tokens.
-
-10.5. Lock-Token Header
-
- Lock-Token = "Lock-Token" ":" Coded-URL
-
- The Lock-Token request header is used with the UNLOCK method to
- identify the lock to be removed. The lock token in the Lock-Token
- request header MUST identify a lock that contains the resource
- identified by Request-URI as a member.
-
- The Lock-Token response header is used with the LOCK method to
- indicate the lock token created as a result of a successful LOCK
- request to create a new lock.
-
-10.6. Overwrite Header
-
- Overwrite = "Overwrite" ":" ("T" | "F")
-
- The Overwrite request header specifies whether the server should
- overwrite a resource mapped to the destination URL during a COPY or
- MOVE. A value of "F" states that the server must not perform the
- COPY or MOVE operation if the destination URL does map to a resource.
- If the overwrite header is not included in a COPY or MOVE request,
- then the resource MUST treat the request as if it has an overwrite
- header of value "T". While the Overwrite header appears to duplicate
- the functionality of using an "If-Match: *" header (see [RFC2616]),
- If-Match applies only to the Request-URI, and not to the Destination
- of a COPY or MOVE.
-
- If a COPY or MOVE is not performed due to the value of the Overwrite
- header, the method MUST fail with a 412 (Precondition Failed) status
- code. The server MUST do authorization checks before checking this
- or any conditional header.
-
- All DAV-compliant resources MUST support the Overwrite header.
-
-
-
-
-Dusseault Standards Track [Page 77]
-
-RFC 4918 WebDAV June 2007
-
-
-10.7. Timeout Request Header
-
- TimeOut = "Timeout" ":" 1#TimeType
- TimeType = ("Second-" DAVTimeOutVal | "Infinite")
- ; No LWS allowed within TimeType
- DAVTimeOutVal = 1*DIGIT
-
- Clients MAY include Timeout request headers in their LOCK requests.
- However, the server is not required to honor or even consider these
- requests. Clients MUST NOT submit a Timeout request header with any
- method other than a LOCK method.
-
- The "Second" TimeType specifies the number of seconds that will
- elapse between granting of the lock at the server, and the automatic
- removal of the lock. The timeout value for TimeType "Second" MUST
- NOT be greater than 2^32-1.
-
- See Section 6.6 for a description of lock timeout behavior.
-
-11. Status Code Extensions to HTTP/1.1
-
- The following status codes are added to those defined in HTTP/1.1
- [RFC2616].
-
-11.1. 207 Multi-Status
-
- The 207 (Multi-Status) status code provides status for multiple
- independent operations (see Section 13 for more information).
-
-11.2. 422 Unprocessable Entity
-
- The 422 (Unprocessable Entity) status code means the server
- understands the content type of the request entity (hence a
- 415(Unsupported Media Type) status code is inappropriate), and the
- syntax of the request entity is correct (thus a 400 (Bad Request)
- status code is inappropriate) but was unable to process the contained
- instructions. For example, this error condition may occur if an XML
- request body contains well-formed (i.e., syntactically correct), but
- semantically erroneous, XML instructions.
-
-11.3. 423 Locked
-
- The 423 (Locked) status code means the source or destination resource
- of a method is locked. This response SHOULD contain an appropriate
- precondition or postcondition code, such as 'lock-token-submitted' or
- 'no-conflicting-lock'.
-
-
-
-
-
-Dusseault Standards Track [Page 78]
-
-RFC 4918 WebDAV June 2007
-
-
-11.4. 424 Failed Dependency
-
- The 424 (Failed Dependency) status code means that the method could
- not be performed on the resource because the requested action
- depended on another action and that action failed. For example, if a
- command in a PROPPATCH method fails, then, at minimum, the rest of
- the commands will also fail with 424 (Failed Dependency).
-
-11.5. 507 Insufficient Storage
-
- The 507 (Insufficient Storage) status code means the method could not
- be performed on the resource because the server is unable to store
- the representation needed to successfully complete the request. This
- condition is considered to be temporary. If the request that
- received this status code was the result of a user action, the
- request MUST NOT be repeated until it is requested by a separate user
- action.
-
-12. Use of HTTP Status Codes
-
- These HTTP codes are not redefined, but their use is somewhat
- extended by WebDAV methods and requirements. In general, many HTTP
- status codes can be used in response to any request, not just in
- cases described in this document. Note also that WebDAV servers are
- known to use 300-level redirect responses (and early interoperability
- tests found clients unprepared to see those responses). A 300-level
- response MUST NOT be used when the server has created a new resource
- in response to the request.
-
-12.1. 412 Precondition Failed
-
- Any request can contain a conditional header defined in HTTP (If-
- Match, If-Modified-Since, etc.) or the "If" or "Overwrite"
- conditional headers defined in this specification. If the server
- evaluates a conditional header, and if that condition fails to hold,
- then this error code MUST be returned. On the other hand, if the
- client did not include a conditional header in the request, then the
- server MUST NOT use this status code.
-
-12.2. 414 Request-URI Too Long
-
- This status code is used in HTTP 1.1 only for Request-URIs, not URIs
- in other locations.
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 79]
-
-RFC 4918 WebDAV June 2007
-
-
-13. Multi-Status Response
-
- A Multi-Status response conveys information about multiple resources
- in situations where multiple status codes might be appropriate. The
- default Multi-Status response body is a text/xml or application/xml
- HTTP entity with a 'multistatus' root element. Further elements
- contain 200, 300, 400, and 500 series status codes generated during
- the method invocation. 100 series status codes SHOULD NOT be recorded
- in a 'response' XML element.
-
- Although '207' is used as the overall response status code, the
- recipient needs to consult the contents of the multistatus response
- body for further information about the success or failure of the
- method execution. The response MAY be used in success, partial
- success and also in failure situations.
-
- The 'multistatus' root element holds zero or more 'response' elements
- in any order, each with information about an individual resource.
- Each 'response' element MUST have an 'href' element to identify the
- resource.
-
- A Multi-Status response uses one out of two distinct formats for
- representing the status:
-
- 1. A 'status' element as child of the 'response' element indicates
- the status of the message execution for the identified resource
- as a whole (for instance, see Section 9.6.2). Some method
- definitions provide information about specific status codes
- clients should be prepared to see in a response. However,
- clients MUST be able to handle other status codes, using the
- generic rules defined in Section 10 of [RFC2616].
-
- 2. For PROPFIND and PROPPATCH, the format has been extended using
- the 'propstat' element instead of 'status', providing information
- about individual properties of a resource. This format is
- specific to PROPFIND and PROPPATCH, and is described in detail in
- Sections 9.1 and 9.2.
-
-13.1. Response Headers
-
- HTTP defines the Location header to indicate a preferred URL for the
- resource that was addressed in the Request-URI (e.g., in response to
- successful PUT requests or in redirect responses). However, use of
- this header creates ambiguity when there are URLs in the body of the
- response, as with Multi-Status. Thus, use of the Location header
- with the Multi-Status response is intentionally undefined.
-
-
-
-
-
-Dusseault Standards Track [Page 80]
-
-RFC 4918 WebDAV June 2007
-
-
-13.2. Handling Redirected Child Resources
-
- Redirect responses (300-303, 305, and 307) defined in HTTP 1.1
- normally take a Location header to indicate the new URI for the
- single resource redirected from the Request-URI. Multi-Status
- responses contain many resource addresses, but the original
- definition in [RFC2518] did not have any place for the server to
- provide the new URI for redirected resources. This specification
- does define a 'location' element for this information (see
- Section 14.9). Servers MUST use this new element with redirect
- responses in Multi-Status.
-
- Clients encountering redirected resources in Multi-Status MUST NOT
- rely on the 'location' element being present with a new URI. If the
- element is not present, the client MAY reissue the request to the
- individual redirected resource, because the response to that request
- can be redirected with a Location header containing the new URI.
-
-13.3. Internal Status Codes
-
- Sections 9.2.1, 9.1.2, 9.6.1, 9.8.3, and 9.9.2 define various status
- codes used in Multi-Status responses. This specification does not
- define the meaning of other status codes that could appear in these
- responses.
-
-14. XML Element Definitions
-
- In this section, the final line of each section gives the element
- type declaration using the format defined in [REC-XML]. The "Value"
- field, where present, specifies further restrictions on the allowable
- contents of the XML element using BNF (i.e., to further restrict the
- values of a PCDATA element). Note that all of the elements defined
- here may be extended according to the rules defined in Section 17.
- All elements defined here are in the "DAV:" namespace.
-
-14.1. activelock XML Element
-
- Name: activelock
-
- Purpose: Describes a lock on a resource.
-
-
- <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
- locktoken?, lockroot)>
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 81]
-
-RFC 4918 WebDAV June 2007
-
-
-14.2. allprop XML Element
-
- Name: allprop
-
- Purpose: Specifies that all names and values of dead properties and
- the live properties defined by this document existing on the
- resource are to be returned.
-
- <!ELEMENT allprop EMPTY >
-
-14.3. collection XML Element
-
- Name: collection
-
- Purpose: Identifies the associated resource as a collection. The
- DAV:resourcetype property of a collection resource MUST contain
- this element. It is normally empty but extensions may add sub-
- elements.
-
- <!ELEMENT collection EMPTY >
-
-14.4. depth XML Element
-
- Name: depth
-
- Purpose: Used for representing depth values in XML content (e.g.,
- in lock information).
-
- Value: "0" | "1" | "infinity"
-
- <!ELEMENT depth (#PCDATA) >
-
-14.5. error XML Element
-
- Name: error
-
- Purpose: Error responses, particularly 403 Forbidden and 409
- Conflict, sometimes need more information to indicate what went
- wrong. In these cases, servers MAY return an XML response body
- with a document element of 'error', containing child elements
- identifying particular condition codes.
-
- Description: Contains at least one XML element, and MUST NOT
- contain text or mixed content. Any element that is a child of the
- 'error' element is considered to be a precondition or
- postcondition code. Unrecognized elements MUST be ignored.
-
- <!ELEMENT error ANY >
-
-
-
-Dusseault Standards Track [Page 82]
-
-RFC 4918 WebDAV June 2007
-
-
-14.6. exclusive XML Element
-
- Name: exclusive
-
- Purpose: Specifies an exclusive lock.
-
-
- <!ELEMENT exclusive EMPTY >
-
-
-14.7. href XML Element
-
- Name: href
-
- Purpose: MUST contain a URI or a relative reference.
-
- Description: There may be limits on the value of 'href' depending
- on the context of its use. Refer to the specification text where
- 'href' is used to see what limitations apply in each case.
-
- Value: Simple-ref
-
-
- <!ELEMENT href (#PCDATA)>
-
-14.8. include XML Element
-
- Name: include
-
- Purpose: Any child element represents the name of a property to be
- included in the PROPFIND response. All elements inside an
- 'include' XML element MUST define properties related to the
- resource, although possible property names are in no way limited
- to those property names defined in this document or other
- standards. This element MUST NOT contain text or mixed content.
-
- <!ELEMENT include ANY >
-
-14.9. location XML Element
-
- Name: location
-
- Purpose: HTTP defines the "Location" header (see [RFC2616], Section
- 14.30) for use with some status codes (such as 201 and the 300
- series codes). When these codes are used inside a 'multistatus'
- element, the 'location' element can be used to provide the
- accompanying Location header value.
-
-
-
-
-Dusseault Standards Track [Page 83]
-
-RFC 4918 WebDAV June 2007
-
-
- Description: Contains a single href element with the same value
- that would be used in a Location header.
-
-
- <!ELEMENT location (href)>
-
-14.10. lockentry XML Element
-
- Name: lockentry
-
- Purpose: Defines the types of locks that can be used with the
- resource.
-
- <!ELEMENT lockentry (lockscope, locktype) >
-
-14.11. lockinfo XML Element
-
- Name: lockinfo
-
- Purpose: The 'lockinfo' XML element is used with a LOCK method to
- specify the type of lock the client wishes to have created.
-
-
- <!ELEMENT lockinfo (lockscope, locktype, owner?) >
-
-14.12. lockroot XML Element
-
- Name: lockroot
-
- Purpose: Contains the root URL of the lock, which is the URL
- through which the resource was addressed in the LOCK request.
-
- Description: The href element contains the root of the lock. The
- server SHOULD include this in all DAV:lockdiscovery property
- values and the response to LOCK requests.
-
- <!ELEMENT lockroot (href) >
-
-14.13. lockscope XML Element
-
- Name: lockscope
-
- Purpose: Specifies whether a lock is an exclusive lock, or a shared
- lock.
-
-
- <!ELEMENT lockscope (exclusive | shared) >
-
-
-
-
-Dusseault Standards Track [Page 84]
-
-RFC 4918 WebDAV June 2007
-
-
-14.14. locktoken XML Element
-
- Name: locktoken
-
- Purpose: The lock token associated with a lock.
-
- Description: The href contains a single lock token URI, which
- refers to the lock.
-
- <!ELEMENT locktoken (href) >
-
-14.15. locktype XML Element
-
- Name: locktype
-
- Purpose: Specifies the access type of a lock. At present, this
- specification only defines one lock type, the write lock.
-
-
- <!ELEMENT locktype (write) >
-
-
-14.16. multistatus XML Element
-
- Name: multistatus
-
- Purpose: Contains multiple response messages.
-
- Description: The 'responsedescription' element at the top level is
- used to provide a general message describing the overarching
- nature of the response. If this value is available, an
- application may use it instead of presenting the individual
- response descriptions contained within the responses.
-
-
- <!ELEMENT multistatus (response*, responsedescription?) >
-
-
-14.17. owner XML Element
-
- Name: owner
-
- Purpose: Holds client-supplied information about the creator of a
- lock.
-
- Description: Allows a client to provide information sufficient for
- either directly contacting a principal (such as a telephone number
- or Email URI), or for discovering the principal (such as the URL
-
-
-
-Dusseault Standards Track [Page 85]
-
-RFC 4918 WebDAV June 2007
-
-
- of a homepage) who created a lock. The value provided MUST be
- treated as a dead property in terms of XML Information Item
- preservation. The server MUST NOT alter the value unless the
- owner value provided by the client is empty. For a certain amount
- of interoperability between different client implementations, if
- clients have URI-formatted contact information for the lock
- creator suitable for user display, then clients SHOULD put those
- URIs in 'href' child elements of the 'owner' element.
-
- Extensibility: MAY be extended with child elements, mixed content,
- text content or attributes.
-
- <!ELEMENT owner ANY >
-
-14.18. prop XML Element
-
- Name: prop
-
- Purpose: Contains properties related to a resource.
-
- Description: A generic container for properties defined on
- resources. All elements inside a 'prop' XML element MUST define
- properties related to the resource, although possible property
- names are in no way limited to those property names defined in
- this document or other standards. This element MUST NOT contain
- text or mixed content.
-
- <!ELEMENT prop ANY >
-
-14.19. propertyupdate XML Element
-
- Name: propertyupdate
-
- Purpose: Contains a request to alter the properties on a resource.
-
- Description: This XML element is a container for the information
- required to modify the properties on the resource.
-
- <!ELEMENT propertyupdate (remove | set)+ >
-
-14.20. propfind XML Element
-
- Name: propfind
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 86]
-
-RFC 4918 WebDAV June 2007
-
-
- Purpose: Specifies the properties to be returned from a PROPFIND
- method. Four special elements are specified for use with
- 'propfind': 'prop', 'allprop', 'include', and 'propname'. If
- 'prop' is used inside 'propfind', it MUST NOT contain property
- values.
-
- <!ELEMENT propfind ( propname | (allprop, include?) | prop ) >
-
-14.21. propname XML Element
-
- Name: propname
-
- Purpose: Specifies that only a list of property names on the
- resource is to be returned.
-
- <!ELEMENT propname EMPTY >
-
-14.22. propstat XML Element
-
- Name: propstat
-
- Purpose: Groups together a prop and status element that is
- associated with a particular 'href' element.
-
- Description: The propstat XML element MUST contain one prop XML
- element and one status XML element. The contents of the prop XML
- element MUST only list the names of properties to which the result
- in the status element applies. The optional precondition/
- postcondition element and 'responsedescription' text also apply to
- the properties named in 'prop'.
-
- <!ELEMENT propstat (prop, status, error?, responsedescription?) >
-
-14.23. remove XML Element
-
- Name: remove
-
- Purpose: Lists the properties to be removed from a resource.
-
- Description: Remove instructs that the properties specified in prop
- should be removed. Specifying the removal of a property that does
- not exist is not an error. All the XML elements in a 'prop' XML
- element inside of a 'remove' XML element MUST be empty, as only
- the names of properties to be removed are required.
-
- <!ELEMENT remove (prop) >
-
-
-
-
-
-Dusseault Standards Track [Page 87]
-
-RFC 4918 WebDAV June 2007
-
-
-14.24. response XML Element
-
- Name: response
-
- Purpose: Holds a single response describing the effect of a method
- on resource and/or its properties.
-
- Description: The 'href' element contains an HTTP URL pointing to a
- WebDAV resource when used in the 'response' container. A
- particular 'href' value MUST NOT appear more than once as the
- child of a 'response' XML element under a 'multistatus' XML
- element. This requirement is necessary in order to keep
- processing costs for a response to linear time. Essentially, this
- prevents having to search in order to group together all the
- responses by 'href'. There are, however, no requirements
- regarding ordering based on 'href' values. The optional
- precondition/postcondition element and 'responsedescription' text
- can provide additional information about this resource relative to
- the request or result.
-
-
- <!ELEMENT response (href, ((href*, status)|(propstat+)),
- error?, responsedescription? , location?) >
-
-14.25. responsedescription XML Element
-
- Name: responsedescription
-
- Purpose: Contains information about a status response within a
- Multi-Status.
-
- Description: Provides information suitable to be presented to a
- user.
-
- <!ELEMENT responsedescription (#PCDATA) >
-
-14.26. set XML Element
-
- Name: set
-
- Purpose: Lists the property values to be set for a resource.
-
- Description: The 'set' element MUST contain only a 'prop' element.
- The elements contained by the 'prop' element inside the 'set'
- element MUST specify the name and value of properties that are set
- on the resource identified by Request-URI. If a property already
- exists, then its value is replaced. Language tagging information
- appearing in the scope of the 'prop' element (in the "xml:lang"
-
-
-
-Dusseault Standards Track [Page 88]
-
-RFC 4918 WebDAV June 2007
-
-
- attribute, if present) MUST be persistently stored along with the
- property, and MUST be subsequently retrievable using PROPFIND.
-
- <!ELEMENT set (prop) >
-
-14.27. shared XML Element
-
- Name: shared
-
- Purpose: Specifies a shared lock.
-
-
- <!ELEMENT shared EMPTY >
-
-
-14.28. status XML Element
-
- Name: status
-
- Purpose: Holds a single HTTP status-line.
-
- Value: status-line (defined in Section 6.1 of [RFC2616])
-
- <!ELEMENT status (#PCDATA) >
-
-14.29. timeout XML Element
-
- Name: timeout
-
- Purpose: The number of seconds remaining before a lock expires.
-
- Value: TimeType (defined in Section 10.7)
-
-
- <!ELEMENT timeout (#PCDATA) >
-
-14.30. write XML Element
-
- Name: write
-
- Purpose: Specifies a write lock.
-
-
- <!ELEMENT write EMPTY >
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 89]
-
-RFC 4918 WebDAV June 2007
-
-
-15. DAV Properties
-
- For DAV properties, the name of the property is also the same as the
- name of the XML element that contains its value. In the section
- below, the final line of each section gives the element type
- declaration using the format defined in [REC-XML]. The "Value"
- field, where present, specifies further restrictions on the allowable
- contents of the XML element using BNF (i.e., to further restrict the
- values of a PCDATA element).
-
- A protected property is one that cannot be changed with a PROPPATCH
- request. There may be other requests that would result in a change
- to a protected property (as when a LOCK request affects the value of
- DAV:lockdiscovery). Note that a given property could be protected on
- one type of resource, but not protected on another type of resource.
-
- A computed property is one with a value defined in terms of a
- computation (based on the content and other properties of that
- resource, or even of some other resource). A computed property is
- always a protected property.
-
- COPY and MOVE behavior refers to local COPY and MOVE operations.
-
- For properties defined based on HTTP GET response headers (DAV:get*),
- the header value could include LWS as defined in [RFC2616], Section
- 4.2. Server implementors SHOULD strip LWS from these values before
- using as WebDAV property values.
-
-15.1. creationdate Property
-
- Name: creationdate
-
- Purpose: Records the time and date the resource was created.
-
- Value: date-time (defined in [RFC3339], see the ABNF in Section
- 5.6.)
-
- Protected: MAY be protected. Some servers allow DAV:creationdate
- to be changed to reflect the time the document was created if that
- is more meaningful to the user (rather than the time it was
- uploaded). Thus, clients SHOULD NOT use this property in
- synchronization logic (use DAV:getetag instead).
-
- COPY/MOVE behavior: This property value SHOULD be kept during a
- MOVE operation, but is normally re-initialized when a resource is
- created with a COPY. It should not be set in a COPY.
-
-
-
-
-
-Dusseault Standards Track [Page 90]
-
-RFC 4918 WebDAV June 2007
-
-
- Description: The DAV:creationdate property SHOULD be defined on all
- DAV compliant resources. If present, it contains a timestamp of
- the moment when the resource was created. Servers that are
- incapable of persistently recording the creation date SHOULD
- instead leave it undefined (i.e. report "Not Found").
-
- <!ELEMENT creationdate (#PCDATA) >
-
-15.2. displayname Property
-
- Name: displayname
-
- Purpose: Provides a name for the resource that is suitable for
- presentation to a user.
-
- Value: Any text.
-
- Protected: SHOULD NOT be protected. Note that servers implementing
- [RFC2518] might have made this a protected property as this is a
- new requirement.
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: Contains a description of the resource that is
- suitable for presentation to a user. This property is defined on
- the resource, and hence SHOULD have the same value independent of
- the Request-URI used to retrieve it (thus, computing this property
- based on the Request-URI is deprecated). While generic clients
- might display the property value to end users, client UI designers
- must understand that the method for identifying resources is still
- the URL. Changes to DAV:displayname do not issue moves or copies
- to the server, but simply change a piece of meta-data on the
- individual resource. Two resources can have the same DAV:
- displayname value even within the same collection.
-
- <!ELEMENT displayname (#PCDATA) >
-
-15.3. getcontentlanguage Property
-
- Name: getcontentlanguage
-
- Purpose: Contains the Content-Language header value (from Section
- 14.12 of [RFC2616]) as it would be returned by a GET without
- accept headers.
-
- Value: language-tag (language-tag is defined in Section 3.10 of
- [RFC2616])
-
-
-
-Dusseault Standards Track [Page 91]
-
-RFC 4918 WebDAV June 2007
-
-
- Protected: SHOULD NOT be protected, so that clients can reset the
- language. Note that servers implementing [RFC2518] might have
- made this a protected property as this is a new requirement.
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: The DAV:getcontentlanguage property MUST be defined on
- any DAV-compliant resource that returns the Content-Language
- header on a GET.
-
- <!ELEMENT getcontentlanguage (#PCDATA) >
-
-15.4. getcontentlength Property
-
- Name: getcontentlength
-
- Purpose: Contains the Content-Length header returned by a GET
- without accept headers.
-
- Value: See Section 14.13 of [RFC2616].
-
- Protected: This property is computed, therefore protected.
-
- Description: The DAV:getcontentlength property MUST be defined on
- any DAV-compliant resource that returns the Content-Length header
- in response to a GET.
-
- COPY/MOVE behavior: This property value is dependent on the size of
- the destination resource, not the value of the property on the
- source resource.
-
- <!ELEMENT getcontentlength (#PCDATA) >
-
-15.5. getcontenttype Property
-
- Name: getcontenttype
-
- Purpose: Contains the Content-Type header value (from Section 14.17
- of [RFC2616]) as it would be returned by a GET without accept
- headers.
-
- Value: media-type (defined in Section 3.7 of [RFC2616])
-
- Protected: Potentially protected if the server prefers to assign
- content types on its own (see also discussion in Section 9.7.1).
-
-
-
-
-
-Dusseault Standards Track [Page 92]
-
-RFC 4918 WebDAV June 2007
-
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: This property MUST be defined on any DAV-compliant
- resource that returns the Content-Type header in response to a
- GET.
-
- <!ELEMENT getcontenttype (#PCDATA) >
-
-15.6. getetag Property
-
- Name: getetag
-
- Purpose: Contains the ETag header value (from Section 14.19 of
- [RFC2616]) as it would be returned by a GET without accept
- headers.
-
- Value: entity-tag (defined in Section 3.11 of [RFC2616])
-
- Protected: MUST be protected because this value is created and
- controlled by the server.
-
- COPY/MOVE behavior: This property value is dependent on the final
- state of the destination resource, not the value of the property
- on the source resource. Also note the considerations in
- Section 8.8.
-
- Description: The getetag property MUST be defined on any DAV-
- compliant resource that returns the Etag header. Refer to Section
- 3.11 of RFC 2616 for a complete definition of the semantics of an
- ETag, and to Section 8.6 for a discussion of ETags in WebDAV.
-
- <!ELEMENT getetag (#PCDATA) >
-
-15.7. getlastmodified Property
-
- Name: getlastmodified
-
- Purpose: Contains the Last-Modified header value (from Section
- 14.29 of [RFC2616]) as it would be returned by a GET method
- without accept headers.
-
- Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616])
-
- Protected: SHOULD be protected because some clients may rely on the
- value for appropriate caching behavior, or on the value of the
- Last-Modified header to which this property is linked.
-
-
-
-
-Dusseault Standards Track [Page 93]
-
-RFC 4918 WebDAV June 2007
-
-
- COPY/MOVE behavior: This property value is dependent on the last
- modified date of the destination resource, not the value of the
- property on the source resource. Note that some server
- implementations use the file system date modified value for the
- DAV:getlastmodified value, and this can be preserved in a MOVE
- even when the HTTP Last-Modified value SHOULD change. Note that
- since [RFC2616] requires clients to use ETags where provided, a
- server implementing ETags can count on clients using a much better
- mechanism than modification dates for offline synchronization or
- cache control. Also note the considerations in Section 8.8.
-
- Description: The last-modified date on a resource SHOULD only
- reflect changes in the body (the GET responses) of the resource.
- A change in a property only SHOULD NOT cause the last-modified
- date to change, because clients MAY rely on the last-modified date
- to know when to overwrite the existing body. The DAV:
- getlastmodified property MUST be defined on any DAV-compliant
- resource that returns the Last-Modified header in response to a
- GET.
-
- <!ELEMENT getlastmodified (#PCDATA) >
-
-15.8. lockdiscovery Property
-
- Name: lockdiscovery
-
- Purpose: Describes the active locks on a resource
-
- Protected: MUST be protected. Clients change the list of locks
- through LOCK and UNLOCK, not through PROPPATCH.
-
- COPY/MOVE behavior: The value of this property depends on the lock
- state of the destination, not on the locks of the source resource.
- Recall that locks are not moved in a MOVE operation.
-
- Description: Returns a listing of who has a lock, what type of lock
- he has, the timeout type and the time remaining on the timeout,
- and the associated lock token. Owner information MAY be omitted
- if it is considered sensitive. If there are no locks, but the
- server supports locks, the property will be present but contain
- zero 'activelock' elements. If there are one or more locks, an
- 'activelock' element appears for each lock on the resource. This
- property is NOT lockable with respect to write locks (Section 7).
-
- <!ELEMENT lockdiscovery (activelock)* >
-
-
-
-
-
-
-Dusseault Standards Track [Page 94]
-
-RFC 4918 WebDAV June 2007
-
-
-15.8.1. Example - Retrieving DAV:lockdiscovery
-
- >>Request
-
- PROPFIND /container/ HTTP/1.1
- Host: www.example.com
- Content-Length: xxxx
- Content-Type: application/xml; charset="utf-8"
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D='DAV:'>
- <D:prop><D:lockdiscovery/></D:prop>
- </D:propfind>
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/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.example.com/container/</D:href>
- <D:propstat>
- <D:prop>
- <D:lockdiscovery>
- <D:activelock>
- <D:locktype><D:write/></D:locktype>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:depth>0</D:depth>
- <D:owner>Jane Smith</D:owner>
- <D:timeout>Infinite</D:timeout>
- <D:locktoken>
- <D:href
- >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
- </D:locktoken>
- <D:lockroot>
- <D:href>http://www.example.com/container/</D:href>
- </D:lockroot>
- </D:activelock>
- </D:lockdiscovery>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
- </D:multistatus>
-
-
-
-
-Dusseault Standards Track [Page 95]
-
-RFC 4918 WebDAV June 2007
-
-
- This resource has a single exclusive write lock on it, with an
- infinite timeout.
-
-15.9. resourcetype Property
-
- Name: resourcetype
-
- Purpose: Specifies the nature of the resource.
-
- Protected: SHOULD be protected. Resource type is generally decided
- through the operation creating the resource (MKCOL vs PUT), not by
- PROPPATCH.
-
- COPY/MOVE behavior: Generally a COPY/MOVE of a resource results in
- the same type of resource at the destination.
-
- Description: MUST be defined on all DAV-compliant resources. Each
- child element identifies a specific type the resource belongs to,
- such as 'collection', which is the only resource type defined by
- this specification (see Section 14.3). If the element contains
- the 'collection' child element plus additional unrecognized
- elements, it should generally be treated as a collection. If the
- element contains no recognized child elements, it should be
- treated as a non-collection resource. The default value is empty.
- This element MUST NOT contain text or mixed content. Any custom
- child element is considered to be an identifier for a resource
- type.
-
- Example: (fictional example to show extensibility)
-
- <x:resourcetype xmlns:x="DAV:">
- <x:collection/>
- <f:search-results xmlns:f="http://www.example.com/ns"/>
- </x:resourcetype>
-
-15.10. supportedlock Property
-
- Name: supportedlock
-
- Purpose: To provide a listing of the lock capabilities supported by
- the resource.
-
- Protected: MUST be protected. Servers, not clients, determine what
- lock mechanisms are supported.
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 96]
-
-RFC 4918 WebDAV June 2007
-
-
- COPY/MOVE behavior: This property value is dependent on the kind of
- locks supported at the destination, not on the value of the
- property at the source resource. Servers attempting to COPY to a
- destination should not attempt to set this property at the
- destination.
-
- Description: Returns a listing of the combinations of scope and
- access types that may be specified in a lock request on the
- resource. Note that the actual contents are themselves controlled
- by access controls, so a server is not required to provide
- information the client is not authorized to see. This property is
- NOT lockable with respect to write locks (Section 7).
-
- <!ELEMENT supportedlock (lockentry)* >
-
-15.10.1. Example - Retrieving DAV:supportedlock
-
- >>Request
-
- PROPFIND /container/ HTTP/1.1
- Host: www.example.com
- Content-Length: xxxx
- Content-Type: application/xml; charset="utf-8"
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:">
- <D:prop><D:supportedlock/></D:prop>
- </D:propfind>
-
- >>Response
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/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.example.com/container/</D:href>
- <D:propstat>
- <D:prop>
- <D:supportedlock>
- <D:lockentry>
- <D:lockscope><D:exclusive/></D:lockscope>
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- <D:lockentry>
- <D:lockscope><D:shared/></D:lockscope>
-
-
-
-Dusseault Standards Track [Page 97]
-
-RFC 4918 WebDAV June 2007
-
-
- <D:locktype><D:write/></D:locktype>
- </D:lockentry>
- </D:supportedlock>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
- </D:multistatus>
-
-16. Precondition/Postcondition XML Elements
-
- As introduced in Section 8.7, extra information on error conditions
- can be included in the body of many status responses. This section
- makes requirements on the use of the error body mechanism and
- introduces a number of precondition and postcondition codes.
-
- 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.
-
- Each precondition and postcondition has a unique XML element
- associated with it. In a 207 Multi-Status response, the XML element
- MUST appear inside an 'error' element in the appropriate 'propstat or
- 'response' element depending on whether the condition applies to one
- or more properties or to the resource as a whole. In all other error
- responses where this specification's 'error' body is used, the
- precondition/postcondition XML element MUST be returned as the child
- of a top-level 'error' element in the response body, unless otherwise
- negotiated by the request, along with an appropriate response status.
- The most common response status codes are 403 (Forbidden) if the
- request should not be repeated because it will always fail, and 409
- (Conflict) if it is expected that the user might be able to resolve
- the conflict and resubmit the request. The 'error' element MAY
- contain child elements with specific error information and MAY be
- extended with any custom child elements.
-
- This mechanism does not take the place of using a correct numeric
- status code as defined here or in HTTP, because the client must
- always be able to take a reasonable course of action based only on
- the numeric code. However, it does remove the need to define new
- numeric codes. The new machine-readable codes used for this purpose
- are XML elements classified as preconditions and postconditions, so
- naturally, any group defining a new condition code can use their own
- namespace. As always, the "DAV:" namespace is reserved for use by
- IETF-chartered WebDAV working groups.
-
-
-
-
-
-Dusseault Standards Track [Page 98]
-
-RFC 4918 WebDAV June 2007
-
-
- A server supporting this specification SHOULD use the XML error
- whenever a precondition or postcondition defined in this document is
- violated. For error conditions not specified in this document, the
- server MAY simply choose an appropriate numeric status and leave the
- response body blank. However, a server MAY instead use a custom
- condition code and other supporting text, because even when clients
- do not automatically recognize condition codes, they can be quite
- useful in interoperability testing and debugging.
-
- Example - Response with precondition code
-
- >>Response
-
- HTTP/1.1 423 Locked
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:error xmlns:D="DAV:">
- <D:lock-token-submitted>
- <D:href>/workspace/webdav/</D:href>
- </D:lock-token-submitted>
- </D:error>
-
- In this example, a client unaware of a depth-infinity lock on the
- parent collection "/workspace/webdav/" attempted to modify the
- collection member "/workspace/webdav/proposal.doc".
-
- Some other useful preconditions and postconditions have been defined
- in other specifications extending WebDAV, such as [RFC3744] (see
- particularly Section 7.1.1), [RFC3253], and [RFC3648].
-
- All these elements are in the "DAV:" namespace. If not specified
- otherwise, the content for each condition's XML element is defined to
- be empty.
-
-
- Name: lock-token-matches-request-uri
-
- Use with: 409 Conflict
-
- Purpose: (precondition) -- A request may include a Lock-Token header
- to identify a lock for the UNLOCK method. However, if the
- Request-URI does not fall within the scope of the lock identified
- by the token, the server SHOULD use this error. The lock may have
- a scope that does not include the Request-URI, or the lock could
- have disappeared, or the token may be invalid.
-
-
-
-
-Dusseault Standards Track [Page 99]
-
-RFC 4918 WebDAV June 2007
-
-
- Name: lock-token-submitted (precondition)
-
- Use with: 423 Locked
-
- Purpose: The request could not succeed because a lock token should
- have been submitted. This element, if present, MUST contain at
- least one URL of a locked resource that prevented the request. In
- cases of MOVE, COPY, and DELETE where collection locks are
- involved, it can be difficult for the client to find out which
- locked resource made the request fail -- but the server is only
- responsible for returning one such locked resource. The server
- MAY return every locked resource that prevented the request from
- succeeding if it knows them all.
-
- <!ELEMENT lock-token-submitted (href+) >
-
-
- Name: no-conflicting-lock (precondition)
-
- Use with: Typically 423 Locked
-
- Purpose: A LOCK request failed due the presence of an already
- existing conflicting lock. Note that a lock can be in conflict
- although the resource to which the request was directed is only
- indirectly locked. In this case, the precondition code can be
- used to inform the client about the resource that is the root of
- the conflicting lock, avoiding a separate lookup of the
- "lockdiscovery" property.
-
- <!ELEMENT no-conflicting-lock (href)* >
-
-
- Name: no-external-entities
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- If the server rejects a client request
- because the request body contains an external entity, the server
- SHOULD use this error.
-
-
- Name: preserved-live-properties
-
- Use with: 409 Conflict
-
- Purpose: (postcondition) -- The server received an otherwise-valid
- MOVE or COPY request, but cannot maintain the live properties with
- the same behavior at the destination. It may be that the server
-
-
-
-Dusseault Standards Track [Page 100]
-
-RFC 4918 WebDAV June 2007
-
-
- only supports some live properties in some parts of the
- repository, or simply has an internal error.
-
-
- Name: propfind-finite-depth
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- This server does not allow infinite-depth
- PROPFIND requests on collections.
-
-
- Name: cannot-modify-protected-property
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The client attempted to set a protected
- property in a PROPPATCH (such as DAV:getetag). See also
- [RFC3253], Section 3.12.
-
-17. XML Extensibility in DAV
-
- The XML namespace extension ([REC-XML-NAMES]) is used in this
- specification in order to allow for new XML elements to be added
- without fear of colliding with other element names. 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 SHOULD NOT be used in the request or
- response body unless that XML element is explicitly defined in an
- IETF RFC reviewed by a WebDAV working group.
-
- For WebDAV to be both extensible and backwards-compatible, both
- clients and servers need to know how to behave when unexpected or
- unrecognized command extensions are received. For XML processing,
- this means that clients and servers MUST process received XML
- documents as if unexpected elements and attributes (and all children
- of unrecognized elements) were not there. An unexpected element or
- attribute includes one that may be used in another context but is not
- expected here. Ignoring such items for purposes of processing can of
- course be consistent with logging all information or presenting for
- debugging.
-
- This restriction also applies to the processing, by clients, of DAV
- property values where unexpected XML elements SHOULD be ignored
- unless the property's schema declares otherwise.
-
- This restriction does not apply to setting dead DAV properties on the
- server where the server MUST record all XML elements.
-
-
-
-Dusseault Standards Track [Page 101]
-
-RFC 4918 WebDAV June 2007
-
-
- Additionally, this restriction does not apply to the use of XML where
- XML happens to be the content type of the entity body, for example,
- when used as the body of a PUT.
-
- Processing instructions in XML SHOULD be ignored by recipients.
- Thus, specifications extending WebDAV SHOULD NOT use processing
- instructions to define normative behavior.
-
- XML DTD fragments are included for all the XML elements defined in
- this specification. However, correct XML will not be valid according
- to any DTD due to namespace usage and extension rules. In
- particular:
-
- o Elements (from this specification) are in the "DAV:" namespace,
-
- o Element ordering is irrelevant unless otherwise stated,
-
- o Extension attributes MAY be added,
-
- o For element type definitions of "ANY", the normative text
- definition for that element defines what can be in it and what
- that means.
-
- o For element type definitions of "#PCDATA", extension elements MUST
- NOT be added.
-
- o For other element type definitions, including "EMPTY", extension
- elements MAY be added.
-
- Note that this means that elements containing elements cannot be
- extended to contain text, and vice versa.
-
- With DTD validation relaxed by the rules above, the constraints
- described by the DTD fragments are normative (see for example
- Appendix A). A recipient of a WebDAV message with an XML body MUST
- NOT validate the XML document according to any hard-coded or
- dynamically-declared DTD.
-
- Note that this section describes backwards-compatible extensibility
- rules. There might also be times when an extension is designed not
- to be backwards-compatible, for example, defining an extension that
- reuses an XML element defined in this document but omitting one of
- the child elements required by the DTDs in this specification.
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 102]
-
-RFC 4918 WebDAV June 2007
-
-
-18. DAV Compliance Classes
-
- A DAV-compliant resource can advertise several classes of compliance.
- A client can discover the compliance classes of a resource by
- executing OPTIONS on the resource and examining the "DAV" header
- which is returned. Note particularly that resources, rather than
- servers, are spoken of as being compliant. That is because
- theoretically some resources on a server could support different
- feature sets. For example, a server could have a sub-repository
- where an advanced feature like versioning was supported, even if that
- feature was not supported on all sub-repositories.
-
- Since this document describes extensions to the HTTP/1.1 protocol,
- minimally all DAV-compliant resources, clients, and proxies MUST be
- compliant with [RFC2616].
-
- A resource that is class 2 or class 3 compliant must also be class 1
- compliant.
-
-18.1. Class 1
-
- A class 1 compliant resource MUST meet all "MUST" requirements in all
- sections of this document.
-
- Class 1 compliant resources MUST return, at minimum, the value "1" in
- the DAV header on all responses to the OPTIONS method.
-
-18.2. Class 2
-
- A class 2 compliant resource MUST meet all class 1 requirements and
- support the LOCK method, the DAV:supportedlock property, the DAV:
- lockdiscovery property, the Time-Out response header and the Lock-
- Token request header. A class 2 compliant resource SHOULD also
- support the Timeout request header and the 'owner' XML element.
-
- Class 2 compliant resources MUST return, at minimum, the values "1"
- and "2" in the DAV header on all responses to the OPTIONS method.
-
-18.3. Class 3
-
- A resource can explicitly advertise its support for the revisions to
- [RFC2518] made in this document. Class 1 MUST be supported as well.
- Class 2 MAY be supported. Advertising class 3 support in addition to
- class 1 and 2 means that the server supports all the requirements in
- this specification. Advertising class 3 and class 1 support, but not
- class 2, means that the server supports all the requirements in this
- specification except possibly those that involve locking support.
-
-
-
-
-Dusseault Standards Track [Page 103]
-
-RFC 4918 WebDAV June 2007
-
-
- Example:
-
- DAV: 1, 3
-
-19. Internationalization Considerations
-
- In the realm of internationalization, this specification complies
- with the IETF Character Set Policy [RFC2277]. In this specification,
- human-readable fields can be found either in the value of a property,
- or in an error message returned in a response entity body. In both
- cases, the human-readable content is encoded using XML, which has
- explicit provisions for character set tagging and encoding, and
- requires that XML processors read XML elements encoded, at minimum,
- using the UTF-8 [RFC3629] and UTF-16 [RFC2781] encodings of the ISO
- 10646 multilingual plane. XML examples in this specification
- demonstrate use of the charset parameter of the Content-Type header
- (defined in [RFC3023]), as well as XML charset declarations.
-
- XML also provides a language tagging capability for specifying the
- language of the contents of a particular XML element. The "xml:lang"
- attribute appears on an XML element to identify the language of its
- content and attributes. See [REC-XML] for definitions of values and
- scoping.
-
- WebDAV applications MUST support the character set tagging, character
- set encoding, and the language tagging functionality of the XML
- specification. Implementors of WebDAV applications are strongly
- encouraged to read "XML Media Types" [RFC3023] for instruction on
- which MIME media type to use for XML transport, and on use of the
- charset parameter of the Content-Type header.
-
- Names used within this specification fall into four categories: names
- of protocol elements such as methods and headers, names of XML
- elements, names of properties, and names of conditions. Naming of
- protocol elements follows the precedent of HTTP, using English names
- encoded in US-ASCII for methods and headers. Since these protocol
- elements are not visible to users, and are simply long token
- identifiers, they do not need to support multiple languages.
- Similarly, the names of XML elements used in this specification are
- not visible to the user and hence do not need to support multiple
- languages.
-
- WebDAV property names are qualified XML names (pairs of XML namespace
- name and local name). Although some applications (e.g., a generic
- property viewer) will display property names directly to their users,
- it is expected that the typical application will use a fixed set of
- properties, and will provide a mapping from the property name and
- namespace to a human-readable field when displaying the property name
-
-
-
-Dusseault Standards Track [Page 104]
-
-RFC 4918 WebDAV June 2007
-
-
- to a user. It is only in the case where the set of properties is not
- known ahead of time that an application need display a property name
- to a user. We recommend that applications provide human-readable
- property names wherever feasible.
-
- For error reporting, we follow the convention of HTTP/1.1 status
- codes, including with each status code a short, English description
- of the code (e.g., 423 (Locked)). While the possibility exists that
- a poorly crafted user agent would display this message to a user,
- internationalized applications will ignore this message, and display
- an appropriate message in the user's language and character set.
-
- Since interoperation of clients and servers does not require locale
- information, this specification does not specify any mechanism for
- transmission of this information.
-
-20. Security Considerations
-
- This section is provided to detail issues concerning security
- implications of which WebDAV applications need to be aware.
-
- All of the security considerations of HTTP/1.1 (discussed in
- [RFC2616]) and XML (discussed in [RFC3023]) also apply to WebDAV. In
- addition, the security risks inherent in remote authoring require
- stronger authentication technology, introduce several new privacy
- concerns, and may increase the hazards from poor server design.
- These issues are detailed below.
-
-20.1. Authentication of Clients
-
- Due to their emphasis on authoring, WebDAV servers need to use
- authentication technology to protect not just access to a network
- resource, but the integrity of the resource as well. Furthermore,
- the introduction of locking functionality requires support for
- authentication.
-
- A password sent in the clear over an insecure channel is an
- inadequate means for protecting the accessibility and integrity of a
- resource as the password may be intercepted. Since Basic
- authentication for HTTP/1.1 performs essentially clear text
- transmission of a password, Basic authentication MUST NOT be used to
- authenticate a WebDAV client to a server unless the connection is
- secure. Furthermore, a WebDAV server MUST NOT send a Basic
- authentication challenge in a WWW-Authenticate header unless the
- connection is secure. An example of a secure connection would be a
- Transport Layer Security (TLS) connection employing a strong cipher
- suite and server authentication.
-
-
-
-
-Dusseault Standards Track [Page 105]
-
-RFC 4918 WebDAV June 2007
-
-
- WebDAV applications MUST support the Digest authentication scheme
- [RFC2617]. Since Digest authentication verifies that both parties to
- a communication know a shared secret, a password, without having to
- send that secret in the clear, Digest authentication avoids the
- security problems inherent in Basic authentication while providing a
- level of authentication that is useful in a wide range of scenarios.
-
-20.2. Denial of Service
-
- Denial-of-service attacks are of special concern to WebDAV servers.
- WebDAV plus HTTP enables denial-of-service attacks on every part of a
- system's resources.
-
- o The underlying storage can be attacked by PUTting extremely large
- files.
-
- o Asking for recursive operations on large collections can attack
- processing time.
-
- o Making multiple pipelined requests on multiple connections can
- attack network connections.
-
- WebDAV servers need to be aware of the possibility of a denial-of-
- service attack at all levels. The proper response to such an attack
- MAY be to simply drop the connection. Or, if the server is able to
- make a response, the server MAY use a 400-level status request such
- as 400 (Bad Request) and indicate why the request was refused (a 500-
- level status response would indicate that the problem is with the
- server, whereas unintentional DoS attacks are something the client is
- capable of remedying).
-
-20.3. Security through Obscurity
-
- WebDAV provides, through the PROPFIND method, a mechanism for listing
- the member resources of a collection. This greatly diminishes the
- effectiveness of security or privacy techniques that rely only on the
- difficulty of discovering the names of network resources. Users of
- WebDAV servers are encouraged to use access control techniques to
- prevent unwanted access to resources, rather than depending on the
- relative obscurity of their resource names.
-
-20.4. Privacy Issues Connected to Locks
-
- When submitting a lock request, a user agent may also submit an
- 'owner' XML field giving contact information for the person taking
- out the lock (for those cases where a person, rather than a robot, is
- taking out the lock). This contact information is stored in a DAV:
- lockdiscovery property on the resource, and can be used by other
-
-
-
-Dusseault Standards Track [Page 106]
-
-RFC 4918 WebDAV June 2007
-
-
- collaborators to begin negotiation over access to the resource.
- However, in many cases, this contact information can be very private,
- and should not be widely disseminated. Servers SHOULD limit read
- access to the DAV:lockdiscovery property as appropriate.
- Furthermore, user agents SHOULD provide control over whether contact
- information is sent at all, and if contact information is sent,
- control over exactly what information is sent.
-
-20.5. Privacy Issues Connected to Properties
-
- Since property values are typically used to hold information such as
- the author of a document, there is the possibility that privacy
- concerns could arise stemming from widespread access to a resource's
- property data. To reduce the risk of inadvertent release of private
- information via properties, servers are encouraged to develop access
- control mechanisms that separate read access to the resource body and
- read access to the resource's properties. This allows a user to
- control the dissemination of their property data without overly
- restricting access to the resource's contents.
-
-20.6. Implications of XML Entities
-
- XML supports a facility known as "external entities", defined in
- Section 4.2.2 of [REC-XML], which instructs an XML processor to
- retrieve and include additional XML. An external XML entity can be
- used to append or modify the document type declaration (DTD)
- associated with an XML document. An external XML entity can also be
- used to include XML within the content of an XML document. For non-
- validating XML, such as the XML used in this specification, including
- an external XML entity is not required by XML. However, XML does
- state that an XML processor may, at its discretion, include the
- external XML entity.
-
- External XML entities have no inherent trustworthiness and are
- subject to all the attacks that are endemic to any HTTP GET request.
- Furthermore, it is possible for an external XML entity to modify the
- DTD, and hence affect the final form of an XML document, in the worst
- case, significantly modifying its semantics or exposing the XML
- processor to the security risks discussed in [RFC3023]. Therefore,
- implementers must be aware that external XML entities should be
- treated as untrustworthy. If a server chooses not to handle external
- XML entities, it SHOULD respond to requests containing external
- entities with the 'no-external-entities' condition code.
-
- There is also the scalability risk that would accompany a widely
- deployed application that made use of external XML entities. In this
- situation, it is possible that there would be significant numbers of
- requests for one external XML entity, potentially overloading any
-
-
-
-Dusseault Standards Track [Page 107]
-
-RFC 4918 WebDAV June 2007
-
-
- server that fields requests for the resource containing the external
- XML entity.
-
- Furthermore, there's also a risk based on the evaluation of "internal
- entities" as defined in Section 4.2.2 of [REC-XML]. A small,
- carefully crafted request using nested internal entities may require
- enormous amounts of memory and/or processing time to process. Server
- implementers should be aware of this risk and configure their XML
- parsers so that requests like these can be detected and rejected as
- early as possible.
-
-20.7. Risks Connected with Lock Tokens
-
- This specification encourages the use of "A Universally Unique
- Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens
- (Section 6.5), in order to guarantee their uniqueness across space
- and time. Version 1 UUIDs (defined in Section 4) MAY contain a
- "node" field that "consists of an IEEE 802 MAC address, usually the
- host address. For systems with multiple IEEE addresses, any
- available one can be used". Since a WebDAV server will issue many
- locks over its lifetime, the implication is that it may also be
- publicly exposing its IEEE 802 address.
-
- There are several risks associated with exposure of IEEE 802
- addresses. Using the IEEE 802 address:
-
- o It is possible to track the movement of hardware from subnet to
- subnet.
-
- o It may be possible to identify the manufacturer of the hardware
- running a WebDAV server.
-
- o It may be possible to determine the number of each type of
- computer running WebDAV.
-
- This risk only applies to host-address-based UUID versions. Section
- 4 of [RFC4122] describes several other mechanisms for generating
- UUIDs that do not involve the host address and therefore do not
- suffer from this risk.
-
-20.8. Hosting Malicious Content
-
- HTTP has the ability to host programs that are executed on client
- machines. These programs can take many forms including Web scripts,
- executables, plug-in modules, and macros in documents. WebDAV does
- not change any of the security concerns around these programs, yet
- often WebDAV is used in contexts where a wide range of users can
- publish documents on a server. The server might not have a close
-
-
-
-Dusseault Standards Track [Page 108]
-
-RFC 4918 WebDAV June 2007
-
-
- trust relationship with the author that is publishing the document.
- Servers that allow clients to publish arbitrary content can usefully
- implement precautions to check that content published to the server
- is not harmful to other clients. Servers could do this by techniques
- such as restricting the types of content that is allowed to be
- published and running virus and malware detection software on
- published content. Servers can also mitigate the risk by having
- appropriate access restriction and authentication of users that are
- allowed to publish content to the server.
-
-21. IANA Considerations
-
-21.1. New URI Schemes
-
- This specification defines two URI schemes:
-
- 1. the "opaquelocktoken" scheme defined in Appendix C, and
-
- 2. the "DAV" URI scheme, which historically was used in [RFC2518] to
- disambiguate WebDAV property and XML element names and which
- continues to be used for that purpose in this specification and
- others extending WebDAV. Creation of identifiers in the "DAV:"
- namespace is controlled by the IETF.
-
- Note that defining new URI schemes for XML namespaces is now
- discouraged. "DAV:" was defined before standard best practices
- emerged.
-
-21.2. XML Namespaces
-
- XML namespaces disambiguate WebDAV property names and XML elements.
- Any WebDAV user or application can define a new namespace in order to
- create custom properties or extend WebDAV XML syntax. IANA does not
- need to manage such namespaces, property names, or element names.
-
-21.3. Message Header Fields
-
- The message header fields below should be added to the permanent
- registry (see [RFC3864]).
-
-21.3.1. DAV
-
- Header field name: DAV
-
- Applicable protocol: http
-
- Status: standard
-
-
-
-
-Dusseault Standards Track [Page 109]
-
-RFC 4918 WebDAV June 2007
-
-
- Author/Change controller: IETF
-
- Specification document: this specification (Section 10.1)
-
-21.3.2. Depth
-
- Header field name: Depth
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document: this specification (Section 10.2)
-
-21.3.3. Destination
-
- Header field name: Destination
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document: this specification (Section 10.3)
-
-21.3.4. If
-
- Header field name: If
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document: this specification (Section 10.4)
-
-21.3.5. Lock-Token
-
- Header field name: Lock-Token
-
- Applicable protocol: http
-
- Status: standard
-
-
-
-
-Dusseault Standards Track [Page 110]
-
-RFC 4918 WebDAV June 2007
-
-
- Author/Change controller: IETF
-
- Specification document: this specification (Section 10.5)
-
-21.3.6. Overwrite
-
- Header field name: Overwrite
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document: this specification (Section 10.6)
-
-21.3.7. Timeout
-
- Header field name: Timeout
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document: this specification (Section 10.7)
-
-21.4. HTTP Status Codes
-
- This specification defines the HTTP status codes
-
- o 207 Multi-Status (Section 11.1)
-
- o 422 Unprocessable Entity (Section 11.2),
-
- o 423 Locked (Section 11.3),
-
- o 424 Failed Dependency (Section 11.4) and
-
- o 507 Insufficient Storage (Section 11.5),
-
- to be updated in the registry at
- <http://www.iana.org/assignments/http-status-codes>.
-
- Note: the HTTP status code 102 (Processing) has been removed in this
- specification; its IANA registration should continue to reference RFC
- 2518.
-
-
-
-Dusseault Standards Track [Page 111]
-
-RFC 4918 WebDAV June 2007
-
-
-22. Acknowledgements
-
- A specification such as this thrives on piercing critical review and
- withers from apathetic neglect. The authors gratefully acknowledge
- the contributions of the following people, whose insights were so
- valuable at every stage of our work.
-
- Contributors to RFC 2518
-
- Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
- Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
- Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
- Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
- Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
- Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
- Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der
- Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven
- Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten,
- Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff,
- Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike
- Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi,
- Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran,
- Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
-
- Two from this list deserve special mention. The contributions by
- Larry Masinter have been invaluable; he both helped the formation of
- the working group and patiently coached the authors along the way.
- In so many ways he has set high standards that we have toiled to
- meet. The contributions of Judith Slein were also invaluable; by
- clarifying the requirements and in patiently reviewing version after
- version, she both improved this specification and expanded our minds
- on document management.
-
- We would also like to thank John Turner for developing the XML DTD.
-
- The authors of RFC 2518 were Yaron Goland, Jim Whitehead, A. Faizi,
- Steve Carter, and D. Jensen. Although their names had to be removed
- due to IETF author count restrictions, they can take credit for the
- majority of the design of WebDAV.
-
- Additional Acknowledgements for This Specification
-
- Significant contributors of text for this specification are listed as
- contributors in the section below. We must also gratefully
- acknowledge Geoff Clemm, Joel Soderberg, and Dan Brotsky for hashing
- out specific text on the list or in meetings. Joe Hildebrand and
- Cullen Jennings helped close many issues. Barry Lind described an
- additional security consideration and Cullen Jennings provided text
-
-
-
-Dusseault Standards Track [Page 112]
-
-RFC 4918 WebDAV June 2007
-
-
- for that consideration. Jason Crawford tracked issue status for this
- document for a period of years, followed by Elias Sinderson.
-
-23. Contributors to This Specification
-
- Julian Reschke
- <green/>bytes GmbH
- Hafenweg 16, 48155 Muenster, Germany
- EMail: julian.reschke at greenbytes.de
-
-
- Elias Sinderson
- University of California, Santa Cruz
- 1156 High Street, Santa Cruz, CA 95064
- EMail: elias at cse.ucsc.edu
-
-
- Jim Whitehead
- University of California, Santa Cruz
- 1156 High Street, Santa Cruz, CA 95064
- EMail: ejw at soe.ucsc.edu
-
-24. Authors of RFC 2518
-
- Y. Y. Goland
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052-6399
- EMail: yarong at microsoft.com
-
-
- E. J. Whitehead, Jr.
- Dept. Of Information and Computer Science
- University of California, Irvine
- Irvine, CA 92697-3425
- EMail: ejw at ics.uci.edu
-
-
- A. Faizi
- Netscape
- 685 East Middlefield Road
- Mountain View, CA 94043
- EMail: asad at netscape.com
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 113]
-
-RFC 4918 WebDAV June 2007
-
-
- S. R. Carter
- Novell
- 1555 N. Technology Way
- M/S ORM F111
- Orem, UT 84097-2399
- EMail: srcarter at novell.com
-
-
- D. Jensen
- Novell
- 1555 N. Technology Way
- M/S ORM F111
- Orem, UT 84097-2399
- EMail: dcjensen at novell.com
-
-25. References
-
-25.1. Normative References
-
- [REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler,
- E., and F. Yergeau, "Extensible Markup Language
- (XML) 1.0 (Fourth Edition)", W3C REC-xml-20060816,
- August 2006,
- <http://www.w3.org/TR/2006/REC-xml-20060816/>.
-
- [REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set
- (Second Edition)", W3C REC-xml-infoset-20040204,
- February 2004, <http://www.w3.org/TR/2004/
- REC-xml-infoset-20040204/>.
-
- [REC-XML-NAMES] Bray, T., Hollander, D., Layman, A., and R. Tobin,
- "Namespaces in XML 1.0 (Second Edition)", W3C REC-
- xml-names-20060816, August 2006, <http://
- www.w3.org/TR/2006/REC-xml-names-20060816/>.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to
- Indicate Requirement Levels", BCP 14, RFC 2119,
- March 1997.
-
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
- Languages", BCP 18, RFC 2277, January 1998.
-
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., and T. Berners-Lee,
- "Hypertext Transfer Protocol -- HTTP/1.1",
- RFC 2616, June 1999.
-
-
-
-
-
-Dusseault Standards Track [Page 114]
-
-RFC 4918 WebDAV June 2007
-
-
- [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J.,
- Lawrence, S., Leach, P., Luotonen, A., and L.
- Stewart, "HTTP Authentication: Basic and Digest
- Access Authentication", RFC 2617, June 1999.
-
- [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on
- the Internet: Timestamps", RFC 3339, July 2002.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of
- ISO 10646", STD 63, RFC 3629, November 2003.
-
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
- "Uniform Resource Identifier (URI): Generic
- Syntax", STD 66, RFC 3986, January 2005.
-
- [RFC4122] Leach, P., Mealling, M., and R. Salz, "A
- Universally Unique IDentifier (UUID) URN
- Namespace", RFC 4122, July 2005.
-
-25.2. Informative References
-
- [RFC2291] Slein, J., Vitali, F., Whitehead, E., and D.
- Durand, "Requirements for a Distributed Authoring
- and Versioning Protocol for the World Wide Web",
- RFC 2291, February 1998.
-
- [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S.,
- and D. Jensen, "HTTP Extensions for Distributed
- Authoring -- WEBDAV", RFC 2518, February 1999.
-
- [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding
- of ISO 10646", RFC 2781, February 2000.
-
- [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML
- Media Types", RFC 3023, January 2001.
-
- [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and
- J. Whitehead, "Versioning Extensions to WebDAV
- (Web Distributed Authoring and Versioning)",
- RFC 3253, March 2002.
-
- [RFC3648] Whitehead, J. and J. Reschke, Ed., "Web
- Distributed Authoring and Versioning (WebDAV)
- Ordered Collections Protocol", RFC 3648,
- December 2003.
-
-
-
-
-
-
-Dusseault Standards Track [Page 115]
-
-RFC 4918 WebDAV June 2007
-
-
- [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J.
- Whitehead, "Web Distributed Authoring and
- Versioning (WebDAV) Access Control Protocol",
- RFC 3744, May 2004.
-
- [RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
- "Registration Procedures for Message Header
- Fields", BCP 90, RFC 3864, September 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 116]
-
-RFC 4918 WebDAV June 2007
-
-
-Appendix A. Notes on Processing XML Elements
-
-A.1. Notes on Empty XML Elements
-
- XML supports two mechanisms for indicating that an XML element does
- not have any content. The first is to declare an XML element of the
- form <A></A>. The second is to declare an XML element of the form
- <A/>. The two XML elements are semantically identical.
-
-A.2. Notes on Illegal XML Processing
-
- XML is a flexible data format that makes it easy to submit data that
- appears legal but in fact is not. The philosophy of "Be flexible in
- what you accept and strict in what you send" still applies, but it
- must not be applied inappropriately. XML is extremely flexible in
- dealing with issues of whitespace, element ordering, inserting new
- elements, etc. This flexibility does not require extension,
- especially not in the area of the meaning of elements.
-
- There is no kindness in accepting illegal combinations of XML
- elements. At best, it will cause an unwanted result and at worst it
- can cause real damage.
-
-A.3. Example - XML Syntax Error
-
- The following request body for a PROPFIND method is illegal.
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:">
- <D:allprop/>
- <D:propname/>
- </D:propfind>
-
- The definition of the propfind element only allows for the allprop or
- the propname element, not both. Thus, the above is an error and must
- be responded to with a 400 (Bad Request).
-
- Imagine, however, that a server wanted to be "kind" and decided to
- pick the allprop element as the true element and respond to it. A
- client running over a bandwidth limited line who intended to execute
- a propname would be in for a big surprise if the server treated the
- command as an allprop.
-
- Additionally, if a server were lenient and decided to reply to this
- request, the results would vary randomly from server to server, with
- some servers executing the allprop directive, and others executing
- the propname directive. This reduces interoperability rather than
- increasing it.
-
-
-
-Dusseault Standards Track [Page 117]
-
-RFC 4918 WebDAV June 2007
-
-
-A.4. Example - Unexpected XML Element
-
- The previous example was illegal because it contained two elements
- that were explicitly banned from appearing together in the propfind
- element. However, XML is an extensible language, so one can imagine
- new elements being defined for use with propfind. Below is the
- request body of a PROPFIND and, like the previous example, must be
- rejected with a 400 (Bad Request) by a server that does not
- understand the expired-props element.
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:"
- xmlns:E="http://www.example.com/standards/props/">
- <E:expired-props/>
- </D:propfind>
-
- To understand why a 400 (Bad Request) is returned, let us look at the
- request body as the server unfamiliar with expired-props sees it.
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:"
- xmlns:E="http://www.example.com/standards/props/">
- </D:propfind>
-
- As the server does not understand the 'expired-props' element,
- according to the WebDAV-specific XML processing rules specified in
- Section 17, it must process the request as if the element were not
- there. Thus, the server sees an empty propfind, which by the
- definition of the propfind element is illegal.
-
- Please note that had the extension been additive, it would not
- necessarily have resulted in a 400 (Bad Request). For example,
- imagine the following request body for a PROPFIND:
-
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:propfind xmlns:D="DAV:"
- xmlns:E="http://www.example.com/standards/props/">
- <D:propname/>
- <E:leave-out>*boss*</E:leave-out>
- </D:propfind>
-
- The previous example contains the fictitious element leave-out. Its
- purpose is to prevent the return of any property whose name matches
- the submitted pattern. If the previous example were submitted to a
- server unfamiliar with 'leave-out', the only result would be that the
- 'leave-out' element would be ignored and a propname would be
- executed.
-
-
-
-Dusseault Standards Track [Page 118]
-
-RFC 4918 WebDAV June 2007
-
-
-Appendix B. Notes on HTTP Client Compatibility
-
- WebDAV was designed to be, and has been found to be, backward-
- compatible with HTTP 1.1. The PUT and DELETE methods are defined in
- HTTP and thus may be used by HTTP clients as well as WebDAV-aware
- clients, but the responses to PUT and DELETE have been extended in
- this specification in ways that only a WebDAV client would be
- entirely prepared for. Some theoretical concerns were raised about
- whether those responses would cause interoperability problems with
- HTTP-only clients, and this section addresses those concerns.
-
- Since any HTTP client ought to handle unrecognized 400-level and 500-
- level status codes as errors, the following new status codes should
- not present any issues: 422, 423, and 507 (424 is also a new status
- code but it appears only in the body of a Multistatus response.) So,
- for example, if an HTTP client attempted to PUT or DELETE a locked
- resource, the 423 Locked response ought to result in a generic error
- presented to the user.
-
- The 207 Multistatus response is interesting because an HTTP client
- issuing a DELETE request to a collection might interpret a 207
- response as a success, even though it does not realize the resource
- is a collection and cannot understand that the DELETE operation might
- have been a complete or partial failure. That interpretation isn't
- entirely justified, because a 200-level response indicates that the
- server "received, understood, and accepted" the request, not that the
- request resulted in complete success.
-
- One option is that a server could treat a DELETE of a collection as
- an atomic operation, and use either 204 No Content in case of
- success, or some appropriate error response (400 or 500 level) for an
- error. This approach would indeed maximize backward compatibility.
- However, since interoperability tests and working group discussions
- have not turned up any instances of HTTP clients issuing a DELETE
- request against a WebDAV collection, this concern is more theoretical
- than practical. Thus, servers are likely to be completely successful
- at interoperating with HTTP clients even if they treat any collection
- DELETE request as a WebDAV request and send a 207 Multi-Status
- response.
-
- In general, server implementations are encouraged to use the detailed
- responses and other mechanisms defined in this document rather than
- make changes for theoretical interoperability concerns.
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 119]
-
-RFC 4918 WebDAV June 2007
-
-
-Appendix C. The 'opaquelocktoken' Scheme and URIs
-
- The 'opaquelocktoken' URI scheme was defined in [RFC2518] (and
- registered by IANA) in order to create syntactically correct and
- easy-to-generate URIs out of UUIDs, intended to be used as lock
- tokens and to be unique across all resources for all time.
-
- An opaquelocktoken URI is constructed by concatenating the
- 'opaquelocktoken' scheme with a UUID, along with an optional
- extension. Servers can create new UUIDs for each new lock token. If
- a server wishes to reuse UUIDs, the server MUST add an extension, and
- the algorithm generating the extension MUST guarantee that the same
- extension will never be used twice with the associated UUID.
-
- OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
- ; UUID is defined in Section 3 of [RFC4122]. Note that LWS
- ; is not allowed between elements of
- ; this production.
-
- Extension = path
- ; path is defined in Section 3.3 of [RFC3986]
-
-
-Appendix D. Lock-null Resources
-
- The original WebDAV model for locking unmapped URLs created "lock-
- null resources". This model was over-complicated and some
- interoperability and implementation problems were discovered. The
- new WebDAV model for locking unmapped URLs (see Section 7.3) creates
- "locked empty resources". Lock-null resources are deprecated. This
- section discusses the original model briefly because clients MUST be
- able to handle either model.
-
- In the original "lock-null resource" model, which is no longer
- recommended for implementation:
-
- o A lock-null resource sometimes appeared as "Not Found". The
- server responds with a 404 or 405 to any method except for PUT,
- MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
-
- o A lock-null resource does however show up as a member of its
- parent collection.
-
- o The server removes the lock-null resource entirely (its URI
- becomes unmapped) if its lock goes away before it is converted to
- a regular resource. Recall that locks go away not only when they
- expire or are unlocked, but are also removed if a resource is
- renamed or moved, or if any parent collection is renamed or moved.
-
-
-
-Dusseault Standards Track [Page 120]
-
-RFC 4918 WebDAV June 2007
-
-
- o The server converts the lock-null resource into a regular resource
- if a PUT request to the URL is successful.
-
- o The server converts the lock-null resource into a collection if a
- MKCOL request to the URL is successful (though interoperability
- experience showed that not all servers followed this requirement).
-
- o Property values were defined for DAV:lockdiscovery and DAV:
- supportedlock properties but not necessarily for other properties
- like DAV:getcontenttype.
-
- Clients can easily interoperate both with servers that support the
- old model "lock-null resources" and the recommended model of "locked
- empty resources" by only attempting PUT after a LOCK to an unmapped
- URL, not MKCOL or GET.
-
-D.1. Guidance for Clients Using LOCK to Create Resources
-
- A WebDAV client implemented to this specification might find servers
- that create lock-null resources (implemented before this
- specification using [RFC2518]) as well as servers that create locked
- empty resources. The response to the LOCK request will not indicate
- what kind of resource was created. There are a few techniques that
- help the client deal with either type.
-
- If the client wishes to avoid accidentally creating either lock-
- null or empty locked resources, an "If-Match: *" header can be
- included with LOCK requests to prevent the server from creating a
- new resource.
-
- If a LOCK request creates a resource and the client subsequently
- wants to overwrite that resource using a COPY or MOVE request, the
- client should include an "Overwrite: T" header.
-
- If a LOCK request creates a resource and the client then decides
- to get rid of that resource, a DELETE request is supposed to fail
- on a lock-null resource and UNLOCK should be used instead. But
- with a locked empty resource, UNLOCK doesn't make the resource
- disappear. Therefore, the client might have to try both requests
- and ignore an error in one of the two requests.
-
-Appendix E. Guidance for Clients Desiring to Authenticate
-
- Many WebDAV clients that have already been implemented have account
- settings (similar to the way email clients store IMAP account
- settings). Thus, the WebDAV client would be able to authenticate
- with its first couple requests to the server, provided it had a way
- to get the authentication challenge from the server with realm name,
-
-
-
-Dusseault Standards Track [Page 121]
-
-RFC 4918 WebDAV June 2007
-
-
- nonce, and other challenge information. Note that the results of
- some requests might vary according to whether or not the client is
- authenticated -- a PROPFIND might return more visible resources if
- the client is authenticated, yet not fail if the client is anonymous.
-
- There are a number of ways the client might be able to trigger the
- server to provide an authentication challenge. This appendix
- describes a couple approaches that seem particularly likely to work.
-
- The first approach is to perform a request that ought to require
- authentication. However, it's possible that a server might handle
- any request even without authentication, so to be entirely safe, the
- client could add a conditional header to ensure that even if the
- request passes permissions checks, it's not actually handled by the
- server. An example of following this approach would be to use a PUT
- request with an "If-Match" header with a made-up ETag value. This
- approach might fail to result in an authentication challenge if the
- server does not test authorization before testing conditionals as is
- required (see Section 8.5), or if the server does not need to test
- authorization.
-
- Example - forcing auth challenge with write request
-
- >>Request
-
- PUT /forceauth.txt HTTP/1.1
- Host: www.example.com
- If-Match: "xxx"
- Content-Type: text/plain
- Content-Length: 0
-
-
- The second approach is to use an Authorization header (defined in
- [RFC2617]), which is likely to be rejected by the server but which
- will then prompt a proper authentication challenge. For example, the
- client could start with a PROPFIND request containing an
- Authorization header containing a made-up Basic userid:password
- string or with actual plausible credentials. This approach relies on
- the server responding with a "401 Unauthorized" along with a
- challenge if it receives an Authorization header with an unrecognized
- username, invalid password, or if it doesn't even handle Basic
- authentication. This seems likely to work because of the
- requirements of RFC 2617:
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 122]
-
-RFC 4918 WebDAV June 2007
-
-
- "If the origin server does not wish to accept the credentials sent
- with a request, it SHOULD return a 401 (Unauthorized) response. The
- response MUST include a WWW-Authenticate header field containing at
- least one (possibly new) challenge applicable to the requested
- resource."
-
- There's a slight problem with implementing that recommendation in
- some cases, because some servers do not even have challenge
- information for certain resources. Thus, when there's no way to
- authenticate to a resource or the resource is entirely publicly
- available over all accepted methods, the server MAY ignore the
- Authorization header, and the client will presumably try again later.
-
- Example - forcing auth challenge with Authorization header
-
- >>Request
-
- PROPFIND /docs/ HTTP/1.1
- Host: www.example.com
- Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
- Content-type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- [body omitted]
-
-
-Appendix F. Summary of Changes from RFC 2518
-
- This section lists major changes between this document and RFC 2518,
- starting with those that are likely to result in implementation
- changes. Servers will advertise support for all changes in this
- specification by returning the compliance class "3" in the DAV
- response header (see Sections 10.1 and 18.3).
-
-F.1. Changes for Both Client and Server Implementations
-
- Collections and Namespace Operations
-
- o The semantics of PROPFIND 'allprop' (Section 9.1) have been
- relaxed so that servers return results including, at a minimum,
- the live properties defined in this specification, but not
- necessarily return other live properties. The 'allprop' directive
- therefore means something more like "return all properties that
- are supposed to be returned when 'allprop' is requested" -- a set
- of properties that may include custom properties and properties
- defined in other specifications if those other specifications so
- require. Related to this, 'allprop' requests can now be extended
- with the 'include' syntax to include specific named properties,
-
-
-
-Dusseault Standards Track [Page 123]
-
-RFC 4918 WebDAV June 2007
-
-
- thereby avoiding additional requests due to changed 'allprop'
- semantics.
-
- o Servers are now allowed to reject PROPFIND requests with Depth:
- Infinity. Clients that used this will need to be able to do a
- series of Depth:1 requests instead.
-
- o Multi-Status response bodies now can transport the value of HTTP's
- Location response header in the new 'location' element. Clients
- may use this to avoid additional roundtrips to the server when
- there is a 'response' element with a 3xx status (see
- Section 14.24).
-
- o The definition of COPY has been relaxed so that it doesn't require
- servers to first delete the target resources anymore (this was a
- known incompatibility with [RFC3253]). See Section 9.8.
-
- Headers and Marshalling
-
- o The Destination and If request headers now allow absolute paths in
- addition to full URIs (see Section 8.3). This may be useful for
- clients operating through a reverse proxy that does rewrite the
- Host request header, but not WebDAV-specific headers.
-
- o This specification adopts the error marshalling extensions and the
- "precondition/postcondition" terminology defined in [RFC3253] (see
- Section 16). Related to that, it adds the "error" XML element
- inside multistatus response bodies (see Section 14.5, however note
- that it uses a format different from the one recommended in RFC
- 3253).
-
- o Senders and recipients are now required to support the UTF-16
- character encoding in XML message bodies (see Section 19).
-
- o Clients are now required to send the Depth header on PROPFIND
- requests, although servers are still encouraged to support clients
- that don't.
-
- Locking
-
- o RFC 2518's concept of "lock-null resources" (LNRs) has been
- replaced by a simplified approach, the "locked empty resources"
- (see Section 7.3). There are some aspects of lock-null resources
- clients cannot rely on anymore, namely, the ability to use them to
- create a locked collection or the fact that they disappear upon
- UNLOCK when no PUT or MKCOL request was issued. Note that servers
- are still allowed to implement LNRs as per RFC 2518.
-
-
-
-
-Dusseault Standards Track [Page 124]
-
-RFC 4918 WebDAV June 2007
-
-
- o There is no implicit refresh of locks anymore. Locks are only
- refreshed upon explicit request (see Section 9.10.2).
-
- o Clarified that the DAV:owner value supplied in the LOCK request
- must be preserved by the server just like a dead property
- (Section 14.17). Also added the DAV:lockroot element
- (Section 14.12), which allows clients to discover the root of
- lock.
-
-F.2. Changes for Server Implementations
-
- Collections and Namespace Operations
-
- o Due to interoperability problems, allowable formats for contents
- of 'href' elements in multistatus responses have been limited (see
- Section 8.3).
-
- o Due to lack of implementation, support for the 'propertybehavior'
- request body for COPY and MOVE has been removed. Instead,
- requirements for property preservation have been clarified (see
- Sections 9.8 and 9.9).
-
- Properties
-
- o Strengthened server requirements for storage of property values,
- in particular persistence of language information (xml:lang),
- whitespace, and XML namespace information (see Section 4.3).
-
- o Clarified requirements on which properties should be writable by
- the client; in particular, setting "DAV:displayname" should be
- supported by servers (see Section 15).
-
- o Only 'rfc1123-date' productions are legal as values for DAV:
- getlastmodified (see Section 15.7).
-
- Headers and Marshalling
-
- o Servers are now required to do authorization checks before
- processing conditional headers (see Section 8.5).
-
- Locking
-
- o Strengthened requirement to check identity of lock creator when
- accessing locked resources (see Section 6.4). Clients should be
- aware that lock tokens returned to other principals can only be
- used to break a lock, if at all.
-
-
-
-
-
-Dusseault Standards Track [Page 125]
-
-RFC 4918 WebDAV June 2007
-
-
- o Section 8.10.4 of [RFC2518] incorrectly required servers to return
- a 409 status where a 207 status was really appropriate. This has
- been corrected (Section 9.10).
-
-F.3. Other Changes
-
- The definition of collection state has been fixed so it doesn't vary
- anymore depending on the Request-URI (see Section 5.2).
-
- The DAV:source property introduced in Section 4.6 of [RFC2518] was
- removed due to lack of implementation experience.
-
- The DAV header now allows non-IETF extensions through URIs in
- addition to compliance class tokens. It also can now be used in
- requests, although this specification does not define any associated
- semantics for the compliance classes defined in here (see
- Section 10.1).
-
- In RFC 2518, the definition of the Depth header (Section 9.2)
- required that, by default, request headers would be applied to each
- resource in scope. Based on implementation experience, the default
- has now been reversed (see Section 10.2).
-
- The definitions of HTTP status code 102 ([RFC2518], Section 10.1) and
- the Status-URI response header (Section 9.7) have been removed due to
- lack of implementation.
-
- The TimeType format used in the Timeout request header and the
- "timeout" XML element used to be extensible. Now, only the two
- formats defined by this specification are allowed (see Section 10.7).
-
-Author's Address
-
- Lisa Dusseault (editor)
- CommerceNet
- 2064 Edgewood Dr.
- Palo Alto, CA 94303
- US
-
- EMail: ldusseault at commerce.net
-
-
-
-
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 126]
-
-RFC 4918 WebDAV June 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights 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; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
- http://www.ietf.org/ipr.
-
- 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 implement
- this standard. Please address the information to the IETF at
- ietf-ipr at ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Dusseault Standards Track [Page 127]
-
Copied: CalendarServer/trunk/doc/RFC/rfc4918-WebDAV.txt (from rev 2332, CalendarServer/trunk/doc/RFC/rfc4918-WebDAV Update.txt)
===================================================================
--- CalendarServer/trunk/doc/RFC/rfc4918-WebDAV.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/rfc4918-WebDAV.txt 2008-04-21 22:41:07 UTC (rev 2333)
@@ -0,0 +1,7115 @@
+
+
+
+
+
+
+Network Working Group L. Dusseault, Ed.
+Request for Comments: 4918 CommerceNet
+Obsoletes: 2518 June 2007
+Category: Standards Track
+
+
+ HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
+
+Status of This Memo
+
+ 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 Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ Web Distributed Authoring and Versioning (WebDAV) consists of a set
+ of methods, headers, and content-types ancillary to HTTP/1.1 for the
+ management of resource properties, creation and management of
+ resource collections, URL namespace manipulation, and resource
+ locking (collision avoidance).
+
+ RFC 2518 was published in February 1999, and this specification
+ obsoletes RFC 2518 with minor revisions mostly due to
+ interoperability experience.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 1]
+
+RFC 4918 WebDAV June 2007
+
+
+Table of Contents
+
+ 1. Introduction ....................................................7
+ 2. Notational Conventions ..........................................8
+ 3. Terminology .....................................................8
+ 4. Data Model for Resource Properties .............................10
+ 4.1. The Resource Property Model ...............................10
+ 4.2. Properties and HTTP Headers ...............................10
+ 4.3. Property Values ...........................................10
+ 4.3.1. Example - Property with Mixed Content ..............12
+ 4.4. Property Names ............................................14
+ 4.5. Source Resources and Output Resources .....................14
+ 5. Collections of Web Resources ...................................14
+ 5.1. HTTP URL Namespace Model ..................................15
+ 5.2. Collection Resources ......................................15
+ 6. Locking ........................................................17
+ 6.1. Lock Model ................................................18
+ 6.2. Exclusive vs. Shared Locks ................................19
+ 6.3. Required Support ..........................................20
+ 6.4. Lock Creator and Privileges ...............................20
+ 6.5. Lock Tokens ...............................................21
+ 6.6. Lock Timeout ..............................................21
+ 6.7. Lock Capability Discovery .................................22
+ 6.8. Active Lock Discovery .....................................22
+ 7. Write Lock .....................................................23
+ 7.1. Write Locks and Properties ................................24
+ 7.2. Avoiding Lost Updates .....................................24
+ 7.3. Write Locks and Unmapped URLs .............................25
+ 7.4. Write Locks and Collections ...............................26
+ 7.5. Write Locks and the If Request Header .....................28
+ 7.5.1. Example - Write Lock and COPY ......................28
+ 7.5.2. Example - Deleting a Member of a Locked
+ Collection .........................................29
+ 7.6. Write Locks and COPY/MOVE .................................30
+ 7.7. Refreshing Write Locks ....................................30
+ 8. General Request and Response Handling ..........................31
+ 8.1. Precedence in Error Handling ..............................31
+ 8.2. Use of XML ................................................31
+ 8.3. URL Handling ..............................................32
+ 8.3.1. Example - Correct URL Handling .....................32
+ 8.4. Required Bodies in Requests ...............................33
+ 8.5. HTTP Headers for Use in WebDAV ............................33
+ 8.6. ETag ......................................................33
+ 8.7. Including Error Response Bodies ...........................34
+ 8.8. Impact of Namespace Operations on Cache Validators ........34
+ 9. HTTP Methods for Distributed Authoring .........................35
+ 9.1. PROPFIND Method ...........................................35
+ 9.1.1. PROPFIND Status Codes ..............................37
+
+
+
+Dusseault Standards Track [Page 2]
+
+RFC 4918 WebDAV June 2007
+
+
+ 9.1.2. Status Codes for Use in 'propstat' Element .........37
+ 9.1.3. Example - Retrieving Named Properties ..............38
+ 9.1.4. Example - Using 'propname' to Retrieve All
+ Property Names .....................................39
+ 9.1.5. Example - Using So-called 'allprop' ................41
+ 9.1.6. Example - Using 'allprop' with 'include' ...........43
+ 9.2. PROPPATCH Method ..........................................44
+ 9.2.1. Status Codes for Use in 'propstat' Element .........44
+ 9.2.2. Example - PROPPATCH ................................45
+ 9.3. MKCOL Method ..............................................46
+ 9.3.1. MKCOL Status Codes .................................47
+ 9.3.2. Example - MKCOL ....................................47
+ 9.4. GET, HEAD for Collections .................................48
+ 9.5. POST for Collections ......................................48
+ 9.6. DELETE Requirements .......................................48
+ 9.6.1. DELETE for Collections .............................49
+ 9.6.2. Example - DELETE ...................................49
+ 9.7. PUT Requirements ..........................................50
+ 9.7.1. PUT for Non-Collection Resources ...................50
+ 9.7.2. PUT for Collections ................................51
+ 9.8. COPY Method ...............................................51
+ 9.8.1. COPY for Non-collection Resources ..................51
+ 9.8.2. COPY for Properties ................................52
+ 9.8.3. COPY for Collections ...............................52
+ 9.8.4. COPY and Overwriting Destination Resources .........53
+ 9.8.5. Status Codes .......................................54
+ 9.8.6. Example - COPY with Overwrite ......................55
+ 9.8.7. Example - COPY with No Overwrite ...................55
+ 9.8.8. Example - COPY of a Collection .....................56
+ 9.9. MOVE Method ...............................................56
+ 9.9.1. MOVE for Properties ................................57
+ 9.9.2. MOVE for Collections ...............................57
+ 9.9.3. MOVE and the Overwrite Header ......................58
+ 9.9.4. Status Codes .......................................59
+ 9.9.5. Example - MOVE of a Non-Collection .................60
+ 9.9.6. Example - MOVE of a Collection .....................60
+ 9.10. LOCK Method ..............................................61
+ 9.10.1. Creating a Lock on an Existing Resource ...........61
+ 9.10.2. Refreshing Locks ..................................62
+ 9.10.3. Depth and Locking .................................62
+ 9.10.4. Locking Unmapped URLs .............................63
+ 9.10.5. Lock Compatibility Table ..........................63
+ 9.10.6. LOCK Responses ....................................63
+ 9.10.7. Example - Simple Lock Request .....................64
+ 9.10.8. Example - Refreshing a Write Lock .................65
+ 9.10.9. Example - Multi-Resource Lock Request .............66
+ 9.11. UNLOCK Method ............................................68
+ 9.11.1. Status Codes ......................................68
+
+
+
+Dusseault Standards Track [Page 3]
+
+RFC 4918 WebDAV June 2007
+
+
+ 9.11.2. Example - UNLOCK ..................................69
+ 10. HTTP Headers for Distributed Authoring ........................69
+ 10.1. DAV Header ...............................................69
+ 10.2. Depth Header .............................................70
+ 10.3. Destination Header .......................................71
+ 10.4. If Header ................................................72
+ 10.4.1. Purpose ...........................................72
+ 10.4.2. Syntax ............................................72
+ 10.4.3. List Evaluation ...................................73
+ 10.4.4. Matching State Tokens and ETags ...................74
+ 10.4.5. If Header and Non-DAV-Aware Proxies ...............74
+ 10.4.6. Example - No-tag Production .......................75
+ 10.4.7. Example - Using "Not" with No-tag Production ......75
+ 10.4.8. Example - Causing a Condition to Always
+ Evaluate to True ..................................75
+ 10.4.9. Example - Tagged List If Header in COPY ...........76
+ 10.4.10. Example - Matching Lock Tokens with
+ Collection Locks .................................76
+ 10.4.11. Example - Matching ETags on Unmapped URLs ........76
+ 10.5. Lock-Token Header ........................................77
+ 10.6. Overwrite Header .........................................77
+ 10.7. Timeout Request Header ...................................78
+ 11. Status Code Extensions to HTTP/1.1 ............................78
+ 11.1. 207 Multi-Status .........................................78
+ 11.2. 422 Unprocessable Entity .................................78
+ 11.3. 423 Locked ...............................................78
+ 11.4. 424 Failed Dependency ....................................79
+ 11.5. 507 Insufficient Storage .................................79
+ 12. Use of HTTP Status Codes ......................................79
+ 12.1. 412 Precondition Failed ..................................79
+ 12.2. 414 Request-URI Too Long .................................79
+ 13. Multi-Status Response .........................................80
+ 13.1. Response Headers .........................................80
+ 13.2. Handling Redirected Child Resources ......................81
+ 13.3. Internal Status Codes ....................................81
+ 14. XML Element Definitions .......................................81
+ 14.1. activelock XML Element ...................................81
+ 14.2. allprop XML Element ......................................82
+ 14.3. collection XML Element ...................................82
+ 14.4. depth XML Element ........................................82
+ 14.5. error XML Element ........................................82
+ 14.6. exclusive XML Element ....................................83
+ 14.7. href XML Element .........................................83
+ 14.8. include XML Element ......................................83
+ 14.9. location XML Element .....................................83
+ 14.10. lockentry XML Element ...................................84
+ 14.11. lockinfo XML Element ....................................84
+ 14.12. lockroot XML Element ....................................84
+
+
+
+Dusseault Standards Track [Page 4]
+
+RFC 4918 WebDAV June 2007
+
+
+ 14.13. lockscope XML Element ...................................84
+ 14.14. locktoken XML Element ...................................85
+ 14.15. locktype XML Element ....................................85
+ 14.16. multistatus XML Element .................................85
+ 14.17. owner XML Element .......................................85
+ 14.18. prop XML Element ........................................86
+ 14.19. propertyupdate XML Element ..............................86
+ 14.20. propfind XML Element ....................................86
+ 14.21. propname XML Element ....................................87
+ 14.22. propstat XML Element ....................................87
+ 14.23. remove XML Element ......................................87
+ 14.24. response XML Element ....................................88
+ 14.25. responsedescription XML Element .........................88
+ 14.26. set XML Element .........................................88
+ 14.27. shared XML Element ......................................89
+ 14.28. status XML Element ......................................89
+ 14.29. timeout XML Element .....................................89
+ 14.30. write XML Element .......................................89
+ 15. DAV Properties ................................................90
+ 16. Precondition/Postcondition XML Elements .......................98
+ 17. XML Extensibility in DAV .....................................101
+ 18. DAV Compliance Classes .......................................103
+ 18.1. Class 1 .................................................103
+ 18.2. Class 2 .................................................103
+ 18.3. Class 3 .................................................103
+ 19. Internationalization Considerations ..........................104
+ 20. Security Considerations ......................................105
+ 20.1. Authentication of Clients ...............................105
+ 20.2. Denial of Service .......................................106
+ 20.3. Security through Obscurity ..............................106
+ 20.4. Privacy Issues Connected to Locks .......................106
+ 20.5. Privacy Issues Connected to Properties ..................107
+ 20.6. Implications of XML Entities ............................107
+ 20.7. Risks Connected with Lock Tokens ........................108
+ 20.8. Hosting Malicious Content ...............................108
+ 21. IANA Considerations ..........................................109
+ 21.1. New URI Schemes .........................................109
+ 21.2. XML Namespaces ..........................................109
+ 21.3. Message Header Fields ...................................109
+ 21.3.1. DAV ..............................................109
+ 21.3.2. Depth ............................................110
+ 21.3.3. Destination ......................................110
+ 21.3.4. If ...............................................110
+ 21.3.5. Lock-Token .......................................110
+ 21.3.6. Overwrite ........................................111
+ 21.3.7. Timeout ..........................................111
+ 21.4. HTTP Status Codes .......................................111
+ 22. Acknowledgements .............................................112
+
+
+
+Dusseault Standards Track [Page 5]
+
+RFC 4918 WebDAV June 2007
+
+
+ 23. Contributors to This Specification ...........................113
+ 24. Authors of RFC 2518 ..........................................113
+ 25. References ...................................................114
+ 25.1. Normative References.....................................114
+ 25.2. Informative References ..................................115
+ Appendix A. Notes on Processing XML Elements ....................117
+ A.1. Notes on Empty XML Elements ..............................117
+ A.2. Notes on Illegal XML Processing ..........................117
+ A.3. Example - XML Syntax Error ...............................117
+ A.4. Example - Unexpected XML Element .........................118
+ Appendix B. Notes on HTTP Client Compatibility ...................119
+ Appendix C. The 'opaquelocktoken' Scheme and URIs ................120
+ Appendix D. Lock-null Resources ..................................120
+ D.1. Guidance for Clients Using LOCK to Create Resources ......121
+ Appendix E. Guidance for Clients Desiring to Authenticate ........121
+ Appendix F. Summary of Changes from RFC 2518 .....................123
+ F.1. Changes for Both Client and Server Implementations .......123
+ F.2. Changes for Server Implementations .......................125
+ F.3. Other Changes ............................................126
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 6]
+
+RFC 4918 WebDAV June 2007
+
+
+1. Introduction
+
+ This document describes an extension to the HTTP/1.1 protocol that
+ allows clients to perform remote Web content authoring operations.
+ This extension provides a coherent set of methods, headers, request
+ entity body formats, and response entity body formats that provide
+ operations for:
+
+ Properties: The ability to create, remove, and query information
+ about Web pages, such as their authors, creation dates, etc.
+
+ Collections: The ability to create sets of documents and to retrieve
+ a hierarchical membership listing (like a directory listing in a file
+ system).
+
+ Locking: The ability to keep more than one person from working on a
+ document at the same time. This prevents the "lost update problem",
+ in which modifications are lost as first one author, then another,
+ writes changes without merging the other author's changes.
+
+ Namespace Operations: The ability to instruct the server to copy and
+ move Web resources, operations that change the mapping from URLs to
+ resources.
+
+ Requirements and rationale for these operations are described in a
+ companion document, "Requirements for a Distributed Authoring and
+ Versioning Protocol for the World Wide Web" [RFC2291].
+
+ This document does not specify the versioning operations suggested by
+ [RFC2291]. That work was done in a separate document, "Versioning
+ Extensions to WebDAV" [RFC3253].
+
+ The sections below provide a detailed introduction to various WebDAV
+ abstractions: resource properties (Section 4), collections of
+ resources (Section 5), locks (Section 6) in general, and write locks
+ (Section 7) specifically.
+
+ These abstractions are manipulated by the WebDAV-specific HTTP
+ methods (Section 9) and the extra HTTP headers (Section 10) used with
+ WebDAV methods. General considerations for handling HTTP requests
+ and responses in WebDAV are found in Section 8.
+
+ While the status codes provided by HTTP/1.1 are sufficient to
+ describe most error conditions encountered by WebDAV methods, there
+ are some errors that do not fall neatly into the existing categories.
+ This specification defines extra status codes developed for WebDAV
+ methods (Section 11) and describes existing HTTP status codes
+ (Section 12) as used in WebDAV. Since some WebDAV methods may
+
+
+
+Dusseault Standards Track [Page 7]
+
+RFC 4918 WebDAV June 2007
+
+
+ operate over many resources, the Multi-Status response (Section 13)
+ has been introduced to return status information for multiple
+ resources. Finally, this version of WebDAV introduces precondition
+ and postcondition (Section 16) XML elements in error response bodies.
+
+ WebDAV uses XML ([REC-XML]) for property names and some values, and
+ also uses XML to marshal complicated requests and responses. This
+ specification contains DTD and text definitions of all properties
+ (Section 15) and all other XML elements (Section 14) used in
+ marshalling. WebDAV includes a few special rules on extending WebDAV
+ XML marshalling in backwards-compatible ways (Section 17).
+
+ Finishing off the specification are sections on what it means for a
+ resource to be compliant with this specification (Section 18), on
+ internationalization support (Section 19), and on security
+ (Section 20).
+
+2. Notational Conventions
+
+ Since this document describes a set of extensions to the HTTP/1.1
+ protocol, the augmented BNF used herein to describe protocol elements
+ is exactly the same as described in Section 2.1 of [RFC2616],
+ including the rules about implied linear whitespace. Since this
+ augmented BNF uses the basic production rules provided in Section 2.2
+ of [RFC2616], these rules apply to this document as well. Note this
+ is not the standard BNF syntax used in other RFCs.
+
+ 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 [RFC2119].
+
+ Note that in natural language, a property like the "creationdate"
+ property in the "DAV:" XML namespace is sometimes referred to as
+ "DAV:creationdate" for brevity.
+
+3. Terminology
+
+ URI/URL - A Uniform Resource Identifier and Uniform Resource Locator,
+ respectively. These terms (and the distinction between them) are
+ defined in [RFC3986].
+
+ URI/URL Mapping - A relation between an absolute URI and a resource.
+ Since a resource can represent items that are not network
+ retrievable, as well as those that are, it is possible for a resource
+ to have zero, one, or many URI mappings. Mapping a resource to an
+ "http" scheme URI makes it possible to submit HTTP protocol requests
+ to the resource using the URI.
+
+
+
+
+Dusseault Standards Track [Page 8]
+
+RFC 4918 WebDAV June 2007
+
+
+ Path Segment - Informally, the characters found between slashes ("/")
+ in a URI. Formally, as defined in Section 3.3 of [RFC3986].
+
+ Collection - Informally, a resource that also acts as a container of
+ references to child resources. Formally, a resource that contains a
+ set of mappings between path segments and resources and meets the
+ requirements defined in Section 5.
+
+ Internal Member (of a Collection) - Informally, a child resource of a
+ collection. Formally, a resource referenced by a path segment
+ mapping contained in the collection.
+
+ Internal Member URL (of a Collection) - A URL of an internal member,
+ consisting of the URL of the collection (including trailing slash)
+ plus the path segment identifying the internal member.
+
+ Member (of a Collection) - Informally, a "descendant" of a
+ collection. Formally, an internal member of the collection, or,
+ recursively, a member of an internal member.
+
+ Member URL (of a Collection) - A URL that is either an internal
+ member URL of the collection itself, or is an internal member URL of
+ a member of that collection.
+
+ Property - A name/value pair that contains descriptive information
+ about a resource.
+
+ Live Property - A property whose semantics and syntax are enforced by
+ the server. For example, the live property DAV:getcontentlength has
+ its value, the length of the entity returned by a GET request,
+ automatically calculated by the server.
+
+ Dead Property - A property whose semantics and syntax are not
+ enforced by the server. The server only records the value of a dead
+ property; the client is responsible for maintaining the consistency
+ of the syntax and semantics of a dead property.
+
+ Principal - A distinct human or computational actor that initiates
+ access to network resources.
+
+ State Token - A URI that represents a state of a resource. Lock
+ tokens are the only state tokens defined in this specification.
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 9]
+
+RFC 4918 WebDAV June 2007
+
+
+4. Data Model for Resource Properties
+
+4.1. The Resource Property Model
+
+ Properties are pieces of data that describe the state of a resource.
+ Properties are data about data.
+
+ Properties are used in distributed authoring environments to provide
+ for efficient discovery and management of resources. For example, a
+ 'subject' property might allow for the indexing of all resources by
+ their subject, and an 'author' property might allow for the discovery
+ of what authors have written which documents.
+
+ The DAV property model consists of name/value pairs. The name of a
+ property identifies the property's syntax and semantics, and provides
+ an address by which to refer to its syntax and semantics.
+
+ There are two categories of properties: "live" and "dead". A live
+ property has its syntax and semantics enforced by the server. Live
+ properties include cases where a) the value of a property is
+ protected and maintained by the server, and b) the value of the
+ property is maintained by the client, but the server performs syntax
+ checking on submitted values. All instances of a given live property
+ MUST comply with the definition associated with that property name.
+ A dead property has its syntax and semantics enforced by the client;
+ the server merely records the value of the property verbatim.
+
+4.2. Properties and HTTP Headers
+
+ Properties already exist, in a limited sense, in HTTP message
+ headers. However, in distributed authoring environments, a
+ relatively large number of properties are needed to describe the
+ state of a resource, and setting/returning them all through HTTP
+ headers is inefficient. Thus, a mechanism is needed that allows a
+ principal to identify a set of properties in which the principal is
+ interested and to set or retrieve just those properties.
+
+4.3. Property Values
+
+ The value of a property is always a (well-formed) XML fragment.
+
+ XML has been chosen because it is a flexible, self-describing,
+ structured data format that supports rich schema definitions, and
+ because of its support for multiple character sets. XML's self-
+ describing nature allows any property's value to be extended by
+ adding elements. Clients will not break when they encounter
+ extensions because they will still have the data specified in the
+ original schema and MUST ignore elements they do not understand.
+
+
+
+Dusseault Standards Track [Page 10]
+
+RFC 4918 WebDAV June 2007
+
+
+ XML's support for multiple character sets allows any human-readable
+ property to be encoded and read in a character set familiar to the
+ user. XML's support for multiple human languages, using the "xml:
+ lang" attribute, handles cases where the same character set is
+ employed by multiple human languages. Note that xml:lang scope is
+ recursive, so an xml:lang attribute on any element containing a
+ property name element applies to the property value unless it has
+ been overridden by a more locally scoped attribute. Note that a
+ property only has one value, in one language (or language MAY be left
+ undefined); a property does not have multiple values in different
+ languages or a single value in multiple languages.
+
+ A property is always represented with an XML element consisting of
+ the property name, called the "property name element". The simplest
+ example is an empty property, which is different from a property that
+ does not exist:
+
+ <R:title xmlns:R="http://www.example.com/ns/"></R:title>
+
+ The value of the property appears inside the property name element.
+ The value may be any kind of well-formed XML content, including both
+ text-only and mixed content. Servers MUST preserve the following XML
+ Information Items (using the terminology from [REC-XML-INFOSET]) in
+ storage and transmission of dead properties:
+
+ For the property name Element Information Item itself:
+
+ [namespace name]
+
+ [local name]
+
+ [attributes] named "xml:lang" or any such attribute in scope
+
+ [children] of type element or character
+
+ On all Element Information Items in the property value:
+
+ [namespace name]
+
+ [local name]
+
+ [attributes]
+
+ [children] of type element or character
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 11]
+
+RFC 4918 WebDAV June 2007
+
+
+ On Attribute Information Items in the property value:
+
+ [namespace name]
+
+ [local name]
+
+ [normalized value]
+
+ On Character Information Items in the property value:
+
+ [character code]
+
+ Since prefixes are used in some XML vocabularies (XPath and XML
+ Schema, for example), servers SHOULD preserve, for any Information
+ Item in the value:
+
+ [prefix]
+
+ XML Infoset attributes not listed above MAY be preserved by the
+ server, but clients MUST NOT rely on them being preserved. The above
+ rules would also apply by default to live properties, unless defined
+ otherwise.
+
+ Servers MUST ignore the XML attribute xml:space if present and never
+ use it to change whitespace handling. Whitespace in property values
+ is significant.
+
+4.3.1. Example - Property with Mixed Content
+
+ Consider a dead property 'author' created by the client as follows:
+
+ <D:prop xml:lang="en" xmlns:D="DAV:">
+ <x:author xmlns:x='http://example.com/ns'>
+ <x:name>Jane Doe</x:name>
+ <!-- Jane's contact info -->
+ <x:uri type='email'
+ added='2005-11-26'>mailto:jane.doe at example.com</x:uri>
+ <x:uri type='web'
+ added='2005-11-27'>http://www.example.com</x:uri>
+ <x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
+ Jane has been working way <h:em>too</h:em> long on the
+ long-awaited revision of <![CDATA[<RFC2518>]]>.
+ </x:notes>
+ </x:author>
+ </D:prop>
+
+
+
+
+
+
+Dusseault Standards Track [Page 12]
+
+RFC 4918 WebDAV June 2007
+
+
+ When this property is requested, a server might return:
+
+ <D:prop xmlns:D='DAV:'><author
+ xml:lang='en'
+ xmlns:x='http://example.com/ns'
+ xmlns='http://example.com/ns'
+ xmlns:h='http://www.w3.org/1999/xhtml'>
+ <x:name>Jane Doe</x:name>
+ <x:uri added="2005-11-26" type="email"
+ >mailto:jane.doe at example.com</x:uri>
+ <x:uri added="2005-11-27" type="web"
+ >http://www.example.com</x:uri>
+ <x:notes>
+ Jane has been working way <h:em>too</h:em> long on the
+ long-awaited revision of <RFC2518>.
+ </x:notes>
+ </author>
+ </D:prop>
+
+ Note in this example:
+
+ o The [prefix] for the property name itself was not preserved, being
+ non-significant, whereas all other [prefix] values have been
+ preserved,
+
+ o attribute values have been rewritten with double quotes instead of
+ single quotes (quoting style is not significant), and attribute
+ order has not been preserved,
+
+ o the xml:lang attribute has been returned on the property name
+ element itself (it was in scope when the property was set, but the
+ exact position in the response is not considered significant as
+ long as it is in scope),
+
+ o whitespace between tags has been preserved everywhere (whitespace
+ between attributes not so),
+
+ o CDATA encapsulation was replaced with character escaping (the
+ reverse would also be legal),
+
+ o the comment item was stripped (as would have been a processing
+ instruction item).
+
+ Implementation note: there are cases such as editing scenarios where
+ clients may require that XML content is preserved character by
+ character (such as attribute ordering or quoting style). In this
+ case, clients should consider using a text-only property value by
+ escaping all characters that have a special meaning in XML parsing.
+
+
+
+Dusseault Standards Track [Page 13]
+
+RFC 4918 WebDAV June 2007
+
+
+4.4. Property Names
+
+ A property name is a universally unique identifier that is associated
+ with a schema that provides information about the syntax and
+ semantics of the property.
+
+ Because a property's name is universally unique, clients can depend
+ upon consistent behavior for a particular property across multiple
+ resources, on the same and across different servers, so long as that
+ property is "live" on the resources in question, and the
+ implementation of the live property is faithful to its definition.
+
+ The XML namespace mechanism, which is based on URIs ([RFC3986]), is
+ used to name properties because it prevents namespace collisions and
+ provides for varying degrees of administrative control.
+
+ The property namespace is flat; that is, no hierarchy of properties
+ is explicitly recognized. Thus, if a property A and a property A/B
+ exist on a resource, there is no recognition of any relationship
+ between the two properties. It is expected that a separate
+ specification will eventually be produced that will address issues
+ relating to hierarchical properties.
+
+ Finally, it is not possible to define the same property twice on a
+ single resource, as this would cause a collision in the resource's
+ property namespace.
+
+4.5. Source Resources and Output Resources
+
+ Some HTTP resources are dynamically generated by the server. For
+ these resources, there presumably exists source code somewhere
+ governing how that resource is generated. The relationship of source
+ files to output HTTP resources may be one to one, one to many, many
+ to one, or many to many. There is no mechanism in HTTP to determine
+ whether a resource is even dynamic, let alone where its source files
+ exist or how to author them. Although this problem would usefully be
+ solved, interoperable WebDAV implementations have been widely
+ deployed without actually solving this problem, by dealing only with
+ static resources. Thus, the source vs. output problem is not solved
+ in this specification and has been deferred to a separate document.
+
+5. Collections of Web Resources
+
+ This section provides a description of a type of Web resource, the
+ collection, and discusses its interactions with the HTTP URL
+ namespace and with HTTP methods. The purpose of a collection
+ resource is to model collection-like objects (e.g., file system
+ directories) within a server's namespace.
+
+
+
+Dusseault Standards Track [Page 14]
+
+RFC 4918 WebDAV June 2007
+
+
+ All DAV-compliant resources MUST support the HTTP URL namespace model
+ specified herein.
+
+5.1. HTTP URL Namespace Model
+
+ The HTTP URL namespace is a hierarchical namespace where the
+ hierarchy is delimited with the "/" character.
+
+ An HTTP URL namespace is said to be consistent if it meets the
+ following conditions: for every URL in the HTTP hierarchy there
+ exists a collection that contains that URL as an internal member URL.
+ The root, or top-level collection of the namespace under
+ consideration, is exempt from the previous rule. The top-level
+ collection of the namespace under consideration is not necessarily
+ the collection identified by the absolute path '/' -- it may be
+ identified by one or more path segments (e.g., /servlets/webdav/...)
+
+ Neither HTTP/1.1 nor WebDAV requires that the entire HTTP URL
+ namespace be consistent -- a WebDAV-compatible resource may not have
+ a parent collection. However, certain WebDAV methods are prohibited
+ from producing results that cause namespace inconsistencies.
+
+ As is implicit in [RFC2616] and [RFC3986], any resource, including
+ collection resources, MAY be identified by more than one URI. For
+ example, a resource could be identified by multiple HTTP URLs.
+
+5.2. Collection Resources
+
+ Collection resources differ from other resources in that they also
+ act as containers. Some HTTP methods apply only to a collection, but
+ some apply to some or all of the resources inside the container
+ defined by the collection. When the scope of a method is not clear,
+ the client can specify what depth to apply. Depth can be either zero
+ levels (only the collection), one level (the collection and directly
+ contained resources), or infinite levels (the collection and all
+ contained resources recursively).
+
+ A collection's state consists of at least a set of mappings between
+ path segments and resources, and a set of properties on the
+ collection itself. In this document, a resource B will be said to be
+ contained in the collection resource A if there is a path segment
+ mapping that maps to B and that is contained in A. A collection MUST
+ contain at most one mapping for a given path segment, i.e., it is
+ illegal to have the same path segment mapped to more than one
+ resource.
+
+
+
+
+
+
+Dusseault Standards Track [Page 15]
+
+RFC 4918 WebDAV June 2007
+
+
+ Properties defined on collections behave exactly as do properties on
+ non-collection resources. A collection MAY have additional state
+ such as entity bodies returned by GET.
+
+ For all WebDAV-compliant resources A and B, identified by URLs "U"
+ and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST
+ be a collection that contains a mapping from "SEGMENT" to B. So, if
+ resource B with URL "http://example.com/bar/blah" is WebDAV compliant
+ and if resource A with URL "http://example.com/bar/" is WebDAV
+ compliant, then resource A must be a collection and must contain
+ exactly one mapping from "blah" to B.
+
+ Although commonly a mapping consists of a single segment and a
+ resource, in general, a mapping consists of a set of segments and a
+ resource. This allows a server to treat a set of segments as
+ equivalent (i.e., either all of the segments are mapped to the same
+ resource, or none of the segments are mapped to a resource). For
+ example, a server that performs case-folding on segments will treat
+ the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can
+ then use any of these segments to identify the resource. Note that a
+ PROPFIND result will select one of these equivalent segments to
+ identify the mapping, so there will be one PROPFIND response element
+ per mapping, not one per segment in the mapping.
+
+ Collection resources MAY have mappings to non-WebDAV-compliant
+ resources in the HTTP URL namespace hierarchy but are not required to
+ do so. For example, if resource X with URL
+ "http://example.com/bar/blah" is not WebDAV compliant and resource A
+ with "URL http://example.com/bar/" identifies a WebDAV collection,
+ then A may or may not have a mapping from "blah" to X.
+
+ If a WebDAV-compliant resource has no WebDAV-compliant internal
+ members in the HTTP URL namespace hierarchy, then the WebDAV-
+ compliant resource is not required to be a collection.
+
+ There is a standing convention that when a collection is referred to
+ by its name without a trailing slash, the server MAY handle the
+ request as if the trailing slash were present. In this case, it
+ SHOULD return a Content-Location header in the response, pointing to
+ the URL ending with the "/". For example, if a client invokes a
+ method on http://example.com/blah (no trailing slash), the server may
+ respond as if the operation were invoked on http://example.com/blah/
+ (trailing slash), and should return a Content-Location header with
+ the value http://example.com/blah/. Wherever a server produces a URL
+ referring to a collection, the server SHOULD include the trailing
+ slash. In general, clients SHOULD use the trailing slash form of
+ collection names. If clients do not use the trailing slash form the
+ client needs to be prepared to see a redirect response. Clients will
+
+
+
+Dusseault Standards Track [Page 16]
+
+RFC 4918 WebDAV June 2007
+
+
+ find the DAV:resourcetype property more reliable than the URL to find
+ out if a resource is a collection.
+
+ Clients MUST be able to support the case where WebDAV resources are
+ contained inside non-WebDAV resources. For example, if an OPTIONS
+ response from "http://example.com/servlet/dav/collection" indicates
+ WebDAV support, the client cannot assume that
+ "http://example.com/servlet/dav/" or its parent necessarily are
+ WebDAV collections.
+
+ A typical scenario in which mapped URLs do not appear as members of
+ their parent collection is the case where a server allows links or
+ redirects to non-WebDAV resources. For instance, "/col/link" might
+ not appear as a member of "/col/", although the server would respond
+ with a 302 status to a GET request to "/col/link"; thus, the URL
+ "/col/link" would indeed be mapped. Similarly, a dynamically-
+ generated page might have a URL mapping from "/col/index.html", thus
+ this resource might respond with a 200 OK to a GET request yet not
+ appear as a member of "/col/".
+
+ Some mappings to even WebDAV-compliant resources might not appear in
+ the parent collection. An example for this case are servers that
+ support multiple alias URLs for each WebDAV-compliant resource. A
+ server may implement case-insensitive URLs, thus "/col/a" and
+ "/col/A" identify the same resource, yet only either "a" or "A" is
+ reported upon listing the members of "/col". In cases where a server
+ treats a set of segments as equivalent, the server MUST expose only
+ one preferred segment per mapping, consistently chosen, in PROPFIND
+ responses.
+
+6. Locking
+
+ The ability to lock a resource provides a mechanism for serializing
+ access to that resource. Using a lock, an authoring client can
+ provide a reasonable guarantee that another principal will not modify
+ a resource while it is being edited. In this way, a client can
+ prevent the "lost update" problem.
+
+ This specification allows locks to vary over two client-specified
+ parameters, the number of principals involved (exclusive vs. shared)
+ and the type of access to be granted. This document defines locking
+ for only one access type, write. However, the syntax is extensible,
+ and permits the eventual specification of locking for other access
+ types.
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 17]
+
+RFC 4918 WebDAV June 2007
+
+
+6.1. Lock Model
+
+ This section provides a concise model for how locking behaves. Later
+ sections will provide more detail on some of the concepts and refer
+ back to these model statements. Normative statements related to LOCK
+ and UNLOCK method handling can be found in the sections on those
+ methods, whereas normative statements that cover any method are
+ gathered here.
+
+ 1. A lock either directly or indirectly locks a resource.
+
+ 2. A resource becomes directly locked when a LOCK request to a URL
+ of that resource creates a new lock. The "lock-root" of the new
+ lock is that URL. If at the time of the request, the URL is not
+ mapped to a resource, a new empty resource is created and
+ directly locked.
+
+ 3. An exclusive lock (Section 6.2) conflicts with any other kind of
+ lock on the same resource, whether either lock is direct or
+ indirect. A server MUST NOT create conflicting locks on a
+ resource.
+
+ 4. For a collection that is locked with a depth-infinity lock L, all
+ member resources are indirectly locked. Changes in membership of
+ such a collection affect the set of indirectly locked resources:
+
+ * If a member resource is added to the collection, the new
+ member resource MUST NOT already have a conflicting lock,
+ because the new resource MUST become indirectly locked by L.
+
+ * If a member resource stops being a member of the collection,
+ then the resource MUST no longer be indirectly locked by L.
+
+ 5. Each lock is identified by a single globally unique lock token
+ (Section 6.5).
+
+ 6. An UNLOCK request deletes the lock with the specified lock token.
+ After a lock is deleted, no resource is locked by that lock.
+
+ 7. A lock token is "submitted" in a request when it appears in an
+ "If" header (Section 7, "Write Lock", discusses when token
+ submission is required for write locks).
+
+ 8. If a request causes the lock-root of any lock to become an
+ unmapped URL, then the lock MUST also be deleted by that request.
+
+
+
+
+
+
+Dusseault Standards Track [Page 18]
+
+RFC 4918 WebDAV June 2007
+
+
+6.2. Exclusive vs. Shared Locks
+
+ The most basic form of lock is an exclusive lock. Exclusive locks
+ avoid having to deal with content change conflicts, without requiring
+ any coordination other than the methods described in this
+ specification.
+
+ However, there are times when the goal of a lock is not to exclude
+ others from exercising an access right but rather to provide a
+ mechanism for principals to indicate that they intend to exercise
+ their access rights. Shared locks are provided for this case. A
+ shared lock allows multiple principals to receive a lock. Hence any
+ principal that has both access privileges and a valid lock can use
+ the locked resource.
+
+ With shared locks, there are two trust sets that affect a resource.
+ The first trust set is created by access permissions. Principals who
+ are trusted, for example, may have permission to write to the
+ resource. Among those who have access permission to write to the
+ resource, the set of principals who have taken out a shared lock also
+ must trust each other, creating a (typically) smaller trust set
+ within the access permission write set.
+
+ Starting with every possible principal on the Internet, in most
+ situations the vast majority of these principals will not have write
+ access to a given resource. Of the small number who do have write
+ access, some principals may decide to guarantee their edits are free
+ from overwrite conflicts by using exclusive write locks. Others may
+ decide they trust their collaborators will not overwrite their work
+ (the potential set of collaborators being the set of principals who
+ have write permission) and use a shared lock, which informs their
+ collaborators that a principal may be working on the resource.
+
+ The WebDAV extensions to HTTP do not need to provide all of the
+ communications paths necessary for principals to coordinate their
+ activities. When using shared locks, principals may use any out-of-
+ band communication channel to coordinate their work (e.g., face-to-
+ face interaction, written notes, post-it notes on the screen,
+ telephone conversation, email, etc.) The intent of a shared lock is
+ to let collaborators know who else may be working on a resource.
+
+ Shared locks are included because experience from Web-distributed
+ authoring systems has indicated that exclusive locks are often too
+ rigid. An exclusive lock is used to enforce a particular editing
+ process: take out an exclusive lock, read the resource, perform
+ edits, write the resource, release the lock. This editing process
+ has the problem that locks are not always properly released, for
+ example, when a program crashes or when a lock creator leaves without
+
+
+
+Dusseault Standards Track [Page 19]
+
+RFC 4918 WebDAV June 2007
+
+
+ unlocking a resource. While both timeouts (Section 6.6) and
+ administrative action can be used to remove an offending lock,
+ neither mechanism may be available when needed; the timeout may be
+ long or the administrator may not be available.
+
+ A successful request for a new shared lock MUST result in the
+ generation of a unique lock associated with the requesting principal.
+ Thus, if five principals have taken out shared write locks on the
+ same resource, there will be five locks and five lock tokens, one for
+ each principal.
+
+6.3. Required Support
+
+ A WebDAV-compliant resource is not required to support locking in any
+ form. If the resource does support locking, it may choose to support
+ any combination of exclusive and shared locks for any access types.
+
+ The reason for this flexibility is that locking policy strikes to the
+ very heart of the resource management and versioning systems employed
+ by various storage repositories. These repositories require control
+ over what sort of locking will be made available. For example, some
+ repositories only support shared write locks, while others only
+ provide support for exclusive write locks, while yet others use no
+ locking at all. As each system is sufficiently different to merit
+ exclusion of certain locking features, this specification leaves
+ locking as the sole axis of negotiation within WebDAV.
+
+6.4. Lock Creator and Privileges
+
+ The creator of a lock has special privileges to use the lock to
+ modify the resource. When a locked resource is modified, a server
+ MUST check that the authenticated principal matches the lock creator
+ (in addition to checking for valid lock token submission).
+
+ The server MAY allow privileged users other than the lock creator to
+ destroy a lock (for example, the resource owner or an administrator).
+ The 'unlock' privilege in [RFC3744] was defined to provide that
+ permission.
+
+ There is no requirement for servers to accept LOCK requests from all
+ users or from anonymous users.
+
+ Note that having a lock does not confer full privilege to modify the
+ locked resource. Write access and other privileges MUST be enforced
+ through normal privilege or authentication mechanisms, not based on
+ the possible obscurity of lock token values.
+
+
+
+
+
+Dusseault Standards Track [Page 20]
+
+RFC 4918 WebDAV June 2007
+
+
+6.5. Lock Tokens
+
+ A lock token is a type of state token that identifies a particular
+ lock. Each lock has exactly one unique lock token generated by the
+ server. Clients MUST NOT attempt to interpret lock tokens in any
+ way.
+
+ Lock token URIs MUST be unique across all resources for all time.
+ This uniqueness constraint allows lock tokens to be submitted across
+ resources and servers without fear of confusion. Since lock tokens
+ are unique, a client MAY submit a lock token in an If header on a
+ resource other than the one that returned it.
+
+ When a LOCK operation creates a new lock, the new lock token is
+ returned in the Lock-Token response header defined in Section 10.5,
+ and also in the body of the response.
+
+ Servers MAY make lock tokens publicly readable (e.g., in the DAV:
+ lockdiscovery property). One use case for making lock tokens
+ readable is so that a long-lived lock can be removed by the resource
+ owner (the client that obtained the lock might have crashed or
+ disconnected before cleaning up the lock). Except for the case of
+ using UNLOCK under user guidance, a client SHOULD NOT use a lock
+ token created by another client instance.
+
+ This specification encourages servers to create Universally Unique
+ Identifiers (UUIDs) for lock tokens, and to use the URI form defined
+ by "A Universally Unique Identifier (UUID) URN Namespace"
+ ([RFC4122]). However, servers are free to use any URI (e.g., from
+ another scheme) so long as it meets the uniqueness requirements. For
+ example, a valid lock token might be constructed using the
+ "opaquelocktoken" scheme defined in Appendix C.
+
+ Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
+
+6.6. Lock Timeout
+
+ A lock MAY have a limited lifetime. The lifetime is suggested by the
+ client when creating or refreshing the lock, but the server
+ ultimately chooses the timeout value. Timeout is measured in seconds
+ remaining until lock expiration.
+
+ The timeout counter MUST be restarted if a refresh lock request is
+ successful (see Section 9.10.2). The timeout counter SHOULD NOT be
+ restarted at any other time.
+
+ If the timeout expires, then the lock SHOULD be removed. In this
+ case the server SHOULD act as if an UNLOCK method was executed by the
+
+
+
+Dusseault Standards Track [Page 21]
+
+RFC 4918 WebDAV June 2007
+
+
+ server on the resource using the lock token of the timed-out lock,
+ performed with its override authority.
+
+ Servers are advised to pay close attention to the values submitted by
+ clients, as they will be indicative of the type of activity the
+ client intends to perform. For example, an applet running in a
+ browser may need to lock a resource, but because of the instability
+ of the environment within which the applet is running, the applet may
+ be turned off without warning. As a result, the applet is likely to
+ ask for a relatively small timeout value so that if the applet dies,
+ the lock can be quickly harvested. However, a document management
+ system is likely to ask for an extremely long timeout because its
+ user may be planning on going offline.
+
+ A client MUST NOT assume that just because the timeout has expired,
+ the lock has immediately been removed.
+
+ Likewise, a client MUST NOT assume that just because the timeout has
+ not expired, the lock still exists. Clients MUST assume that locks
+ can arbitrarily disappear at any time, regardless of the value given
+ in the Timeout header. The Timeout header only indicates the
+ behavior of the server if extraordinary circumstances do not occur.
+ For example, a sufficiently privileged user may remove a lock at any
+ time, or the system may crash in such a way that it loses the record
+ of the lock's existence.
+
+6.7. Lock Capability Discovery
+
+ Since server lock support is optional, a client trying to lock a
+ resource on a server can either try the lock and hope for the best,
+ or perform some form of discovery to determine what lock capabilities
+ the server supports. This is known as lock capability discovery. A
+ client can determine what lock types the server supports by
+ retrieving the DAV:supportedlock property.
+
+ Any DAV-compliant resource that supports the LOCK method MUST support
+ the DAV:supportedlock property.
+
+6.8. Active Lock Discovery
+
+ If another principal locks a resource that a principal wishes to
+ access, it is useful for the second principal to be able to find out
+ who the first principal is. For this purpose the DAV:lockdiscovery
+ property is provided. This property lists all outstanding locks,
+ describes their type, and MAY even provide the lock tokens.
+
+ Any DAV-compliant resource that supports the LOCK method MUST support
+ the DAV:lockdiscovery property.
+
+
+
+Dusseault Standards Track [Page 22]
+
+RFC 4918 WebDAV June 2007
+
+
+7. Write Lock
+
+ This section describes the semantics specific to the write lock type.
+ The write lock is a specific instance of a lock type, and is the only
+ lock type described in this specification.
+
+ An exclusive write lock protects a resource: it prevents changes by
+ any principal other than the lock creator and in any case where the
+ lock token is not submitted (e.g., by a client process other than the
+ one holding the lock).
+
+ Clients MUST submit a lock-token they are authorized to use in any
+ request that modifies a write-locked resource. The list of
+ modifications covered by a write-lock include:
+
+ 1. A change to any of the following aspects of any write-locked
+ resource:
+
+ * any variant,
+
+ * any dead property,
+
+ * any live property that is lockable (a live property is
+ lockable unless otherwise defined.)
+
+ 2. For collections, any modification of an internal member URI. An
+ internal member URI of a collection is considered to be modified
+ if it is added, removed, or identifies a different resource.
+ More discussion on write locks and collections is found in
+ Section 7.4.
+
+ 3. A modification of the mapping of the root of the write lock,
+ either to another resource or to no resource (e.g., DELETE).
+
+ Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH,
+ LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and
+ MKCOL are affected by write locks. All other HTTP/WebDAV methods
+ defined so far -- GET in particular -- function independently of a
+ write lock.
+
+ The next few sections describe in more specific terms how write locks
+ interact with various operations.
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 23]
+
+RFC 4918 WebDAV June 2007
+
+
+7.1. Write Locks and Properties
+
+ While those without a write lock may not alter a property on a
+ resource it is still possible for the values of live properties to
+ change, even while locked, due to the requirements of their schemas.
+ Only dead properties and live properties defined as lockable are
+ guaranteed not to change while write locked.
+
+7.2. Avoiding Lost Updates
+
+ Although the write locks provide some help in preventing lost
+ updates, they cannot guarantee that updates will never be lost.
+ Consider the following scenario:
+
+ Two clients A and B are interested in editing the resource
+ 'index.html'. Client A is an HTTP client rather than a WebDAV
+ client, and so does not know how to perform locking.
+
+ Client A doesn't lock the document, but does a GET, and begins
+ editing.
+
+ Client B does LOCK, performs a GET and begins editing.
+
+ Client B finishes editing, performs a PUT, then an UNLOCK.
+
+ Client A performs a PUT, overwriting and losing all of B's changes.
+
+ There are several reasons why the WebDAV protocol itself cannot
+ prevent this situation. First, it cannot force all clients to use
+ locking because it must be compatible with HTTP clients that do not
+ comprehend locking. Second, it cannot require servers to support
+ locking because of the variety of repository implementations, some of
+ which rely on reservations and merging rather than on locking.
+ Finally, being stateless, it cannot enforce a sequence of operations
+ like LOCK / GET / PUT / UNLOCK.
+
+ WebDAV servers that support locking can reduce the likelihood that
+ clients will accidentally overwrite each other's changes by requiring
+ clients to lock resources before modifying them. Such servers would
+ effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
+ resources.
+
+ WebDAV clients can be good citizens by using a lock / retrieve /
+ write /unlock sequence of operations (at least by default) whenever
+ they interact with a WebDAV server that supports locking.
+
+
+
+
+
+
+Dusseault Standards Track [Page 24]
+
+RFC 4918 WebDAV June 2007
+
+
+ HTTP 1.1 clients can be good citizens, avoiding overwriting other
+ clients' changes, by using entity tags in If-Match headers with any
+ requests that would modify resources.
+
+ Information managers may attempt to prevent overwrites by
+ implementing client-side procedures requiring locking before
+ modifying WebDAV resources.
+
+7.3. Write Locks and Unmapped URLs
+
+ WebDAV provides the ability to send a LOCK request to an unmapped URL
+ in order to reserve the name for use. This is a simple way to avoid
+ the lost-update problem on the creation of a new resource (another
+ way is to use If-None-Match header specified in Section 14.26 of
+ [RFC2616]). It has the side benefit of locking the new resource
+ immediately for use of the creator.
+
+ Note that the lost-update problem is not an issue for collections
+ because MKCOL can only be used to create a collection, not to
+ overwrite an existing collection. When trying to lock a collection
+ upon creation, clients can attempt to increase the likelihood of
+ getting the lock by pipelining the MKCOL and LOCK requests together
+ (but because this doesn't convert two separate operations into one
+ atomic operation, there's no guarantee this will work).
+
+ A successful lock request to an unmapped URL MUST result in the
+ creation of a locked (non-collection) resource with empty content.
+ Subsequently, a successful PUT request (with the correct lock token)
+ provides the content for the resource. Note that the LOCK request
+ has no mechanism for the client to provide Content-Type or Content-
+ Language, thus the server will use defaults or empty values and rely
+ on the subsequent PUT request for correct values.
+
+ A resource created with a LOCK is empty but otherwise behaves in
+ every way as a normal resource. It behaves the same way as a
+ resource created by a PUT request with an empty body (and where a
+ Content-Type and Content-Language was not specified), followed by a
+ LOCK request to the same resource. Following from this model, a
+ locked empty resource:
+
+ o Can be read, deleted, moved, and copied, and in all ways behaves
+ as a regular non-collection resource.
+
+ o Appears as a member of its parent collection.
+
+ o SHOULD NOT disappear when its lock goes away (clients must
+ therefore be responsible for cleaning up their own mess, as with
+ any other operation or any non-empty resource).
+
+
+
+Dusseault Standards Track [Page 25]
+
+RFC 4918 WebDAV June 2007
+
+
+ o MAY NOT have values for properties like DAV:getcontentlanguage
+ that haven't been specified yet by the client.
+
+ o Can be updated (have content added) with a PUT request.
+
+ o MUST NOT be converted into a collection. The server MUST fail a
+ MKCOL request (as it would with a MKCOL request to any existing
+ non-collection resource).
+
+ o MUST have defined values for DAV:lockdiscovery and DAV:
+ supportedlock properties.
+
+ o The response MUST indicate that a resource was created, by use of
+ the "201 Created" response code (a LOCK request to an existing
+ resource instead will result in 200 OK). The body must still
+ include the DAV:lockdiscovery property, as with a LOCK request to
+ an existing resource.
+
+ The client is expected to update the locked empty resource shortly
+ after locking it, using PUT and possibly PROPPATCH.
+
+ Alternatively and for backwards compatibility to [RFC2518], servers
+ MAY implement Lock-Null Resources (LNRs) instead (see definition in
+ Appendix D). Clients can easily interoperate both with servers that
+ support the old model LNRs and the recommended model of "locked empty
+ resources" by only attempting PUT after a LOCK to an unmapped URL,
+ not MKCOL or GET, and by not relying on specific properties of LNRs.
+
+7.4. Write Locks and Collections
+
+ There are two kinds of collection write locks. A depth-0 write lock
+ on a collection protects the collection properties plus the internal
+ member URLs of that one collection, while not protecting the content
+ or properties of member resources (if the collection itself has any
+ entity bodies, those are also protected). A depth-infinity write
+ lock on a collection provides the same protection on that collection
+ and also provides write lock protection on every member resource.
+
+ Expressed otherwise, a write lock of either kind protects any request
+ that would create a new resource in a write locked collection, any
+ request that would remove an internal member URL of a write locked
+ collection, and any request that would change the segment name of any
+ internal member.
+
+ Thus, a collection write lock protects all the following actions:
+
+ o DELETE a collection's direct internal member,
+
+
+
+
+Dusseault Standards Track [Page 26]
+
+RFC 4918 WebDAV June 2007
+
+
+ o MOVE an internal member out of the collection,
+
+ o MOVE an internal member into the collection,
+
+ o MOVE to rename an internal member within a collection,
+
+ o COPY an internal member into a collection, and
+
+ o PUT or MKCOL request that would create a new internal member.
+
+ The collection's lock token is required in addition to the lock token
+ on the internal member itself, if it is locked separately.
+
+ In addition, a depth-infinity lock affects all write operations to
+ all members of the locked collection. With a depth-infinity lock,
+ the resource identified by the root of the lock is directly locked,
+ and all its members are indirectly locked.
+
+ o Any new resource added as a descendant of a depth-infinity locked
+ collection becomes indirectly locked.
+
+ o Any indirectly locked resource moved out of the locked collection
+ into an unlocked collection is thereafter unlocked.
+
+ o Any indirectly locked resource moved out of a locked source
+ collection into a depth-infinity locked target collection remains
+ indirectly locked but is now protected by the lock on the target
+ collection (the target collection's lock token will thereafter be
+ required to make further changes).
+
+ If a depth-infinity write LOCK request is issued to a collection
+ containing member URLs identifying resources that are currently
+ locked in a manner that conflicts with the new lock (see Section 6.1,
+ point 3), the request MUST fail with a 423 (Locked) status code, and
+ the response SHOULD contain the 'no-conflicting-lock' precondition.
+
+ If a lock request causes the URL of a resource to be added as an
+ internal member URL of a depth-infinity locked collection, then the
+ new resource MUST be automatically protected by the lock. For
+ example, if the collection /a/b/ is write locked and the resource /c
+ is moved to /a/b/c, then resource /a/b/c will be added to the write
+ lock.
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 27]
+
+RFC 4918 WebDAV June 2007
+
+
+7.5. Write Locks and the If Request Header
+
+ A user agent has to demonstrate knowledge of a lock when requesting
+ an operation on a locked resource. Otherwise, the following scenario
+ might occur. In the scenario, program A, run by User A, takes out a
+ write lock on a resource. Program B, also run by User A, has no
+ knowledge of the lock taken out by program A, yet performs a PUT to
+ the locked resource. In this scenario, the PUT succeeds because
+ locks are associated with a principal, not a program, and thus
+ program B, because it is acting with principal A's credential, is
+ allowed to perform the PUT. However, had program B known about the
+ lock, it would not have overwritten the resource, preferring instead
+ to present a dialog box describing the conflict to the user. Due to
+ this scenario, a mechanism is needed to prevent different programs
+ from accidentally ignoring locks taken out by other programs with the
+ same authorization.
+
+ In order to prevent these collisions, a lock token MUST be submitted
+ by an authorized principal for all locked resources that a method may
+ change or the method MUST fail. A lock token is submitted when it
+ appears in an If header. For example, if a resource is to be moved
+ and both the source and destination are locked, then two lock tokens
+ must be submitted in the If header, one for the source and the other
+ for the destination.
+
+7.5.1. Example - Write Lock and COPY
+
+ >>Request
+
+ COPY /~fielding/index.html HTTP/1.1
+ Host: www.example.com
+ Destination: http://www.example.com/users/f/fielding/index.html
+ If: <http://www.example.com/users/f/fielding/index.html>
+ (<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
+
+ >>Response
+
+ HTTP/1.1 204 No Content
+
+ In this example, even though both the source and destination are
+ locked, only one lock token must be submitted (the one for the lock
+ on the destination). This is because the source resource is not
+ modified by a COPY, and hence unaffected by the write lock. In this
+ example, user agent authentication has previously occurred via a
+ mechanism outside the scope of the HTTP protocol, in the underlying
+ transport layer.
+
+
+
+
+
+Dusseault Standards Track [Page 28]
+
+RFC 4918 WebDAV June 2007
+
+
+7.5.2. Example - Deleting a Member of a Locked Collection
+
+ Consider a collection "/locked" with an exclusive, depth-infinity
+ write lock, and an attempt to delete an internal member "/locked/
+ member":
+
+ >>Request
+
+ DELETE /locked/member HTTP/1.1
+ Host: example.com
+
+ >>Response
+
+ HTTP/1.1 423 Locked
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:error xmlns:D="DAV:">
+ <D:lock-token-submitted>
+ <D:href>/locked/</D:href>
+ </D:lock-token-submitted>
+ </D:error>
+
+ Thus, the client would need to submit the lock token with the request
+ to make it succeed. To do that, various forms of the If header (see
+ Section 10.4) could be used.
+
+ "No-Tag-List" format:
+
+ If: (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
+
+ "Tagged-List" format, for "http://example.com/locked/":
+
+ If: <http://example.com/locked/>
+ (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
+
+ "Tagged-List" format, for "http://example.com/locked/member":
+
+ If: <http://example.com/locked/member>
+ (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
+
+ Note that, for the purpose of submitting the lock token, the actual
+ form doesn't matter; what's relevant is that the lock token appears
+ in the If header, and that the If header itself evaluates to true.
+
+
+
+
+
+
+Dusseault Standards Track [Page 29]
+
+RFC 4918 WebDAV June 2007
+
+
+7.6. Write Locks and COPY/MOVE
+
+ A COPY method invocation MUST NOT duplicate any write locks active on
+ the source. However, as previously noted, if the COPY copies the
+ resource into a collection that is locked with a depth-infinity lock,
+ then the resource will be added to the lock.
+
+ A successful MOVE request on a write locked resource MUST NOT move
+ the write lock with the resource. However, if there is an existing
+ lock at the destination, the server MUST add the moved resource to
+ the destination lock scope. For example, if the MOVE makes the
+ resource a child of a collection that has a depth-infinity lock, then
+ the resource will be added to that collection's lock. Additionally,
+ if a resource with a depth-infinity lock is moved to a destination
+ that is within the scope of the same lock (e.g., within the URL
+ namespace tree covered by the lock), the moved resource will again be
+ added to the lock. In both these examples, as specified in
+ Section 7.5, an If header must be submitted containing a lock token
+ for both the source and destination.
+
+7.7. Refreshing Write Locks
+
+ A client MUST NOT submit the same write lock request twice. Note
+ that a client is always aware it is resubmitting the same lock
+ request because it must include the lock token in the If header in
+ order to make the request for a resource that is already locked.
+
+ However, a client may submit a LOCK request with an If header but
+ without a body. A server receiving a LOCK request with no body MUST
+ NOT create a new lock -- this form of the LOCK request is only to be
+ used to "refresh" an existing lock (meaning, at minimum, that any
+ timers associated with the lock MUST be reset).
+
+ Clients may submit Timeout headers of arbitrary value with their lock
+ refresh requests. Servers, as always, may ignore Timeout headers
+ submitted by the client, and a server MAY refresh a lock with a
+ timeout period that is different than the previous timeout period
+ used for the lock, provided it advertises the new value in the LOCK
+ refresh response.
+
+ If an error is received in response to a refresh LOCK request, the
+ client MUST NOT assume that the lock was refreshed.
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 30]
+
+RFC 4918 WebDAV June 2007
+
+
+8. General Request and Response Handling
+
+8.1. Precedence in Error Handling
+
+ Servers MUST return authorization errors in preference to other
+ errors. This avoids leaking information about protected resources
+ (e.g., a client that finds that a hidden resource exists by seeing a
+ 423 Locked response to an anonymous request to the resource).
+
+8.2. Use of XML
+
+ In HTTP/1.1, method parameter information was exclusively encoded in
+ HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
+ information either in an XML ([REC-XML]) request entity body, or in
+ an HTTP header. The use of XML to encode method parameters was
+ motivated by the ability to add extra XML elements to existing
+ structures, providing extensibility; and by XML's ability to encode
+ information in ISO 10646 character sets, providing
+ internationalization support.
+
+ In addition to encoding method parameters, XML is used in WebDAV to
+ encode the responses from methods, providing the extensibility and
+ internationalization advantages of XML for method output, as well as
+ input.
+
+ When XML is used for a request or response body, the Content-Type
+ type SHOULD be application/xml. Implementations MUST accept both
+ text/xml and application/xml in request and response bodies. Use of
+ text/xml is deprecated.
+
+ All DAV-compliant clients and resources MUST use XML parsers that are
+ compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either
+ requests or responses MUST be, at minimum, well formed and use
+ namespaces correctly. If a server receives XML that is not well-
+ formed, then the server MUST reject the entire request with a 400
+ (Bad Request). If a client receives XML that is not well-formed in a
+ response, then the client MUST NOT assume anything about the outcome
+ of the executed method and SHOULD treat the server as malfunctioning.
+
+ Note that processing XML submitted by an untrusted source may cause
+ risks connected to privacy, security, and service quality (see
+ Section 20). Servers MAY reject questionable requests (even though
+ they consist of well-formed XML), for instance, with a 400 (Bad
+ Request) status code and an optional response body explaining the
+ problem.
+
+
+
+
+
+
+Dusseault Standards Track [Page 31]
+
+RFC 4918 WebDAV June 2007
+
+
+8.3. URL Handling
+
+ URLs appear in many places in requests and responses.
+ Interoperability experience with [RFC2518] showed that many clients
+ parsing Multi-Status responses did not fully implement the full
+ Reference Resolution defined in Section 5 of [RFC3986]. Thus,
+ servers in particular need to be careful in handling URLs in
+ responses, to ensure that clients have enough context to be able to
+ interpret all the URLs. The rules in this section apply not only to
+ resource URLs in the 'href' element in Multi-Status responses, but
+ also to the Destination and If header resource URLs.
+
+ The sender has a choice between two approaches: using a relative
+ reference, which is resolved against the Request-URI, or a full URI.
+ A server MUST ensure that every 'href' value within a Multi-Status
+ response uses the same format.
+
+ WebDAV only uses one form of relative reference in its extensions,
+ the absolute path.
+
+ Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )
+
+ The absolute-URI, path-absolute and query productions are defined in
+ Sections 4.3, 3.3, and 3.4 of [RFC3986].
+
+ Within Simple-ref productions, senders MUST NOT:
+
+ o use dot-segments ("." or ".."), or
+
+ o have prefixes that do not match the Request-URI (using the
+ comparison rules defined in Section 3.2.3 of [RFC2616]).
+
+ Identifiers for collections SHOULD end in a '/' character.
+
+8.3.1. Example - Correct URL Handling
+
+ Consider the collection http://example.com/sample/ with the internal
+ member URL http://example.com/sample/a%20test and the PROPFIND
+ request below:
+
+ >>Request:
+
+ PROPFIND /sample/ HTTP/1.1
+ Host: example.com
+ Depth: 1
+
+
+
+
+
+
+Dusseault Standards Track [Page 32]
+
+RFC 4918 WebDAV June 2007
+
+
+ In this case, the server should return two 'href' elements containing
+ either
+
+ o 'http://example.com/sample/' and
+ 'http://example.com/sample/a%20test', or
+
+ o '/sample/' and '/sample/a%20test'
+
+ Note that even though the server may be storing the member resource
+ internally as 'a test', it has to be percent-encoded when used inside
+ a URI reference (see Section 2.1 of [RFC3986]). Also note that a
+ legal URI may still contain characters that need to be escaped within
+ XML character data, such as the ampersand character.
+
+8.4. Required Bodies in Requests
+
+ Some of these new methods do not define bodies. Servers MUST examine
+ all requests for a body, even when a body was not expected. In cases
+ where a request body is present but would be ignored by a server, the
+ server MUST reject the request with 415 (Unsupported Media Type).
+ This informs the client (which may have been attempting to use an
+ extension) that the body could not be processed as the client
+ intended.
+
+8.5. HTTP Headers for Use in WebDAV
+
+ HTTP defines many headers that can be used in WebDAV requests and
+ responses. Not all of these are appropriate in all situations and
+ some interactions may be undefined. Note that HTTP 1.1 requires the
+ Date header in all responses if possible (see Section 14.18,
+ [RFC2616]).
+
+ The server MUST do authorization checks before checking any HTTP
+ conditional header.
+
+8.6. ETag
+
+ HTTP 1.1 recommends the use of ETags rather than modification dates,
+ for cache control, and there are even stronger reasons to prefer
+ ETags for authoring. Correct use of ETags is even more important in
+ a distributed authoring environment, because ETags are necessary
+ along with locks to avoid the lost-update problem. A client might
+ fail to renew a lock, for example, when the lock times out and the
+ client is accidentally offline or in the middle of a long upload.
+ When a client fails to renew the lock, it's quite possible the
+ resource can still be relocked and the user can go on editing, as
+ long as no changes were made in the meantime. ETags are required for
+ the client to be able to distinguish this case. Otherwise, the
+
+
+
+Dusseault Standards Track [Page 33]
+
+RFC 4918 WebDAV June 2007
+
+
+ client is forced to ask the user whether to overwrite the resource on
+ the server without even being able to tell the user if it has
+ changed. Timestamps do not solve this problem nearly as well as
+ ETags.
+
+ Strong ETags are much more useful for authoring use cases than weak
+ ETags (see Section 13.3.3 of [RFC2616]). Semantic equivalence can be
+ a useful concept but that depends on the document type and the
+ application type, and interoperability might require some agreement
+ or standard outside the scope of this specification and HTTP. Note
+ also that weak ETags have certain restrictions in HTTP, e.g., these
+ cannot be used in If-Match headers.
+
+ Note that the meaning of an ETag in a PUT response is not clearly
+ defined either in this document or in RFC 2616 (i.e., whether the
+ ETag means that the resource is octet-for-octet equivalent to the
+ body of the PUT request, or whether the server could have made minor
+ changes in the formatting or content of the document upon storage).
+ This is an HTTP issue, not purely a WebDAV issue.
+
+ Because clients may be forced to prompt users or throw away changed
+ content if the ETag changes, a WebDAV server SHOULD NOT change the
+ ETag (or the Last-Modified time) for a resource that has an unchanged
+ body and location. The ETag represents the state of the body or
+ contents of the resource. There is no similar way to tell if
+ properties have changed.
+
+8.7. Including Error Response Bodies
+
+ HTTP and WebDAV did not use the bodies of most error responses for
+ machine-parsable information until the specification for Versioning
+ Extensions to WebDAV introduced a mechanism to include more specific
+ information in the body of an error response (Section 1.6 of
+ [RFC3253]). The error body mechanism is appropriate to use with any
+ error response that may take a body but does not already have a body
+ defined. The mechanism is particularly appropriate when a status
+ code can mean many things (for example, 400 Bad Request can mean
+ required headers are missing, headers are incorrectly formatted, or
+ much more). This error body mechanism is covered in Section 16.
+
+8.8. Impact of Namespace Operations on Cache Validators
+
+ Note that the HTTP response headers "Etag" and "Last-Modified" (see
+ [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per
+ resource), and are used by clients for caching. Therefore servers
+ must ensure that executing any operation that affects the URL
+ namespace (such as COPY, MOVE, DELETE, PUT, or MKCOL) does preserve
+ their semantics, in particular:
+
+
+
+Dusseault Standards Track [Page 34]
+
+RFC 4918 WebDAV June 2007
+
+
+ o For any given URL, the "Last-Modified" value MUST increment every
+ time the representation returned upon GET changes (within the
+ limits of timestamp resolution).
+
+ o For any given URL, an "ETag" value MUST NOT be reused for
+ different representations returned by GET.
+
+ In practice this means that servers
+
+ o might have to increment "Last-Modified" timestamps for every
+ resource inside the destination namespace of a namespace operation
+ unless it can do so more selectively, and
+
+ o similarly, might have to re-assign "ETag" values for these
+ resources (unless the server allocates entity tags in a way so
+ that they are unique across the whole URL namespace managed by the
+ server).
+
+ Note that these considerations also apply to specific use cases, such
+ as using PUT to create a new resource at a URL that has been mapped
+ before, but has been deleted since then.
+
+ Finally, WebDAV properties (such as DAV:getetag and DAV:
+ getlastmodified) that inherit their semantics from HTTP headers must
+ behave accordingly.
+
+9. HTTP Methods for Distributed Authoring
+
+9.1. PROPFIND Method
+
+ The PROPFIND method retrieves properties defined on the resource
+ identified by the Request-URI, if the resource does not have any
+ internal members, or on the resource identified by the Request-URI
+ and potentially its member resources, if the resource is a collection
+ that has internal member URLs. All DAV-compliant resources MUST
+ support the PROPFIND method and the propfind XML element
+ (Section 14.20) along with all XML elements defined for use with that
+ element.
+
+ A client MUST submit a Depth header with a value of "0", "1", or
+ "infinity" with a PROPFIND request. Servers MUST support "0" and "1"
+ depth requests on WebDAV-compliant resources and SHOULD support
+ "infinity" requests. In practice, support for infinite-depth
+ requests MAY be disabled, due to the performance and security
+ concerns associated with this behavior. Servers SHOULD treat a
+ request without a Depth header as if a "Depth: infinity" header was
+ included.
+
+
+
+
+Dusseault Standards Track [Page 35]
+
+RFC 4918 WebDAV June 2007
+
+
+ A client may submit a 'propfind' XML element in the body of the
+ request method describing what information is being requested. It is
+ possible to:
+
+ o Request particular property values, by naming the properties
+ desired within the 'prop' element (the ordering of properties in
+ here MAY be ignored by the server),
+
+ o Request property values for those properties defined in this
+ specification (at a minimum) plus dead properties, by using the
+ 'allprop' element (the 'include' element can be used with
+ 'allprop' to instruct the server to also include additional live
+ properties that may not have been returned otherwise),
+
+ o Request a list of names of all the properties defined on the
+ resource, by using the 'propname' element.
+
+ A client may choose not to submit a request body. An empty PROPFIND
+ request body MUST be treated as if it were an 'allprop' request.
+
+ Note that 'allprop' does not return values for all live properties.
+ WebDAV servers increasingly have expensively-calculated or lengthy
+ properties (see [RFC3253] and [RFC3744]) and do not return all
+ properties already. Instead, WebDAV clients can use propname
+ requests to discover what live properties exist, and request named
+ properties when retrieving values. For a live property defined
+ elsewhere, that definition can specify whether or not that live
+ property would be returned in 'allprop' requests.
+
+ All servers MUST support returning a response of content type text/
+ xml or application/xml that contains a multistatus XML element that
+ describes the results of the attempts to retrieve the various
+ properties.
+
+ If there is an error retrieving a property, then a proper error
+ result MUST be included in the response. A request to retrieve the
+ value of a property that does not exist is an error and MUST be noted
+ with a 'response' XML element that contains a 404 (Not Found) status
+ value.
+
+ Consequently, the 'multistatus' XML element for a collection resource
+ MUST include a 'response' XML element for each member URL of the
+ collection, to whatever depth was requested. It SHOULD NOT include
+ any 'response' elements for resources that are not WebDAV-compliant.
+ Each 'response' element MUST contain an 'href' element that contains
+ the URL of the resource on which the properties in the prop XML
+ element are defined. Results for a PROPFIND on a collection resource
+ are returned as a flat list whose order of entries is not
+
+
+
+Dusseault Standards Track [Page 36]
+
+RFC 4918 WebDAV June 2007
+
+
+ significant. Note that a resource may have only one value for a
+ property of a given name, so the property may only show up once in
+ PROPFIND responses.
+
+ Properties may be subject to access control. In the case of
+ 'allprop' and 'propname' requests, if a principal does not have the
+ right to know whether a particular property exists, then the property
+ MAY be silently excluded from the response.
+
+ Some PROPFIND results MAY be cached, with care, as there is no cache
+ validation mechanism for most properties. This method is both safe
+ and idempotent (see Section 9.1 of [RFC2616]).
+
+9.1.1. PROPFIND Status Codes
+
+ This section, as with similar sections for other methods, provides
+ some guidance on error codes and preconditions or postconditions
+ (defined in Section 16) that might be particularly useful with
+ PROPFIND.
+
+ 403 Forbidden - A server MAY reject PROPFIND requests on collections
+ with depth header of "Infinity", in which case it SHOULD use this
+ error with the precondition code 'propfind-finite-depth' inside the
+ error body.
+
+9.1.2. Status Codes for Use in 'propstat' Element
+
+ In PROPFIND responses, information about individual properties is
+ returned inside 'propstat' elements (see Section 14.22), each
+ containing an individual 'status' element containing information
+ about the properties appearing in it. The list below summarizes the
+ most common status codes used inside 'propstat'; however, clients
+ should be prepared to handle other 2/3/4/5xx series status codes as
+ well.
+
+ 200 OK - A property exists and/or its value is successfully returned.
+
+ 401 Unauthorized - The property cannot be viewed without appropriate
+ authorization.
+
+ 403 Forbidden - The property cannot be viewed regardless of
+ authentication.
+
+ 404 Not Found - The property does not exist.
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 37]
+
+RFC 4918 WebDAV June 2007
+
+
+9.1.3. Example - Retrieving Named Properties
+
+ >>Request
+
+ PROPFIND /file HTTP/1.1
+ Host: www.example.com
+ Content-type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:">
+ <D:prop xmlns:R="http://ns.example.com/boxschema/">
+ <R:bigbox/>
+ <R:author/>
+ <R:DingALing/>
+ <R:Random/>
+ </D:prop>
+ </D:propfind>
+
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:">
+ <D:response xmlns:R="http://ns.example.com/boxschema/">
+ <D:href>http://www.example.com/file</D:href>
+ <D:propstat>
+ <D:prop>
+ <R:bigbox>
+ <R:BoxType>Box type A</R:BoxType>
+ </R:bigbox>
+ <R:author>
+ <R:Name>J.J. Johnson</R:Name>
+ </R:author>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ <D:propstat>
+ <D:prop><R:DingALing/><R:Random/></D:prop>
+ <D:status>HTTP/1.1 403 Forbidden</D:status>
+ <D:responsedescription> The user does not have access to the
+ DingALing property.
+ </D:responsedescription>
+ </D:propstat>
+
+
+
+Dusseault Standards Track [Page 38]
+
+RFC 4918 WebDAV June 2007
+
+
+ </D:response>
+ <D:responsedescription> There has been an access violation error.
+ </D:responsedescription>
+ </D:multistatus>
+
+
+ In this example, PROPFIND is executed on a non-collection resource
+ http://www.example.com/file. The propfind XML element specifies the
+ name of four properties whose values are being requested. In this
+ case, only two properties were returned, since the principal issuing
+ the request did not have sufficient access rights to see the third
+ and fourth properties.
+
+9.1.4. Example - Using 'propname' to Retrieve All Property Names
+
+ >>Request
+
+ PROPFIND /container/ HTTP/1.1
+ Host: www.example.com
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <propfind xmlns="DAV:">
+ <propname/>
+ </propfind>
+
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <multistatus xmlns="DAV:">
+ <response>
+ <href>http://www.example.com/container/</href>
+ <propstat>
+ <prop xmlns:R="http://ns.example.com/boxschema/">
+ <R:bigbox/>
+ <R:author/>
+ <creationdate/>
+ <displayname/>
+ <resourcetype/>
+ <supportedlock/>
+ </prop>
+ <status>HTTP/1.1 200 OK</status>
+
+
+
+Dusseault Standards Track [Page 39]
+
+RFC 4918 WebDAV June 2007
+
+
+ </propstat>
+ </response>
+ <response>
+ <href>http://www.example.com/container/front.html</href>
+ <propstat>
+ <prop xmlns:R="http://ns.example.com/boxschema/">
+ <R:bigbox/>
+ <creationdate/>
+ <displayname/>
+ <getcontentlength/>
+ <getcontenttype/>
+ <getetag/>
+ <getlastmodified/>
+ <resourcetype/>
+ <supportedlock/>
+ </prop>
+ <status>HTTP/1.1 200 OK</status>
+ </propstat>
+ </response>
+ </multistatus>
+
+ In this example, PROPFIND is invoked on the collection resource
+ http://www.example.com/container/, with a propfind XML element
+ containing the propname XML element, meaning the name of all
+ properties should be returned. Since no Depth header is present, it
+ assumes its default value of "infinity", meaning the name of the
+ properties on the collection and all its descendants should be
+ returned.
+
+ Consistent with the previous example, resource
+ http://www.example.com/container/ has six properties defined on it:
+ bigbox and author in the "http://ns.example.com/boxschema/"
+ namespace, and creationdate, displayname, resourcetype, and
+ supportedlock in the "DAV:" namespace.
+
+ The resource http://www.example.com/container/index.html, a member of
+ the "container" collection, has nine properties defined on it, bigbox
+ in the "http://ns.example.com/boxschema/" namespace and creationdate,
+ displayname, getcontentlength, getcontenttype, getetag,
+ getlastmodified, resourcetype, and supportedlock in the "DAV:"
+ namespace.
+
+ This example also demonstrates the use of XML namespace scoping and
+ the default namespace. Since the "xmlns" attribute does not contain
+ a prefix, the namespace applies by default to all enclosed elements.
+ Hence, all elements that do not explicitly state the namespace to
+ which they belong are members of the "DAV:" namespace.
+
+
+
+
+Dusseault Standards Track [Page 40]
+
+RFC 4918 WebDAV June 2007
+
+
+9.1.5. Example - Using So-called 'allprop'
+
+ Note that 'allprop', despite its name, which remains for backward-
+ compatibility, does not return every property, but only dead
+ properties and the live properties defined in this specification.
+
+ >>Request
+
+ PROPFIND /container/ HTTP/1.1
+ Host: www.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:">
+ <D:allprop/>
+ </D:propfind>
+
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:">
+ <D:response>
+ <D:href>/container/</D:href>
+ <D:propstat>
+ <D:prop xmlns:R="http://ns.example.com/boxschema/">
+ <R:bigbox><R:BoxType>Box type A</R:BoxType></R:bigbox>
+ <R:author><R:Name>Hadrian</R:Name></R:author>
+ <D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
+ <D:displayname>Example collection</D:displayname>
+ <D:resourcetype><D:collection/></D:resourcetype>
+ <D:supportedlock>
+ <D:lockentry>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ <D:lockentry>
+ <D:lockscope><D:shared/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ </D:supportedlock>
+ </D:prop>
+
+
+
+Dusseault Standards Track [Page 41]
+
+RFC 4918 WebDAV June 2007
+
+
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ <D:response>
+ <D:href>/container/front.html</D:href>
+ <D:propstat>
+ <D:prop xmlns:R="http://ns.example.com/boxschema/">
+ <R:bigbox><R:BoxType>Box type B</R:BoxType>
+ </R:bigbox>
+ <D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate>
+ <D:displayname>Example HTML resource</D:displayname>
+ <D:getcontentlength>4525</D:getcontentlength>
+ <D:getcontenttype>text/html</D:getcontenttype>
+ <D:getetag>"zzyzx"</D:getetag>
+ <D:getlastmodified
+ >Mon, 12 Jan 1998 09:25:56 GMT</D:getlastmodified>
+ <D:resourcetype/>
+ <D:supportedlock>
+ <D:lockentry>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ <D:lockentry>
+ <D:lockscope><D:shared/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ </D:supportedlock>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+ In this example, PROPFIND was invoked on the resource
+ http://www.example.com/container/ with a Depth header of 1, meaning
+ the request applies to the resource and its children, and a propfind
+ XML element containing the allprop XML element, meaning the request
+ should return the name and value of all the dead properties defined
+ on the resources, plus the name and value of all the properties
+ defined in this specification. This example illustrates the use of
+ relative references in the 'href' elements of the response.
+
+ The resource http://www.example.com/container/ has six properties
+ defined on it: 'bigbox' and 'author in the
+ "http://ns.example.com/boxschema/" namespace, DAV:creationdate, DAV:
+ displayname, DAV:resourcetype, and DAV:supportedlock.
+
+
+
+
+
+Dusseault Standards Track [Page 42]
+
+RFC 4918 WebDAV June 2007
+
+
+ The last four properties are WebDAV-specific, defined in Section 15.
+ Since GET is not supported on this resource, the get* properties
+ (e.g., DAV:getcontentlength) are not defined on this resource. The
+ WebDAV-specific properties assert that "container" was created on
+ December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT
+ (DAV:creationdate), has a name of "Example collection" (DAV:
+ displayname), a collection resource type (DAV:resourcetype), and
+ supports exclusive write and shared write locks (DAV:supportedlock).
+
+ The resource http://www.example.com/container/front.html has nine
+ properties defined on it:
+
+ 'bigbox' in the "http://ns.example.com/boxschema/" namespace (another
+ instance of the "bigbox" property type), DAV:creationdate, DAV:
+ displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
+ DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
+
+ The DAV-specific properties assert that "front.html" was created on
+ December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT
+ (DAV:creationdate), has a name of "Example HTML resource" (DAV:
+ displayname), a content length of 4525 bytes (DAV:getcontentlength),
+ a MIME type of "text/html" (DAV:getcontenttype), an entity tag of
+ "zzyzx" (DAV:getetag), was last modified on Monday, January 12, 1998,
+ at 09:25:56 GMT (DAV:getlastmodified), has an empty resource type,
+ meaning that it is not a collection (DAV:resourcetype), and supports
+ both exclusive write and shared write locks (DAV:supportedlock).
+
+9.1.6. Example - Using 'allprop' with 'include'
+
+ >>Request
+
+ PROPFIND /mycol/ HTTP/1.1
+ Host: www.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:">
+ <D:allprop/>
+ <D:include>
+ <D:supported-live-property-set/>
+ <D:supported-report-set/>
+ </D:include>
+ </D:propfind>
+
+
+
+
+
+
+Dusseault Standards Track [Page 43]
+
+RFC 4918 WebDAV June 2007
+
+
+ In this example, PROPFIND is executed on the resource
+ http://www.example.com/mycol/ and its internal member resources. The
+ client requests the values of all live properties defined in this
+ specification, plus all dead properties, plus two more live
+ properties defined in [RFC3253]. The response is not shown.
+
+9.2. PROPPATCH Method
+
+ The PROPPATCH method processes instructions specified in the request
+ body to set and/or remove properties defined on the resource
+ identified by the Request-URI.
+
+ All DAV-compliant resources MUST support the PROPPATCH method and
+ MUST process instructions that are specified using the
+ propertyupdate, set, and remove XML elements. Execution of the
+ directives in this method is, of course, subject to access control
+ constraints. DAV-compliant resources SHOULD support the setting of
+ arbitrary dead properties.
+
+ The request message body of a PROPPATCH method MUST contain the
+ propertyupdate XML element.
+
+ Servers MUST process PROPPATCH instructions in document order (an
+ exception to the normal rule that ordering is irrelevant).
+ Instructions MUST either all be executed or none executed. Thus, if
+ any error occurs during processing, all executed instructions MUST be
+ undone and a proper error result returned. Instruction processing
+ details can be found in the definition of the set and remove
+ instructions in Sections 14.23 and 14.26.
+
+ If a server attempts to make any of the property changes in a
+ PROPPATCH request (i.e., the request is not rejected for high-level
+ errors before processing the body), the response MUST be a Multi-
+ Status response as described in Section 9.2.1.
+
+ This method is idempotent, but not safe (see Section 9.1 of
+ [RFC2616]). Responses to this method MUST NOT be cached.
+
+9.2.1. Status Codes for Use in 'propstat' Element
+
+ In PROPPATCH responses, information about individual properties is
+ returned inside 'propstat' elements (see Section 14.22), each
+ containing an individual 'status' element containing information
+ about the properties appearing in it. The list below summarizes the
+ most common status codes used inside 'propstat'; however, clients
+ should be prepared to handle other 2/3/4/5xx series status codes as
+ well.
+
+
+
+
+Dusseault Standards Track [Page 44]
+
+RFC 4918 WebDAV June 2007
+
+
+ 200 (OK) - The property set or change succeeded. Note that if this
+ appears for one property, it appears for every property in the
+ response, due to the atomicity of PROPPATCH.
+
+ 403 (Forbidden) - The client, for reasons the server chooses not to
+ specify, cannot alter one of the properties.
+
+ 403 (Forbidden): The client has attempted to set a protected
+ property, such as DAV:getetag. If returning this error, the server
+ SHOULD use the precondition code 'cannot-modify-protected-property'
+ inside the response body.
+
+ 409 (Conflict) - The client has provided a value whose semantics are
+ not appropriate for the property.
+
+ 424 (Failed Dependency) - The property change could not be made
+ because of another property change that failed.
+
+ 507 (Insufficient Storage) - The server did not have sufficient space
+ to record the property.
+
+9.2.2. Example - PROPPATCH
+
+ >>Request
+
+ PROPPATCH /bar.html HTTP/1.1
+ Host: www.example.com
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propertyupdate xmlns:D="DAV:"
+ xmlns:Z="http://ns.example.com/standards/z39.50/">
+ <D:set>
+ <D:prop>
+ <Z:Authors>
+ <Z:Author>Jim Whitehead</Z:Author>
+ <Z:Author>Roy Fielding</Z:Author>
+ </Z:Authors>
+ </D:prop>
+ </D:set>
+ <D:remove>
+ <D:prop><Z:Copyright-Owner/></D:prop>
+ </D:remove>
+ </D:propertyupdate>
+
+
+
+
+
+
+Dusseault Standards Track [Page 45]
+
+RFC 4918 WebDAV June 2007
+
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:Z="http://ns.example.com/standards/z39.50/">
+ <D:response>
+ <D:href>http://www.example.com/bar.html</D:href>
+ <D:propstat>
+ <D:prop><Z:Authors/></D:prop>
+ <D:status>HTTP/1.1 424 Failed Dependency</D:status>
+ </D:propstat>
+ <D:propstat>
+ <D:prop><Z:Copyright-Owner/></D:prop>
+ <D:status>HTTP/1.1 409 Conflict</D:status>
+ </D:propstat>
+ <D:responsedescription> Copyright Owner cannot be deleted or
+ altered.</D:responsedescription>
+ </D:response>
+ </D:multistatus>
+
+ In this example, the client requests the server to set the value of
+ the "Authors" property in the
+ "http://ns.example.com/standards/z39.50/" namespace, and to remove
+ the property "Copyright-Owner" in the same namespace. Since the
+ Copyright-Owner property could not be removed, no property
+ modifications occur. The 424 (Failed Dependency) status code for the
+ Authors property indicates this action would have succeeded if it
+ were not for the conflict with removing the Copyright-Owner property.
+
+9.3. MKCOL Method
+
+ MKCOL creates a new collection resource at the location specified by
+ the Request-URI. If the Request-URI is already mapped to a resource,
+ then the MKCOL MUST fail. During MKCOL processing, a server MUST
+ make the Request-URI an internal member of its parent collection,
+ unless the Request-URI is "/". If no such ancestor exists, the
+ method MUST fail. When the MKCOL operation creates a new collection
+ resource, all ancestors MUST already exist, or the method MUST fail
+ with a 409 (Conflict) status code. For example, if a request to
+ create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the
+ request must fail.
+
+ When MKCOL is invoked without a request body, the newly created
+ collection SHOULD have no members.
+
+
+
+Dusseault Standards Track [Page 46]
+
+RFC 4918 WebDAV June 2007
+
+
+ A MKCOL request message may contain a message body. The precise
+ behavior of a MKCOL request when the body is present is undefined,
+ but limited to creating collections, members of a collection, bodies
+ of members, and properties on the collections or members. If the
+ server receives a MKCOL request entity type it does not support or
+ understand, it MUST respond with a 415 (Unsupported Media Type)
+ status code. If the server decides to reject the request based on
+ the presence of an entity or the type of an entity, it should use the
+ 415 (Unsupported Media Type) status code.
+
+ This method is idempotent, but not safe (see Section 9.1 of
+ [RFC2616]). Responses to this method MUST NOT be cached.
+
+9.3.1. MKCOL Status Codes
+
+ In addition to the general status codes possible, the following
+ status codes have specific applicability to MKCOL:
+
+ 201 (Created) - The collection was created.
+
+ 403 (Forbidden) - This indicates at least one of two conditions: 1)
+ the server does not allow the creation of collections at the given
+ location in its URL namespace, or 2) the parent collection of the
+ Request-URI exists but cannot accept members.
+
+ 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped
+ URL.
+
+ 409 (Conflict) - A collection cannot be made at the Request-URI until
+ one or more intermediate collections have been created. The server
+ MUST NOT create those intermediate collections automatically.
+
+ 415 (Unsupported Media Type) - The server does not support the
+ request body type (although bodies are legal on MKCOL requests, since
+ this specification doesn't define any, the server is likely not to
+ support any given body type).
+
+ 507 (Insufficient Storage) - The resource does not have sufficient
+ space to record the state of the resource after the execution of this
+ method.
+
+9.3.2. Example - MKCOL
+
+ This example creates a collection called /webdisc/xfiles/ on the
+ server www.example.com.
+
+
+
+
+
+
+Dusseault Standards Track [Page 47]
+
+RFC 4918 WebDAV June 2007
+
+
+ >>Request
+
+ MKCOL /webdisc/xfiles/ HTTP/1.1
+ Host: www.example.com
+
+
+ >>Response
+
+ HTTP/1.1 201 Created
+
+9.4. GET, HEAD for Collections
+
+ The semantics of GET are unchanged when applied to a collection,
+ since GET is defined as, "retrieve whatever information (in the form
+ of an entity) is identified by the Request-URI" [RFC2616]. GET, when
+ applied to a collection, may return the contents of an "index.html"
+ resource, a human-readable view of the contents of the collection, or
+ something else altogether. Hence, it is possible that the result of
+ a GET on a collection will bear no correlation to the membership of
+ the collection.
+
+ Similarly, since the definition of HEAD is a GET without a response
+ message body, the semantics of HEAD are unmodified when applied to
+ collection resources.
+
+9.5. POST for Collections
+
+ Since by definition the actual function performed by POST is
+ determined by the server and often depends on the particular
+ resource, the behavior of POST when applied to collections cannot be
+ meaningfully modified because it is largely undefined. Thus, the
+ semantics of POST are unmodified when applied to a collection.
+
+9.6. DELETE Requirements
+
+ DELETE is defined in [RFC2616], Section 9.7, to "delete the resource
+ identified by the Request-URI". However, WebDAV changes some DELETE
+ handling requirements.
+
+ A server processing a successful DELETE request:
+
+ MUST destroy locks rooted on the deleted resource
+
+ MUST remove the mapping from the Request-URI to any resource.
+
+ Thus, after a successful DELETE operation (and in the absence of
+ other actions), a subsequent GET/HEAD/PROPFIND request to the target
+ Request-URI MUST return 404 (Not Found).
+
+
+
+Dusseault Standards Track [Page 48]
+
+RFC 4918 WebDAV June 2007
+
+
+9.6.1. DELETE for Collections
+
+ The DELETE method on a collection MUST act as if a "Depth: infinity"
+ header was used on it. A client MUST NOT submit a Depth header with
+ a DELETE on a collection with any value but infinity.
+
+ DELETE instructs that the collection specified in the Request-URI and
+ all resources identified by its internal member URLs are to be
+ deleted.
+
+ If any resource identified by a member URL cannot be deleted, then
+ all of the member's ancestors MUST NOT be deleted, so as to maintain
+ URL namespace consistency.
+
+ Any headers included with DELETE MUST be applied in processing every
+ resource to be deleted.
+
+ When the DELETE method has completed processing, it MUST result in a
+ consistent URL namespace.
+
+ If an error occurs deleting a member resource (a resource other than
+ the resource identified in the Request-URI), then the response can be
+ a 207 (Multi-Status). Multi-Status is used here to indicate which
+ internal resources could NOT be deleted, including an error code,
+ which should help the client understand which resources caused the
+ failure. For example, the Multi-Status body could include a response
+ with status 423 (Locked) if an internal resource was locked.
+
+ The server MAY return a 4xx status response, rather than a 207, if
+ the request failed completely.
+
+ 424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi-
+ Status) response for DELETE. They can be safely left out because the
+ client will know that the ancestors of a resource could not be
+ deleted when the client receives an error for the ancestor's progeny.
+ Additionally, 204 (No Content) errors SHOULD NOT be returned in the
+ 207 (Multi-Status). The reason for this prohibition is that 204 (No
+ Content) is the default success code.
+
+9.6.2. Example - DELETE
+
+ >>Request
+
+ DELETE /container/ HTTP/1.1
+ Host: www.example.com
+
+
+
+
+
+
+Dusseault Standards Track [Page 49]
+
+RFC 4918 WebDAV June 2007
+
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/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.example.com/container/resource3</d:href>
+ <d:status>HTTP/1.1 423 Locked</d:status>
+ <d:error><d:lock-token-submitted/></d:error>
+ </d:response>
+ </d:multistatus>
+
+ In this example, the attempt to delete
+ http://www.example.com/container/resource3 failed because it is
+ locked, and no lock token was submitted with the request.
+ Consequently, the attempt to delete http://www.example.com/container/
+ also failed. Thus, the client knows that the attempt to delete
+ http://www.example.com/container/ must have also failed since the
+ parent cannot be deleted unless its child has also been deleted.
+ Even though a Depth header has not been included, a depth of infinity
+ is assumed because the method is on a collection.
+
+9.7. PUT Requirements
+
+9.7.1. PUT for Non-Collection Resources
+
+ A PUT performed on an existing resource replaces the GET response
+ entity of the resource. Properties defined on the resource may be
+ recomputed during PUT processing but are not otherwise affected. For
+ example, if a server recognizes the content type of the request body,
+ it may be able to automatically extract information that could be
+ profitably exposed as properties.
+
+ A PUT that would result in the creation of a resource without an
+ appropriately scoped parent collection MUST fail with a 409
+ (Conflict).
+
+ A PUT request allows a client to indicate what media type an entity
+ body has, and whether it should change if overwritten. Thus, a
+ client SHOULD provide a Content-Type for a new resource if any is
+ known. If the client does not provide a Content-Type for a new
+ resource, the server MAY create a resource with no Content-Type
+ assigned, or it MAY attempt to assign a Content-Type.
+
+
+
+
+
+Dusseault Standards Track [Page 50]
+
+RFC 4918 WebDAV June 2007
+
+
+ Note that although a recipient ought generally to treat metadata
+ supplied with an HTTP request as authoritative, in practice there's
+ no guarantee that a server will accept client-supplied metadata
+ (e.g., any request header beginning with "Content-"). Many servers
+ do not allow configuring the Content-Type on a per-resource basis in
+ the first place. Thus, clients can't always rely on the ability to
+ directly influence the content type by including a Content-Type
+ request header.
+
+9.7.2. PUT for Collections
+
+ This specification does not define the behavior of the PUT method for
+ existing collections. A PUT request to an existing collection MAY be
+ treated as an error (405 Method Not Allowed).
+
+ The MKCOL method is defined to create collections.
+
+9.8. COPY Method
+
+ The COPY method creates a duplicate of the source resource identified
+ by the Request-URI, in the destination resource identified by the URI
+ in the Destination header. The Destination header MUST be present.
+ The exact behavior of the COPY method depends on the type of the
+ source resource.
+
+ All WebDAV-compliant resources MUST support the COPY method.
+ However, support for the COPY method does not guarantee the ability
+ to copy a resource. For example, separate programs may control
+ resources on the same server. As a result, it may not be possible to
+ copy a resource to a location that appears to be on the same server.
+
+ This method is idempotent, but not safe (see Section 9.1 of
+ [RFC2616]). Responses to this method MUST NOT be cached.
+
+9.8.1. COPY for Non-collection Resources
+
+ When the source resource is not a collection, the result of the COPY
+ method is the creation of a new resource at the destination whose
+ state and behavior match that of the source resource as closely as
+ possible. Since the environment at the destination may be different
+ than at the source due to factors outside the scope of control of the
+ server, such as the absence of resources required for correct
+ operation, it may not be possible to completely duplicate the
+ behavior of the resource at the destination. Subsequent alterations
+ to the destination resource will not modify the source resource.
+ Subsequent alterations to the source resource will not modify the
+ destination resource.
+
+
+
+
+Dusseault Standards Track [Page 51]
+
+RFC 4918 WebDAV June 2007
+
+
+9.8.2. COPY for Properties
+
+ After a successful COPY invocation, all dead properties on the source
+ resource SHOULD be duplicated on the destination resource. Live
+ properties described in this document SHOULD be duplicated as
+ identically behaving live properties at the destination resource, but
+ not necessarily with the same values. Servers SHOULD NOT convert
+ live properties into dead properties on the destination resource,
+ because clients may then draw incorrect conclusions about the state
+ or functionality of a resource. Note that some live properties are
+ defined such that the absence of the property has a specific meaning
+ (e.g., a flag with one meaning if present, and the opposite if
+ absent), and in these cases, a successful COPY might result in the
+ property being reported as "Not Found" in subsequent requests.
+
+ When the destination is an unmapped URL, a COPY operation creates a
+ new resource much like a PUT operation does. Live properties that
+ are related to resource creation (such as DAV:creationdate) should
+ have their values set accordingly.
+
+9.8.3. COPY for Collections
+
+ The COPY method on a collection without a Depth header MUST act as if
+ a Depth header with value "infinity" was included. A client may
+ submit a Depth header on a COPY on a collection with a value of "0"
+ or "infinity". Servers MUST support the "0" and "infinity" Depth
+ header behaviors on WebDAV-compliant resources.
+
+ An infinite-depth COPY instructs that the collection resource
+ identified by the Request-URI is to be copied to the location
+ identified by the URI in the Destination header, and all its internal
+ member resources are to be copied to a location relative to it,
+ recursively through all levels of the collection hierarchy. Note
+ that an infinite-depth COPY of /A/ into /A/B/ could lead to infinite
+ recursion if not handled correctly.
+
+ A COPY of "Depth: 0" only instructs that the collection and its
+ properties, but not resources identified by its internal member URLs,
+ are to be copied.
+
+ Any headers included with a COPY MUST be applied in processing every
+ resource to be copied with the exception of the Destination header.
+
+ The Destination header only specifies the destination URI for the
+ Request-URI. When applied to members of the collection identified by
+ the Request-URI, the value of Destination is to be modified to
+ reflect the current location in the hierarchy. So, if the Request-
+ URI is /a/ with Host header value http://example.com/ and the
+
+
+
+Dusseault Standards Track [Page 52]
+
+RFC 4918 WebDAV June 2007
+
+
+ Destination is http://example.com/b/, then when
+ http://example.com/a/c/d is processed, it must use a Destination of
+ http://example.com/b/c/d.
+
+ When the COPY method has completed processing, it MUST have created a
+ consistent URL namespace at the destination (see Section 5.1 for the
+ definition of namespace consistency). However, if an error occurs
+ while copying an internal collection, the server MUST NOT copy any
+ resources identified by members of this collection (i.e., the server
+ must skip this subtree), as this would create an inconsistent
+ namespace. After detecting an error, the COPY operation SHOULD try
+ to finish as much of the original copy operation as possible (i.e.,
+ the server should still attempt to copy other subtrees and their
+ members that are not descendants of an error-causing collection).
+
+ So, for example, if an infinite-depth copy operation is performed on
+ collection /a/, which contains collections /a/b/ and /a/c/, and an
+ error occurs copying /a/b/, an attempt should still be made to copy
+ /a/c/. Similarly, after encountering an error copying a non-
+ collection resource as part of an infinite-depth copy, the server
+ SHOULD try to finish as much of the original copy operation as
+ possible.
+
+ If an error in executing the COPY method occurs with a resource other
+ than the resource identified in the Request-URI, then the response
+ MUST be a 207 (Multi-Status), and the URL of the resource causing the
+ failure MUST appear with the specific error.
+
+ The 424 (Failed Dependency) status code SHOULD NOT be returned in the
+ 207 (Multi-Status) response from a COPY method. These responses can
+ be safely omitted because the client will know that the progeny of a
+ resource could not be copied when the client receives an error for
+ the parent. Additionally, 201 (Created)/204 (No Content) status
+ codes SHOULD NOT be returned as values in 207 (Multi-Status)
+ responses from COPY methods. They, too, can be safely omitted
+ because they are the default success codes.
+
+9.8.4. COPY and Overwriting Destination Resources
+
+ If a COPY request has an Overwrite header with a value of "F", and a
+ resource exists at the Destination URL, the server MUST fail the
+ request.
+
+ When a server executes a COPY request and overwrites a destination
+ resource, the exact behavior MAY depend on many factors, including
+ WebDAV extension capabilities (see particularly [RFC3253]). For
+
+
+
+
+
+Dusseault Standards Track [Page 53]
+
+RFC 4918 WebDAV June 2007
+
+
+ example, when an ordinary resource is overwritten, the server could
+ delete the target resource before doing the copy, or could do an in-
+ place overwrite to preserve live properties.
+
+ When a collection is overwritten, the membership of the destination
+ collection after the successful COPY request MUST be the same
+ membership as the source collection immediately before the COPY.
+ Thus, merging the membership of the source and destination
+ collections together in the destination is not a compliant behavior.
+
+ In general, if clients require the state of the destination URL to be
+ wiped out prior to a COPY (e.g., to force live properties to be
+ reset), then the client could send a DELETE to the destination before
+ the COPY request to ensure this reset.
+
+9.8.5. Status Codes
+
+ In addition to the general status codes possible, the following
+ status codes have specific applicability to COPY:
+
+ 201 (Created) - The source resource was successfully copied. The
+ COPY operation resulted in the creation of a new resource.
+
+ 204 (No Content) - The source resource was successfully copied to a
+ preexisting destination resource.
+
+ 207 (Multi-Status) - Multiple resources were to be affected by the
+ COPY, but errors on some of them prevented the operation from taking
+ place. Specific error messages, together with the most appropriate
+ of the source and destination URLs, appear in the body of the multi-
+ status response. For example, if a destination resource was locked
+ and could not be overwritten, then the destination resource URL
+ appears with the 423 (Locked) status.
+
+ 403 (Forbidden) - The operation is forbidden. A special case for
+ COPY could be that the source and destination resources are the same
+ resource.
+
+ 409 (Conflict) - A resource cannot be created at the destination
+ until one or more intermediate collections have been created. The
+ server MUST NOT create those intermediate collections automatically.
+
+ 412 (Precondition Failed) - A precondition header check failed, e.g.,
+ the Overwrite header is "F" and the destination URL is already mapped
+ to a resource.
+
+
+
+
+
+
+Dusseault Standards Track [Page 54]
+
+RFC 4918 WebDAV June 2007
+
+
+ 423 (Locked) - The destination resource, or resource within the
+ destination collection, was locked. This response SHOULD contain the
+ 'lock-token-submitted' precondition element.
+
+ 502 (Bad Gateway) - This may occur when the destination is on another
+ server, repository, or URL namespace. Either the source namespace
+ does not support copying to the destination namespace, or the
+ destination namespace refuses to accept the resource. The client may
+ wish to try GET/PUT and PROPFIND/PROPPATCH instead.
+
+ 507 (Insufficient Storage) - The destination resource does not have
+ sufficient space to record the state of the resource after the
+ execution of this method.
+
+9.8.6. Example - COPY with Overwrite
+
+ This example shows resource
+ http://www.example.com/~fielding/index.html being copied to the
+ location http://www.example.com/users/f/fielding/index.html. The 204
+ (No Content) status code indicates that the existing resource at the
+ destination was overwritten.
+
+ >>Request
+
+ COPY /~fielding/index.html HTTP/1.1
+ Host: www.example.com
+ Destination: http://www.example.com/users/f/fielding/index.html
+
+ >>Response
+
+ HTTP/1.1 204 No Content
+
+9.8.7. Example - COPY with No Overwrite
+
+ The following example shows the same copy operation being performed,
+ but with the Overwrite header set to "F." A response of 412
+ (Precondition Failed) is returned because the destination URL is
+ already mapped to a resource.
+
+ >>Request
+
+ COPY /~fielding/index.html HTTP/1.1
+ Host: www.example.com
+ Destination: http://www.example.com/users/f/fielding/index.html
+ Overwrite: F
+
+
+
+
+
+
+Dusseault Standards Track [Page 55]
+
+RFC 4918 WebDAV June 2007
+
+
+ >>Response
+
+ HTTP/1.1 412 Precondition Failed
+
+9.8.8. Example - COPY of a Collection
+
+ >>Request
+
+ COPY /container/ HTTP/1.1
+ Host: www.example.com
+ Destination: http://www.example.com/othercontainer/
+ Depth: infinity
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/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.example.com/othercontainer/R2/</d:href>
+ <d:status>HTTP/1.1 423 Locked</d:status>
+ <d:error><d:lock-token-submitted/></d:error>
+ </d:response>
+ </d:multistatus>
+
+ The Depth header is unnecessary as the default behavior of COPY on a
+ collection is to act as if a "Depth: infinity" header had been
+ submitted. In this example, most of the resources, along with the
+ collection, were copied successfully. However, the collection R2
+ failed because the destination R2 is locked. Because there was an
+ error copying R2, none of R2's members were copied. However, no
+ errors were listed for those members due to the error minimization
+ rules.
+
+9.9. MOVE Method
+
+ The MOVE operation on a non-collection resource is the logical
+ equivalent of a copy (COPY), followed by consistency maintenance
+ processing, followed by a delete of the source, where all three
+ actions are performed in a single operation. The consistency
+ maintenance step allows the server to perform updates caused by the
+ move, such as updating all URLs, other than the Request-URI that
+ identifies the source resource, to point to the new destination
+ resource.
+
+
+
+Dusseault Standards Track [Page 56]
+
+RFC 4918 WebDAV June 2007
+
+
+ The Destination header MUST be present on all MOVE methods and MUST
+ follow all COPY requirements for the COPY part of the MOVE method.
+ All WebDAV-compliant resources MUST support the MOVE method.
+
+ Support for the MOVE method does not guarantee the ability to move a
+ resource to a particular destination. For example, separate programs
+ may actually control different sets of resources on the same server.
+ Therefore, it may not be possible to move a resource within a
+ namespace that appears to belong to the same server.
+
+ If a resource exists at the destination, the destination resource
+ will be deleted as a side-effect of the MOVE operation, subject to
+ the restrictions of the Overwrite header.
+
+ This method is idempotent, but not safe (see Section 9.1 of
+ [RFC2616]). Responses to this method MUST NOT be cached.
+
+9.9.1. MOVE for Properties
+
+ Live properties described in this document SHOULD be moved along with
+ the resource, such that the resource has identically behaving live
+ properties at the destination resource, but not necessarily with the
+ same values. Note that some live properties are defined such that
+ the absence of the property has a specific meaning (e.g., a flag with
+ one meaning if present, and the opposite if absent), and in these
+ cases, a successful MOVE might result in the property being reported
+ as "Not Found" in subsequent requests. If the live properties will
+ not work the same way at the destination, the server MAY fail the
+ request.
+
+ MOVE is frequently used by clients to rename a file without changing
+ its parent collection, so it's not appropriate to reset all live
+ properties that are set at resource creation. For example, the DAV:
+ creationdate property value SHOULD remain the same after a MOVE.
+
+ Dead properties MUST be moved along with the resource.
+
+9.9.2. MOVE for Collections
+
+ A MOVE with "Depth: infinity" instructs that the collection
+ identified by the Request-URI be moved to the address specified in
+ the Destination header, and all resources identified by its internal
+ member URLs are to be moved to locations relative to it, recursively
+ through all levels of the collection hierarchy.
+
+ The MOVE method on a collection MUST act as if a "Depth: infinity"
+ header was used on it. A client MUST NOT submit a Depth header on a
+ MOVE on a collection with any value but "infinity".
+
+
+
+Dusseault Standards Track [Page 57]
+
+RFC 4918 WebDAV June 2007
+
+
+ Any headers included with MOVE MUST be applied in processing every
+ resource to be moved with the exception of the Destination header.
+ The behavior of the Destination header is the same as given for COPY
+ on collections.
+
+ When the MOVE method has completed processing, it MUST have created a
+ consistent URL namespace at both the source and destination (see
+ Section 5.1 for the definition of namespace consistency). However,
+ if an error occurs while moving an internal collection, the server
+ MUST NOT move any resources identified by members of the failed
+ collection (i.e., the server must skip the error-causing subtree), as
+ this would create an inconsistent namespace. In this case, after
+ detecting the error, the move operation SHOULD try to finish as much
+ of the original move as possible (i.e., the server should still
+ attempt to move other subtrees and the resources identified by their
+ members that are not descendants of an error-causing collection).
+ So, for example, if an infinite-depth move is performed on collection
+ /a/, which contains collections /a/b/ and /a/c/, and an error occurs
+ moving /a/b/, an attempt should still be made to try moving /a/c/.
+ Similarly, after encountering an error moving a non-collection
+ resource as part of an infinite-depth move, the server SHOULD try to
+ finish as much of the original move operation as possible.
+
+ If an error occurs with a resource other than the resource identified
+ in the Request-URI, then the response MUST be a 207 (Multi-Status),
+ and the errored resource's URL MUST appear with the specific error.
+
+ The 424 (Failed Dependency) status code SHOULD NOT be returned in the
+ 207 (Multi-Status) response from a MOVE method. These errors can be
+ safely omitted because the client will know that the progeny of a
+ resource could not be moved when the client receives an error for the
+ parent. Additionally, 201 (Created)/204 (No Content) responses
+ SHOULD NOT be returned as values in 207 (Multi-Status) responses from
+ a MOVE. These responses can be safely omitted because they are the
+ default success codes.
+
+9.9.3. MOVE and the Overwrite Header
+
+ If a resource exists at the destination and the Overwrite header is
+ "T", then prior to performing the move, the server MUST perform a
+ DELETE with "Depth: infinity" on the destination resource. If the
+ Overwrite header is set to "F", then the operation will fail.
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 58]
+
+RFC 4918 WebDAV June 2007
+
+
+9.9.4. Status Codes
+
+ In addition to the general status codes possible, the following
+ status codes have specific applicability to MOVE:
+
+ 201 (Created) - The source resource was successfully moved, and a new
+ URL mapping was created at the destination.
+
+ 204 (No Content) - The source resource was successfully moved to a
+ URL that was already mapped.
+
+ 207 (Multi-Status) - Multiple resources were to be affected by the
+ MOVE, but errors on some of them prevented the operation from taking
+ place. Specific error messages, together with the most appropriate
+ of the source and destination URLs, appear in the body of the multi-
+ status response. For example, if a source resource was locked and
+ could not be moved, then the source resource URL appears with the 423
+ (Locked) status.
+
+ 403 (Forbidden) - Among many possible reasons for forbidding a MOVE
+ operation, this status code is recommended for use when the source
+ and destination resources are the same.
+
+ 409 (Conflict) - A resource cannot be created at the destination
+ until one or more intermediate collections have been created. The
+ server MUST NOT create those intermediate collections automatically.
+ Or, the server was unable to preserve the behavior of the live
+ properties and still move the resource to the destination (see
+ 'preserved-live-properties' postcondition).
+
+ 412 (Precondition Failed) - A condition header failed. Specific to
+ MOVE, this could mean that the Overwrite header is "F" and the
+ destination URL is already mapped to a resource.
+
+ 423 (Locked) - The source or the destination resource, the source or
+ destination resource parent, or some resource within the source or
+ destination collection, was locked. This response SHOULD contain the
+ 'lock-token-submitted' precondition element.
+
+ 502 (Bad Gateway) - This may occur when the destination is on another
+ server and the destination server refuses to accept the resource.
+ This could also occur when the destination is on another sub-section
+ of the same server namespace.
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 59]
+
+RFC 4918 WebDAV June 2007
+
+
+9.9.5. Example - MOVE of a Non-Collection
+
+ This example shows resource
+ http://www.example.com/~fielding/index.html being moved to the
+ location http://www.example.com/users/f/fielding/index.html. The
+ contents of the destination resource would have been overwritten if
+ the destination URL was already mapped to a resource. In this case,
+ since there was nothing at the destination resource, the response
+ code is 201 (Created).
+
+ >>Request
+
+ MOVE /~fielding/index.html HTTP/1.1
+ Host: www.example.com
+ Destination: http://www.example/users/f/fielding/index.html
+
+ >>Response
+
+ HTTP/1.1 201 Created
+ Location: http://www.example.com/users/f/fielding/index.html
+
+9.9.6. Example - MOVE of a Collection
+
+ >>Request
+
+ MOVE /container/ HTTP/1.1
+ Host: www.example.com
+ Destination: http://www.example.com/othercontainer/
+ Overwrite: F
+ If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
+ (<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/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.example.com/othercontainer/C2/</d:href>
+ <d:status>HTTP/1.1 423 Locked</d:status>
+ <d:error><d:lock-token-submitted/></d:error>
+ </d:response>
+ </d:multistatus>
+
+
+
+
+
+Dusseault Standards Track [Page 60]
+
+RFC 4918 WebDAV June 2007
+
+
+ In this example, the client has submitted a number of lock tokens
+ with the request. A lock token will need to be submitted for every
+ resource, both source and destination, anywhere in the scope of the
+ method, that is locked. In this case, the proper lock token was not
+ submitted for the destination
+ http://www.example.com/othercontainer/C2/. This means that the
+ resource /container/C2/ could not be moved. Because there was an
+ error moving /container/C2/, none of /container/C2's members were
+ moved. However, no errors were listed for those members due to the
+ error minimization rules. User agent authentication has previously
+ occurred via a mechanism outside the scope of the HTTP protocol, in
+ an underlying transport layer.
+
+9.10. LOCK Method
+
+ The following sections describe the LOCK method, which is used to
+ take out a lock of any access type and to refresh an existing lock.
+ These sections on the LOCK method describe only those semantics that
+ are specific to the LOCK method and are independent of the access
+ type of the lock being requested.
+
+ Any resource that supports the LOCK method MUST, at minimum, support
+ the XML request and response formats defined herein.
+
+ This method is neither idempotent nor safe (see Section 9.1 of
+ [RFC2616]). Responses to this method MUST NOT be cached.
+
+9.10.1. Creating a Lock on an Existing Resource
+
+ A LOCK request to an existing resource will create a lock on the
+ resource identified by the Request-URI, provided the resource is not
+ already locked with a conflicting lock. The resource identified in
+ the Request-URI becomes the root of the lock. LOCK method requests
+ to create a new lock MUST have an XML request body. The server MUST
+ preserve the information provided by the client in the 'owner'
+ element in the LOCK request. The LOCK request MAY have a Timeout
+ header.
+
+ When a new lock is created, the LOCK response:
+
+ o MUST contain a body with the value of the DAV:lockdiscovery
+ property in a prop XML element. This MUST contain the full
+ information about the lock just granted, while information about
+ other (shared) locks is OPTIONAL.
+
+ o MUST include the Lock-Token response header with the token
+ associated with the new lock.
+
+
+
+
+Dusseault Standards Track [Page 61]
+
+RFC 4918 WebDAV June 2007
+
+
+9.10.2. Refreshing Locks
+
+ A lock is refreshed by sending a LOCK request to the URL of a
+ resource within the scope of the lock. This request MUST NOT have a
+ body and it MUST specify which lock to refresh by using the 'If'
+ header with a single lock token (only one lock may be refreshed at a
+ time). The request MAY contain a Timeout header, which a server MAY
+ accept to change the duration remaining on the lock to the new value.
+ A server MUST ignore the Depth header on a LOCK refresh.
+
+ If the resource has other (shared) locks, those locks are unaffected
+ by a lock refresh. Additionally, those locks do not prevent the
+ named lock from being refreshed.
+
+ The Lock-Token header is not returned in the response for a
+ successful refresh LOCK request, but the LOCK response body MUST
+ contain the new value for the DAV:lockdiscovery property.
+
+9.10.3. Depth and Locking
+
+ The Depth header may be used with the LOCK method. Values other than
+ 0 or infinity MUST NOT be used with the Depth header on a LOCK
+ method. All resources that support the LOCK method MUST support the
+ Depth header.
+
+ A Depth header of value 0 means to just lock the resource specified
+ by the Request-URI.
+
+ If the Depth header is set to infinity, then the resource specified
+ in the Request-URI along with all its members, all the way down the
+ hierarchy, are to be locked. A successful result MUST return a
+ single lock token. Similarly, if an UNLOCK is successfully executed
+ on this token, all associated resources are unlocked. Hence, partial
+ success is not an option for LOCK or UNLOCK. Either the entire
+ hierarchy is locked or no resources are locked.
+
+ If the lock cannot be granted to all resources, the server MUST
+ return a Multi-Status response with a 'response' element for at least
+ one resource that prevented the lock from being granted, along with a
+ suitable status code for that failure (e.g., 403 (Forbidden) or 423
+ (Locked)). Additionally, if the resource causing the failure was not
+ the resource requested, then the server SHOULD include a 'response'
+ element for the Request-URI as well, with a 'status' element
+ containing 424 Failed Dependency.
+
+ If no Depth header is submitted on a LOCK request, then the request
+ MUST act as if a "Depth:infinity" had been submitted.
+
+
+
+
+Dusseault Standards Track [Page 62]
+
+RFC 4918 WebDAV June 2007
+
+
+9.10.4. Locking Unmapped URLs
+
+ A successful LOCK method MUST result in the creation of an empty
+ resource that is locked (and that is not a collection) when a
+ resource did not previously exist at that URL. Later on, the lock
+ may go away but the empty resource remains. Empty resources MUST
+ then appear in PROPFIND responses including that URL in the response
+ scope. A server MUST respond successfully to a GET request to an
+ empty resource, either by using a 204 No Content response, or by
+ using 200 OK with a Content-Length header indicating zero length
+
+9.10.5. Lock Compatibility Table
+
+ The table below describes the behavior that occurs when a lock
+ request is made on a resource.
+
+ +--------------------------+----------------+-------------------+
+ | Current State | Shared Lock OK | Exclusive Lock OK |
+ +--------------------------+----------------+-------------------+
+ | None | True | True |
+ | Shared Lock | True | False |
+ | Exclusive Lock | False | False* |
+ +--------------------------+----------------+-------------------+
+
+ Legend: True = lock may be granted. False = lock MUST NOT be
+ granted. *=It is illegal for a principal to request the same lock
+ twice.
+
+ The current lock state of a resource is given in the leftmost column,
+ and lock requests are listed in the first row. The intersection of a
+ row and column gives the result of a lock request. For example, if a
+ shared lock is held on a resource, and an exclusive lock is
+ requested, the table entry is "false", indicating that the lock must
+ not be granted.
+
+9.10.6. LOCK Responses
+
+ In addition to the general status codes possible, the following
+ status codes have specific applicability to LOCK:
+
+ 200 (OK) - The LOCK request succeeded and the value of the DAV:
+ lockdiscovery property is included in the response body.
+
+ 201 (Created) - The LOCK request was to an unmapped URL, the request
+ succeeded and resulted in the creation of a new resource, and the
+ value of the DAV:lockdiscovery property is included in the response
+ body.
+
+
+
+
+Dusseault Standards Track [Page 63]
+
+RFC 4918 WebDAV June 2007
+
+
+ 409 (Conflict) - A resource cannot be created at the destination
+ until one or more intermediate collections have been created. The
+ server MUST NOT create those intermediate collections automatically.
+
+ 423 (Locked), potentially with 'no-conflicting-lock' precondition
+ code - There is already a lock on the resource that is not compatible
+ with the requested lock (see lock compatibility table above).
+
+ 412 (Precondition Failed), with 'lock-token-matches-request-uri'
+ precondition code - The LOCK request was made with an If header,
+ indicating that the client wishes to refresh the given lock.
+ However, the Request-URI did not fall within the scope of the lock
+ identified by the token. The lock may have a scope that does not
+ include the Request-URI, or the lock could have disappeared, or the
+ token may be invalid.
+
+9.10.7. Example - Simple Lock Request
+
+ >>Request
+
+ LOCK /workspace/webdav/proposal.doc HTTP/1.1
+ Host: example.com
+ Timeout: Infinite, Second-4100000000
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+ Authorization: Digest username="ejw",
+ realm="ejw at example.com", nonce="...",
+ uri="/workspace/webdav/proposal.doc",
+ response="...", opaque="..."
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:lockinfo xmlns:D='DAV:'>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ <D:owner>
+ <D:href>http://example.org/~ejw/contact.html</D:href>
+ </D:owner>
+ </D:lockinfo>
+
+ >>Response
+
+ HTTP/1.1 200 OK
+ Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:prop xmlns:D="DAV:">
+
+
+
+Dusseault Standards Track [Page 64]
+
+RFC 4918 WebDAV June 2007
+
+
+ <D:lockdiscovery>
+ <D:activelock>
+ <D:locktype><D:write/></D:locktype>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:depth>infinity</D:depth>
+ <D:owner>
+ <D:href>http://example.org/~ejw/contact.html</D:href>
+ </D:owner>
+ <D:timeout>Second-604800</D:timeout>
+ <D:locktoken>
+ <D:href
+ >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
+ </D:locktoken>
+ <D:lockroot>
+ <D:href
+ >http://example.com/workspace/webdav/proposal.doc</D:href>
+ </D:lockroot>
+ </D:activelock>
+ </D:lockdiscovery>
+ </D:prop>
+
+
+ This example shows the successful creation of an exclusive write lock
+ on resource http://example.com/workspace/webdav/proposal.doc. The
+ resource http://example.org/~ejw/contact.html contains contact
+ information for the creator of the lock. The server has an activity-
+ based timeout policy in place on this resource, which causes the lock
+ to automatically be removed after 1 week (604800 seconds). Note that
+ the nonce, response, and opaque fields have not been calculated in
+ the Authorization request header.
+
+9.10.8. Example - Refreshing a Write Lock
+
+ >>Request
+
+ LOCK /workspace/webdav/proposal.doc HTTP/1.1
+ Host: example.com
+ Timeout: Infinite, Second-4100000000
+ If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
+ Authorization: Digest username="ejw",
+ realm="ejw at example.com", nonce="...",
+ uri="/workspace/webdav/proposal.doc",
+ response="...", opaque="..."
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 65]
+
+RFC 4918 WebDAV June 2007
+
+
+ >>Response
+
+ HTTP/1.1 200 OK
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:prop xmlns:D="DAV:">
+ <D:lockdiscovery>
+ <D:activelock>
+ <D:locktype><D:write/></D:locktype>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:depth>infinity</D:depth>
+ <D:owner>
+ <D:href>http://example.org/~ejw/contact.html</D:href>
+ </D:owner>
+ <D:timeout>Second-604800</D:timeout>
+ <D:locktoken>
+ <D:href
+ >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
+ </D:locktoken>
+ <D:lockroot>
+ <D:href
+ >http://example.com/workspace/webdav/proposal.doc</D:href>
+ </D:lockroot>
+ </D:activelock>
+ </D:lockdiscovery>
+ </D:prop>
+
+
+ This request would refresh the lock, attempting to reset the timeout
+ to the new value specified in the timeout header. Notice that the
+ client asked for an infinite time out but the server choose to ignore
+ the request. In this example, the nonce, response, and opaque fields
+ have not been calculated in the Authorization request header.
+
+9.10.9. Example - Multi-Resource Lock Request
+
+ >>Request
+
+ LOCK /webdav/ HTTP/1.1
+ Host: example.com
+ Timeout: Infinite, Second-4100000000
+ Depth: infinity
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+ Authorization: Digest username="ejw",
+ realm="ejw at example.com", nonce="...",
+
+
+
+Dusseault Standards Track [Page 66]
+
+RFC 4918 WebDAV June 2007
+
+
+ uri="/workspace/webdav/proposal.doc",
+ response="...", opaque="..."
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:lockinfo xmlns:D="DAV:">
+ <D:locktype><D:write/></D:locktype>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:owner>
+ <D:href>http://example.org/~ejw/contact.html</D:href>
+ </D:owner>
+ </D:lockinfo>
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:">
+ <D:response>
+ <D:href>http://example.com/webdav/secret</D:href>
+ <D:status>HTTP/1.1 403 Forbidden</D:status>
+ </D:response>
+ <D:response>
+ <D:href>http://example.com/webdav/</D:href>
+ <D:status>HTTP/1.1 424 Failed Dependency</D:status>
+ </D:response>
+ </D:multistatus>
+
+
+ This example shows a request for an exclusive write lock on a
+ collection and all its children. In this request, the client has
+ specified that it desires an infinite-length lock, if available,
+ otherwise a timeout of 4.1 billion seconds, if available. The
+ request entity body contains the contact information for the
+ principal taking out the lock -- in this case, a Web page URL.
+
+ The error is a 403 (Forbidden) response on the resource
+ http://example.com/webdav/secret. Because this resource could not be
+ locked, none of the resources were locked. Note also that the a
+ 'response' element for the Request-URI itself has been included as
+ required.
+
+ In this example, the nonce, response, and opaque fields have not been
+ calculated in the Authorization request header.
+
+
+
+
+
+Dusseault Standards Track [Page 67]
+
+RFC 4918 WebDAV June 2007
+
+
+9.11. UNLOCK Method
+
+ The UNLOCK method removes the lock identified by the lock token in
+ the Lock-Token request header. The Request-URI MUST identify a
+ resource within the scope of the lock.
+
+ Note that use of the Lock-Token header to provide the lock token is
+ not consistent with other state-changing methods, which all require
+ an If header with the lock token. Thus, the If header is not needed
+ to provide the lock token. Naturally, when the If header is present,
+ it has its normal meaning as a conditional header.
+
+ For a successful response to this method, the server MUST delete the
+ lock entirely.
+
+ If all resources that have been locked under the submitted lock token
+ cannot be unlocked, then the UNLOCK request MUST fail.
+
+ A successful response to an UNLOCK method does not mean that the
+ resource is necessarily unlocked. It means that the specific lock
+ corresponding to the specified token no longer exists.
+
+ Any DAV-compliant resource that supports the LOCK method MUST support
+ the UNLOCK method.
+
+ This method is idempotent, but not safe (see Section 9.1 of
+ [RFC2616]). Responses to this method MUST NOT be cached.
+
+9.11.1. Status Codes
+
+ In addition to the general status codes possible, the following
+ status codes have specific applicability to UNLOCK:
+
+ 204 (No Content) - Normal success response (rather than 200 OK, since
+ 200 OK would imply a response body, and an UNLOCK success response
+ does not normally contain a body).
+
+ 400 (Bad Request) - No lock token was provided.
+
+ 403 (Forbidden) - The currently authenticated principal does not have
+ permission to remove the lock.
+
+ 409 (Conflict), with 'lock-token-matches-request-uri' precondition -
+ The resource was not locked, or the request was made to a Request-URI
+ that was not within the scope of the lock.
+
+
+
+
+
+
+Dusseault Standards Track [Page 68]
+
+RFC 4918 WebDAV June 2007
+
+
+9.11.2. Example - UNLOCK
+
+ >>Request
+
+ UNLOCK /workspace/webdav/info.doc HTTP/1.1
+ Host: example.com
+ Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
+ Authorization: Digest username="ejw"
+ realm="ejw at example.com", nonce="...",
+ uri="/workspace/webdav/proposal.doc",
+ response="...", opaque="..."
+
+ >>Response
+
+ HTTP/1.1 204 No Content
+
+ In this example, the lock identified by the lock token
+ "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully
+ removed from the resource
+ http://example.com/workspace/webdav/info.doc. If this lock included
+ more than just one resource, the lock is removed from all resources
+ included in the lock.
+
+ In this example, the nonce, response, and opaque fields have not been
+ calculated in the Authorization request header.
+
+10. HTTP Headers for Distributed Authoring
+
+ All DAV headers follow the same basic formatting rules as HTTP
+ headers. This includes rules like line continuation and how to
+ combine (or separate) multiple instances of the same header using
+ commas.
+
+ WebDAV adds two new conditional headers to the set defined in HTTP:
+ the If and Overwrite headers.
+
+10.1. DAV Header
+
+ DAV = "DAV" ":" #( compliance-class )
+ compliance-class = ( "1" | "2" | "3" | extend )
+ extend = Coded-URL | token
+ ; token is defined in RFC 2616, Section 2.2
+ Coded-URL = "<" absolute-URI ">"
+ ; No linear whitespace (LWS) allowed in Coded-URL
+ ; absolute-URI defined in RFC 3986, Section 4.3
+
+
+
+
+
+
+Dusseault Standards Track [Page 69]
+
+RFC 4918 WebDAV June 2007
+
+
+ This general-header appearing in the response indicates that the
+ resource supports the DAV schema and protocol as specified. All DAV-
+ compliant resources MUST return the DAV header with compliance-class
+ "1" on all OPTIONS responses. In cases where WebDAV is only
+ supported in part of the server namespace, an OPTIONS request to non-
+ WebDAV resources (including "/") SHOULD NOT advertise WebDAV support.
+
+ The value is a comma-separated list of all compliance class
+ identifiers that the resource supports. Class identifiers may be
+ Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can
+ appear in any order. Identifiers that are standardized through the
+ IETF RFC process are tokens, but other identifiers SHOULD be Coded-
+ URLs to encourage uniqueness.
+
+ A resource must show class 1 compliance if it shows class 2 or 3
+ compliance. In general, support for one compliance class does not
+ entail support for any other, and in particular, support for
+ compliance class 3 does not require support for compliance class 2.
+ Please refer to Section 18 for more details on compliance classes
+ defined in this specification.
+
+ Note that many WebDAV servers do not advertise WebDAV support in
+ response to "OPTIONS *".
+
+ As a request header, this header allows the client to advertise
+ compliance with named features when the server needs that
+ information. Clients SHOULD NOT send this header unless a standards
+ track specification requires it. Any extension that makes use of
+ this as a request header will need to carefully consider caching
+ implications.
+
+10.2. Depth Header
+
+ Depth = "Depth" ":" ("0" | "1" | "infinity")
+
+ The Depth request header is used with methods executed on resources
+ that could potentially have internal members to indicate whether the
+ method is to be applied only to the resource ("Depth: 0"), to the
+ resource and its internal members only ("Depth: 1"), or the resource
+ and all its members ("Depth: infinity").
+
+ The Depth header is only supported if a method's definition
+ explicitly provides for such support.
+
+ The following rules are the default behavior for any method that
+ supports the Depth header. A method may override these defaults by
+ defining different behavior in its definition.
+
+
+
+
+Dusseault Standards Track [Page 70]
+
+RFC 4918 WebDAV June 2007
+
+
+ Methods that support the Depth header may choose not to support all
+ of the header's values and may define, on a case-by-case basis, the
+ behavior of the method if a Depth header is not present. For
+ example, the MOVE method only supports "Depth: infinity", and if a
+ Depth header is not present, it will act as if a "Depth: infinity"
+ header had been applied.
+
+ Clients MUST NOT rely upon methods executing on members of their
+ hierarchies in any particular order or on the execution being atomic
+ unless the particular method explicitly provides such guarantees.
+
+ Upon execution, a method with a Depth header will perform as much of
+ its assigned task as possible and then return a response specifying
+ what it was able to accomplish and what it failed to do.
+
+ So, for example, an attempt to COPY a hierarchy may result in some of
+ the members being copied and some not.
+
+ By default, the Depth header does not interact with other headers.
+ That is, each header on a request with a Depth header MUST be applied
+ only to the Request-URI if it applies to any resource, unless
+ specific Depth behavior is defined for that header.
+
+ If a source or destination resource within the scope of the Depth
+ header is locked in such a way as to prevent the successful execution
+ of the method, then the lock token for that resource MUST be
+ submitted with the request in the If request header.
+
+ The Depth header only specifies the behavior of the method with
+ regards to internal members. If a resource does not have internal
+ members, then the Depth header MUST be ignored.
+
+10.3. Destination Header
+
+ The Destination request header specifies the URI that identifies a
+ destination resource for methods such as COPY and MOVE, which take
+ two URIs as parameters.
+
+ Destination = "Destination" ":" Simple-ref
+
+
+ If the Destination value is an absolute-URI (Section 4.3 of
+ [RFC3986]), it may name a different server (or different port or
+ scheme). If the source server cannot attempt a copy to the remote
+ server, it MUST fail the request. Note that copying and moving
+ resources to remote servers is not fully defined in this
+ specification (e.g., specific error conditions).
+
+
+
+
+Dusseault Standards Track [Page 71]
+
+RFC 4918 WebDAV June 2007
+
+
+ If the Destination value is too long or otherwise unacceptable, the
+ server SHOULD return 400 (Bad Request), ideally with helpful
+ information in an error body.
+
+10.4. If Header
+
+ The If request header is intended to have similar functionality to
+ the If-Match header defined in Section 14.24 of [RFC2616]. However,
+ the If header handles any state token as well as ETags. A typical
+ example of a state token is a lock token, and lock tokens are the
+ only state tokens defined in this specification.
+
+10.4.1. Purpose
+
+ The If header has two distinct purposes:
+
+ o The first purpose is to make a request conditional by supplying a
+ series of state lists with conditions that match tokens and ETags
+ to a specific resource. If this header is evaluated and all state
+ lists fail, then the request MUST fail with a 412 (Precondition
+ Failed) status. On the other hand, the request can succeed only
+ if one of the described state lists succeeds. The success
+ criteria for state lists and matching functions are defined in
+ Sections 10.4.3 and 10.4.4.
+
+ o Additionally, the mere fact that a state token appears in an If
+ header means that it has been "submitted" with the request. In
+ general, this is used to indicate that the client has knowledge of
+ that state token. The semantics for submitting a state token
+ depend on its type (for lock tokens, please refer to Section 6).
+
+ Note that these two purposes need to be treated distinctly: a state
+ token counts as being submitted independently of whether the server
+ actually has evaluated the state list it appears in, and also
+ independently of whether or not the condition it expressed was found
+ to be true.
+
+10.4.2. Syntax
+
+ If = "If" ":" ( 1*No-tag-list | 1*Tagged-list )
+
+ No-tag-list = List
+ Tagged-list = Resource-Tag 1*List
+
+ List = "(" 1*Condition ")"
+ Condition = ["Not"] (State-token | "[" entity-tag "]")
+ ; entity-tag: see Section 3.11 of [RFC2616]
+ ; No LWS allowed between "[", entity-tag and "]"
+
+
+
+Dusseault Standards Track [Page 72]
+
+RFC 4918 WebDAV June 2007
+
+
+ State-token = Coded-URL
+
+ Resource-Tag = "<" Simple-ref ">"
+ ; Simple-ref: see Section 8.3
+ ; No LWS allowed in Resource-Tag
+
+ The syntax distinguishes between untagged lists ("No-tag-list") and
+ tagged lists ("Tagged-list"). Untagged lists apply to the resource
+ identified by the Request-URI, while tagged lists apply to the
+ resource identified by the preceding Resource-Tag.
+
+ A Resource-Tag applies to all subsequent Lists, up to the next
+ Resource-Tag.
+
+ Note that the two list types cannot be mixed within an If header.
+ This is not a functional restriction because the No-tag-list syntax
+ is just a shorthand notation for a Tagged-list production with a
+ Resource-Tag referring to the Request-URI.
+
+ Each List consists of one or more Conditions. Each Condition is
+ defined in terms of an entity-tag or state-token, potentially negated
+ by the prefix "Not".
+
+ Note that the If header syntax does not allow multiple instances of
+ If headers in a single request. However, the HTTP header syntax
+ allows extending single header values across multiple lines, by
+ inserting a line break followed by whitespace (see [RFC2616], Section
+ 4.2).
+
+10.4.3. List Evaluation
+
+ A Condition that consists of a single entity-tag or state-token
+ evaluates to true if the resource matches the described state (where
+ the individual matching functions are defined below in
+ Section 10.4.4). Prefixing it with "Not" reverses the result of the
+ evaluation (thus, the "Not" applies only to the subsequent entity-tag
+ or state-token).
+
+ Each List production describes a series of conditions. The whole
+ list evaluates to true if and only if each condition evaluates to
+ true (that is, the list represents a logical conjunction of
+ Conditions).
+
+ Each No-tag-list and Tagged-list production may contain one or more
+ Lists. They evaluate to true if and only if any of the contained
+ lists evaluates to true (that is, if there's more than one List, that
+ List sequence represents a logical disjunction of the Lists).
+
+
+
+
+Dusseault Standards Track [Page 73]
+
+RFC 4918 WebDAV June 2007
+
+
+ Finally, the whole If header evaluates to true if and only if at
+ least one of the No-tag-list or Tagged-list productions evaluates to
+ true. If the header evaluates to false, the server MUST reject the
+ request with a 412 (Precondition Failed) status. Otherwise,
+ execution of the request can proceed as if the header wasn't present.
+
+10.4.4. Matching State Tokens and ETags
+
+ When performing If header processing, the definition of a matching
+ state token or entity tag is as follows:
+
+ Identifying a resource: The resource is identified by the URI along
+ with the token, in tagged list production, or by the Request-URI in
+ untagged list production.
+
+ Matching entity tag: Where the entity tag matches an entity tag
+ associated with the identified resource. Servers MUST use either the
+ weak or the strong comparison function defined in Section 13.3.3 of
+ [RFC2616].
+
+ Matching state token: Where there is an exact match between the state
+ token in the If header and any state token on the identified
+ resource. A lock state token is considered to match if the resource
+ is anywhere in the scope of the lock.
+
+ Handling unmapped URLs: For both ETags and state tokens, treat as if
+ the URL identified a resource that exists but does not have the
+ specified state.
+
+10.4.5. If Header and Non-DAV-Aware Proxies
+
+ Non-DAV-aware proxies will not honor the If header, since they will
+ not understand the If header, and HTTP requires non-understood
+ headers to be ignored. When communicating with HTTP/1.1 proxies, the
+ client MUST use the "Cache-Control: no-cache" request header so as to
+ prevent the proxy from improperly trying to service the request from
+ its cache. When dealing with HTTP/1.0 proxies, the "Pragma: no-
+ cache" request header MUST be used for the same reason.
+
+ Because in general clients may not be able to reliably detect non-
+ DAV-aware intermediates, they are advised to always prevent caching
+ using the request directives mentioned above.
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 74]
+
+RFC 4918 WebDAV June 2007
+
+
+10.4.6. Example - No-tag Production
+
+ If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
+ ["I am an ETag"])
+ (["I am another ETag"])
+
+ The previous header would require that the resource identified in the
+ Request-URI be locked with the specified lock token and be in the
+ state identified by the "I am an ETag" ETag or in the state
+ identified by the second ETag "I am another ETag".
+
+ To put the matter more plainly one can think of the previous If
+ header as expressing the condition below:
+
+ (
+ is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND
+ matches-etag("I am an ETag")
+ )
+ OR
+ (
+ matches-etag("I am another ETag")
+ )
+
+10.4.7. Example - Using "Not" with No-tag Production
+
+ If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
+ <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
+
+ This If header requires that the resource must not be locked with a
+ lock having the lock token
+ urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a
+ lock with the lock token
+ urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
+
+10.4.8. Example - Causing a Condition to Always Evaluate to True
+
+ There may be cases where a client wishes to submit state tokens, but
+ doesn't want the request to fail just because the state token isn't
+ current anymore. One simple way to do this is to include a Condition
+ that is known to always evaluate to true, such as in:
+
+ If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
+ (Not <DAV:no-lock>)
+
+ "DAV:no-lock" is known to never represent a current lock token. Lock
+ tokens are assigned by the server, following the uniqueness
+ requirements described in Section 6.5, therefore cannot use the
+ "DAV:" scheme. Thus, by applying "Not" to a state token that is
+
+
+
+Dusseault Standards Track [Page 75]
+
+RFC 4918 WebDAV June 2007
+
+
+ known not to be current, the Condition always evaluates to true.
+ Consequently, the whole If header will always evaluate to true, and
+ the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 will be
+ submitted in any case.
+
+10.4.9. Example - Tagged List If Header in COPY
+
+ >>Request
+
+ COPY /resource1 HTTP/1.1
+ Host: www.example.com
+ Destination: /resource2
+ If: </resource1>
+ (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
+ [W/"A weak ETag"]) (["strong ETag"])
+
+ In this example, http://www.example.com/resource1 is being copied to
+ http://www.example.com/resource2. When the method is first applied
+ to http://www.example.com/resource1, resource1 must be in the state
+ specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A
+ weak ETag"]) (["strong ETag"])". That is, either it must be locked
+ with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2"
+ and have a weak entity tag W/"A weak ETag" or it must have a strong
+ entity tag "strong ETag".
+
+10.4.10. Example - Matching Lock Tokens with Collection Locks
+
+ DELETE /specs/rfc2518.txt HTTP/1.1
+ Host: www.example.com
+ If: <http://www.example.com/specs/>
+ (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
+
+ For this example, the lock token must be compared to the identified
+ resource, which is the 'specs' collection identified by the URL in
+ the tagged list production. If the 'specs' collection is not locked
+ by a lock with the specified lock token, the request MUST fail.
+ Otherwise, this request could succeed, because the If header
+ evaluates to true, and because the lock token for the lock affecting
+ the affected resource has been submitted.
+
+10.4.11. Example - Matching ETags on Unmapped URLs
+
+ Consider a collection "/specs" that does not contain the member
+ "/specs/rfc2518.doc". In this case, the If header
+
+ If: </specs/rfc2518.doc> (["4217"])
+
+
+
+
+
+Dusseault Standards Track [Page 76]
+
+RFC 4918 WebDAV June 2007
+
+
+ will evaluate to false (the URI isn't mapped, thus the resource
+ identified by the URI doesn't have an entity matching the ETag
+ "4217").
+
+ On the other hand, an If header of
+
+ If: </specs/rfc2518.doc> (Not ["4217"])
+
+ will consequently evaluate to true.
+
+ Note that, as defined above in Section 10.4.4, the same
+ considerations apply to matching state tokens.
+
+10.5. Lock-Token Header
+
+ Lock-Token = "Lock-Token" ":" Coded-URL
+
+ The Lock-Token request header is used with the UNLOCK method to
+ identify the lock to be removed. The lock token in the Lock-Token
+ request header MUST identify a lock that contains the resource
+ identified by Request-URI as a member.
+
+ The Lock-Token response header is used with the LOCK method to
+ indicate the lock token created as a result of a successful LOCK
+ request to create a new lock.
+
+10.6. Overwrite Header
+
+ Overwrite = "Overwrite" ":" ("T" | "F")
+
+ The Overwrite request header specifies whether the server should
+ overwrite a resource mapped to the destination URL during a COPY or
+ MOVE. A value of "F" states that the server must not perform the
+ COPY or MOVE operation if the destination URL does map to a resource.
+ If the overwrite header is not included in a COPY or MOVE request,
+ then the resource MUST treat the request as if it has an overwrite
+ header of value "T". While the Overwrite header appears to duplicate
+ the functionality of using an "If-Match: *" header (see [RFC2616]),
+ If-Match applies only to the Request-URI, and not to the Destination
+ of a COPY or MOVE.
+
+ If a COPY or MOVE is not performed due to the value of the Overwrite
+ header, the method MUST fail with a 412 (Precondition Failed) status
+ code. The server MUST do authorization checks before checking this
+ or any conditional header.
+
+ All DAV-compliant resources MUST support the Overwrite header.
+
+
+
+
+Dusseault Standards Track [Page 77]
+
+RFC 4918 WebDAV June 2007
+
+
+10.7. Timeout Request Header
+
+ TimeOut = "Timeout" ":" 1#TimeType
+ TimeType = ("Second-" DAVTimeOutVal | "Infinite")
+ ; No LWS allowed within TimeType
+ DAVTimeOutVal = 1*DIGIT
+
+ Clients MAY include Timeout request headers in their LOCK requests.
+ However, the server is not required to honor or even consider these
+ requests. Clients MUST NOT submit a Timeout request header with any
+ method other than a LOCK method.
+
+ The "Second" TimeType specifies the number of seconds that will
+ elapse between granting of the lock at the server, and the automatic
+ removal of the lock. The timeout value for TimeType "Second" MUST
+ NOT be greater than 2^32-1.
+
+ See Section 6.6 for a description of lock timeout behavior.
+
+11. Status Code Extensions to HTTP/1.1
+
+ The following status codes are added to those defined in HTTP/1.1
+ [RFC2616].
+
+11.1. 207 Multi-Status
+
+ The 207 (Multi-Status) status code provides status for multiple
+ independent operations (see Section 13 for more information).
+
+11.2. 422 Unprocessable Entity
+
+ The 422 (Unprocessable Entity) status code means the server
+ understands the content type of the request entity (hence a
+ 415(Unsupported Media Type) status code is inappropriate), and the
+ syntax of the request entity is correct (thus a 400 (Bad Request)
+ status code is inappropriate) but was unable to process the contained
+ instructions. For example, this error condition may occur if an XML
+ request body contains well-formed (i.e., syntactically correct), but
+ semantically erroneous, XML instructions.
+
+11.3. 423 Locked
+
+ The 423 (Locked) status code means the source or destination resource
+ of a method is locked. This response SHOULD contain an appropriate
+ precondition or postcondition code, such as 'lock-token-submitted' or
+ 'no-conflicting-lock'.
+
+
+
+
+
+Dusseault Standards Track [Page 78]
+
+RFC 4918 WebDAV June 2007
+
+
+11.4. 424 Failed Dependency
+
+ The 424 (Failed Dependency) status code means that the method could
+ not be performed on the resource because the requested action
+ depended on another action and that action failed. For example, if a
+ command in a PROPPATCH method fails, then, at minimum, the rest of
+ the commands will also fail with 424 (Failed Dependency).
+
+11.5. 507 Insufficient Storage
+
+ The 507 (Insufficient Storage) status code means the method could not
+ be performed on the resource because the server is unable to store
+ the representation needed to successfully complete the request. This
+ condition is considered to be temporary. If the request that
+ received this status code was the result of a user action, the
+ request MUST NOT be repeated until it is requested by a separate user
+ action.
+
+12. Use of HTTP Status Codes
+
+ These HTTP codes are not redefined, but their use is somewhat
+ extended by WebDAV methods and requirements. In general, many HTTP
+ status codes can be used in response to any request, not just in
+ cases described in this document. Note also that WebDAV servers are
+ known to use 300-level redirect responses (and early interoperability
+ tests found clients unprepared to see those responses). A 300-level
+ response MUST NOT be used when the server has created a new resource
+ in response to the request.
+
+12.1. 412 Precondition Failed
+
+ Any request can contain a conditional header defined in HTTP (If-
+ Match, If-Modified-Since, etc.) or the "If" or "Overwrite"
+ conditional headers defined in this specification. If the server
+ evaluates a conditional header, and if that condition fails to hold,
+ then this error code MUST be returned. On the other hand, if the
+ client did not include a conditional header in the request, then the
+ server MUST NOT use this status code.
+
+12.2. 414 Request-URI Too Long
+
+ This status code is used in HTTP 1.1 only for Request-URIs, not URIs
+ in other locations.
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 79]
+
+RFC 4918 WebDAV June 2007
+
+
+13. Multi-Status Response
+
+ A Multi-Status response conveys information about multiple resources
+ in situations where multiple status codes might be appropriate. The
+ default Multi-Status response body is a text/xml or application/xml
+ HTTP entity with a 'multistatus' root element. Further elements
+ contain 200, 300, 400, and 500 series status codes generated during
+ the method invocation. 100 series status codes SHOULD NOT be recorded
+ in a 'response' XML element.
+
+ Although '207' is used as the overall response status code, the
+ recipient needs to consult the contents of the multistatus response
+ body for further information about the success or failure of the
+ method execution. The response MAY be used in success, partial
+ success and also in failure situations.
+
+ The 'multistatus' root element holds zero or more 'response' elements
+ in any order, each with information about an individual resource.
+ Each 'response' element MUST have an 'href' element to identify the
+ resource.
+
+ A Multi-Status response uses one out of two distinct formats for
+ representing the status:
+
+ 1. A 'status' element as child of the 'response' element indicates
+ the status of the message execution for the identified resource
+ as a whole (for instance, see Section 9.6.2). Some method
+ definitions provide information about specific status codes
+ clients should be prepared to see in a response. However,
+ clients MUST be able to handle other status codes, using the
+ generic rules defined in Section 10 of [RFC2616].
+
+ 2. For PROPFIND and PROPPATCH, the format has been extended using
+ the 'propstat' element instead of 'status', providing information
+ about individual properties of a resource. This format is
+ specific to PROPFIND and PROPPATCH, and is described in detail in
+ Sections 9.1 and 9.2.
+
+13.1. Response Headers
+
+ HTTP defines the Location header to indicate a preferred URL for the
+ resource that was addressed in the Request-URI (e.g., in response to
+ successful PUT requests or in redirect responses). However, use of
+ this header creates ambiguity when there are URLs in the body of the
+ response, as with Multi-Status. Thus, use of the Location header
+ with the Multi-Status response is intentionally undefined.
+
+
+
+
+
+Dusseault Standards Track [Page 80]
+
+RFC 4918 WebDAV June 2007
+
+
+13.2. Handling Redirected Child Resources
+
+ Redirect responses (300-303, 305, and 307) defined in HTTP 1.1
+ normally take a Location header to indicate the new URI for the
+ single resource redirected from the Request-URI. Multi-Status
+ responses contain many resource addresses, but the original
+ definition in [RFC2518] did not have any place for the server to
+ provide the new URI for redirected resources. This specification
+ does define a 'location' element for this information (see
+ Section 14.9). Servers MUST use this new element with redirect
+ responses in Multi-Status.
+
+ Clients encountering redirected resources in Multi-Status MUST NOT
+ rely on the 'location' element being present with a new URI. If the
+ element is not present, the client MAY reissue the request to the
+ individual redirected resource, because the response to that request
+ can be redirected with a Location header containing the new URI.
+
+13.3. Internal Status Codes
+
+ Sections 9.2.1, 9.1.2, 9.6.1, 9.8.3, and 9.9.2 define various status
+ codes used in Multi-Status responses. This specification does not
+ define the meaning of other status codes that could appear in these
+ responses.
+
+14. XML Element Definitions
+
+ In this section, the final line of each section gives the element
+ type declaration using the format defined in [REC-XML]. The "Value"
+ field, where present, specifies further restrictions on the allowable
+ contents of the XML element using BNF (i.e., to further restrict the
+ values of a PCDATA element). Note that all of the elements defined
+ here may be extended according to the rules defined in Section 17.
+ All elements defined here are in the "DAV:" namespace.
+
+14.1. activelock XML Element
+
+ Name: activelock
+
+ Purpose: Describes a lock on a resource.
+
+
+ <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
+ locktoken?, lockroot)>
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 81]
+
+RFC 4918 WebDAV June 2007
+
+
+14.2. allprop XML Element
+
+ Name: allprop
+
+ Purpose: Specifies that all names and values of dead properties and
+ the live properties defined by this document existing on the
+ resource are to be returned.
+
+ <!ELEMENT allprop EMPTY >
+
+14.3. collection XML Element
+
+ Name: collection
+
+ Purpose: Identifies the associated resource as a collection. The
+ DAV:resourcetype property of a collection resource MUST contain
+ this element. It is normally empty but extensions may add sub-
+ elements.
+
+ <!ELEMENT collection EMPTY >
+
+14.4. depth XML Element
+
+ Name: depth
+
+ Purpose: Used for representing depth values in XML content (e.g.,
+ in lock information).
+
+ Value: "0" | "1" | "infinity"
+
+ <!ELEMENT depth (#PCDATA) >
+
+14.5. error XML Element
+
+ Name: error
+
+ Purpose: Error responses, particularly 403 Forbidden and 409
+ Conflict, sometimes need more information to indicate what went
+ wrong. In these cases, servers MAY return an XML response body
+ with a document element of 'error', containing child elements
+ identifying particular condition codes.
+
+ Description: Contains at least one XML element, and MUST NOT
+ contain text or mixed content. Any element that is a child of the
+ 'error' element is considered to be a precondition or
+ postcondition code. Unrecognized elements MUST be ignored.
+
+ <!ELEMENT error ANY >
+
+
+
+Dusseault Standards Track [Page 82]
+
+RFC 4918 WebDAV June 2007
+
+
+14.6. exclusive XML Element
+
+ Name: exclusive
+
+ Purpose: Specifies an exclusive lock.
+
+
+ <!ELEMENT exclusive EMPTY >
+
+
+14.7. href XML Element
+
+ Name: href
+
+ Purpose: MUST contain a URI or a relative reference.
+
+ Description: There may be limits on the value of 'href' depending
+ on the context of its use. Refer to the specification text where
+ 'href' is used to see what limitations apply in each case.
+
+ Value: Simple-ref
+
+
+ <!ELEMENT href (#PCDATA)>
+
+14.8. include XML Element
+
+ Name: include
+
+ Purpose: Any child element represents the name of a property to be
+ included in the PROPFIND response. All elements inside an
+ 'include' XML element MUST define properties related to the
+ resource, although possible property names are in no way limited
+ to those property names defined in this document or other
+ standards. This element MUST NOT contain text or mixed content.
+
+ <!ELEMENT include ANY >
+
+14.9. location XML Element
+
+ Name: location
+
+ Purpose: HTTP defines the "Location" header (see [RFC2616], Section
+ 14.30) for use with some status codes (such as 201 and the 300
+ series codes). When these codes are used inside a 'multistatus'
+ element, the 'location' element can be used to provide the
+ accompanying Location header value.
+
+
+
+
+Dusseault Standards Track [Page 83]
+
+RFC 4918 WebDAV June 2007
+
+
+ Description: Contains a single href element with the same value
+ that would be used in a Location header.
+
+
+ <!ELEMENT location (href)>
+
+14.10. lockentry XML Element
+
+ Name: lockentry
+
+ Purpose: Defines the types of locks that can be used with the
+ resource.
+
+ <!ELEMENT lockentry (lockscope, locktype) >
+
+14.11. lockinfo XML Element
+
+ Name: lockinfo
+
+ Purpose: The 'lockinfo' XML element is used with a LOCK method to
+ specify the type of lock the client wishes to have created.
+
+
+ <!ELEMENT lockinfo (lockscope, locktype, owner?) >
+
+14.12. lockroot XML Element
+
+ Name: lockroot
+
+ Purpose: Contains the root URL of the lock, which is the URL
+ through which the resource was addressed in the LOCK request.
+
+ Description: The href element contains the root of the lock. The
+ server SHOULD include this in all DAV:lockdiscovery property
+ values and the response to LOCK requests.
+
+ <!ELEMENT lockroot (href) >
+
+14.13. lockscope XML Element
+
+ Name: lockscope
+
+ Purpose: Specifies whether a lock is an exclusive lock, or a shared
+ lock.
+
+
+ <!ELEMENT lockscope (exclusive | shared) >
+
+
+
+
+Dusseault Standards Track [Page 84]
+
+RFC 4918 WebDAV June 2007
+
+
+14.14. locktoken XML Element
+
+ Name: locktoken
+
+ Purpose: The lock token associated with a lock.
+
+ Description: The href contains a single lock token URI, which
+ refers to the lock.
+
+ <!ELEMENT locktoken (href) >
+
+14.15. locktype XML Element
+
+ Name: locktype
+
+ Purpose: Specifies the access type of a lock. At present, this
+ specification only defines one lock type, the write lock.
+
+
+ <!ELEMENT locktype (write) >
+
+
+14.16. multistatus XML Element
+
+ Name: multistatus
+
+ Purpose: Contains multiple response messages.
+
+ Description: The 'responsedescription' element at the top level is
+ used to provide a general message describing the overarching
+ nature of the response. If this value is available, an
+ application may use it instead of presenting the individual
+ response descriptions contained within the responses.
+
+
+ <!ELEMENT multistatus (response*, responsedescription?) >
+
+
+14.17. owner XML Element
+
+ Name: owner
+
+ Purpose: Holds client-supplied information about the creator of a
+ lock.
+
+ Description: Allows a client to provide information sufficient for
+ either directly contacting a principal (such as a telephone number
+ or Email URI), or for discovering the principal (such as the URL
+
+
+
+Dusseault Standards Track [Page 85]
+
+RFC 4918 WebDAV June 2007
+
+
+ of a homepage) who created a lock. The value provided MUST be
+ treated as a dead property in terms of XML Information Item
+ preservation. The server MUST NOT alter the value unless the
+ owner value provided by the client is empty. For a certain amount
+ of interoperability between different client implementations, if
+ clients have URI-formatted contact information for the lock
+ creator suitable for user display, then clients SHOULD put those
+ URIs in 'href' child elements of the 'owner' element.
+
+ Extensibility: MAY be extended with child elements, mixed content,
+ text content or attributes.
+
+ <!ELEMENT owner ANY >
+
+14.18. prop XML Element
+
+ Name: prop
+
+ Purpose: Contains properties related to a resource.
+
+ Description: A generic container for properties defined on
+ resources. All elements inside a 'prop' XML element MUST define
+ properties related to the resource, although possible property
+ names are in no way limited to those property names defined in
+ this document or other standards. This element MUST NOT contain
+ text or mixed content.
+
+ <!ELEMENT prop ANY >
+
+14.19. propertyupdate XML Element
+
+ Name: propertyupdate
+
+ Purpose: Contains a request to alter the properties on a resource.
+
+ Description: This XML element is a container for the information
+ required to modify the properties on the resource.
+
+ <!ELEMENT propertyupdate (remove | set)+ >
+
+14.20. propfind XML Element
+
+ Name: propfind
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 86]
+
+RFC 4918 WebDAV June 2007
+
+
+ Purpose: Specifies the properties to be returned from a PROPFIND
+ method. Four special elements are specified for use with
+ 'propfind': 'prop', 'allprop', 'include', and 'propname'. If
+ 'prop' is used inside 'propfind', it MUST NOT contain property
+ values.
+
+ <!ELEMENT propfind ( propname | (allprop, include?) | prop ) >
+
+14.21. propname XML Element
+
+ Name: propname
+
+ Purpose: Specifies that only a list of property names on the
+ resource is to be returned.
+
+ <!ELEMENT propname EMPTY >
+
+14.22. propstat XML Element
+
+ Name: propstat
+
+ Purpose: Groups together a prop and status element that is
+ associated with a particular 'href' element.
+
+ Description: The propstat XML element MUST contain one prop XML
+ element and one status XML element. The contents of the prop XML
+ element MUST only list the names of properties to which the result
+ in the status element applies. The optional precondition/
+ postcondition element and 'responsedescription' text also apply to
+ the properties named in 'prop'.
+
+ <!ELEMENT propstat (prop, status, error?, responsedescription?) >
+
+14.23. remove XML Element
+
+ Name: remove
+
+ Purpose: Lists the properties to be removed from a resource.
+
+ Description: Remove instructs that the properties specified in prop
+ should be removed. Specifying the removal of a property that does
+ not exist is not an error. All the XML elements in a 'prop' XML
+ element inside of a 'remove' XML element MUST be empty, as only
+ the names of properties to be removed are required.
+
+ <!ELEMENT remove (prop) >
+
+
+
+
+
+Dusseault Standards Track [Page 87]
+
+RFC 4918 WebDAV June 2007
+
+
+14.24. response XML Element
+
+ Name: response
+
+ Purpose: Holds a single response describing the effect of a method
+ on resource and/or its properties.
+
+ Description: The 'href' element contains an HTTP URL pointing to a
+ WebDAV resource when used in the 'response' container. A
+ particular 'href' value MUST NOT appear more than once as the
+ child of a 'response' XML element under a 'multistatus' XML
+ element. This requirement is necessary in order to keep
+ processing costs for a response to linear time. Essentially, this
+ prevents having to search in order to group together all the
+ responses by 'href'. There are, however, no requirements
+ regarding ordering based on 'href' values. The optional
+ precondition/postcondition element and 'responsedescription' text
+ can provide additional information about this resource relative to
+ the request or result.
+
+
+ <!ELEMENT response (href, ((href*, status)|(propstat+)),
+ error?, responsedescription? , location?) >
+
+14.25. responsedescription XML Element
+
+ Name: responsedescription
+
+ Purpose: Contains information about a status response within a
+ Multi-Status.
+
+ Description: Provides information suitable to be presented to a
+ user.
+
+ <!ELEMENT responsedescription (#PCDATA) >
+
+14.26. set XML Element
+
+ Name: set
+
+ Purpose: Lists the property values to be set for a resource.
+
+ Description: The 'set' element MUST contain only a 'prop' element.
+ The elements contained by the 'prop' element inside the 'set'
+ element MUST specify the name and value of properties that are set
+ on the resource identified by Request-URI. If a property already
+ exists, then its value is replaced. Language tagging information
+ appearing in the scope of the 'prop' element (in the "xml:lang"
+
+
+
+Dusseault Standards Track [Page 88]
+
+RFC 4918 WebDAV June 2007
+
+
+ attribute, if present) MUST be persistently stored along with the
+ property, and MUST be subsequently retrievable using PROPFIND.
+
+ <!ELEMENT set (prop) >
+
+14.27. shared XML Element
+
+ Name: shared
+
+ Purpose: Specifies a shared lock.
+
+
+ <!ELEMENT shared EMPTY >
+
+
+14.28. status XML Element
+
+ Name: status
+
+ Purpose: Holds a single HTTP status-line.
+
+ Value: status-line (defined in Section 6.1 of [RFC2616])
+
+ <!ELEMENT status (#PCDATA) >
+
+14.29. timeout XML Element
+
+ Name: timeout
+
+ Purpose: The number of seconds remaining before a lock expires.
+
+ Value: TimeType (defined in Section 10.7)
+
+
+ <!ELEMENT timeout (#PCDATA) >
+
+14.30. write XML Element
+
+ Name: write
+
+ Purpose: Specifies a write lock.
+
+
+ <!ELEMENT write EMPTY >
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 89]
+
+RFC 4918 WebDAV June 2007
+
+
+15. DAV Properties
+
+ For DAV properties, the name of the property is also the same as the
+ name of the XML element that contains its value. In the section
+ below, the final line of each section gives the element type
+ declaration using the format defined in [REC-XML]. The "Value"
+ field, where present, specifies further restrictions on the allowable
+ contents of the XML element using BNF (i.e., to further restrict the
+ values of a PCDATA element).
+
+ A protected property is one that cannot be changed with a PROPPATCH
+ request. There may be other requests that would result in a change
+ to a protected property (as when a LOCK request affects the value of
+ DAV:lockdiscovery). Note that a given property could be protected on
+ one type of resource, but not protected on another type of resource.
+
+ A computed property is one with a value defined in terms of a
+ computation (based on the content and other properties of that
+ resource, or even of some other resource). A computed property is
+ always a protected property.
+
+ COPY and MOVE behavior refers to local COPY and MOVE operations.
+
+ For properties defined based on HTTP GET response headers (DAV:get*),
+ the header value could include LWS as defined in [RFC2616], Section
+ 4.2. Server implementors SHOULD strip LWS from these values before
+ using as WebDAV property values.
+
+15.1. creationdate Property
+
+ Name: creationdate
+
+ Purpose: Records the time and date the resource was created.
+
+ Value: date-time (defined in [RFC3339], see the ABNF in Section
+ 5.6.)
+
+ Protected: MAY be protected. Some servers allow DAV:creationdate
+ to be changed to reflect the time the document was created if that
+ is more meaningful to the user (rather than the time it was
+ uploaded). Thus, clients SHOULD NOT use this property in
+ synchronization logic (use DAV:getetag instead).
+
+ COPY/MOVE behavior: This property value SHOULD be kept during a
+ MOVE operation, but is normally re-initialized when a resource is
+ created with a COPY. It should not be set in a COPY.
+
+
+
+
+
+Dusseault Standards Track [Page 90]
+
+RFC 4918 WebDAV June 2007
+
+
+ Description: The DAV:creationdate property SHOULD be defined on all
+ DAV compliant resources. If present, it contains a timestamp of
+ the moment when the resource was created. Servers that are
+ incapable of persistently recording the creation date SHOULD
+ instead leave it undefined (i.e. report "Not Found").
+
+ <!ELEMENT creationdate (#PCDATA) >
+
+15.2. displayname Property
+
+ Name: displayname
+
+ Purpose: Provides a name for the resource that is suitable for
+ presentation to a user.
+
+ Value: Any text.
+
+ Protected: SHOULD NOT be protected. Note that servers implementing
+ [RFC2518] might have made this a protected property as this is a
+ new requirement.
+
+ COPY/MOVE behavior: This property value SHOULD be preserved in COPY
+ and MOVE operations.
+
+ Description: Contains a description of the resource that is
+ suitable for presentation to a user. This property is defined on
+ the resource, and hence SHOULD have the same value independent of
+ the Request-URI used to retrieve it (thus, computing this property
+ based on the Request-URI is deprecated). While generic clients
+ might display the property value to end users, client UI designers
+ must understand that the method for identifying resources is still
+ the URL. Changes to DAV:displayname do not issue moves or copies
+ to the server, but simply change a piece of meta-data on the
+ individual resource. Two resources can have the same DAV:
+ displayname value even within the same collection.
+
+ <!ELEMENT displayname (#PCDATA) >
+
+15.3. getcontentlanguage Property
+
+ Name: getcontentlanguage
+
+ Purpose: Contains the Content-Language header value (from Section
+ 14.12 of [RFC2616]) as it would be returned by a GET without
+ accept headers.
+
+ Value: language-tag (language-tag is defined in Section 3.10 of
+ [RFC2616])
+
+
+
+Dusseault Standards Track [Page 91]
+
+RFC 4918 WebDAV June 2007
+
+
+ Protected: SHOULD NOT be protected, so that clients can reset the
+ language. Note that servers implementing [RFC2518] might have
+ made this a protected property as this is a new requirement.
+
+ COPY/MOVE behavior: This property value SHOULD be preserved in COPY
+ and MOVE operations.
+
+ Description: The DAV:getcontentlanguage property MUST be defined on
+ any DAV-compliant resource that returns the Content-Language
+ header on a GET.
+
+ <!ELEMENT getcontentlanguage (#PCDATA) >
+
+15.4. getcontentlength Property
+
+ Name: getcontentlength
+
+ Purpose: Contains the Content-Length header returned by a GET
+ without accept headers.
+
+ Value: See Section 14.13 of [RFC2616].
+
+ Protected: This property is computed, therefore protected.
+
+ Description: The DAV:getcontentlength property MUST be defined on
+ any DAV-compliant resource that returns the Content-Length header
+ in response to a GET.
+
+ COPY/MOVE behavior: This property value is dependent on the size of
+ the destination resource, not the value of the property on the
+ source resource.
+
+ <!ELEMENT getcontentlength (#PCDATA) >
+
+15.5. getcontenttype Property
+
+ Name: getcontenttype
+
+ Purpose: Contains the Content-Type header value (from Section 14.17
+ of [RFC2616]) as it would be returned by a GET without accept
+ headers.
+
+ Value: media-type (defined in Section 3.7 of [RFC2616])
+
+ Protected: Potentially protected if the server prefers to assign
+ content types on its own (see also discussion in Section 9.7.1).
+
+
+
+
+
+Dusseault Standards Track [Page 92]
+
+RFC 4918 WebDAV June 2007
+
+
+ COPY/MOVE behavior: This property value SHOULD be preserved in COPY
+ and MOVE operations.
+
+ Description: This property MUST be defined on any DAV-compliant
+ resource that returns the Content-Type header in response to a
+ GET.
+
+ <!ELEMENT getcontenttype (#PCDATA) >
+
+15.6. getetag Property
+
+ Name: getetag
+
+ Purpose: Contains the ETag header value (from Section 14.19 of
+ [RFC2616]) as it would be returned by a GET without accept
+ headers.
+
+ Value: entity-tag (defined in Section 3.11 of [RFC2616])
+
+ Protected: MUST be protected because this value is created and
+ controlled by the server.
+
+ COPY/MOVE behavior: This property value is dependent on the final
+ state of the destination resource, not the value of the property
+ on the source resource. Also note the considerations in
+ Section 8.8.
+
+ Description: The getetag property MUST be defined on any DAV-
+ compliant resource that returns the Etag header. Refer to Section
+ 3.11 of RFC 2616 for a complete definition of the semantics of an
+ ETag, and to Section 8.6 for a discussion of ETags in WebDAV.
+
+ <!ELEMENT getetag (#PCDATA) >
+
+15.7. getlastmodified Property
+
+ Name: getlastmodified
+
+ Purpose: Contains the Last-Modified header value (from Section
+ 14.29 of [RFC2616]) as it would be returned by a GET method
+ without accept headers.
+
+ Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616])
+
+ Protected: SHOULD be protected because some clients may rely on the
+ value for appropriate caching behavior, or on the value of the
+ Last-Modified header to which this property is linked.
+
+
+
+
+Dusseault Standards Track [Page 93]
+
+RFC 4918 WebDAV June 2007
+
+
+ COPY/MOVE behavior: This property value is dependent on the last
+ modified date of the destination resource, not the value of the
+ property on the source resource. Note that some server
+ implementations use the file system date modified value for the
+ DAV:getlastmodified value, and this can be preserved in a MOVE
+ even when the HTTP Last-Modified value SHOULD change. Note that
+ since [RFC2616] requires clients to use ETags where provided, a
+ server implementing ETags can count on clients using a much better
+ mechanism than modification dates for offline synchronization or
+ cache control. Also note the considerations in Section 8.8.
+
+ Description: The last-modified date on a resource SHOULD only
+ reflect changes in the body (the GET responses) of the resource.
+ A change in a property only SHOULD NOT cause the last-modified
+ date to change, because clients MAY rely on the last-modified date
+ to know when to overwrite the existing body. The DAV:
+ getlastmodified property MUST be defined on any DAV-compliant
+ resource that returns the Last-Modified header in response to a
+ GET.
+
+ <!ELEMENT getlastmodified (#PCDATA) >
+
+15.8. lockdiscovery Property
+
+ Name: lockdiscovery
+
+ Purpose: Describes the active locks on a resource
+
+ Protected: MUST be protected. Clients change the list of locks
+ through LOCK and UNLOCK, not through PROPPATCH.
+
+ COPY/MOVE behavior: The value of this property depends on the lock
+ state of the destination, not on the locks of the source resource.
+ Recall that locks are not moved in a MOVE operation.
+
+ Description: Returns a listing of who has a lock, what type of lock
+ he has, the timeout type and the time remaining on the timeout,
+ and the associated lock token. Owner information MAY be omitted
+ if it is considered sensitive. If there are no locks, but the
+ server supports locks, the property will be present but contain
+ zero 'activelock' elements. If there are one or more locks, an
+ 'activelock' element appears for each lock on the resource. This
+ property is NOT lockable with respect to write locks (Section 7).
+
+ <!ELEMENT lockdiscovery (activelock)* >
+
+
+
+
+
+
+Dusseault Standards Track [Page 94]
+
+RFC 4918 WebDAV June 2007
+
+
+15.8.1. Example - Retrieving DAV:lockdiscovery
+
+ >>Request
+
+ PROPFIND /container/ HTTP/1.1
+ Host: www.example.com
+ Content-Length: xxxx
+ Content-Type: application/xml; charset="utf-8"
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D='DAV:'>
+ <D:prop><D:lockdiscovery/></D:prop>
+ </D:propfind>
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/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.example.com/container/</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:lockdiscovery>
+ <D:activelock>
+ <D:locktype><D:write/></D:locktype>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:depth>0</D:depth>
+ <D:owner>Jane Smith</D:owner>
+ <D:timeout>Infinite</D:timeout>
+ <D:locktoken>
+ <D:href
+ >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
+ </D:locktoken>
+ <D:lockroot>
+ <D:href>http://www.example.com/container/</D:href>
+ </D:lockroot>
+ </D:activelock>
+ </D:lockdiscovery>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+
+
+
+Dusseault Standards Track [Page 95]
+
+RFC 4918 WebDAV June 2007
+
+
+ This resource has a single exclusive write lock on it, with an
+ infinite timeout.
+
+15.9. resourcetype Property
+
+ Name: resourcetype
+
+ Purpose: Specifies the nature of the resource.
+
+ Protected: SHOULD be protected. Resource type is generally decided
+ through the operation creating the resource (MKCOL vs PUT), not by
+ PROPPATCH.
+
+ COPY/MOVE behavior: Generally a COPY/MOVE of a resource results in
+ the same type of resource at the destination.
+
+ Description: MUST be defined on all DAV-compliant resources. Each
+ child element identifies a specific type the resource belongs to,
+ such as 'collection', which is the only resource type defined by
+ this specification (see Section 14.3). If the element contains
+ the 'collection' child element plus additional unrecognized
+ elements, it should generally be treated as a collection. If the
+ element contains no recognized child elements, it should be
+ treated as a non-collection resource. The default value is empty.
+ This element MUST NOT contain text or mixed content. Any custom
+ child element is considered to be an identifier for a resource
+ type.
+
+ Example: (fictional example to show extensibility)
+
+ <x:resourcetype xmlns:x="DAV:">
+ <x:collection/>
+ <f:search-results xmlns:f="http://www.example.com/ns"/>
+ </x:resourcetype>
+
+15.10. supportedlock Property
+
+ Name: supportedlock
+
+ Purpose: To provide a listing of the lock capabilities supported by
+ the resource.
+
+ Protected: MUST be protected. Servers, not clients, determine what
+ lock mechanisms are supported.
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 96]
+
+RFC 4918 WebDAV June 2007
+
+
+ COPY/MOVE behavior: This property value is dependent on the kind of
+ locks supported at the destination, not on the value of the
+ property at the source resource. Servers attempting to COPY to a
+ destination should not attempt to set this property at the
+ destination.
+
+ Description: Returns a listing of the combinations of scope and
+ access types that may be specified in a lock request on the
+ resource. Note that the actual contents are themselves controlled
+ by access controls, so a server is not required to provide
+ information the client is not authorized to see. This property is
+ NOT lockable with respect to write locks (Section 7).
+
+ <!ELEMENT supportedlock (lockentry)* >
+
+15.10.1. Example - Retrieving DAV:supportedlock
+
+ >>Request
+
+ PROPFIND /container/ HTTP/1.1
+ Host: www.example.com
+ Content-Length: xxxx
+ Content-Type: application/xml; charset="utf-8"
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:">
+ <D:prop><D:supportedlock/></D:prop>
+ </D:propfind>
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/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.example.com/container/</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:supportedlock>
+ <D:lockentry>
+ <D:lockscope><D:exclusive/></D:lockscope>
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ <D:lockentry>
+ <D:lockscope><D:shared/></D:lockscope>
+
+
+
+Dusseault Standards Track [Page 97]
+
+RFC 4918 WebDAV June 2007
+
+
+ <D:locktype><D:write/></D:locktype>
+ </D:lockentry>
+ </D:supportedlock>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+16. Precondition/Postcondition XML Elements
+
+ As introduced in Section 8.7, extra information on error conditions
+ can be included in the body of many status responses. This section
+ makes requirements on the use of the error body mechanism and
+ introduces a number of precondition and postcondition codes.
+
+ 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.
+
+ Each precondition and postcondition has a unique XML element
+ associated with it. In a 207 Multi-Status response, the XML element
+ MUST appear inside an 'error' element in the appropriate 'propstat or
+ 'response' element depending on whether the condition applies to one
+ or more properties or to the resource as a whole. In all other error
+ responses where this specification's 'error' body is used, the
+ precondition/postcondition XML element MUST be returned as the child
+ of a top-level 'error' element in the response body, unless otherwise
+ negotiated by the request, along with an appropriate response status.
+ The most common response status codes are 403 (Forbidden) if the
+ request should not be repeated because it will always fail, and 409
+ (Conflict) if it is expected that the user might be able to resolve
+ the conflict and resubmit the request. The 'error' element MAY
+ contain child elements with specific error information and MAY be
+ extended with any custom child elements.
+
+ This mechanism does not take the place of using a correct numeric
+ status code as defined here or in HTTP, because the client must
+ always be able to take a reasonable course of action based only on
+ the numeric code. However, it does remove the need to define new
+ numeric codes. The new machine-readable codes used for this purpose
+ are XML elements classified as preconditions and postconditions, so
+ naturally, any group defining a new condition code can use their own
+ namespace. As always, the "DAV:" namespace is reserved for use by
+ IETF-chartered WebDAV working groups.
+
+
+
+
+
+Dusseault Standards Track [Page 98]
+
+RFC 4918 WebDAV June 2007
+
+
+ A server supporting this specification SHOULD use the XML error
+ whenever a precondition or postcondition defined in this document is
+ violated. For error conditions not specified in this document, the
+ server MAY simply choose an appropriate numeric status and leave the
+ response body blank. However, a server MAY instead use a custom
+ condition code and other supporting text, because even when clients
+ do not automatically recognize condition codes, they can be quite
+ useful in interoperability testing and debugging.
+
+ Example - Response with precondition code
+
+ >>Response
+
+ HTTP/1.1 423 Locked
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:error xmlns:D="DAV:">
+ <D:lock-token-submitted>
+ <D:href>/workspace/webdav/</D:href>
+ </D:lock-token-submitted>
+ </D:error>
+
+ In this example, a client unaware of a depth-infinity lock on the
+ parent collection "/workspace/webdav/" attempted to modify the
+ collection member "/workspace/webdav/proposal.doc".
+
+ Some other useful preconditions and postconditions have been defined
+ in other specifications extending WebDAV, such as [RFC3744] (see
+ particularly Section 7.1.1), [RFC3253], and [RFC3648].
+
+ All these elements are in the "DAV:" namespace. If not specified
+ otherwise, the content for each condition's XML element is defined to
+ be empty.
+
+
+ Name: lock-token-matches-request-uri
+
+ Use with: 409 Conflict
+
+ Purpose: (precondition) -- A request may include a Lock-Token header
+ to identify a lock for the UNLOCK method. However, if the
+ Request-URI does not fall within the scope of the lock identified
+ by the token, the server SHOULD use this error. The lock may have
+ a scope that does not include the Request-URI, or the lock could
+ have disappeared, or the token may be invalid.
+
+
+
+
+Dusseault Standards Track [Page 99]
+
+RFC 4918 WebDAV June 2007
+
+
+ Name: lock-token-submitted (precondition)
+
+ Use with: 423 Locked
+
+ Purpose: The request could not succeed because a lock token should
+ have been submitted. This element, if present, MUST contain at
+ least one URL of a locked resource that prevented the request. In
+ cases of MOVE, COPY, and DELETE where collection locks are
+ involved, it can be difficult for the client to find out which
+ locked resource made the request fail -- but the server is only
+ responsible for returning one such locked resource. The server
+ MAY return every locked resource that prevented the request from
+ succeeding if it knows them all.
+
+ <!ELEMENT lock-token-submitted (href+) >
+
+
+ Name: no-conflicting-lock (precondition)
+
+ Use with: Typically 423 Locked
+
+ Purpose: A LOCK request failed due the presence of an already
+ existing conflicting lock. Note that a lock can be in conflict
+ although the resource to which the request was directed is only
+ indirectly locked. In this case, the precondition code can be
+ used to inform the client about the resource that is the root of
+ the conflicting lock, avoiding a separate lookup of the
+ "lockdiscovery" property.
+
+ <!ELEMENT no-conflicting-lock (href)* >
+
+
+ Name: no-external-entities
+
+ Use with: 403 Forbidden
+
+ Purpose: (precondition) -- If the server rejects a client request
+ because the request body contains an external entity, the server
+ SHOULD use this error.
+
+
+ Name: preserved-live-properties
+
+ Use with: 409 Conflict
+
+ Purpose: (postcondition) -- The server received an otherwise-valid
+ MOVE or COPY request, but cannot maintain the live properties with
+ the same behavior at the destination. It may be that the server
+
+
+
+Dusseault Standards Track [Page 100]
+
+RFC 4918 WebDAV June 2007
+
+
+ only supports some live properties in some parts of the
+ repository, or simply has an internal error.
+
+
+ Name: propfind-finite-depth
+
+ Use with: 403 Forbidden
+
+ Purpose: (precondition) -- This server does not allow infinite-depth
+ PROPFIND requests on collections.
+
+
+ Name: cannot-modify-protected-property
+
+ Use with: 403 Forbidden
+
+ Purpose: (precondition) -- The client attempted to set a protected
+ property in a PROPPATCH (such as DAV:getetag). See also
+ [RFC3253], Section 3.12.
+
+17. XML Extensibility in DAV
+
+ The XML namespace extension ([REC-XML-NAMES]) is used in this
+ specification in order to allow for new XML elements to be added
+ without fear of colliding with other element names. 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 SHOULD NOT be used in the request or
+ response body unless that XML element is explicitly defined in an
+ IETF RFC reviewed by a WebDAV working group.
+
+ For WebDAV to be both extensible and backwards-compatible, both
+ clients and servers need to know how to behave when unexpected or
+ unrecognized command extensions are received. For XML processing,
+ this means that clients and servers MUST process received XML
+ documents as if unexpected elements and attributes (and all children
+ of unrecognized elements) were not there. An unexpected element or
+ attribute includes one that may be used in another context but is not
+ expected here. Ignoring such items for purposes of processing can of
+ course be consistent with logging all information or presenting for
+ debugging.
+
+ This restriction also applies to the processing, by clients, of DAV
+ property values where unexpected XML elements SHOULD be ignored
+ unless the property's schema declares otherwise.
+
+ This restriction does not apply to setting dead DAV properties on the
+ server where the server MUST record all XML elements.
+
+
+
+Dusseault Standards Track [Page 101]
+
+RFC 4918 WebDAV June 2007
+
+
+ Additionally, this restriction does not apply to the use of XML where
+ XML happens to be the content type of the entity body, for example,
+ when used as the body of a PUT.
+
+ Processing instructions in XML SHOULD be ignored by recipients.
+ Thus, specifications extending WebDAV SHOULD NOT use processing
+ instructions to define normative behavior.
+
+ XML DTD fragments are included for all the XML elements defined in
+ this specification. However, correct XML will not be valid according
+ to any DTD due to namespace usage and extension rules. In
+ particular:
+
+ o Elements (from this specification) are in the "DAV:" namespace,
+
+ o Element ordering is irrelevant unless otherwise stated,
+
+ o Extension attributes MAY be added,
+
+ o For element type definitions of "ANY", the normative text
+ definition for that element defines what can be in it and what
+ that means.
+
+ o For element type definitions of "#PCDATA", extension elements MUST
+ NOT be added.
+
+ o For other element type definitions, including "EMPTY", extension
+ elements MAY be added.
+
+ Note that this means that elements containing elements cannot be
+ extended to contain text, and vice versa.
+
+ With DTD validation relaxed by the rules above, the constraints
+ described by the DTD fragments are normative (see for example
+ Appendix A). A recipient of a WebDAV message with an XML body MUST
+ NOT validate the XML document according to any hard-coded or
+ dynamically-declared DTD.
+
+ Note that this section describes backwards-compatible extensibility
+ rules. There might also be times when an extension is designed not
+ to be backwards-compatible, for example, defining an extension that
+ reuses an XML element defined in this document but omitting one of
+ the child elements required by the DTDs in this specification.
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 102]
+
+RFC 4918 WebDAV June 2007
+
+
+18. DAV Compliance Classes
+
+ A DAV-compliant resource can advertise several classes of compliance.
+ A client can discover the compliance classes of a resource by
+ executing OPTIONS on the resource and examining the "DAV" header
+ which is returned. Note particularly that resources, rather than
+ servers, are spoken of as being compliant. That is because
+ theoretically some resources on a server could support different
+ feature sets. For example, a server could have a sub-repository
+ where an advanced feature like versioning was supported, even if that
+ feature was not supported on all sub-repositories.
+
+ Since this document describes extensions to the HTTP/1.1 protocol,
+ minimally all DAV-compliant resources, clients, and proxies MUST be
+ compliant with [RFC2616].
+
+ A resource that is class 2 or class 3 compliant must also be class 1
+ compliant.
+
+18.1. Class 1
+
+ A class 1 compliant resource MUST meet all "MUST" requirements in all
+ sections of this document.
+
+ Class 1 compliant resources MUST return, at minimum, the value "1" in
+ the DAV header on all responses to the OPTIONS method.
+
+18.2. Class 2
+
+ A class 2 compliant resource MUST meet all class 1 requirements and
+ support the LOCK method, the DAV:supportedlock property, the DAV:
+ lockdiscovery property, the Time-Out response header and the Lock-
+ Token request header. A class 2 compliant resource SHOULD also
+ support the Timeout request header and the 'owner' XML element.
+
+ Class 2 compliant resources MUST return, at minimum, the values "1"
+ and "2" in the DAV header on all responses to the OPTIONS method.
+
+18.3. Class 3
+
+ A resource can explicitly advertise its support for the revisions to
+ [RFC2518] made in this document. Class 1 MUST be supported as well.
+ Class 2 MAY be supported. Advertising class 3 support in addition to
+ class 1 and 2 means that the server supports all the requirements in
+ this specification. Advertising class 3 and class 1 support, but not
+ class 2, means that the server supports all the requirements in this
+ specification except possibly those that involve locking support.
+
+
+
+
+Dusseault Standards Track [Page 103]
+
+RFC 4918 WebDAV June 2007
+
+
+ Example:
+
+ DAV: 1, 3
+
+19. Internationalization Considerations
+
+ In the realm of internationalization, this specification complies
+ with the IETF Character Set Policy [RFC2277]. In this specification,
+ human-readable fields can be found either in the value of a property,
+ or in an error message returned in a response entity body. In both
+ cases, the human-readable content is encoded using XML, which has
+ explicit provisions for character set tagging and encoding, and
+ requires that XML processors read XML elements encoded, at minimum,
+ using the UTF-8 [RFC3629] and UTF-16 [RFC2781] encodings of the ISO
+ 10646 multilingual plane. XML examples in this specification
+ demonstrate use of the charset parameter of the Content-Type header
+ (defined in [RFC3023]), as well as XML charset declarations.
+
+ XML also provides a language tagging capability for specifying the
+ language of the contents of a particular XML element. The "xml:lang"
+ attribute appears on an XML element to identify the language of its
+ content and attributes. See [REC-XML] for definitions of values and
+ scoping.
+
+ WebDAV applications MUST support the character set tagging, character
+ set encoding, and the language tagging functionality of the XML
+ specification. Implementors of WebDAV applications are strongly
+ encouraged to read "XML Media Types" [RFC3023] for instruction on
+ which MIME media type to use for XML transport, and on use of the
+ charset parameter of the Content-Type header.
+
+ Names used within this specification fall into four categories: names
+ of protocol elements such as methods and headers, names of XML
+ elements, names of properties, and names of conditions. Naming of
+ protocol elements follows the precedent of HTTP, using English names
+ encoded in US-ASCII for methods and headers. Since these protocol
+ elements are not visible to users, and are simply long token
+ identifiers, they do not need to support multiple languages.
+ Similarly, the names of XML elements used in this specification are
+ not visible to the user and hence do not need to support multiple
+ languages.
+
+ WebDAV property names are qualified XML names (pairs of XML namespace
+ name and local name). Although some applications (e.g., a generic
+ property viewer) will display property names directly to their users,
+ it is expected that the typical application will use a fixed set of
+ properties, and will provide a mapping from the property name and
+ namespace to a human-readable field when displaying the property name
+
+
+
+Dusseault Standards Track [Page 104]
+
+RFC 4918 WebDAV June 2007
+
+
+ to a user. It is only in the case where the set of properties is not
+ known ahead of time that an application need display a property name
+ to a user. We recommend that applications provide human-readable
+ property names wherever feasible.
+
+ For error reporting, we follow the convention of HTTP/1.1 status
+ codes, including with each status code a short, English description
+ of the code (e.g., 423 (Locked)). While the possibility exists that
+ a poorly crafted user agent would display this message to a user,
+ internationalized applications will ignore this message, and display
+ an appropriate message in the user's language and character set.
+
+ Since interoperation of clients and servers does not require locale
+ information, this specification does not specify any mechanism for
+ transmission of this information.
+
+20. Security Considerations
+
+ This section is provided to detail issues concerning security
+ implications of which WebDAV applications need to be aware.
+
+ All of the security considerations of HTTP/1.1 (discussed in
+ [RFC2616]) and XML (discussed in [RFC3023]) also apply to WebDAV. In
+ addition, the security risks inherent in remote authoring require
+ stronger authentication technology, introduce several new privacy
+ concerns, and may increase the hazards from poor server design.
+ These issues are detailed below.
+
+20.1. Authentication of Clients
+
+ Due to their emphasis on authoring, WebDAV servers need to use
+ authentication technology to protect not just access to a network
+ resource, but the integrity of the resource as well. Furthermore,
+ the introduction of locking functionality requires support for
+ authentication.
+
+ A password sent in the clear over an insecure channel is an
+ inadequate means for protecting the accessibility and integrity of a
+ resource as the password may be intercepted. Since Basic
+ authentication for HTTP/1.1 performs essentially clear text
+ transmission of a password, Basic authentication MUST NOT be used to
+ authenticate a WebDAV client to a server unless the connection is
+ secure. Furthermore, a WebDAV server MUST NOT send a Basic
+ authentication challenge in a WWW-Authenticate header unless the
+ connection is secure. An example of a secure connection would be a
+ Transport Layer Security (TLS) connection employing a strong cipher
+ suite and server authentication.
+
+
+
+
+Dusseault Standards Track [Page 105]
+
+RFC 4918 WebDAV June 2007
+
+
+ WebDAV applications MUST support the Digest authentication scheme
+ [RFC2617]. Since Digest authentication verifies that both parties to
+ a communication know a shared secret, a password, without having to
+ send that secret in the clear, Digest authentication avoids the
+ security problems inherent in Basic authentication while providing a
+ level of authentication that is useful in a wide range of scenarios.
+
+20.2. Denial of Service
+
+ Denial-of-service attacks are of special concern to WebDAV servers.
+ WebDAV plus HTTP enables denial-of-service attacks on every part of a
+ system's resources.
+
+ o The underlying storage can be attacked by PUTting extremely large
+ files.
+
+ o Asking for recursive operations on large collections can attack
+ processing time.
+
+ o Making multiple pipelined requests on multiple connections can
+ attack network connections.
+
+ WebDAV servers need to be aware of the possibility of a denial-of-
+ service attack at all levels. The proper response to such an attack
+ MAY be to simply drop the connection. Or, if the server is able to
+ make a response, the server MAY use a 400-level status request such
+ as 400 (Bad Request) and indicate why the request was refused (a 500-
+ level status response would indicate that the problem is with the
+ server, whereas unintentional DoS attacks are something the client is
+ capable of remedying).
+
+20.3. Security through Obscurity
+
+ WebDAV provides, through the PROPFIND method, a mechanism for listing
+ the member resources of a collection. This greatly diminishes the
+ effectiveness of security or privacy techniques that rely only on the
+ difficulty of discovering the names of network resources. Users of
+ WebDAV servers are encouraged to use access control techniques to
+ prevent unwanted access to resources, rather than depending on the
+ relative obscurity of their resource names.
+
+20.4. Privacy Issues Connected to Locks
+
+ When submitting a lock request, a user agent may also submit an
+ 'owner' XML field giving contact information for the person taking
+ out the lock (for those cases where a person, rather than a robot, is
+ taking out the lock). This contact information is stored in a DAV:
+ lockdiscovery property on the resource, and can be used by other
+
+
+
+Dusseault Standards Track [Page 106]
+
+RFC 4918 WebDAV June 2007
+
+
+ collaborators to begin negotiation over access to the resource.
+ However, in many cases, this contact information can be very private,
+ and should not be widely disseminated. Servers SHOULD limit read
+ access to the DAV:lockdiscovery property as appropriate.
+ Furthermore, user agents SHOULD provide control over whether contact
+ information is sent at all, and if contact information is sent,
+ control over exactly what information is sent.
+
+20.5. Privacy Issues Connected to Properties
+
+ Since property values are typically used to hold information such as
+ the author of a document, there is the possibility that privacy
+ concerns could arise stemming from widespread access to a resource's
+ property data. To reduce the risk of inadvertent release of private
+ information via properties, servers are encouraged to develop access
+ control mechanisms that separate read access to the resource body and
+ read access to the resource's properties. This allows a user to
+ control the dissemination of their property data without overly
+ restricting access to the resource's contents.
+
+20.6. Implications of XML Entities
+
+ XML supports a facility known as "external entities", defined in
+ Section 4.2.2 of [REC-XML], which instructs an XML processor to
+ retrieve and include additional XML. An external XML entity can be
+ used to append or modify the document type declaration (DTD)
+ associated with an XML document. An external XML entity can also be
+ used to include XML within the content of an XML document. For non-
+ validating XML, such as the XML used in this specification, including
+ an external XML entity is not required by XML. However, XML does
+ state that an XML processor may, at its discretion, include the
+ external XML entity.
+
+ External XML entities have no inherent trustworthiness and are
+ subject to all the attacks that are endemic to any HTTP GET request.
+ Furthermore, it is possible for an external XML entity to modify the
+ DTD, and hence affect the final form of an XML document, in the worst
+ case, significantly modifying its semantics or exposing the XML
+ processor to the security risks discussed in [RFC3023]. Therefore,
+ implementers must be aware that external XML entities should be
+ treated as untrustworthy. If a server chooses not to handle external
+ XML entities, it SHOULD respond to requests containing external
+ entities with the 'no-external-entities' condition code.
+
+ There is also the scalability risk that would accompany a widely
+ deployed application that made use of external XML entities. In this
+ situation, it is possible that there would be significant numbers of
+ requests for one external XML entity, potentially overloading any
+
+
+
+Dusseault Standards Track [Page 107]
+
+RFC 4918 WebDAV June 2007
+
+
+ server that fields requests for the resource containing the external
+ XML entity.
+
+ Furthermore, there's also a risk based on the evaluation of "internal
+ entities" as defined in Section 4.2.2 of [REC-XML]. A small,
+ carefully crafted request using nested internal entities may require
+ enormous amounts of memory and/or processing time to process. Server
+ implementers should be aware of this risk and configure their XML
+ parsers so that requests like these can be detected and rejected as
+ early as possible.
+
+20.7. Risks Connected with Lock Tokens
+
+ This specification encourages the use of "A Universally Unique
+ Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens
+ (Section 6.5), in order to guarantee their uniqueness across space
+ and time. Version 1 UUIDs (defined in Section 4) MAY contain a
+ "node" field that "consists of an IEEE 802 MAC address, usually the
+ host address. For systems with multiple IEEE addresses, any
+ available one can be used". Since a WebDAV server will issue many
+ locks over its lifetime, the implication is that it may also be
+ publicly exposing its IEEE 802 address.
+
+ There are several risks associated with exposure of IEEE 802
+ addresses. Using the IEEE 802 address:
+
+ o It is possible to track the movement of hardware from subnet to
+ subnet.
+
+ o It may be possible to identify the manufacturer of the hardware
+ running a WebDAV server.
+
+ o It may be possible to determine the number of each type of
+ computer running WebDAV.
+
+ This risk only applies to host-address-based UUID versions. Section
+ 4 of [RFC4122] describes several other mechanisms for generating
+ UUIDs that do not involve the host address and therefore do not
+ suffer from this risk.
+
+20.8. Hosting Malicious Content
+
+ HTTP has the ability to host programs that are executed on client
+ machines. These programs can take many forms including Web scripts,
+ executables, plug-in modules, and macros in documents. WebDAV does
+ not change any of the security concerns around these programs, yet
+ often WebDAV is used in contexts where a wide range of users can
+ publish documents on a server. The server might not have a close
+
+
+
+Dusseault Standards Track [Page 108]
+
+RFC 4918 WebDAV June 2007
+
+
+ trust relationship with the author that is publishing the document.
+ Servers that allow clients to publish arbitrary content can usefully
+ implement precautions to check that content published to the server
+ is not harmful to other clients. Servers could do this by techniques
+ such as restricting the types of content that is allowed to be
+ published and running virus and malware detection software on
+ published content. Servers can also mitigate the risk by having
+ appropriate access restriction and authentication of users that are
+ allowed to publish content to the server.
+
+21. IANA Considerations
+
+21.1. New URI Schemes
+
+ This specification defines two URI schemes:
+
+ 1. the "opaquelocktoken" scheme defined in Appendix C, and
+
+ 2. the "DAV" URI scheme, which historically was used in [RFC2518] to
+ disambiguate WebDAV property and XML element names and which
+ continues to be used for that purpose in this specification and
+ others extending WebDAV. Creation of identifiers in the "DAV:"
+ namespace is controlled by the IETF.
+
+ Note that defining new URI schemes for XML namespaces is now
+ discouraged. "DAV:" was defined before standard best practices
+ emerged.
+
+21.2. XML Namespaces
+
+ XML namespaces disambiguate WebDAV property names and XML elements.
+ Any WebDAV user or application can define a new namespace in order to
+ create custom properties or extend WebDAV XML syntax. IANA does not
+ need to manage such namespaces, property names, or element names.
+
+21.3. Message Header Fields
+
+ The message header fields below should be added to the permanent
+ registry (see [RFC3864]).
+
+21.3.1. DAV
+
+ Header field name: DAV
+
+ Applicable protocol: http
+
+ Status: standard
+
+
+
+
+Dusseault Standards Track [Page 109]
+
+RFC 4918 WebDAV June 2007
+
+
+ Author/Change controller: IETF
+
+ Specification document: this specification (Section 10.1)
+
+21.3.2. Depth
+
+ Header field name: Depth
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document: this specification (Section 10.2)
+
+21.3.3. Destination
+
+ Header field name: Destination
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document: this specification (Section 10.3)
+
+21.3.4. If
+
+ Header field name: If
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document: this specification (Section 10.4)
+
+21.3.5. Lock-Token
+
+ Header field name: Lock-Token
+
+ Applicable protocol: http
+
+ Status: standard
+
+
+
+
+Dusseault Standards Track [Page 110]
+
+RFC 4918 WebDAV June 2007
+
+
+ Author/Change controller: IETF
+
+ Specification document: this specification (Section 10.5)
+
+21.3.6. Overwrite
+
+ Header field name: Overwrite
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document: this specification (Section 10.6)
+
+21.3.7. Timeout
+
+ Header field name: Timeout
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document: this specification (Section 10.7)
+
+21.4. HTTP Status Codes
+
+ This specification defines the HTTP status codes
+
+ o 207 Multi-Status (Section 11.1)
+
+ o 422 Unprocessable Entity (Section 11.2),
+
+ o 423 Locked (Section 11.3),
+
+ o 424 Failed Dependency (Section 11.4) and
+
+ o 507 Insufficient Storage (Section 11.5),
+
+ to be updated in the registry at
+ <http://www.iana.org/assignments/http-status-codes>.
+
+ Note: the HTTP status code 102 (Processing) has been removed in this
+ specification; its IANA registration should continue to reference RFC
+ 2518.
+
+
+
+Dusseault Standards Track [Page 111]
+
+RFC 4918 WebDAV June 2007
+
+
+22. Acknowledgements
+
+ A specification such as this thrives on piercing critical review and
+ withers from apathetic neglect. The authors gratefully acknowledge
+ the contributions of the following people, whose insights were so
+ valuable at every stage of our work.
+
+ Contributors to RFC 2518
+
+ Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
+ Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
+ Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
+ Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
+ Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
+ Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
+ Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der
+ Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven
+ Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten,
+ Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff,
+ Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike
+ Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi,
+ Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran,
+ Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
+
+ Two from this list deserve special mention. The contributions by
+ Larry Masinter have been invaluable; he both helped the formation of
+ the working group and patiently coached the authors along the way.
+ In so many ways he has set high standards that we have toiled to
+ meet. The contributions of Judith Slein were also invaluable; by
+ clarifying the requirements and in patiently reviewing version after
+ version, she both improved this specification and expanded our minds
+ on document management.
+
+ We would also like to thank John Turner for developing the XML DTD.
+
+ The authors of RFC 2518 were Yaron Goland, Jim Whitehead, A. Faizi,
+ Steve Carter, and D. Jensen. Although their names had to be removed
+ due to IETF author count restrictions, they can take credit for the
+ majority of the design of WebDAV.
+
+ Additional Acknowledgements for This Specification
+
+ Significant contributors of text for this specification are listed as
+ contributors in the section below. We must also gratefully
+ acknowledge Geoff Clemm, Joel Soderberg, and Dan Brotsky for hashing
+ out specific text on the list or in meetings. Joe Hildebrand and
+ Cullen Jennings helped close many issues. Barry Lind described an
+ additional security consideration and Cullen Jennings provided text
+
+
+
+Dusseault Standards Track [Page 112]
+
+RFC 4918 WebDAV June 2007
+
+
+ for that consideration. Jason Crawford tracked issue status for this
+ document for a period of years, followed by Elias Sinderson.
+
+23. Contributors to This Specification
+
+ Julian Reschke
+ <green/>bytes GmbH
+ Hafenweg 16, 48155 Muenster, Germany
+ EMail: julian.reschke at greenbytes.de
+
+
+ Elias Sinderson
+ University of California, Santa Cruz
+ 1156 High Street, Santa Cruz, CA 95064
+ EMail: elias at cse.ucsc.edu
+
+
+ Jim Whitehead
+ University of California, Santa Cruz
+ 1156 High Street, Santa Cruz, CA 95064
+ EMail: ejw at soe.ucsc.edu
+
+24. Authors of RFC 2518
+
+ Y. Y. Goland
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ EMail: yarong at microsoft.com
+
+
+ E. J. Whitehead, Jr.
+ Dept. Of Information and Computer Science
+ University of California, Irvine
+ Irvine, CA 92697-3425
+ EMail: ejw at ics.uci.edu
+
+
+ A. Faizi
+ Netscape
+ 685 East Middlefield Road
+ Mountain View, CA 94043
+ EMail: asad at netscape.com
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 113]
+
+RFC 4918 WebDAV June 2007
+
+
+ S. R. Carter
+ Novell
+ 1555 N. Technology Way
+ M/S ORM F111
+ Orem, UT 84097-2399
+ EMail: srcarter at novell.com
+
+
+ D. Jensen
+ Novell
+ 1555 N. Technology Way
+ M/S ORM F111
+ Orem, UT 84097-2399
+ EMail: dcjensen at novell.com
+
+25. References
+
+25.1. Normative References
+
+ [REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler,
+ E., and F. Yergeau, "Extensible Markup Language
+ (XML) 1.0 (Fourth Edition)", W3C REC-xml-20060816,
+ August 2006,
+ <http://www.w3.org/TR/2006/REC-xml-20060816/>.
+
+ [REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set
+ (Second Edition)", W3C REC-xml-infoset-20040204,
+ February 2004, <http://www.w3.org/TR/2004/
+ REC-xml-infoset-20040204/>.
+
+ [REC-XML-NAMES] Bray, T., Hollander, D., Layman, A., and R. Tobin,
+ "Namespaces in XML 1.0 (Second Edition)", W3C REC-
+ xml-names-20060816, August 2006, <http://
+ www.w3.org/TR/2006/REC-xml-names-20060816/>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", BCP 18, RFC 2277, January 1998.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol -- HTTP/1.1",
+ RFC 2616, June 1999.
+
+
+
+
+
+Dusseault Standards Track [Page 114]
+
+RFC 4918 WebDAV June 2007
+
+
+ [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J.,
+ Lawrence, S., Leach, P., Luotonen, A., and L.
+ Stewart, "HTTP Authentication: Basic and Digest
+ Access Authentication", RFC 2617, June 1999.
+
+ [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on
+ the Internet: Timestamps", RFC 3339, July 2002.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of
+ ISO 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic
+ Syntax", STD 66, RFC 3986, January 2005.
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A
+ Universally Unique IDentifier (UUID) URN
+ Namespace", RFC 4122, July 2005.
+
+25.2. Informative References
+
+ [RFC2291] Slein, J., Vitali, F., Whitehead, E., and D.
+ Durand, "Requirements for a Distributed Authoring
+ and Versioning Protocol for the World Wide Web",
+ RFC 2291, February 1998.
+
+ [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S.,
+ and D. Jensen, "HTTP Extensions for Distributed
+ Authoring -- WEBDAV", RFC 2518, February 1999.
+
+ [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding
+ of ISO 10646", RFC 2781, February 2000.
+
+ [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML
+ Media Types", RFC 3023, January 2001.
+
+ [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and
+ J. Whitehead, "Versioning Extensions to WebDAV
+ (Web Distributed Authoring and Versioning)",
+ RFC 3253, March 2002.
+
+ [RFC3648] Whitehead, J. and J. Reschke, Ed., "Web
+ Distributed Authoring and Versioning (WebDAV)
+ Ordered Collections Protocol", RFC 3648,
+ December 2003.
+
+
+
+
+
+
+Dusseault Standards Track [Page 115]
+
+RFC 4918 WebDAV June 2007
+
+
+ [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J.
+ Whitehead, "Web Distributed Authoring and
+ Versioning (WebDAV) Access Control Protocol",
+ RFC 3744, May 2004.
+
+ [RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
+ "Registration Procedures for Message Header
+ Fields", BCP 90, RFC 3864, September 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 116]
+
+RFC 4918 WebDAV June 2007
+
+
+Appendix A. Notes on Processing XML Elements
+
+A.1. Notes on Empty XML Elements
+
+ XML supports two mechanisms for indicating that an XML element does
+ not have any content. The first is to declare an XML element of the
+ form <A></A>. The second is to declare an XML element of the form
+ <A/>. The two XML elements are semantically identical.
+
+A.2. Notes on Illegal XML Processing
+
+ XML is a flexible data format that makes it easy to submit data that
+ appears legal but in fact is not. The philosophy of "Be flexible in
+ what you accept and strict in what you send" still applies, but it
+ must not be applied inappropriately. XML is extremely flexible in
+ dealing with issues of whitespace, element ordering, inserting new
+ elements, etc. This flexibility does not require extension,
+ especially not in the area of the meaning of elements.
+
+ There is no kindness in accepting illegal combinations of XML
+ elements. At best, it will cause an unwanted result and at worst it
+ can cause real damage.
+
+A.3. Example - XML Syntax Error
+
+ The following request body for a PROPFIND method is illegal.
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:">
+ <D:allprop/>
+ <D:propname/>
+ </D:propfind>
+
+ The definition of the propfind element only allows for the allprop or
+ the propname element, not both. Thus, the above is an error and must
+ be responded to with a 400 (Bad Request).
+
+ Imagine, however, that a server wanted to be "kind" and decided to
+ pick the allprop element as the true element and respond to it. A
+ client running over a bandwidth limited line who intended to execute
+ a propname would be in for a big surprise if the server treated the
+ command as an allprop.
+
+ Additionally, if a server were lenient and decided to reply to this
+ request, the results would vary randomly from server to server, with
+ some servers executing the allprop directive, and others executing
+ the propname directive. This reduces interoperability rather than
+ increasing it.
+
+
+
+Dusseault Standards Track [Page 117]
+
+RFC 4918 WebDAV June 2007
+
+
+A.4. Example - Unexpected XML Element
+
+ The previous example was illegal because it contained two elements
+ that were explicitly banned from appearing together in the propfind
+ element. However, XML is an extensible language, so one can imagine
+ new elements being defined for use with propfind. Below is the
+ request body of a PROPFIND and, like the previous example, must be
+ rejected with a 400 (Bad Request) by a server that does not
+ understand the expired-props element.
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:"
+ xmlns:E="http://www.example.com/standards/props/">
+ <E:expired-props/>
+ </D:propfind>
+
+ To understand why a 400 (Bad Request) is returned, let us look at the
+ request body as the server unfamiliar with expired-props sees it.
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:"
+ xmlns:E="http://www.example.com/standards/props/">
+ </D:propfind>
+
+ As the server does not understand the 'expired-props' element,
+ according to the WebDAV-specific XML processing rules specified in
+ Section 17, it must process the request as if the element were not
+ there. Thus, the server sees an empty propfind, which by the
+ definition of the propfind element is illegal.
+
+ Please note that had the extension been additive, it would not
+ necessarily have resulted in a 400 (Bad Request). For example,
+ imagine the following request body for a PROPFIND:
+
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:propfind xmlns:D="DAV:"
+ xmlns:E="http://www.example.com/standards/props/">
+ <D:propname/>
+ <E:leave-out>*boss*</E:leave-out>
+ </D:propfind>
+
+ The previous example contains the fictitious element leave-out. Its
+ purpose is to prevent the return of any property whose name matches
+ the submitted pattern. If the previous example were submitted to a
+ server unfamiliar with 'leave-out', the only result would be that the
+ 'leave-out' element would be ignored and a propname would be
+ executed.
+
+
+
+Dusseault Standards Track [Page 118]
+
+RFC 4918 WebDAV June 2007
+
+
+Appendix B. Notes on HTTP Client Compatibility
+
+ WebDAV was designed to be, and has been found to be, backward-
+ compatible with HTTP 1.1. The PUT and DELETE methods are defined in
+ HTTP and thus may be used by HTTP clients as well as WebDAV-aware
+ clients, but the responses to PUT and DELETE have been extended in
+ this specification in ways that only a WebDAV client would be
+ entirely prepared for. Some theoretical concerns were raised about
+ whether those responses would cause interoperability problems with
+ HTTP-only clients, and this section addresses those concerns.
+
+ Since any HTTP client ought to handle unrecognized 400-level and 500-
+ level status codes as errors, the following new status codes should
+ not present any issues: 422, 423, and 507 (424 is also a new status
+ code but it appears only in the body of a Multistatus response.) So,
+ for example, if an HTTP client attempted to PUT or DELETE a locked
+ resource, the 423 Locked response ought to result in a generic error
+ presented to the user.
+
+ The 207 Multistatus response is interesting because an HTTP client
+ issuing a DELETE request to a collection might interpret a 207
+ response as a success, even though it does not realize the resource
+ is a collection and cannot understand that the DELETE operation might
+ have been a complete or partial failure. That interpretation isn't
+ entirely justified, because a 200-level response indicates that the
+ server "received, understood, and accepted" the request, not that the
+ request resulted in complete success.
+
+ One option is that a server could treat a DELETE of a collection as
+ an atomic operation, and use either 204 No Content in case of
+ success, or some appropriate error response (400 or 500 level) for an
+ error. This approach would indeed maximize backward compatibility.
+ However, since interoperability tests and working group discussions
+ have not turned up any instances of HTTP clients issuing a DELETE
+ request against a WebDAV collection, this concern is more theoretical
+ than practical. Thus, servers are likely to be completely successful
+ at interoperating with HTTP clients even if they treat any collection
+ DELETE request as a WebDAV request and send a 207 Multi-Status
+ response.
+
+ In general, server implementations are encouraged to use the detailed
+ responses and other mechanisms defined in this document rather than
+ make changes for theoretical interoperability concerns.
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 119]
+
+RFC 4918 WebDAV June 2007
+
+
+Appendix C. The 'opaquelocktoken' Scheme and URIs
+
+ The 'opaquelocktoken' URI scheme was defined in [RFC2518] (and
+ registered by IANA) in order to create syntactically correct and
+ easy-to-generate URIs out of UUIDs, intended to be used as lock
+ tokens and to be unique across all resources for all time.
+
+ An opaquelocktoken URI is constructed by concatenating the
+ 'opaquelocktoken' scheme with a UUID, along with an optional
+ extension. Servers can create new UUIDs for each new lock token. If
+ a server wishes to reuse UUIDs, the server MUST add an extension, and
+ the algorithm generating the extension MUST guarantee that the same
+ extension will never be used twice with the associated UUID.
+
+ OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
+ ; UUID is defined in Section 3 of [RFC4122]. Note that LWS
+ ; is not allowed between elements of
+ ; this production.
+
+ Extension = path
+ ; path is defined in Section 3.3 of [RFC3986]
+
+
+Appendix D. Lock-null Resources
+
+ The original WebDAV model for locking unmapped URLs created "lock-
+ null resources". This model was over-complicated and some
+ interoperability and implementation problems were discovered. The
+ new WebDAV model for locking unmapped URLs (see Section 7.3) creates
+ "locked empty resources". Lock-null resources are deprecated. This
+ section discusses the original model briefly because clients MUST be
+ able to handle either model.
+
+ In the original "lock-null resource" model, which is no longer
+ recommended for implementation:
+
+ o A lock-null resource sometimes appeared as "Not Found". The
+ server responds with a 404 or 405 to any method except for PUT,
+ MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
+
+ o A lock-null resource does however show up as a member of its
+ parent collection.
+
+ o The server removes the lock-null resource entirely (its URI
+ becomes unmapped) if its lock goes away before it is converted to
+ a regular resource. Recall that locks go away not only when they
+ expire or are unlocked, but are also removed if a resource is
+ renamed or moved, or if any parent collection is renamed or moved.
+
+
+
+Dusseault Standards Track [Page 120]
+
+RFC 4918 WebDAV June 2007
+
+
+ o The server converts the lock-null resource into a regular resource
+ if a PUT request to the URL is successful.
+
+ o The server converts the lock-null resource into a collection if a
+ MKCOL request to the URL is successful (though interoperability
+ experience showed that not all servers followed this requirement).
+
+ o Property values were defined for DAV:lockdiscovery and DAV:
+ supportedlock properties but not necessarily for other properties
+ like DAV:getcontenttype.
+
+ Clients can easily interoperate both with servers that support the
+ old model "lock-null resources" and the recommended model of "locked
+ empty resources" by only attempting PUT after a LOCK to an unmapped
+ URL, not MKCOL or GET.
+
+D.1. Guidance for Clients Using LOCK to Create Resources
+
+ A WebDAV client implemented to this specification might find servers
+ that create lock-null resources (implemented before this
+ specification using [RFC2518]) as well as servers that create locked
+ empty resources. The response to the LOCK request will not indicate
+ what kind of resource was created. There are a few techniques that
+ help the client deal with either type.
+
+ If the client wishes to avoid accidentally creating either lock-
+ null or empty locked resources, an "If-Match: *" header can be
+ included with LOCK requests to prevent the server from creating a
+ new resource.
+
+ If a LOCK request creates a resource and the client subsequently
+ wants to overwrite that resource using a COPY or MOVE request, the
+ client should include an "Overwrite: T" header.
+
+ If a LOCK request creates a resource and the client then decides
+ to get rid of that resource, a DELETE request is supposed to fail
+ on a lock-null resource and UNLOCK should be used instead. But
+ with a locked empty resource, UNLOCK doesn't make the resource
+ disappear. Therefore, the client might have to try both requests
+ and ignore an error in one of the two requests.
+
+Appendix E. Guidance for Clients Desiring to Authenticate
+
+ Many WebDAV clients that have already been implemented have account
+ settings (similar to the way email clients store IMAP account
+ settings). Thus, the WebDAV client would be able to authenticate
+ with its first couple requests to the server, provided it had a way
+ to get the authentication challenge from the server with realm name,
+
+
+
+Dusseault Standards Track [Page 121]
+
+RFC 4918 WebDAV June 2007
+
+
+ nonce, and other challenge information. Note that the results of
+ some requests might vary according to whether or not the client is
+ authenticated -- a PROPFIND might return more visible resources if
+ the client is authenticated, yet not fail if the client is anonymous.
+
+ There are a number of ways the client might be able to trigger the
+ server to provide an authentication challenge. This appendix
+ describes a couple approaches that seem particularly likely to work.
+
+ The first approach is to perform a request that ought to require
+ authentication. However, it's possible that a server might handle
+ any request even without authentication, so to be entirely safe, the
+ client could add a conditional header to ensure that even if the
+ request passes permissions checks, it's not actually handled by the
+ server. An example of following this approach would be to use a PUT
+ request with an "If-Match" header with a made-up ETag value. This
+ approach might fail to result in an authentication challenge if the
+ server does not test authorization before testing conditionals as is
+ required (see Section 8.5), or if the server does not need to test
+ authorization.
+
+ Example - forcing auth challenge with write request
+
+ >>Request
+
+ PUT /forceauth.txt HTTP/1.1
+ Host: www.example.com
+ If-Match: "xxx"
+ Content-Type: text/plain
+ Content-Length: 0
+
+
+ The second approach is to use an Authorization header (defined in
+ [RFC2617]), which is likely to be rejected by the server but which
+ will then prompt a proper authentication challenge. For example, the
+ client could start with a PROPFIND request containing an
+ Authorization header containing a made-up Basic userid:password
+ string or with actual plausible credentials. This approach relies on
+ the server responding with a "401 Unauthorized" along with a
+ challenge if it receives an Authorization header with an unrecognized
+ username, invalid password, or if it doesn't even handle Basic
+ authentication. This seems likely to work because of the
+ requirements of RFC 2617:
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 122]
+
+RFC 4918 WebDAV June 2007
+
+
+ "If the origin server does not wish to accept the credentials sent
+ with a request, it SHOULD return a 401 (Unauthorized) response. The
+ response MUST include a WWW-Authenticate header field containing at
+ least one (possibly new) challenge applicable to the requested
+ resource."
+
+ There's a slight problem with implementing that recommendation in
+ some cases, because some servers do not even have challenge
+ information for certain resources. Thus, when there's no way to
+ authenticate to a resource or the resource is entirely publicly
+ available over all accepted methods, the server MAY ignore the
+ Authorization header, and the client will presumably try again later.
+
+ Example - forcing auth challenge with Authorization header
+
+ >>Request
+
+ PROPFIND /docs/ HTTP/1.1
+ Host: www.example.com
+ Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+ Content-type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ [body omitted]
+
+
+Appendix F. Summary of Changes from RFC 2518
+
+ This section lists major changes between this document and RFC 2518,
+ starting with those that are likely to result in implementation
+ changes. Servers will advertise support for all changes in this
+ specification by returning the compliance class "3" in the DAV
+ response header (see Sections 10.1 and 18.3).
+
+F.1. Changes for Both Client and Server Implementations
+
+ Collections and Namespace Operations
+
+ o The semantics of PROPFIND 'allprop' (Section 9.1) have been
+ relaxed so that servers return results including, at a minimum,
+ the live properties defined in this specification, but not
+ necessarily return other live properties. The 'allprop' directive
+ therefore means something more like "return all properties that
+ are supposed to be returned when 'allprop' is requested" -- a set
+ of properties that may include custom properties and properties
+ defined in other specifications if those other specifications so
+ require. Related to this, 'allprop' requests can now be extended
+ with the 'include' syntax to include specific named properties,
+
+
+
+Dusseault Standards Track [Page 123]
+
+RFC 4918 WebDAV June 2007
+
+
+ thereby avoiding additional requests due to changed 'allprop'
+ semantics.
+
+ o Servers are now allowed to reject PROPFIND requests with Depth:
+ Infinity. Clients that used this will need to be able to do a
+ series of Depth:1 requests instead.
+
+ o Multi-Status response bodies now can transport the value of HTTP's
+ Location response header in the new 'location' element. Clients
+ may use this to avoid additional roundtrips to the server when
+ there is a 'response' element with a 3xx status (see
+ Section 14.24).
+
+ o The definition of COPY has been relaxed so that it doesn't require
+ servers to first delete the target resources anymore (this was a
+ known incompatibility with [RFC3253]). See Section 9.8.
+
+ Headers and Marshalling
+
+ o The Destination and If request headers now allow absolute paths in
+ addition to full URIs (see Section 8.3). This may be useful for
+ clients operating through a reverse proxy that does rewrite the
+ Host request header, but not WebDAV-specific headers.
+
+ o This specification adopts the error marshalling extensions and the
+ "precondition/postcondition" terminology defined in [RFC3253] (see
+ Section 16). Related to that, it adds the "error" XML element
+ inside multistatus response bodies (see Section 14.5, however note
+ that it uses a format different from the one recommended in RFC
+ 3253).
+
+ o Senders and recipients are now required to support the UTF-16
+ character encoding in XML message bodies (see Section 19).
+
+ o Clients are now required to send the Depth header on PROPFIND
+ requests, although servers are still encouraged to support clients
+ that don't.
+
+ Locking
+
+ o RFC 2518's concept of "lock-null resources" (LNRs) has been
+ replaced by a simplified approach, the "locked empty resources"
+ (see Section 7.3). There are some aspects of lock-null resources
+ clients cannot rely on anymore, namely, the ability to use them to
+ create a locked collection or the fact that they disappear upon
+ UNLOCK when no PUT or MKCOL request was issued. Note that servers
+ are still allowed to implement LNRs as per RFC 2518.
+
+
+
+
+Dusseault Standards Track [Page 124]
+
+RFC 4918 WebDAV June 2007
+
+
+ o There is no implicit refresh of locks anymore. Locks are only
+ refreshed upon explicit request (see Section 9.10.2).
+
+ o Clarified that the DAV:owner value supplied in the LOCK request
+ must be preserved by the server just like a dead property
+ (Section 14.17). Also added the DAV:lockroot element
+ (Section 14.12), which allows clients to discover the root of
+ lock.
+
+F.2. Changes for Server Implementations
+
+ Collections and Namespace Operations
+
+ o Due to interoperability problems, allowable formats for contents
+ of 'href' elements in multistatus responses have been limited (see
+ Section 8.3).
+
+ o Due to lack of implementation, support for the 'propertybehavior'
+ request body for COPY and MOVE has been removed. Instead,
+ requirements for property preservation have been clarified (see
+ Sections 9.8 and 9.9).
+
+ Properties
+
+ o Strengthened server requirements for storage of property values,
+ in particular persistence of language information (xml:lang),
+ whitespace, and XML namespace information (see Section 4.3).
+
+ o Clarified requirements on which properties should be writable by
+ the client; in particular, setting "DAV:displayname" should be
+ supported by servers (see Section 15).
+
+ o Only 'rfc1123-date' productions are legal as values for DAV:
+ getlastmodified (see Section 15.7).
+
+ Headers and Marshalling
+
+ o Servers are now required to do authorization checks before
+ processing conditional headers (see Section 8.5).
+
+ Locking
+
+ o Strengthened requirement to check identity of lock creator when
+ accessing locked resources (see Section 6.4). Clients should be
+ aware that lock tokens returned to other principals can only be
+ used to break a lock, if at all.
+
+
+
+
+
+Dusseault Standards Track [Page 125]
+
+RFC 4918 WebDAV June 2007
+
+
+ o Section 8.10.4 of [RFC2518] incorrectly required servers to return
+ a 409 status where a 207 status was really appropriate. This has
+ been corrected (Section 9.10).
+
+F.3. Other Changes
+
+ The definition of collection state has been fixed so it doesn't vary
+ anymore depending on the Request-URI (see Section 5.2).
+
+ The DAV:source property introduced in Section 4.6 of [RFC2518] was
+ removed due to lack of implementation experience.
+
+ The DAV header now allows non-IETF extensions through URIs in
+ addition to compliance class tokens. It also can now be used in
+ requests, although this specification does not define any associated
+ semantics for the compliance classes defined in here (see
+ Section 10.1).
+
+ In RFC 2518, the definition of the Depth header (Section 9.2)
+ required that, by default, request headers would be applied to each
+ resource in scope. Based on implementation experience, the default
+ has now been reversed (see Section 10.2).
+
+ The definitions of HTTP status code 102 ([RFC2518], Section 10.1) and
+ the Status-URI response header (Section 9.7) have been removed due to
+ lack of implementation.
+
+ The TimeType format used in the Timeout request header and the
+ "timeout" XML element used to be extensible. Now, only the two
+ formats defined by this specification are allowed (see Section 10.7).
+
+Author's Address
+
+ Lisa Dusseault (editor)
+ CommerceNet
+ 2064 Edgewood Dr.
+ Palo Alto, CA 94303
+ US
+
+ EMail: ldusseault at commerce.net
+
+
+
+
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 126]
+
+RFC 4918 WebDAV June 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights 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; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ 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 implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Dusseault Standards Track [Page 127]
+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20080421/d5eb03c6/attachment-0001.html
More information about the calendarserver-changes
mailing list