Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4918

HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)

Pages: 127
Proposed Standard
Errata
Obsoletes:  2518
Updated by:  5689
Part 1 of 5 – Pages 1 to 17
None   None   Next

Top   ToC   RFC4918 - Page 1
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.
Top   ToC   RFC4918 - Page 2

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
Top   ToC   RFC4918 - Page 3
           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
Top   ToC   RFC4918 - Page 4
           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
Top   ToC   RFC4918 - Page 5
      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
Top   ToC   RFC4918 - Page 6
   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
Top   ToC   RFC4918 - Page 7

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
Top   ToC   RFC4918 - Page 8
   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.
Top   ToC   RFC4918 - Page 9
   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.
Top   ToC   RFC4918 - Page 10

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.
Top   ToC   RFC4918 - Page 11
   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
Top   ToC   RFC4918 - Page 12
   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>
Top   ToC   RFC4918 - Page 13
   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 &lt;RFC2518&gt;.
         </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.
Top   ToC   RFC4918 - Page 14

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.
Top   ToC   RFC4918 - Page 15
   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.
Top   ToC   RFC4918 - Page 16
   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
Top   ToC   RFC4918 - Page 17
   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)

Next Section