RFC 4918
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
Network Working Group L. Dusseault, Ed. Request for Comments: 4918 CommerceNet Obsoletes: 2518 June 2007 Category: Standards Track HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).Abstract
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance). RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience.
Table of Contents
1. Introduction ....................................................7 2. Notational Conventions ..........................................8 3. Terminology .....................................................8 4. Data Model for Resource Properties .............................10 4.1. The Resource Property Model ...............................10 4.2. Properties and HTTP Headers ...............................10 4.3. Property Values ...........................................10 4.3.1. Example - Property with Mixed Content ..............12 4.4. Property Names ............................................14 4.5. Source Resources and Output Resources .....................14 5. Collections of Web Resources ...................................14 5.1. HTTP URL Namespace Model ..................................15 5.2. Collection Resources ......................................15 6. Locking ........................................................17 6.1. Lock Model ................................................18 6.2. Exclusive vs. Shared Locks ................................19 6.3. Required Support ..........................................20 6.4. Lock Creator and Privileges ...............................20 6.5. Lock Tokens ...............................................21 6.6. Lock Timeout ..............................................21 6.7. Lock Capability Discovery .................................22 6.8. Active Lock Discovery .....................................22 7. Write Lock .....................................................23 7.1. Write Locks and Properties ................................24 7.2. Avoiding Lost Updates .....................................24 7.3. Write Locks and Unmapped URLs .............................25 7.4. Write Locks and Collections ...............................26 7.5. Write Locks and the If Request Header .....................28 7.5.1. Example - Write Lock and COPY ......................28 7.5.2. Example - Deleting a Member of a Locked Collection .........................................29 7.6. Write Locks and COPY/MOVE .................................30 7.7. Refreshing Write Locks ....................................30 8. General Request and Response Handling ..........................31 8.1. Precedence in Error Handling ..............................31 8.2. Use of XML ................................................31 8.3. URL Handling ..............................................32 8.3.1. Example - Correct URL Handling .....................32 8.4. Required Bodies in Requests ...............................33 8.5. HTTP Headers for Use in WebDAV ............................33 8.6. ETag ......................................................33 8.7. Including Error Response Bodies ...........................34 8.8. Impact of Namespace Operations on Cache Validators ........34 9. HTTP Methods for Distributed Authoring .........................35 9.1. PROPFIND Method ...........................................35 9.1.1. PROPFIND Status Codes ..............................37
9.1.2. Status Codes for Use in 'propstat' Element .........37
9.1.3. Example - Retrieving Named Properties ..............38
9.1.4. Example - Using 'propname' to Retrieve All
Property Names .....................................39
9.1.5. Example - Using So-called 'allprop' ................41
9.1.6. Example - Using 'allprop' with 'include' ...........43
9.2. PROPPATCH Method ..........................................44
9.2.1. Status Codes for Use in 'propstat' Element .........44
9.2.2. Example - PROPPATCH ................................45
9.3. MKCOL Method ..............................................46
9.3.1. MKCOL Status Codes .................................47
9.3.2. Example - MKCOL ....................................47
9.4. GET, HEAD for Collections .................................48
9.5. POST for Collections ......................................48
9.6. DELETE Requirements .......................................48
9.6.1. DELETE for Collections .............................49
9.6.2. Example - DELETE ...................................49
9.7. PUT Requirements ..........................................50
9.7.1. PUT for Non-Collection Resources ...................50
9.7.2. PUT for Collections ................................51
9.8. COPY Method ...............................................51
9.8.1. COPY for Non-collection Resources ..................51
9.8.2. COPY for Properties ................................52
9.8.3. COPY for Collections ...............................52
9.8.4. COPY and Overwriting Destination Resources .........53
9.8.5. Status Codes .......................................54
9.8.6. Example - COPY with Overwrite ......................55
9.8.7. Example - COPY with No Overwrite ...................55
9.8.8. Example - COPY of a Collection .....................56
9.9. MOVE Method ...............................................56
9.9.1. MOVE for Properties ................................57
9.9.2. MOVE for Collections ...............................57
9.9.3. MOVE and the Overwrite Header ......................58
9.9.4. Status Codes .......................................59
9.9.5. Example - MOVE of a Non-Collection .................60
9.9.6. Example - MOVE of a Collection .....................60
9.10. LOCK Method ..............................................61
9.10.1. Creating a Lock on an Existing Resource ...........61
9.10.2. Refreshing Locks ..................................62
9.10.3. Depth and Locking .................................62
9.10.4. Locking Unmapped URLs .............................63
9.10.5. Lock Compatibility Table ..........................63
9.10.6. LOCK Responses ....................................63
9.10.7. Example - Simple Lock Request .....................64
9.10.8. Example - Refreshing a Write Lock .................65
9.10.9. Example - Multi-Resource Lock Request .............66
9.11. UNLOCK Method ............................................68
9.11.1. Status Codes ......................................68
9.11.2. Example - UNLOCK ..................................69
10. HTTP Headers for Distributed Authoring ........................69
10.1. DAV Header ...............................................69
10.2. Depth Header .............................................70
10.3. Destination Header .......................................71
10.4. If Header ................................................72
10.4.1. Purpose ...........................................72
10.4.2. Syntax ............................................72
10.4.3. List Evaluation ...................................73
10.4.4. Matching State Tokens and ETags ...................74
10.4.5. If Header and Non-DAV-Aware Proxies ...............74
10.4.6. Example - No-tag Production .......................75
10.4.7. Example - Using "Not" with No-tag Production ......75
10.4.8. Example - Causing a Condition to Always
Evaluate to True ..................................75
10.4.9. Example - Tagged List If Header in COPY ...........76
10.4.10. Example - Matching Lock Tokens with
Collection Locks .................................76
10.4.11. Example - Matching ETags on Unmapped URLs ........76
10.5. Lock-Token Header ........................................77
10.6. Overwrite Header .........................................77
10.7. Timeout Request Header ...................................78
11. Status Code Extensions to HTTP/1.1 ............................78
11.1. 207 Multi-Status .........................................78
11.2. 422 Unprocessable Entity .................................78
11.3. 423 Locked ...............................................78
11.4. 424 Failed Dependency ....................................79
11.5. 507 Insufficient Storage .................................79
12. Use of HTTP Status Codes ......................................79
12.1. 412 Precondition Failed ..................................79
12.2. 414 Request-URI Too Long .................................79
13. Multi-Status Response .........................................80
13.1. Response Headers .........................................80
13.2. Handling Redirected Child Resources ......................81
13.3. Internal Status Codes ....................................81
14. XML Element Definitions .......................................81
14.1. activelock XML Element ...................................81
14.2. allprop XML Element ......................................82
14.3. collection XML Element ...................................82
14.4. depth XML Element ........................................82
14.5. error XML Element ........................................82
14.6. exclusive XML Element ....................................83
14.7. href XML Element .........................................83
14.8. include XML Element ......................................83
14.9. location XML Element .....................................83
14.10. lockentry XML Element ...................................84
14.11. lockinfo XML Element ....................................84
14.12. lockroot XML Element ....................................84
14.13. lockscope XML Element ...................................84
14.14. locktoken XML Element ...................................85
14.15. locktype XML Element ....................................85
14.16. multistatus XML Element .................................85
14.17. owner XML Element .......................................85
14.18. prop XML Element ........................................86
14.19. propertyupdate XML Element ..............................86
14.20. propfind XML Element ....................................86
14.21. propname XML Element ....................................87
14.22. propstat XML Element ....................................87
14.23. remove XML Element ......................................87
14.24. response XML Element ....................................88
14.25. responsedescription XML Element .........................88
14.26. set XML Element .........................................88
14.27. shared XML Element ......................................89
14.28. status XML Element ......................................89
14.29. timeout XML Element .....................................89
14.30. write XML Element .......................................89
15. DAV Properties ................................................90
16. Precondition/Postcondition XML Elements .......................98
17. XML Extensibility in DAV .....................................101
18. DAV Compliance Classes .......................................103
18.1. Class 1 .................................................103
18.2. Class 2 .................................................103
18.3. Class 3 .................................................103
19. Internationalization Considerations ..........................104
20. Security Considerations ......................................105
20.1. Authentication of Clients ...............................105
20.2. Denial of Service .......................................106
20.3. Security through Obscurity ..............................106
20.4. Privacy Issues Connected to Locks .......................106
20.5. Privacy Issues Connected to Properties ..................107
20.6. Implications of XML Entities ............................107
20.7. Risks Connected with Lock Tokens ........................108
20.8. Hosting Malicious Content ...............................108
21. IANA Considerations ..........................................109
21.1. New URI Schemes .........................................109
21.2. XML Namespaces ..........................................109
21.3. Message Header Fields ...................................109
21.3.1. DAV ..............................................109
21.3.2. Depth ............................................110
21.3.3. Destination ......................................110
21.3.4. If ...............................................110
21.3.5. Lock-Token .......................................110
21.3.6. Overwrite ........................................111
21.3.7. Timeout ..........................................111
21.4. HTTP Status Codes .......................................111
22. Acknowledgements .............................................112
23. Contributors to This Specification ...........................113 24. Authors of RFC 2518 ..........................................113 25. References ...................................................114 25.1. Normative References.....................................114 25.2. Informative References ..................................115 Appendix A. Notes on Processing XML Elements ....................117 A.1. Notes on Empty XML Elements ..............................117 A.2. Notes on Illegal XML Processing ..........................117 A.3. Example - XML Syntax Error ...............................117 A.4. Example - Unexpected XML Element .........................118 Appendix B. Notes on HTTP Client Compatibility ...................119 Appendix C. The 'opaquelocktoken' Scheme and URIs ................120 Appendix D. Lock-null Resources ..................................120 D.1. Guidance for Clients Using LOCK to Create Resources ......121 Appendix E. Guidance for Clients Desiring to Authenticate ........121 Appendix F. Summary of Changes from RFC 2518 .....................123 F.1. Changes for Both Client and Server Implementations .......123 F.2. Changes for Server Implementations .......................125 F.3. Other Changes ............................................126
1. Introduction
This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote Web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for: Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc. Collections: The ability to create sets of documents and to retrieve a hierarchical membership listing (like a directory listing in a file system). Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem", in which modifications are lost as first one author, then another, writes changes without merging the other author's changes. Namespace Operations: The ability to instruct the server to copy and move Web resources, operations that change the mapping from URLs to resources. Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" [RFC2291]. This document does not specify the versioning operations suggested by [RFC2291]. That work was done in a separate document, "Versioning Extensions to WebDAV" [RFC3253]. The sections below provide a detailed introduction to various WebDAV abstractions: resource properties (Section 4), collections of resources (Section 5), locks (Section 6) in general, and write locks (Section 7) specifically. These abstractions are manipulated by the WebDAV-specific HTTP methods (Section 9) and the extra HTTP headers (Section 10) used with WebDAV methods. General considerations for handling HTTP requests and responses in WebDAV are found in Section 8. While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines extra status codes developed for WebDAV methods (Section 11) and describes existing HTTP status codes (Section 12) as used in WebDAV. Since some WebDAV methods may
operate over many resources, the Multi-Status response (Section 13) has been introduced to return status information for multiple resources. Finally, this version of WebDAV introduces precondition and postcondition (Section 16) XML elements in error response bodies. WebDAV uses XML ([REC-XML]) for property names and some values, and also uses XML to marshal complicated requests and responses. This specification contains DTD and text definitions of all properties (Section 15) and all other XML elements (Section 14) used in marshalling. WebDAV includes a few special rules on extending WebDAV XML marshalling in backwards-compatible ways (Section 17). Finishing off the specification are sections on what it means for a resource to be compliant with this specification (Section 18), on internationalization support (Section 19), and on security (Section 20).2. Notational Conventions
Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in Section 2.1 of [RFC2616], including the rules about implied linear whitespace. Since this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], these rules apply to this document as well. Note this is not the standard BNF syntax used in other RFCs. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Note that in natural language, a property like the "creationdate" property in the "DAV:" XML namespace is sometimes referred to as "DAV:creationdate" for brevity.3. Terminology
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in [RFC3986]. URI/URL Mapping - A relation between an absolute URI and a resource. Since a resource can represent items that are not network retrievable, as well as those that are, it is possible for a resource to have zero, one, or many URI mappings. Mapping a resource to an "http" scheme URI makes it possible to submit HTTP protocol requests to the resource using the URI.
Path Segment - Informally, the characters found between slashes ("/")
in a URI. Formally, as defined in Section 3.3 of [RFC3986].
Collection - Informally, a resource that also acts as a container of
references to child resources. Formally, a resource that contains a
set of mappings between path segments and resources and meets the
requirements defined in Section 5.
Internal Member (of a Collection) - Informally, a child resource of a
collection. Formally, a resource referenced by a path segment
mapping contained in the collection.
Internal Member URL (of a Collection) - A URL of an internal member,
consisting of the URL of the collection (including trailing slash)
plus the path segment identifying the internal member.
Member (of a Collection) - Informally, a "descendant" of a
collection. Formally, an internal member of the collection, or,
recursively, a member of an internal member.
Member URL (of a Collection) - A URL that is either an internal
member URL of the collection itself, or is an internal member URL of
a member of that collection.
Property - A name/value pair that contains descriptive information
about a resource.
Live Property - A property whose semantics and syntax are enforced by
the server. For example, the live property DAV:getcontentlength has
its value, the length of the entity returned by a GET request,
automatically calculated by the server.
Dead Property - A property whose semantics and syntax are not
enforced by the server. The server only records the value of a dead
property; the client is responsible for maintaining the consistency
of the syntax and semantics of a dead property.
Principal - A distinct human or computational actor that initiates
access to network resources.
State Token - A URI that represents a state of a resource. Lock
tokens are the only state tokens defined in this specification.
4. Data Model for Resource Properties
4.1. The Resource Property Model
Properties are pieces of data that describe the state of a resource. Properties are data about data. Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents. The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics. There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is protected and maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.4.2. Properties and HTTP Headers
Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments, a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus, a mechanism is needed that allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.4.3. Property Values
The value of a property is always a (well-formed) XML fragment. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self- describing nature allows any property's value to be extended by adding elements. Clients will not break when they encounter extensions because they will still have the data specified in the original schema and MUST ignore elements they do not understand.
XML's support for multiple character sets allows any human-readable
property to be encoded and read in a character set familiar to the
user. XML's support for multiple human languages, using the "xml:
lang" attribute, handles cases where the same character set is
employed by multiple human languages. Note that xml:lang scope is
recursive, so an xml:lang attribute on any element containing a
property name element applies to the property value unless it has
been overridden by a more locally scoped attribute. Note that a
property only has one value, in one language (or language MAY be left
undefined); a property does not have multiple values in different
languages or a single value in multiple languages.
A property is always represented with an XML element consisting of
the property name, called the "property name element". The simplest
example is an empty property, which is different from a property that
does not exist:
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
The value of the property appears inside the property name element.
The value may be any kind of well-formed XML content, including both
text-only and mixed content. Servers MUST preserve the following XML
Information Items (using the terminology from [REC-XML-INFOSET]) in
storage and transmission of dead properties:
For the property name Element Information Item itself:
[namespace name]
[local name]
[attributes] named "xml:lang" or any such attribute in scope
[children] of type element or character
On all Element Information Items in the property value:
[namespace name]
[local name]
[attributes]
[children] of type element or character
On Attribute Information Items in the property value:
[namespace name]
[local name]
[normalized value]
On Character Information Items in the property value:
[character code]
Since prefixes are used in some XML vocabularies (XPath and XML
Schema, for example), servers SHOULD preserve, for any Information
Item in the value:
[prefix]
XML Infoset attributes not listed above MAY be preserved by the
server, but clients MUST NOT rely on them being preserved. The above
rules would also apply by default to live properties, unless defined
otherwise.
Servers MUST ignore the XML attribute xml:space if present and never
use it to change whitespace handling. Whitespace in property values
is significant.
4.3.1. Example - Property with Mixed Content
Consider a dead property 'author' created by the client as follows:
<D:prop xml:lang="en" xmlns:D="DAV:">
<x:author xmlns:x='http://example.com/ns'>
<x:name>Jane Doe</x:name>
<!-- Jane's contact info -->
<x:uri type='email'
added='2005-11-26'>mailto:jane.doe@example.com</x:uri>
<x:uri type='web'
added='2005-11-27'>http://www.example.com</x:uri>
<x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <![CDATA[<RFC2518>]]>.
</x:notes>
</x:author>
</D:prop>
When this property is requested, a server might return:
<D:prop xmlns:D='DAV:'><author
xml:lang='en'
xmlns:x='http://example.com/ns'
xmlns='http://example.com/ns'
xmlns:h='http://www.w3.org/1999/xhtml'>
<x:name>Jane Doe</x:name>
<x:uri added="2005-11-26" type="email"
>mailto:jane.doe@example.com</x:uri>
<x:uri added="2005-11-27" type="web"
>http://www.example.com</x:uri>
<x:notes>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <RFC2518>.
</x:notes>
</author>
</D:prop>
Note in this example:
o The [prefix] for the property name itself was not preserved, being
non-significant, whereas all other [prefix] values have been
preserved,
o attribute values have been rewritten with double quotes instead of
single quotes (quoting style is not significant), and attribute
order has not been preserved,
o the xml:lang attribute has been returned on the property name
element itself (it was in scope when the property was set, but the
exact position in the response is not considered significant as
long as it is in scope),
o whitespace between tags has been preserved everywhere (whitespace
between attributes not so),
o CDATA encapsulation was replaced with character escaping (the
reverse would also be legal),
o the comment item was stripped (as would have been a processing
instruction item).
Implementation note: there are cases such as editing scenarios where
clients may require that XML content is preserved character by
character (such as attribute ordering or quoting style). In this
case, clients should consider using a text-only property value by
escaping all characters that have a special meaning in XML parsing.
4.4. Property Names
A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property. Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition. The XML namespace mechanism, which is based on URIs ([RFC3986]), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control. The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced that will address issues relating to hierarchical properties. Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace.4.5. Source Resources and Output Resources
Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one, or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.5. Collections of Web Resources
This section provides a description of a type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace and with HTTP methods. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace.
All DAV-compliant resources MUST support the HTTP URL namespace model specified herein.5.1. HTTP URL Namespace Model
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character. An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member URL. The root, or top-level collection of the namespace under consideration, is exempt from the previous rule. The top-level collection of the namespace under consideration is not necessarily the collection identified by the absolute path '/' -- it may be identified by one or more path segments (e.g., /servlets/webdav/...) Neither HTTP/1.1 nor WebDAV requires that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies. As is implicit in [RFC2616] and [RFC3986], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.5.2. Collection Resources
Collection resources differ from other resources in that they also act as containers. Some HTTP methods apply only to a collection, but some apply to some or all of the resources inside the container defined by the collection. When the scope of a method is not clear, the client can specify what depth to apply. Depth can be either zero levels (only the collection), one level (the collection and directly contained resources), or infinite levels (the collection and all contained resources recursively). A collection's state consists of at least a set of mappings between path segments and resources, and a set of properties on the collection itself. In this document, a resource B will be said to be contained in the collection resource A if there is a path segment mapping that maps to B and that is contained in A. A collection MUST contain at most one mapping for a given path segment, i.e., it is illegal to have the same path segment mapped to more than one resource.
Properties defined on collections behave exactly as do properties on non-collection resources. A collection MAY have additional state such as entity bodies returned by GET. For all WebDAV-compliant resources A and B, identified by URLs "U" and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain exactly one mapping from "blah" to B. Although commonly a mapping consists of a single segment and a resource, in general, a mapping consists of a set of segments and a resource. This allows a server to treat a set of segments as equivalent (i.e., either all of the segments are mapped to the same resource, or none of the segments are mapped to a resource). For example, a server that performs case-folding on segments will treat the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can then use any of these segments to identify the resource. Note that a PROPFIND result will select one of these equivalent segments to identify the mapping, so there will be one PROPFIND response element per mapping, not one per segment in the mapping. Collection resources MAY have mappings to non-WebDAV-compliant resources in the HTTP URL namespace hierarchy but are not required to do so. For example, if resource X with URL "http://example.com/bar/blah" is not WebDAV compliant and resource A with "URL http://example.com/bar/" identifies a WebDAV collection, then A may or may not have a mapping from "blah" to X. If a WebDAV-compliant resource has no WebDAV-compliant internal members in the HTTP URL namespace hierarchy, then the WebDAV- compliant resource is not required to be a collection. There is a standing convention that when a collection is referred to by its name without a trailing slash, the server MAY handle the request as if the trailing slash were present. In this case, it SHOULD return a Content-Location header in the response, pointing to the URL ending with the "/". For example, if a client invokes a method on http://example.com/blah (no trailing slash), the server may respond as if the operation were invoked on http://example.com/blah/ (trailing slash), and should return a Content-Location header with the value http://example.com/blah/. Wherever a server produces a URL referring to a collection, the server SHOULD include the trailing slash. In general, clients SHOULD use the trailing slash form of collection names. If clients do not use the trailing slash form the client needs to be prepared to see a redirect response. Clients will
find the DAV:resourcetype property more reliable than the URL to find out if a resource is a collection. Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if an OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections. A typical scenario in which mapped URLs do not appear as members of their parent collection is the case where a server allows links or redirects to non-WebDAV resources. For instance, "/col/link" might not appear as a member of "/col/", although the server would respond with a 302 status to a GET request to "/col/link"; thus, the URL "/col/link" would indeed be mapped. Similarly, a dynamically- generated page might have a URL mapping from "/col/index.html", thus this resource might respond with a 200 OK to a GET request yet not appear as a member of "/col/". Some mappings to even WebDAV-compliant resources might not appear in the parent collection. An example for this case are servers that support multiple alias URLs for each WebDAV-compliant resource. A server may implement case-insensitive URLs, thus "/col/a" and "/col/A" identify the same resource, yet only either "a" or "A" is reported upon listing the members of "/col". In cases where a server treats a set of segments as equivalent, the server MUST expose only one preferred segment per mapping, consistently chosen, in PROPFIND responses.
(page 17 continued on part 2)
