idnits 2.17.1 draft-ietf-webdav-bind-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1828. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1818. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-webdav-rfc2518bis', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-webdav-rfc2518bis', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-webdav-rfc2518bis', but the file name used is 'draft-ietf-webdav-bind-13' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 573 has weird spacing: '...| x.gif y.g...' == Line 595 has weird spacing: '...| x.gif y.g...' == Line 801 has weird spacing: '...| x.gif y.g...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 8, 2006) is 6652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 5 errors (**), 1 flaw (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Clemm 3 Internet-Draft IBM 4 Updates: J. Crawford 5 draft-ietf-webdav-rfc2518bis (if IBM Research 6 approved) J. Reschke 7 Expires: August 12, 2006 greenbytes 8 J. Whitehead 9 U.C. Santa Cruz 10 February 8, 2006 12 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) 13 draft-ietf-webdav-bind-13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 12, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This specification defines bindings, and the BIND method for creating 47 multiple bindings to the same resource. Creating a new binding to a 48 resource causes at least one new URI to be mapped to that resource. 50 Servers are required to insure the integrity of any bindings that 51 they allow to be created. 53 Editorial Note (To be removed by RFC Editor before publication) 55 Please send comments to the Distributed Authoring and Versioning 56 (WebDAV) working group at , which may be 57 joined by sending a message with subject "subscribe" to 58 . Discussions of the WEBDAV 59 working group are archived at 60 . 62 lists 63 all registered issues since draft 02. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.2. Rationale for Distinguishing Bindings from URI Mappings . 6 70 1.3. Method Preconditions and Postconditions . . . . . . . . . 7 71 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7 72 2.1. Bindings to Collections . . . . . . . . . . . . . . . . . 8 73 2.1.1. Bind loops . . . . . . . . . . . . . . . . . . . . . . 8 74 2.2. URI Mappings Created by a new Binding . . . . . . . . . . 9 75 2.3. COPY and Bindings . . . . . . . . . . . . . . . . . . . . 9 76 2.3.1. Example: COPY with 'Depth: infinity' in presence 77 of bind loops . . . . . . . . . . . . . . . . . . . . 11 78 2.3.2. Example: COPY with 'Depth: infinity' with multiple 79 bindings to a leaf resource . . . . . . . . . . . . . 13 80 2.4. DELETE and Bindings . . . . . . . . . . . . . . . . . . . 14 81 2.5. MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 14 82 2.6. PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 15 83 2.7. Determining Whether Two Bindings Are to the Same 84 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 2.8. Discovering the Bindings to a Resource . . . . . . . . . . 16 86 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 3.1. DAV:resource-id Property . . . . . . . . . . . . . . . . . 17 88 3.2. DAV:parent-set Property . . . . . . . . . . . . . . . . . 17 89 3.2.1. Example for DAV:parent-set property . . . . . . . . . 17 90 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 4.1. Example: BIND . . . . . . . . . . . . . . . . . . . . . . 21 92 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 21 93 5.1. Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 23 94 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 23 95 6.1. Example: REBIND . . . . . . . . . . . . . . . . . . . . . 25 96 6.2. Example: REBIND in presence of locks and bind loops . . . 26 98 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 28 99 7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 28 100 7.1.1. Example: PROPFIND by bind-aware client . . . . . . . . 29 101 7.1.2. Example: PROPFIND by non-bind-aware client . . . . . . 31 102 7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 31 103 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 31 104 8.1. OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 31 105 8.2. 'DAV' request header . . . . . . . . . . . . . . . . . . . 31 106 9. Relationship to WebDAV Access Control Protocol . . . . . . . . 32 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 108 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 32 109 10.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 32 110 10.3. Bindings, and Denial of Service . . . . . . . . . . . . . 32 111 10.4. Private Locations May Be Revealed . . . . . . . . . . . . 33 112 10.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 33 113 11. Internationalization Considerations . . . . . . . . . . . . . 33 114 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 115 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 116 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 117 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 118 14.2. Informative References . . . . . . . . . . . . . . . . . . 34 119 Appendix A. Change Log (to be removed by RFC Editor before 120 publication) . . . . . . . . . . . . . . . . . . . . 34 121 A.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 34 122 A.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 35 123 A.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 35 124 A.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 35 125 A.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 35 126 A.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 35 127 A.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 35 128 A.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 36 129 A.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 36 130 A.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 36 131 A.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 36 132 Appendix B. Resolved issues (to be removed by RFC Editor 133 before publication) . . . . . . . . . . . . . . . . . 36 134 B.1. ED_updates . . . . . . . . . . . . . . . . . . . . . . . . 37 135 Appendix C. Open issues (to be removed by RFC Editor prior to 136 publication) . . . . . . . . . . . . . . . . . . . . 37 137 C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 138 C.2. webdav-rev . . . . . . . . . . . . . . . . . . . . . . . . 37 139 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 141 Intellectual Property and Copyright Statements . . . . . . . . . . 42 143 1. Introduction 145 This specification extends the WebDAV Distributed Authoring Protocol 146 ([draft-ietf-webdav-rfc2518bis]) to enable clients to create new 147 access paths to existing resources. This capability is useful for 148 several reasons: 150 URIs of WebDAV-compliant resources are hierarchical and correspond to 151 a hierarchy of collections in resource space. The WebDAV Distributed 152 Authoring Protocol makes it possible to organize these resources into 153 hierarchies, placing them into groupings, known as collections, which 154 are more easily browsed and manipulated than a single flat 155 collection. However, hierarchies require categorization decisions 156 that locate resources at a single location in the hierarchy, a 157 drawback when a resource has multiple valid categories. For example, 158 in a hierarchy of vehicle descriptions containing collections for 159 cars and boats, a description of a combination car/boat vehicle could 160 belong in either collection. Ideally, the description should be 161 accessible from both. Allowing clients to create new URIs that 162 access the existing resource lets them put that resource into 163 multiple collections. 165 Hierarchies also make resource sharing more difficult, since 166 resources that have utility across many collections are still forced 167 into a single collection. For example, the mathematics department at 168 one university might create a collection of information on fractals 169 that contains bindings to some local resources, but also provides 170 access to some resources at other universities. For many reasons, it 171 may be undesirable to make physical copies of the shared resources on 172 the local server: to conserve disk space, to respect copyright 173 constraints, or to make any changes in the shared resources visible 174 automatically. Being able to create new access paths to existing 175 resources in other collections or even on other servers is useful for 176 this sort of case. 178 The BIND method defined here provides a mechanism for allowing 179 clients to create alternative access paths to existing WebDAV 180 resources. HTTP [RFC2616] and WebDAV [draft-ietf-webdav-rfc2518bis] 181 methods are able to work because there are mappings between URIs and 182 resources. A method is addressed to a URI, and the server follows 183 the mapping from that URI to a resource, applying the method to that 184 resource. Multiple URIs may be mapped to the same resource, but 185 until now there has been no way for clients to create additional URIs 186 mapped to existing resources. 188 BIND lets clients associate a new URI with an existing WebDAV 189 resource, and this URI can then be used to submit requests to the 190 resource. Since URIs of WebDAV resources are hierarchical, and 191 correspond to a hierarchy of collections in resource space, the BIND 192 method also has the effect of adding the resource to a collection. 193 As new URIs are associated with the resource, it appears in 194 additional collections. 196 A BIND request does not create a new resource, but simply makes 197 available a new URI for submitting requests to an existing resource. 198 The new URI is indistinguishable from any other URI when submitting a 199 request to a resource. Only one round trip is needed to submit a 200 request to the intended target. Servers are required to enforce the 201 integrity of the relationships between the new URIs and the resources 202 associated with them. Consequently, it may be very costly for 203 servers to support BIND requests that cross server boundaries. 205 This specification is organized as follows. Section 1.1 defines 206 terminology used in the rest of the specification, while Section 2 207 overviews bindings. Section 3 defines the new properties needed to 208 support multiple bindings to the same resource. Section 4 specifies 209 the BIND method, used to create multiple bindings to the same 210 resource. Section 5 specifies the UNBIND method, used to remove a 211 binding to a resource. Section 6 specifies the REBIND method, used 212 to move a binding to another collection. 214 1.1. Terminology 216 The terminology used here follows and extends that in the WebDAV 217 Distributed Authoring Protocol specification 218 [draft-ietf-webdav-rfc2518bis]. 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in [RFC2119]. 224 This document uses XML DTD fragments ([XML]) as a notational 225 convention, using the rules defined in Section 17 of 226 [draft-ietf-webdav-rfc2518bis]. 228 URI Mapping 230 A relation between an absolute URI and a resource. For an 231 absolute URI U and the resource it identifies R, the URI mapping 232 can be thought of as (U => R). Since a resource can represent 233 items that are not network retrievable, as well as those that are, 234 it is possible for a resource to have zero, one, or many URI 235 mappings. Mapping a resource to an "http" scheme URI makes it 236 possible to submit HTTP protocol requests to the resource using 237 the URI. 239 Path Segment 241 Informally, the characters found between slashes ("/") in a URI. 242 Formally, as defined in Section 3.3 of [RFC3986]. 244 Binding 246 A relation between a single path segment (in a collection) and a 247 resource. A binding is part of the state of a collection. If two 248 different collections contain a binding between the same path 249 segment and the same resource, these are two distinct bindings. 250 So for a collection C, a path segment S, and a resource R, the 251 binding can be thought of as C:(S -> R). Bindings create URI 252 mappings, and hence allow requests to be sent to a single resource 253 from multiple locations in a URI namespace. For example, given a 254 collection C (accessible through the URI 255 http://www.example.com/CollX), a path segment S (equal to 256 "foo.html"), and a resource R, then creating the binding C: (S -> 257 R) makes it possible to use the URI 258 http://www.example.com/CollX/foo.html to access R. 260 Collection 262 A resource that contains, as part of its state, a set of bindings 263 that identify internal member resources. 265 Internal Member URI 267 The URI that identifies an internal member of a collection, and 268 that consists of the URI for the collection, followed by a slash 269 character ('/'), followed by the path segment of the binding for 270 that internal member. 272 1.2. Rationale for Distinguishing Bindings from URI Mappings 274 In [draft-ietf-webdav-rfc2518bis], the definition of collection state 275 has been partly updated so that it doesn't depend on the access URL 276 anymore. However, there are some more changes needed in the 277 subsequent paragraphs to complete this change. The authors of this 278 specification recommend updating paragraphs 2, 3 and 4 of Section 5.2 279 of [draft-ietf-webdav-rfc2518bis] to read: 281 A collection MUST contain at most one mapping for a given path 282 segment, i.e., it is illegal to have the same path segment mapped 283 to more than one resource. Properties defined on collections 284 behave exactly as do properties on non-collection resources. 286 For all WebDAV compliant resources A and B, identified by URLs "U" 287 and "V" respectively, such that "V" is equal to "U/SEGMENT", A 288 MUST be a collection that contains a mapping from "SEGMENT" to B. 289 So, if resource B with URL "http://example.com/bar/blah" is WebDAV 290 compliant and if resource A with URL "http://example.com/bar/" is 291 WebDAV compliant, then resource A must be a collection and must 292 contain a mapping from "blah" to B. 294 Collection resources MAY have mappings to non-WebDAV compliant 295 resources in the HTTP URL namespace hierarchy but are not required 296 to do so. For example, if the resource X with URL 297 "http://example.com/bar/blah" is not WebDAV compliant and the 298 resource A with "URL http://example.com/bar/" identifies a 299 collection, then A may or may not have a mapping from "blah" to X. 301 (See also 302 ). 304 1.3. Method Preconditions and Postconditions 306 See Section 16 of [draft-ietf-webdav-rfc2518bis] for the definitions 307 of "precondition" and "postcondition". 309 2. Overview of Bindings 311 Bindings are part of the state of a collection. They define the 312 internal members of the collection, and the names of those internal 313 members. 315 Bindings are added and removed by a variety of existing HTTP methods. 316 A method that creates a new resource, such as PUT, COPY, and MKCOL, 317 adds a binding. A method that deletes a resource, such as DELETE, 318 removes a binding. A method that moves a resource (e.g. MOVE) both 319 adds a binding (in the destination collection) and removes a binding 320 (in the source collection). The BIND method introduced here provides 321 a mechanism for adding a second binding to an existing resource. 322 There is no difference between an initial binding added by PUT, COPY, 323 or MKCOL, and additional bindings added with BIND. 325 It would be very undesirable if one binding could be destroyed as a 326 side effect of operating on the resource through a different binding. 327 In particular, the removal of one binding to a resource (e.g. with a 328 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 329 e.g. by turning that binding into a dangling path segment. The 330 server MUST NOT reclaim system resources after removing one binding, 331 while other bindings to the resource remain. In other words, the 332 server MUST maintain the integrity of a binding. It is permissible, 333 however, for future method definitions (e.g., a DESTROY method) to 334 have semantics that explicitly remove all bindings and/or immediately 335 reclaim system resources. 337 2.1. Bindings to Collections 339 Creating a new binding to a collection makes each resource associated 340 with a binding in that collection accessible via a new URI, and thus 341 creates new URI mappings to those resources but no new bindings. 343 For example, suppose a new binding CollY is created for collection C1 344 in the figure below. It immediately becomes possible to access 345 resource R1 using the URI /CollY/x.gif and to access resource R2 346 using the URI /CollY/y.jpg, but no new bindings for these child 347 resources were created. This is because bindings are part of the 348 state of a collection, and associate a URI that is relative to that 349 collection with its target resource. No change to the bindings in 350 Collection C1 is needed to make its children accessible using /CollY/ 351 x.gif and /CollY/y.jpg. 353 +-------------------------+ 354 | Root Collection | 355 | bindings: | 356 | CollX CollY | 357 +-------------------------+ 358 | / 359 | / 360 | / 361 +------------------+ 362 | Collection C1 | 363 | bindings: | 364 | x.gif y.jpg | 365 +------------------+ 366 | \ 367 | \ 368 | \ 369 +-------------+ +-------------+ 370 | Resource R1 | | Resource R2 | 371 +-------------+ +-------------+ 373 2.1.1. Bind loops 375 Bindings to collections can result in loops, which servers MUST 376 detect when processing "Depth: infinity" requests. It is sometimes 377 possible to complete an operation in spite of the presence of a loop. 378 For instance, a PROPFIND can still succeed if the server uses the new 379 status code 208 (Already Reported) defined in Section 7.1. 381 However, the 506 (Loop Detected) status code is defined in 382 Section 7.2 for use in contexts where an operation is terminated 383 because a loop was encountered. 385 2.2. URI Mappings Created by a new Binding 387 Suppose a binding from "Binding-Name" to resource R is to be added to 388 a collection, C. Then if C-MAP is the set of URIs that were mapped to 389 C before the BIND request, then for each URI "C-URI" in C-MAP, the 390 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 391 request. 393 For example, if a binding from "foo.html" to R is added to a 394 collection C, and if the following URIs are mapped to C: 396 http://www.example.com/A/1/ 397 http://example.com/A/one/ 399 then the following new mappings to R are introduced: 401 http://www.example.com/A/1/foo.html 402 http://example.com/A/one/foo.html 404 Note that if R is a collection, additional URI mappings are created 405 to the descendents of R. Also, note that if a binding is made in 406 collection C to C itself (or to a parent of C), an infinite number of 407 mappings are introduced. 409 For example, if a binding from "myself" to C is then added to C, the 410 following infinite number of additional mappings to C are introduced: 412 http://www.example.com/A/1/myself 413 http://www.example.com/A/1/myself/myself 414 ... 416 and the following infinite number of additional mappings to R are 417 introduced: 419 http://www.example.com/A/1/myself/foo.html 420 http://www.example.com/A/1/myself/myself/foo.html 421 ... 423 2.3. COPY and Bindings 425 As defined in Section 9.8 of [draft-ietf-webdav-rfc2518bis], COPY 426 causes the resource identified by the Request-URI to be duplicated, 427 and makes the new resource accessible using the URI specified in the 428 Destination header. Upon successful completion of a COPY, a new 429 binding is created between the last path segment of the Destination 430 header, and the destination resource. The new binding is added to 431 its parent collection, identified by the Destination header minus its 432 final segment. 434 The following figure shows an example: Suppose that a COPY is issued 435 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 436 with the Destination header set to URI-X. After successful 437 completion of the COPY operation, resource R is duplicated to create 438 resource R', and a new binding has been created which creates at 439 least the URI mapping between URI-X and the new resource (although 440 other URI mappings may also have been created). 442 URI-1 URI-2 URI-3 URI-X 443 | | | | 444 | | | <---- URI Mappings ----> | 445 | | | | 446 +---------------------+ +------------------------+ 447 | Resource R | | Resource R' | 448 +---------------------+ +------------------------+ 450 It might be thought that a COPY request with "Depth: 0" on a 451 collection would duplicate its bindings, since bindings are part of 452 the collection's state. This is not the case, however. The 453 definition of Depth in [draft-ietf-webdav-rfc2518bis] makes it clear 454 that a "Depth: 0" request does not apply to a collection's members. 455 Consequently, a COPY with "Depth: 0" does not duplicate the bindings 456 contained by the collection. 458 If a COPY request causes an existing resource to be updated, the 459 bindings to that resource MUST be unaffected by the COPY request. 460 Using the preceding example, suppose that a COPY request is issued to 461 URI-X for resource R', with the Destination header set to URI-2. The 462 content and dead properties of resource R would be updated to be a 463 copy of those of resource R', but the mappings from URI-1, URI-2, and 464 URI-3 to resource R remain unaffected. If because of multiple 465 bindings to a resource, more than one source resource updates a 466 single destination resource, the order of the updates is server 467 defined. 469 If a COPY request would cause a new resource to be created as a copy 470 of an existing resource, and that COPY request has already created a 471 copy of that existing resource, the COPY request instead creates 472 another binding to the previous copy, instead of creating a new 473 resource. 475 2.3.1. Example: COPY with 'Depth: infinity' in presence of bind loops 477 As an example of how COPY with Depth infinity would work in the 478 presence of bindings, consider the following collection: 480 +------------------+ 481 | Root Collection | 482 | bindings: | 483 | CollX | 484 +------------------+ 485 | 486 | 487 +-------------------------------+ 488 | Collection C1 |<-------+ 489 | bindings: | | 490 | x.gif CollY | | 491 +-------------------------------+ | 492 | \ (creates loop) | 493 | \ | 494 +-------------+ +------------------+ | 495 | Resource R1 | | Collection C2 | | 496 +-------------+ | bindings: | | 497 | y.gif CollZ | | 498 +------------------+ | 499 | | | 500 | +--------+ 501 | 502 +-------------+ 503 | Resource R2 | 504 +-------------+ 506 If a COPY with Depth infinity is submitted to /CollX, with 507 destination of /CollA, the outcome of the copy operation is: 509 +------------------+ 510 | Root Collection | 511 | bindings: | 512 | CollX CollA | 513 +------------------+ 514 | | 515 | +---------------------------+ 516 | | 517 +-------------------+ | 518 | Collection C1 |<------------------+ | 519 | bindings: | | | 520 | x.gif CollY | | | 521 +-------------------+ | | 522 | \ (creates loop) | | 523 | \ | | 524 +-------------+ +-----------------+ | | 525 | Resource R1 | | Collection C2 | | | 526 +-------------+ | bindings: | | | 527 | y.gif CollZ | | | 528 +-----------------+ | | 529 | | | | 530 | +-------+ | 531 | | 532 +-------------+ | 533 | Resource R2 | | 534 +-------------+ | 535 | 536 +-------------------------------+ 537 | 538 +-------------------+ 539 | Collection C3 |<------------------+ 540 | bindings: | | 541 | x.gif CollY | | 542 +-------------------+ | 543 | \ (creates loop) | 544 | \ | 545 +-------------+ +-----------------+ | 546 | Resource R3 | | Collection C4 | | 547 +-------------+ | bindings: | | 548 | y.gif CollZ | | 549 +-----------------+ | 550 | | | 551 | +-------+ 552 | 553 +-------------+ 554 | Resource R4 | 555 +-------------+ 557 2.3.2. Example: COPY with 'Depth: infinity' with multiple bindings to a 558 leaf resource 560 Given the following collection hierarchy: 562 +------------------+ 563 | Root Collection | 564 | bindings: | 565 | CollX | 566 +------------------+ 567 | 568 | 569 | 570 +----------------+ 571 | Collection C1 | 572 | bindings: | 573 | x.gif y.gif | 574 +----------------+ 575 | | 576 | | 577 +-------------+ 578 | Resource R1 | 579 +-------------+ 581 A COPY of /CollX with Depth infinity to /CollY results in the 582 following collection hierarchy: 584 +------------------+ 585 | Root Collection | 586 | bindings: | 587 | CollX CollY | 588 +------------------+ 589 | \ 590 | \ 591 | \ 592 +----------------+ +-----------------+ 593 | Collection C1 | | Collection C2 | 594 | bindings: | | bindings: | 595 | x.gif y.gif | | x.gif y.gif | 596 +----------------+ +-----------------+ 597 | | | | 598 | | | | 599 +-------------+ +-------------+ 600 | Resource R1 | | Resource R2 | 601 +-------------+ +-------------+ 603 2.4. DELETE and Bindings 605 When there are multiple bindings to a resource, a DELETE applied to 606 that resource MUST NOT remove any bindings to that resource other 607 than the one identified by the Request-URI. For example, suppose the 608 collection identified by the URI "/a" has a binding named "x" to a 609 resource R, and another collection identified by "/b" has a binding 610 named "y" to the same resource R. Then a DELETE applied to "/a/x" 611 removes the binding named "x" from "/a" but MUST NOT remove the 612 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 613 to identify the resource R). 615 When DELETE is applied to a collection, it MUST NOT modify the 616 membership of any other collection that is not itself a member of the 617 collection being deleted. For example, if both "/a/.../x" and 618 "/b/.../y" identify the same collection, C, then applying DELETE to 619 "/a" must not delete an internal member from C or from any other 620 collection that is a member of C, because that would modify the 621 membership of "/b". 623 If a collection supports the UNBIND method (see Section 5), a DELETE 624 of an internal member of a collection MAY be implemented as an UNBIND 625 request. In this case, applying DELETE to a Request-URI has the 626 effect of removing the binding identified by the final segment of the 627 Request-URI from the collection identified by the Request-URI minus 628 its final segment. Although [draft-ietf-webdav-rfc2518bis] allows a 629 DELETE to be a non-atomic operation, when the DELETE operation is 630 implemented as an UNBIND, the operation is atomic. In particular, a 631 DELETE on a hierarchy of resources is simply the removal of a binding 632 to the collection identified by the Request-URI. 634 2.5. MOVE and Bindings 636 When MOVE is applied to a resource, the other bindings to that 637 resource MUST be unaffected, and if the resource being moved is a 638 collection, the bindings to any members of that collection MUST be 639 unaffected. Also, if MOVE is used with Overwrite:T to delete an 640 existing resource, the constraints specified for DELETE apply. 642 If the destination collection of a MOVE request supports the REBIND 643 method (see Section 6), a MOVE of a resource into that collection MAY 644 be implemented as a REBIND request. Although 645 [draft-ietf-webdav-rfc2518bis] allows a MOVE to be a non-atomic 646 operation, when the MOVE operation is implemented as a REBIND, the 647 operation is atomic. In particular, applying a MOVE to a Request-URI 648 and a Destination URI has the effect of removing a binding to a 649 resource (at the Request-URI), and creating a new binding to that 650 resource (at the Destination URI). Even when the Request-URI 651 identifies a collection, the MOVE operation involves only removing 652 one binding to that collection and adding another. 654 As an example, suppose that a MOVE is issued to URI-3 for resource R 655 below (which is also mapped to URI-1 and URI-2), with the Destination 656 header set to URI-X. After successful completion of the MOVE 657 operation, a new binding has been created which creates the URI 658 mapping between URI-X and resource R. The binding corresponding to 659 the final segment of URI-3 has been removed, which also causes the 660 URI mapping between URI-3 and R to be removed. If resource R were a 661 collection, old URI-3 based mappings to members of R would have been 662 removed, and new URI-X based mappings to members of R would have been 663 created. 665 >> Before Request: 667 URI-1 URI-2 URI-3 668 | | | 669 | | | <---- URI Mappings 670 | | | 671 +---------------------+ 672 | Resource R | 673 +---------------------+ 675 >> After Request: 677 URI-1 URI-2 URI-X 678 | | | 679 | | | <---- URI Mappings 680 | | | 681 +---------------------+ 682 | Resource R | 683 +---------------------+ 685 2.6. PROPFIND and Bindings 687 Consistent with [draft-ietf-webdav-rfc2518bis], the value of a dead 688 property MUST be independent of the number of bindings to its host 689 resource or of the path submitted to PROPFIND. On the other hand, 690 the behaviour for each live property depends on its individual 691 definition (for example, see [RFC3744], Section 5, paragraph 2). 693 2.7. Determining Whether Two Bindings Are to the Same Resource 695 It is useful to have some way of determining whether two bindings are 696 to the same resource. Two resources might have identical contents 697 and properties, but not be the same resource (e.g. an update to one 698 resource does not affect the other resource). 700 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 701 resource identifier, which MUST be unique across all resources for 702 all time. If the values of DAV:resource-id returned by PROPFIND 703 requests through two bindings are identical character by character, 704 the client can be assured that the two bindings are to the same 705 resource. 707 The DAV:resource-id property is created, and its value assigned, when 708 the resource is created. The value of DAV:resource-id MUST NOT be 709 changed. Even after the resource is no longer accessible through any 710 URI, that value MUST NOT be reassigned to another resource's DAV: 711 resource-id property. 713 Any method that creates a new resource MUST assign a new, unique 714 value to its DAV:resource-id property. For example, a PUT applied to 715 a null resource, COPY (when not overwriting an existing target) and 716 CHECKIN (see [RFC3253], Section 4.4) must assign a new, unique value 717 to the DAV:resource-id property of the new resource they create. 719 On the other hand, any method that affects an existing resource must 720 not change the value of its DAV:resource-id property. Specifically, 721 a PUT or a COPY that updates an existing resource must not change the 722 value of its DAV:resource-id property. A REBIND, since it does not 723 create a new resource, but only changes the location of an existing 724 resource, must not change the value of the DAV:resource-id property. 726 2.8. Discovering the Bindings to a Resource 728 An OPTIONAL DAV:parent-set property on a resource provides a list of 729 the bindings that associate a collection and a URI segment with that 730 resource. If the DAV:parent-set property exists on a given resource, 731 it MUST contain a complete list of all bindings to that resource that 732 the client is authorized to see. When deciding whether to support 733 the DAV:parent-set property, server implementers / administrators 734 should balance the benefits it provides against the cost of 735 maintaining the property and the security risks enumerated in 736 Sections 10.4 and 10.5. 738 3. Properties 740 The bind feature introduces the properties defined below. 742 A DAV:allprop PROPFIND request SHOULD NOT return any of the 743 properties defined by this document. This allows a binding server to 744 perform efficiently when a naive client, which does not understand 745 the cost of asking a server to compute all possible live properties, 746 issues a DAV:allprop PROPFIND request. 748 3.1. DAV:resource-id Property 750 The DAV:resource-id property is a REQUIRED property that enables 751 clients to determine whether two bindings are to the same resource. 752 The value of DAV:resource-id is a URI, and may use any registered URI 753 scheme that guarantees the uniqueness of the value across all 754 resources for all time (e.g. the urn:uuid: URN namespace defined in 755 [RFC4122] or the opaquelocktoken: URI scheme defined in 756 [draft-ietf-webdav-rfc2518bis]). 758 760 3.2. DAV:parent-set Property 762 The DAV:parent-set property is an OPTIONAL property that enables 763 clients to discover what collections contain a binding to this 764 resource (i.e. what collections have that resource as an internal 765 member). It contains an of href/segment pair for each collection 766 that has a binding to the resource. The href identifies the 767 collection, and the segment identifies the binding name of that 768 resource in that collection. 770 A given collection MUST appear only once in the DAV:parent-set for 771 any given binding, even if there are multiple URI mappings to that 772 collection. 774 775 776 777 780 3.2.1. Example for DAV:parent-set property 782 For example, if collection C1 is mapped to both /CollX and /CollY, 783 and C1 contains a binding named "x.gif" to a resource R1, then either 784 [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set 785 of R1, but not both. But if C1 also had a binding named "y.gif" to 786 R1, then there would be two entries for C1 in the DAV:binding-set of 787 R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, 788 both [/CollY, x.gif] and [/CollY, y.gif]). 790 +-------------------------+ 791 | Root Collection | 792 | bindings: | 793 | CollX CollY | 794 +-------------------------+ 795 | / 796 | / 797 | / 798 +-----------------+ 799 | Collection C1 | 800 | bindings: | 801 | x.gif y.gif | 802 +-----------------+ 803 | | 804 | | 805 | | 806 +--------------+ 807 | Resource R1 | 808 +--------------+ 810 In this case, one possible value for DAV:parent-set property on 811 "/CollX/x.gif" would be: 813 814 815 /CollX 816 x.gif 817 818 819 /CollX 820 y.gif 821 822 824 4. BIND Method 826 The BIND method modifies the collection identified by the Request- 827 URI, by adding a new binding from the segment specified in the BIND 828 body to the resource identified in the BIND body. 830 If a server cannot guarantee the integrity of the binding, the BIND 831 request MUST fail. Note that it is especially difficult to maintain 832 the integrity of cross-server bindings. Unless the server where the 833 resource resides knows about all bindings on all servers to that 834 resource, it may unwittingly destroy the resource or make it 835 inaccessible without notifying another server that manages a binding 836 to the resource. For example, if server A permits creation of a 837 binding to a resource on server B, server A must notify server B 838 about its binding and must have an agreement with B that B will not 839 destroy the resource while A's binding exists. Otherwise server B 840 may receive a DELETE request that it thinks removes the last binding 841 to the resource and destroy the resource while A's binding still 842 exists. The precondition DAV:cross-server-binding is defined below 843 for cases where servers fail cross-server BIND requests because they 844 cannot guarantee the integrity of cross-server bindings. 846 By default, if there already is a binding for the specified segment 847 in the collection, the new binding replaces the existing binding. 848 This default binding replacement behavior can be overridden using the 849 Overwrite header defined in Section 9.6 of 850 [draft-ietf-webdav-rfc2518bis]. 852 If a BIND request fails, the server state preceding the request MUST 853 be restored. This method is unsafe and idempotent (see [RFC2616], 854 Section 9.1). 856 Marshalling: 858 The request MAY include an Overwrite header. 860 The request body MUST be a DAV:bind XML element. 862 864 If the request succeeds, the server MUST return 201 (Created) when 865 a new binding was created and 200 (OK) when an existing binding 866 was replaced. 868 If a response body for a successful request is included, it MUST 869 be a DAV:bind-response XML element. Note that this document does 870 not define any elements for the BIND response body, but the DAV: 871 bind-response element is defined to ensure interoperability 872 between future extensions that do define elements for the BIND 873 response body. 875 877 Preconditions: 879 (DAV:bind-into-collection): The Request-URI MUST identify a 880 collection. 882 (DAV:bind-source-exists): The DAV:href element MUST identify a 883 resource. 885 (DAV:binding-allowed): The resource identified by the DAV:href 886 supports multiple bindings to it. 888 (DAV:cross-server-binding): If the resource identified by the DAV: 889 href element in the request body is on another server from the 890 collection identified by the Request-URI, the server MUST support 891 cross-server bindings. 893 (DAV:name-allowed): The name specified by the DAV:segment is 894 available for use as a new binding name. 896 (DAV:can-overwrite): If the collection already contains a binding 897 with the specified path segment, and if an Overwrite header is 898 included, the value of the Overwrite header MUST be "T". 900 (DAV:cycle-allowed): If the DAV:href element identifies a 901 collection, and if the Request-URI identifies a collection that is 902 a member of that collection, the server MUST support cycles in the 903 URI namespace. 905 (DAV:locked-update-allowed): If the collection identified by the 906 Request-URI is write-locked, then the appropriate token MUST be 907 specified in an If request header. 909 (DAV:locked-overwrite-allowed): If the collection already contains 910 a binding with the specified path segment, and if that binding is 911 protected by a write-lock, then the appropriate token MUST be 912 specified in an If request header. 914 Postconditions: 916 (DAV:new-binding): The collection MUST have a binding that maps 917 the segment specified in the DAV:segment element in the request 918 body, to the resource identified by the DAV:href element in the 919 request body. 921 4.1. Example: BIND 923 >> Request: 925 BIND /CollY HTTP/1.1 926 Host: www.example.com 927 Content-Type: text/xml; charset="utf-8" 928 Content-Length: xxx 930 931 932 bar.html 933 http://www.example.com/CollX/foo.html 934 936 >> Response: 938 HTTP/1.1 201 Created 940 The server added a new binding to the collection, 941 "http://www.example.com/CollY", associating "bar.html" with the 942 resource identified by the URI 943 "http://www.example.com/CollX/foo.html". Clients can now use the URI 944 "http://www.example.com/CollY/bar.html" to submit requests to that 945 resource. 947 5. UNBIND Method 949 The UNBIND method modifies the collection identified by the Request- 950 URI, by removing the binding identified by the segment specified in 951 the UNBIND body. 953 Once a resource is unreachable by any URI mapping, the server MAY 954 reclaim system resources associated with that resource. If UNBIND 955 removes a binding to a resource, but there remain URI mappings to 956 that resource, the server MUST NOT reclaim system resources 957 associated with the resource. 959 If an UNBIND request fails, the server state preceding the request 960 MUST be restored. This method is unsafe and idempotent (see 961 [RFC2616], Section 9.1). 963 Marshalling: 965 The request body MUST be a DAV:unbind XML element. 967 968 If the request succeeds, the server MUST return 200 (OK) when the 969 binding was successfully deleted. 971 If a response body for a successful request is included, it MUST 972 be a DAV:unbind-response XML element. Note that this document 973 does not define any elements for the UNBIND response body, but the 974 DAV:unbind-response element is defined to ensure interoperability 975 between future extensions that do define elements for the UNBIND 976 response body. 978 980 Preconditions: 982 (DAV:unbind-from-collection): The Request-URI MUST identify a 983 collection. 985 (DAV:unbind-source-exists): The DAV:segment element MUST identify 986 a binding in the collection identified by the Request-URI. 988 (DAV:locked-update-allowed): If the collection identified by the 989 Request-URI is write-locked, then the appropriate token MUST be 990 specified in the request. 992 (DAV:protected-url-deletion-allowed): If the binding identified by 993 the segment is protected by a write-lock, then the appropriate 994 token MUST be specified in the request. 996 Postconditions: 998 (DAV:binding-deleted): The collection MUST NOT have a binding for 999 the segment specified in the DAV:segment element in the request 1000 body. 1002 (DAV:lock-deleted): If the internal member URI of the binding 1003 specified by the Request-URI and the DAV:segment element in the 1004 request body was protected by a write-lock at the time of the 1005 request, that write-lock must have been deleted by the request. 1007 5.1. Example: UNBIND 1009 >> Request: 1011 UNBIND /CollX HTTP/1.1 1012 Host: www.example.com 1013 Content-Type: text/xml; charset="utf-8" 1014 Content-Length: xxx 1016 1017 1018 foo.html 1019 1021 >> Response: 1023 HTTP/1.1 200 OK 1025 The server removed the binding named "foo.html" from the collection, 1026 "http://www.example.com/CollX". A request to the resource named 1027 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 1028 response. 1030 6. REBIND Method 1032 The REBIND method removes a binding to a resource from a collection, 1033 and adds a binding to that resource into the collection identified by 1034 the Request-URI. The request body specifies the binding to be added 1035 (segment) and the old binding to be removed (href). It is 1036 effectively an atomic form of a MOVE request, and MUST be treated the 1037 same way as MOVE for the purpose of determining access permissions. 1039 If a REBIND request fails, the server state preceding the request 1040 MUST be restored. This method is unsafe and idempotent (see 1041 [RFC2616], Section 9.1). 1043 Marshalling: 1045 The request MAY include an Overwrite header. 1047 The request body MUST be a DAV:rebind XML element. 1049 1051 If the request succeeds, the server MUST return 201 (Created) when 1052 a new binding was created and 200 (OK) when an existing binding 1053 was replaced. 1055 If a response body for a successful request is included, it MUST 1056 be a DAV:rebind-response XML element. Note that this document 1057 does not define any elements for the REBIND response body, but the 1058 DAV:rebind-response element is defined to ensure interoperability 1059 between future extensions that do define elements for the REBIND 1060 response body. 1062 1064 Preconditions: 1066 (DAV:rebind-into-collection): The Request-URI MUST identify a 1067 collection. 1069 (DAV:rebind-source-exists): The DAV:href element MUST identify a 1070 resource. 1072 (DAV:cross-server-binding): If the resource identified by the DAV: 1073 href element in the request body is on another server from the 1074 collection identified by the Request-URI, the server MUST support 1075 cross-server bindings. 1077 (DAV:name-allowed): The name specified by the DAV:segment is 1078 available for use as a new binding name. 1080 (DAV:can-overwrite): If the collection already contains a binding 1081 with the specified path segment, and if an Overwrite header is 1082 included, the value of the Overwrite header MUST be "T". 1084 (DAV:cycle-allowed): If the DAV:href element identifies a 1085 collection, and if the Request-URI identifies a collection that is 1086 a member of that collection, the server MUST support cycles in the 1087 URI namespace. 1089 (DAV:locked-update-allowed): If the collection identified by the 1090 Request-URI is write-locked, then the appropriate token MUST be 1091 specified in the request. 1093 (DAV:protected-url-modification-allowed): If the collection 1094 identified by the Request-URI already contains a binding with the 1095 specified path segment, and if that binding is protected by a 1096 write-lock, then the appropriate token MUST be specified in the 1097 request. 1099 (DAV:locked-source-collection-update-allowed): If the collection 1100 identified by the parent collection prefix of the DAV:href URI is 1101 write-locked, then the appropriate token MUST be specified in the 1102 request. 1104 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 1105 is protected by a write lock, then the appropriate token MUST be 1106 specified in the request. 1108 Postconditions: 1110 (DAV:new-binding): The collection MUST have a binding that maps 1111 the segment specified in the DAV:segment element in the request 1112 body, to the resource that was identified by the DAV:href element 1113 in the request body. 1115 (DAV:binding-deleted): The URL specified in the DAV:href element 1116 in the request body MUST NOT be mapped to a resource. 1118 (DAV:lock-deleted): If the URL specified in the DAV:href element 1119 in the request body was protected by a write-lock at the time of 1120 the request, that write-lock must have been deleted by the 1121 request. 1123 6.1. Example: REBIND 1125 >> Request: 1127 REBIND /CollX HTTP/1.1 1128 Host: www.example.com 1129 Content-Type: text/xml; charset="utf-8" 1130 Content-Length: xxx 1132 1133 1134 foo.html 1135 http://www.example.com/CollY/bar.html 1136 1138 >> Response: 1140 HTTP/1.1 200 OK 1142 The server added a new binding to the collection, 1143 "http://www.example.com/CollX", associating "foo.html" with the 1144 resource identified by the URI 1145 "http://www.example.com/CollY/bar.html", and removes the binding 1146 named "bar.html" from the collection identified by the URI 1147 "http://www.example.com/CollY". Clients can now use the URI 1148 "http://www.example.com/CollX/foo.html" to submit requests to that 1149 resource, and requests on the URI 1150 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 1151 Found) response. 1153 6.2. Example: REBIND in presence of locks and bind loops 1155 To illustrate the effects of locks and bind loops on a REBIND 1156 operation, consider the following collection: 1158 +------------------+ 1159 | Root Collection | 1160 | bindings: | 1161 | CollW | 1162 +------------------+ 1163 | 1164 | 1165 | 1166 +-------------------------------+ 1167 | Collection C1 |<--------+ 1168 | LOCKED infinity | | 1169 | (lock token L1) | | 1170 | bindings: | | 1171 | CollX CollY | | 1172 +-------------------------------+ | 1173 | | | 1174 | | (creates loop) | 1175 | | | 1176 +-----------------+ +------------------+ | 1177 | Collection C2 | | Collection C3 | | 1178 | (inherit lock) | | (inherit lock) | | 1179 | (lock token L1) | | (lock token L1) | | 1180 | bindings: | | bindings: | | 1181 | {none} | | y.gif CollZ | | 1182 +-----------------+ +------------------+ | 1183 | | | 1184 | +-----+ 1185 | 1186 +---------------------------+ 1187 | Resource R2 | 1188 | (lock inherited from C1) | 1189 | (lock token L1) | 1190 +---------------------------+ 1192 (where L1 is "opaquelocktoken:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). 1194 Note that the binding between CollZ and C1 creates a loop in the 1195 containment hierarchy. Servers are not required to support such 1196 loops, though the server in this example does. 1198 The REBIND request below will remove the segment "CollZ" from C3 and 1199 add a new binding from "CollA" to the collection C2. 1201 REBIND /CollW/CollX HTTP/1.1 1202 Host: www.example.com 1203 If: () 1204 Content-Type: text/xml; charset="utf-8" 1205 Content-Length: xxx 1207 1208 1209 CollA 1210 /CollW/CollY/CollZ 1211 1212 The outcome of the REBIND operation is: 1214 +------------------+ 1215 | Root Collection | 1216 | bindings: | 1217 | CollW | 1218 +------------------+ 1219 | 1220 | 1221 | 1222 +-------------------------------+ 1223 | Collection C1 | 1224 | LOCKED infinity | 1225 | (lock token L1) | 1226 | bindings: | 1227 | CollX CollY | 1228 +-------------------------------+ 1229 | ^ | 1230 | | | 1231 +-----------------+ | +------------------+ 1232 | Collection C2 | | | Collection C3 | 1233 |(inherited lock) | | | (inherited lock) | 1234 |(lock token L1) | | | (lock token L1) | 1235 | bindings: | | | bindings: | 1236 | CollA | | | y.gif | 1237 +-----------------+ | +------------------+ 1238 | | | 1239 +---------------+ | 1240 (creates loop) | 1241 +---------------------------+ 1242 | Resource R2 | 1243 | (inherited lock from C1) | 1244 | (lock token L1) | 1245 +---------------------------+ 1247 7. Additional Status Codes 1249 7.1. 208 Already Reported 1251 The 208 (Already Reported) status code can be used inside a DAV: 1252 propstat response element to avoid enumerating the internal members 1253 of multiple bindings to the same collection repeatedly. For each 1254 binding to a collection inside the request's scope, only one will be 1255 reported with a 200 status, while subsequent DAV:response elements 1256 for all other bindings will use the 208 status, and no DAV:response 1257 elements for their descendants are included. 1259 Note that the 208 status will only occur for "Depth: infinity" 1260 requests, and that it is of particular importance when the multiple 1261 collection bindings cause a bind loop as discussed in Section 2.2. 1263 A client can request the DAV:resource-id property in a PROPFIND 1264 request to guarantee that they can accurately reconstruct the binding 1265 structure of a collection with multiple bindings to a single 1266 resource. 1268 For backward compatibility with clients not aware of the 208 status 1269 code appearing in multistatus response bodies, it SHOULD NOT be used 1270 unless the client has signalled support for this specification using 1271 the "DAV" request header (see Section 8.2). Instead, a 506 status 1272 should be returned when a binding loop is discovered. This allows 1273 the server to return the 506 as the top level return status, if it 1274 discovers it before it started the response, or in the middle of a 1275 multistatus, if it discovers it in the middle of streaming out a 1276 multistatus response. 1278 7.1.1. Example: PROPFIND by bind-aware client 1280 For example, consider a PROPFIND request on /Coll (bound to 1281 collection C), where the members of /Coll are /Coll/Foo (bound to 1282 resource R) and /Coll/Bar (bound to collection C). 1284 >> Request: 1286 PROPFIND /Coll/ HTTP/1.1 1287 Host: www.example.com 1288 Depth: infinity 1289 DAV: bind 1290 Content-Type: text/xml; charset="utf-8" 1291 Content-Length: xxx 1293 1294 1295 1296 1297 1298 1299 1301 >> Response: 1303 HTTP/1.1 207 Multi-Status 1304 Content-Type: text/xml; charset="utf-8" 1305 Content-Length: xxx 1307 1308 1309 1310 http://www.example.com/Coll/ 1311 1312 1313 Loop Demo 1314 1315 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1317 1318 1319 HTTP/1.1 200 OK 1320 1321 1322 1323 http://www.example.com/Coll/Foo 1324 1325 1326 Bird Inventory 1327 1328 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1330 1331 1332 HTTP/1.1 200 OK 1333 1334 1335 1336 http://www.example.com/Coll/Bar 1337 1338 1339 Loop Demo 1340 1341 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1343 1344 1345 HTTP/1.1 208 Already Reported 1346 1347 1348 1350 7.1.2. Example: PROPFIND by non-bind-aware client 1352 In this example, the client isn't aware of the 208 status code 1353 introduced by this specification. As the "Depth: infinity" PROPFIND 1354 request would cause a loop condition, the whole request is rejected 1355 with a 506 status. 1357 >> Request: 1359 PROPFIND /Coll/ HTTP/1.1 1360 Host: www.example.com 1361 Depth: infinity 1362 Content-Type: text/xml; charset="utf-8" 1363 Content-Length: xxx 1365 1366 1367 1368 1370 >> Response: 1372 HTTP/1.1 506 Loop Detected 1374 7.2. 506 Loop Detected 1376 The 506 (Loop Detected) status code indicates that the server 1377 terminated an operation because it encountered an infinite loop while 1378 processing a request with "Depth: infinity". This status indicates 1379 that the entire operation failed. 1381 8. Capability discovery 1383 8.1. OPTIONS method 1385 If the server supports bindings, it MUST return the compliance class 1386 name "bind" as a field in the "DAV" response header (see 1387 [draft-ietf-webdav-rfc2518bis], Section 10.1) from an OPTIONS request 1388 on any resource implemented by that server. A value of "bind" in the 1389 "DAV" header MUST indicate that the server supports all MUST level 1390 requirements and REQUIRED features specified in this document. 1392 8.2. 'DAV' request header 1394 Clients SHOULD signal support for all MUST level requirements and 1395 REQUIRED features by submitting a "DAV" request header containing the 1396 compliance class name "bind". In particular, the client MUST 1397 understand the 208 status code defined in Section 7.1. 1399 9. Relationship to WebDAV Access Control Protocol 1401 BIND and REBIND behave the same as MOVE with respect to the DAV:acl 1402 property (see [RFC3744], Section 7.3). 1404 10. Security Considerations 1406 This section is provided to make WebDAV implementors aware of the 1407 security implications of this protocol. 1409 All of the security considerations of HTTP/1.1 and the WebDAV 1410 Distributed Authoring Protocol specification also apply to this 1411 protocol specification. In addition, bindings introduce several new 1412 security concerns and increase the risk of some existing threats. 1413 These issues are detailed below. 1415 10.1. Privacy Concerns 1417 In a context where cross-server bindings are supported, creating 1418 bindings on a trusted server may make it possible for a hostile agent 1419 to induce users to send private information to a target on a 1420 different server. 1422 10.2. Bind Loops 1424 Although bind loops were already possible in HTTP 1.1, the 1425 introduction of the BIND method creates a new avenue for clients to 1426 create loops accidentally or maliciously. If the binding and its 1427 target are on the same server, the server may be able to detect BIND 1428 requests that would create loops. Servers are required to detect 1429 loops that are caused by bindings to collections during the 1430 processing of any requests with "Depth: infinity". 1432 10.3. Bindings, and Denial of Service 1434 Denial of service attacks were already possible by posting URIs that 1435 were intended for limited use at heavily used Web sites. The 1436 introduction of BIND creates a new avenue for similar denial of 1437 service attacks. If cross-server bindings are supported, clients can 1438 now create bindings at heavily used sites to target locations that 1439 were not designed for heavy usage. 1441 10.4. Private Locations May Be Revealed 1443 If the DAV:parent-set property is maintained on a resource, the 1444 owners of the bindings risk revealing private locations. The 1445 directory structures where bindings are located are available to 1446 anyone who has access to the DAV:parent-set property on the resource. 1447 Moving a binding may reveal its new location to anyone with access to 1448 DAV:parent-set on its resource. 1450 10.5. DAV:parent-set and Denial of Service 1452 If the server maintains the DAV:parent-set property in response to 1453 bindings created in other administrative domains, it is exposed to 1454 hostile attempts to make it devote resources to adding bindings to 1455 the list. 1457 11. Internationalization Considerations 1459 All internationalization considerations mentioned in 1460 [draft-ietf-webdav-rfc2518bis] also apply to this document. 1462 12. IANA Considerations 1464 All IANA considerations mentioned in [draft-ietf-webdav-rfc2518bis] 1465 also apply to this document. 1467 13. Acknowledgements 1469 This document is the collaborative product of the authors and Tyson 1470 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has 1471 benefited from thoughtful discussion by Jim Amsden, Peter Carlson, 1472 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, 1473 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa 1474 Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe 1475 Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris 1476 Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel 1477 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1478 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, 1479 John Stracke, John Tigue, John Turner, Kevin Wiggen, and other 1480 members of the WebDAV working group. 1482 14. References 1483 14.1. Normative References 1485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1486 Requirement Levels", BCP 14, RFC 2119, March 1997. 1488 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1489 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1490 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1492 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1493 Resource Identifier (URI): Generic Syntax", STD 66, 1494 RFC 3986, January 2005. 1496 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1497 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1498 Edition)", W3C REC-xml-20040204, February 2004, 1499 . 1501 [draft-ietf-webdav-rfc2518bis] 1502 Dusseault, L., Ed., "HTTP Extensions for Distributed 1503 Authoring - WebDAV RFC2518 bis", 1504 draft-ietf-webdav-rfc2518bis-12 (work in progress), 1505 February 2006, . 1508 14.2. Informative References 1510 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1511 Whitehead, "Versioning Extensions to WebDAV (Web 1512 Distributed Authoring and Versioning)", RFC 3253, 1513 March 2002. 1515 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1516 Distributed Authoring and Versioning (WebDAV) Access 1517 Control Protocol", RFC 3744, May 2004. 1519 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1520 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1521 July 2005. 1523 Appendix A. Change Log (to be removed by RFC Editor before publication) 1525 A.1. Since draft-ietf-webdav-bind-02 1527 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1528 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1529 resolution, but keep it open. Add issues "ED_references" and 1530 "4_507_status". Started work on index. Rename document to "Binding 1531 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1532 Rename "References" to "Normative References". Close issue 1533 "ED_references". Close issue "4_507_status". 1535 A.2. Since draft-ietf-webdav-bind-03 1537 Add and close issues "9.2_redirect_loops", "ED_authors" and 1538 "ED_updates". Add section about capability discovery (DAV header). 1539 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1540 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1541 "locking" and resolve as invalid. 1543 A.3. Since draft-ietf-webdav-bind-04 1545 Add and close issues "6_precondition_binding_allowed" and 1546 "6_lock_behaviour". Add mailing list and issues list pointers to 1547 front. 1549 A.4. Since draft-ietf-webdav-bind-05 1551 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1552 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1553 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1555 A.5. Since draft-ietf-webdav-bind-06 1557 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1558 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1560 A.6. Since draft-ietf-webdav-bind-07 1562 Add more index items (no change tracking). Add and resolve issues 1563 "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", 1564 "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML 1565 DTD fragment in section 3.3. Make spelling of "Request-URI" 1566 consistent. 1568 A.7. Since draft-ietf-webdav-bind-08 1570 Resolved editorial issues raised by Jim Whitehead in . 1572 Add and resolve issues "atomicity", "2_allow_destroy", 1573 "2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", 1574 "2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops", 1575 "2.6_resource-id_vs_versions", "3.2_example" and 1576 "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open 1577 and resolve "6_rebind_intro". 1579 A.8. Since draft-ietf-webdav-bind-09 1581 Add and resolve issue "6.1_rebind_vs_locks", adding proposed example 1582 text. Add action item "3.1_uuids". Close issue 1583 "2.6_when_do_ids_change". Add and resolve issues 1584 "2.6_bindings_vs_properties" and "uri_draft_ref". 1586 A.9. Since draft-ietf-webdav-bind-10 1588 Resolve action item "3.1_uuids". Add and resolve issue 1589 "2.7_unlock_vs_bindings". Revisit issue 1590 "2.6_bindings_vs_properties", and remove the part of the sentence 1591 that speaks about live properties. Update "rfc2396bis" references to 1592 "RFC3986". Add issue "9_ns_op_and_acl" and add potential resolution. 1593 Align artwork where applicable (new xml2rfc1.29rc2 feature). 1595 A.10. Since draft-ietf-webdav-bind-11 1597 Updated [draft-mealling-uuid-urn] to [RFC4122]. Add statement about 1598 live properties in Section 2.6. 1600 A.11. Since draft-ietf-webdav-bind-12 1602 Updated Author's address. Uppercase "Section" when referring to 1603 other documents. 1605 Updating from RFC2518 to RFC2518bis: 1607 o Remove own explanation of DTD syntax. 1609 o Remove own definition of precondition/postcondition. 1611 o Remove reference to broken RFC2518 language about DELETE and 1612 UNLOCK. 1614 o Remove own definition of DAV: request header. 1616 o Updated Section 1.2 to reflect the changes in 1617 [draft-ietf-webdav-rfc2518bis], making proposals for more changes 1618 so that the issue can be closed (see also 1619 and < 1620 http://greenbytes.de/tech/webdav/ 1621 draft-ietf-webdav-rfc2518bis-12.html#rfc.section.5.2>). 1623 Appendix B. Resolved issues (to be removed by RFC Editor before 1624 publication) 1626 Issues that were either rejected or resolved in this version of this 1627 document. 1629 B.1. ED_updates 1631 Type: edit 1633 1636 julian.reschke@greenbytes.de (2003-12-30): Shouldn't the BIND spec be 1637 labelled as "updating" RFC2518 and/or RFC3253? 1639 julian.reschke@greenbytes.de (2004-01-05): It seems that there was 1640 consensus to say that BIND does update RFC2518, while there's no 1641 consensus about the relationship to RFC3253. As this is a minor 1642 editorial question, I propose to just say "updated 2518" and to close 1643 the issue. 1645 Resolution (2006-02-07): Previously: State "updates 2518". Changed 1646 to: "updated draft-ietf-webdav-rfc2518bis". 1648 Appendix C. Open issues (to be removed by RFC Editor prior to 1649 publication) 1651 C.1. edit 1653 Type: edit 1655 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1656 editorial fixes/enhancements. 1658 C.2. webdav-rev 1660 Type: edit 1662 julian.reschke@greenbytes.de (2006-01-30): Update from RFC2518 to 1663 RFC2518bis. 1665 Resolution (2006-02-07): Partly resolved: removed own explanation of 1666 DTD syntax, removed own definition of precondition/postcondition, 1667 removed reference to broken RFC2518 language about DELETE and UNLOCK, 1668 removed own definition of DAV: request header, updated "Rationale for 1669 Distinguishing Bindings from URI Mappings" to reflect the changes in 1670 draft-ietf-webdav-rfc2518bis-12, making proposals for more changes so 1671 that the issue can be closed (see also 1672 and ). 1676 Index 1678 2 1679 208 Already Reported (status code) 28 1681 5 1682 506 Loop Detected (status code) 31 1684 B 1685 BIND method 18 1686 Binding 6 1688 C 1689 Collection 6 1690 Condition Names 1691 DAV:bind-into-collection (pre) 19 1692 DAV:bind-source-exists (pre) 19 1693 DAV:binding-allowed (pre) 20 1694 DAV:binding-deleted (post) 22, 25 1695 DAV:can-overwrite (pre) 20, 24 1696 DAV:cross-server-binding (pre) 20, 24 1697 DAV:cycle-allowed (pre) 20, 24 1698 DAV:lock-deleted (post) 22, 25 1699 DAV:locked-overwrite-allowed (pre) 20 1700 DAV:locked-source-collection-update-allowed (pre) 24 1701 DAV:locked-update-allowed (pre) 20, 22, 24 1702 DAV:name-allowed (pre) 20, 24 1703 DAV:new-binding (post) 20, 25 1704 DAV:protected-source-url-deletion-allowed (pre) 25 1705 DAV:protected-url-deletion-allowed (pre) 22 1706 DAV:protected-url-modification-allowed (pre) 24 1707 DAV:rebind-from-collection (pre) 24 1708 DAV:rebind-source-exists (pre) 24 1709 DAV:unbind-from-collection (pre) 22 1710 DAV:unbind-source-exists (pre) 22 1712 D 1713 DAV header 1714 compliance class 'bind' 31 1715 DAV:bind-into-collection precondition 19 1716 DAV:bind-source-exists precondition 19 1717 DAV:binding-allowed precondition 20 1718 DAV:binding-deleted postcondition 22, 25 1719 DAV:can-overwrite precondition 20, 24 1720 DAV:cross-server-binding precondition 20, 24 1721 DAV:cycle-allowed precondition 20, 24 1722 DAV:lock-deleted postcondition 22, 25 1723 DAV:locked-overwrite-allowed precondition 20 1724 DAV:locked-source-collection-update-allowed precondition 24 1725 DAV:locked-update-allowed precondition 20, 22, 24 1726 DAV:name-allowed precondition 20, 24 1727 DAV:new-binding postcondition 20, 25 1728 DAV:parent-set property 17 1729 DAV:protected-source-url-deletion-allowed precondition 25 1730 DAV:protected-url-deletion-allowed precondition 22 1731 DAV:protected-url-modification-allowed precondition 24 1732 DAV:rebind-from-collection precondition 24 1733 DAV:rebind-source-exists precondition 24 1734 DAV:resource-id property 17 1735 DAV:unbind-from-collection precondition 22 1736 DAV:unbind-source-exists precondition 22 1738 I 1739 Internal Member URI 6 1741 M 1742 Methods 1743 BIND 18 1744 REBIND 23 1745 UNBIND 21 1747 P 1748 Path Segment 6 1749 Properties 1750 DAV:parent-set 17 1751 DAV:resource-id 17 1753 R 1754 REBIND method 23 1756 S 1757 Status Codes 1758 208 Already Reported 28 1759 506 Loop Detected 31 1761 U 1762 UNBIND method 21 1763 URI Mapping 5 1765 Authors' Addresses 1767 Geoffrey Clemm 1768 IBM 1769 20 Maguire Road 1770 Lexington, MA 02421 1772 Email: geoffrey.clemm@us.ibm.com 1774 Jason Crawford 1775 IBM Research 1776 P.O. Box 704 1777 Yorktown Heights, NY 10598 1779 Email: ccjason@us.ibm.com 1781 Julian F. Reschke 1782 greenbytes GmbH 1783 Hafenweg 16 1784 Muenster, NW 48155 1785 Germany 1787 Email: julian.reschke@greenbytes.de 1789 Jim Whitehead 1790 UC Santa Cruz, Dept. of Computer Science 1791 1156 High Street 1792 Santa Cruz, CA 95064 1794 Email: ejw@cse.ucsc.edu 1796 Intellectual Property Statement 1798 The IETF takes no position regarding the validity or scope of any 1799 Intellectual Property Rights or other rights that might be claimed to 1800 pertain to the implementation or use of the technology described in 1801 this document or the extent to which any license under such rights 1802 might or might not be available; nor does it represent that it has 1803 made any independent effort to identify any such rights. Information 1804 on the procedures with respect to rights in RFC documents can be 1805 found in BCP 78 and BCP 79. 1807 Copies of IPR disclosures made to the IETF Secretariat and any 1808 assurances of licenses to be made available, or the result of an 1809 attempt made to obtain a general license or permission for the use of 1810 such proprietary rights by implementers or users of this 1811 specification can be obtained from the IETF on-line IPR repository at 1812 http://www.ietf.org/ipr. 1814 The IETF invites any interested party to bring to its attention any 1815 copyrights, patents or patent applications, or other proprietary 1816 rights that may cover technology that may be required to implement 1817 this standard. Please address the information to the IETF at 1818 ietf-ipr@ietf.org. 1820 Disclaimer of Validity 1822 This document and the information contained herein are provided on an 1823 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1824 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1825 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1826 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1827 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1828 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1830 Copyright Statement 1832 Copyright (C) The Internet Society (2006). This document is subject 1833 to the rights, licenses and restrictions contained in BCP 78, and 1834 except as set forth therein, the authors retain all their rights. 1836 Acknowledgment 1838 Funding for the RFC Editor function is currently provided by the 1839 Internet Society.