aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/rfc2518.txt
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/sabre/dav/docs/rfc2518.txt')
-rw-r--r--vendor/sabre/dav/docs/rfc2518.txt5267
1 files changed, 5267 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/rfc2518.txt b/vendor/sabre/dav/docs/rfc2518.txt
new file mode 100644
index 000000000..81d40387b
--- /dev/null
+++ b/vendor/sabre/dav/docs/rfc2518.txt
@@ -0,0 +1,5267 @@
+
+
+
+
+
+
+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@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@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@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@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@microsoft.com
+
+
+ E. J. Whitehead, Jr.
+ Dept. Of Information and Computer Science
+ University of California, Irvine
+ Irvine, CA 92697-3425
+
+ EMail: ejw@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@netscape.com
+
+
+ S. R. Carter
+ Novell
+ 1555 N. Technology Way
+ M/S ORM F111
+ Orem, UT 84097-2399
+
+ EMail: srcarter@novell.com
+
+
+ D. Jensen
+ Novell
+ 1555 N. Technology Way
+ M/S ORM F111
+ Orem, UT 84097-2399
+
+ EMail: dcjensen@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]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-11 09:53:36 +0000