RFC 5842 - Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)

This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created.¶

2. Overview of Bindings

Bindings are part of the state of a collection. They define the internal members of the collection and the names of those internal members.¶

Bindings are added and removed by a variety of existing HTTP methods. A method that creates a new resource, such as PUT, COPY, and MKCOL, adds a binding. A method that deletes a resource, such as DELETE, removes a binding. A method that moves a resource (e.g., MOVE) both adds a binding (in the destination collection) and removes a binding (in the source collection). The BIND method introduced here provides a mechanism for adding a second binding to an existing resource. There is no difference between an initial binding added by PUT, COPY, or MKCOL and additional bindings added with BIND.¶

It would be very undesirable if one binding could be destroyed as a side effect of operating on the resource through a different binding. In particular, the removal of one binding to a resource (e.g., with a DELETE or a MOVE) MUST NOT disrupt another binding to that resource, e.g., by turning that binding into a dangling path segment. The server MUST NOT reclaim system resources after removing one binding, while other bindings to the resource remain. In other words, the server MUST maintain the integrity of a binding. It is permissible, however, for future method definitions (e.g., a DESTROY method) to have semantics that explicitly remove all bindings and/or immediately reclaim system resources.¶

2.1. Bindings to Collections

Creating a new binding to a collection makes each resource associated with a binding in that collection accessible via a new URI, and thus creates new URI mappings to those resources but no new bindings.¶

For example, suppose a new binding CollY is created for collection C1 in the figure below. It immediately becomes possible to access resource R1 using the URI /CollY/x.gif and to access resource R2 using the URI /CollY/y.jpg, but no new bindings for these child resources were created. This is because bindings are part of the state of a collection, and they associate a URI that is relative to that collection with its target resource. No change to the bindings in Collection C1 is needed to make its children accessible using /CollY/x.gif and /CollY/y.jpg.¶

┌─────────────────────────┐
│ Root Collection         │
│  bindings:              │
│  CollX          CollY   │
└─────────────────────────┘
    |            /          
    |           /
    |          /
┌──────────────────┐
│ Collection C1    │
│ bindings:        │
│ x.gif     y.jpg  │
└──────────────────┘
    |          \               
    |           \               
    |            \              
┌─────────────┐   ┌─────────────┐
│ Resource R1 │   │ Resource R2 │
└─────────────┘   └─────────────┘

2.1.1. Bind Loops

Bindings to collections can result in loops ("cycles"), which servers MUST detect when processing "Depth: infinity" requests. It is sometimes possible to complete an operation in spite of the presence of a loop. For instance, a PROPFIND can still succeed if the server uses the new status code 208 (Already Reported) defined in Section 7.1.¶

However, the 508 (Loop Detected) status code is defined in Section 7.2 for use in contexts where an operation is terminated because a loop was encountered.¶

Support for loops is OPTIONAL: servers MAY reject requests that would lead to the creation of a bind loop (see DAV:cycle-allowed precondition defined in Section 4).¶

2.2. URI Mappings Created by a New Binding

Suppose a binding from "Binding-Name" to resource R is to be added to a collection, C. Then if C-MAP is the set of URIs that were mapped to C before the BIND request, then for each URI "C-URI" in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R following the BIND request.¶

For example, if a binding from "foo.html" to R is added to a collection C, and if the following URIs are mapped to C:

http://www.example.com/A/1/
http://example.com/A/one/

then the following new mappings to R are introduced:

http://www.example.com/A/1/foo.html
http://example.com/A/one/foo.html

Note that if R is a collection, additional URI mappings are created to the descendents of R. Also, note that if a binding is made in collection C to C itself (or to a parent of C), an infinite number of mappings are introduced.¶

For example, if a binding from "myself" to C is then added to C, the following infinite number of additional mappings to C are introduced:

http://www.example.com/A/1/myself
http://www.example.com/A/1/myself/myself
   ...

and the following infinite number of additional mappings to R are introduced:

http://www.example.com/A/1/myself/foo.html
http://www.example.com/A/1/myself/myself/foo.html
   ...

2.3. COPY and Bindings

As defined in Section 9.8 of [RFC4918], COPY causes the resource identified by the Request-URI to be duplicated and makes the new resource accessible using the URI specified in the Destination header. Upon successful completion of a COPY, a new binding is created between the last path segment of the Destination header and the destination resource. The new binding is added to its parent collection, identified by the Destination header minus its final segment.¶

The following figure shows an example: suppose that a COPY is issued to URI-3 for resource R (which is also mapped to URI-1 and URI-2), with the Destination header set to URI-X. After successful completion of the COPY operation, resource R is duplicated to create resource R', and a new binding has been created that creates at least the URI mapping between URI-X and the new resource (although other URI mappings may also have been created).

URI-1   URI-2    URI-3                           URI-X
   |       |        |                              |
   |       |        |   <---- URI Mappings ---->   |
   |       |        |                              |
┌─────────────────────┐                 ┌────────────────────────┐
│     Resource R      │                 │     Resource R'        │
└─────────────────────┘                 └────────────────────────┘

It might be thought that a COPY request with "Depth: 0" on a collection would duplicate its bindings, since bindings are part of the collection's state. This is not the case, however. The definition of Depth in [RFC4918] makes it clear that a "Depth: 0" request does not apply to a collection's members. Consequently, a COPY with "Depth: 0" does not duplicate the bindings contained by the collection.¶

If a COPY request causes an existing resource to be updated, the bindings to that resource MUST be unaffected by the COPY request. Using the preceding example, suppose that a COPY request is issued to URI-X for resource R', with the Destination header set to URI-2. The content and dead properties of resource R would be updated to be a copy of those of resource R', but the mappings from URI-1, URI-2, and URI-3 to resource R remain unaffected. If, because of multiple bindings to a resource, more than one source resource updates a single destination resource, the order of the updates is server defined (see Section 2.3.2 for an example).¶

If a COPY request would cause a new resource to be created as a copy of an existing resource, and that COPY request has already created a copy of that existing resource, the COPY request instead creates another binding to the previous copy, instead of creating a new resource (see Section 2.3.3 for an example).¶

2.3.1. Example: COPY with "Depth: infinity" in Presence of Bind Loops

As an example of how COPY with "Depth: infinity" would work in the presence of bindings, consider the following collection:

┌──────────────────┐
│ Root Collection  │
│  bindings:       │
│  CollX           │
└──────────────────┘
    |
    |
┌───────────────────────────────┐
│ Collection C1                 │<-------+
│ bindings:                     │        |
│ x.gif      CollY              │        |
└───────────────────────────────┘        |
    |            \        (creates loop) |
    |             \                      |
┌─────────────┐   ┌──────────────────┐   |
│ Resource R1 │   │ Collection C2    │   |
└─────────────┘   │ bindings:        │   |
                  │ y.gif     CollZ  │   |
                  └──────────────────┘   |
                      |         |        |
                      |         +--------+
                      |
                  ┌─────────────┐
                  │ Resource R2 │
                  └─────────────┘

If a COPY request with "Depth: infinity" is submitted to /CollX, with a destination of /CollA, the outcome of the copy operation is that a copy of the tree is replicated to the target /CollA:

┌──────────────────┐
│ Root Collection  │
│  bindings:       │
│  CollX     CollA │
└──────────────────┘
   |           |
   |           +---------------------------+
   |                                       |
┌───────────────────┐                      |
│ Collection C1     │<------------------+  |
│ bindings:         │                   |  |
│ x.gif      CollY  │                   |  |
└───────────────────┘                   |  |
   |            \        (creates loop) |  |
   |             \                      |  |
┌─────────────┐   ┌─────────────────┐   |  |
│ Resource R1 │   │ Collection C2   │   |  |
└─────────────┘   │ bindings:       │   |  |
                  │ y.gif     CollZ │   |  |
                  └─────────────────┘   |  |
                      |         |       |  |
                      |         +-------+  |
                      |                    |
                  ┌─────────────┐          |
                  │ Resource R2 │          |
                  └─────────────┘          |
                                           |
           +-------------------------------+
           |
┌───────────────────┐
│ Collection C3     │<------------------+
│ bindings:         │                   |
│ x.gif      CollY  │                   |
└───────────────────┘                   |
   |            \        (creates loop) |
   |             \                      |
┌─────────────┐   ┌─────────────────┐   |
│ Resource R3 │   │ Collection C4   │   |
└─────────────┘   │ bindings:       │   |
                  │ y.gif     CollZ │   |
                  └─────────────────┘   |
                      |         |       |
                      |         +-------+
                      |
                  ┌─────────────┐
                  │ Resource R4 │
                  └─────────────┘

Note that the same would apply for more complex loops.¶

2.3.2. Example: COPY Updating Multiple Bindings

Given the following collection hierarchy:

                    ┌──────────────────┐
                    │ Root Collection  │
                    │  bindings:       │
                    │  CollX     CollY │
                    └──────────────────┘
                       /              \
                      /                \
                     /                  \           
  ┌──────────────────────────┐   ┌─────────────────┐
  │      Collection C1       │   │ Collection C2   │
  │      bindings:           │   │ bindings:       │
  │     x.gif     y.gif      │   │ x.gif     y.gif │
  └──────────────────────────┘   └─────────────────┘
          |         |                |         |
          |         |                |         |
┌─────────────┐  ┌─────────────┐   ┌─────────────┐
│ Resource R1 │  │ Resource R2 │   │ Resource R3 │
└─────────────┘  └─────────────┘   └─────────────┘

A COPY of /CollX with "Depth: infinity" to /CollY will not result in a changed hierarchy, and Resource R3 will be updated with the content of either Resource R1 or Resource R2.

2.3.3. Example: COPY with "Depth: infinity" with Multiple Bindings to a Leaf Resource

Given the following collection hierarchy:

┌──────────────────┐
│ Root Collection  │
│  bindings:       │
│  CollX           │
└──────────────────┘
   |            
   |  
   |               
┌────────────────┐ 
│ Collection C1  │
│ bindings:      │
│ x.gif    y.gif │ 
└────────────────┘
   |         |     
   |         |    
 ┌─────────────┐   
 │ Resource R1 │
 └─────────────┘

A COPY of /CollX with "Depth: infinity" to /CollY results in the following collection hierarchy:

┌──────────────────┐
│ Root Collection  │
│  bindings:       │
│  CollX     CollY │
└──────────────────┘
   |              \
   |               \
   |                \           
┌────────────────┐  ┌─────────────────┐
│ Collection C1  │  │ Collection C2   │
│ bindings:      │  │ bindings:       │
│ x.gif    y.gif │  │ x.gif     y.gif │
└────────────────┘  └─────────────────┘
   |         |          |         |
   |         |          |         |
 ┌─────────────┐      ┌─────────────┐
 │ Resource R1 │      │ Resource R2 │
 └─────────────┘      └─────────────┘

2.4. DELETE and Bindings

When there are multiple bindings to a resource, a DELETE applied to that resource MUST NOT remove any bindings to that resource other than the one identified by the Request-URI. For example, suppose the collection identified by the URI "/a" has a binding named "x" to a resource R, and another collection identified by "/b" has a binding named "y" to the same resource R. Then, a DELETE applied to "/a/x" removes the binding named "x" from "/a" but MUST NOT remove the binding named "y" from "/b" (i.e., after the DELETE, "/y/b" continues to identify the resource R).¶

When DELETE is applied to a collection, it MUST NOT modify the membership of any other collection that is not itself a member of the collection being deleted. For example, if both "/a/.../x" and "/b/.../y" identify the same collection, C, then applying DELETE to "/a" must not delete an internal member from C or from any other collection that is a member of C, because that would modify the membership of "/b".¶

If a collection supports the UNBIND method (see Section 5), a DELETE of an internal member of a collection MAY be implemented as an UNBIND request. In this case, applying DELETE to a Request-URI has the effect of removing the binding identified by the final segment of the Request-URI from the collection identified by the Request-URI minus its final segment. Although [RFC4918] allows a DELETE to be a non-atomic operation, when the DELETE operation is implemented as an UNBIND, the operation is atomic. In particular, a DELETE on a hierarchy of resources is simply the removal of a binding to the collection identified by the Request-URI.¶

2.5. MOVE and Bindings

When MOVE is applied to a resource, the other bindings to that resource MUST be unaffected; and if the resource being moved is a collection, the bindings to any members of that collection MUST be unaffected. Also, if MOVE is used with Overwrite:T to delete an existing resource, the constraints specified for DELETE apply.¶

If the destination collection of a MOVE request supports the REBIND method (see Section 6), a MOVE of a resource into that collection MAY be implemented as a REBIND request. Although [RFC4918] allows a MOVE to be a non-atomic operation, when the MOVE operation is implemented as a REBIND, the operation is atomic. In particular, applying a MOVE to a Request-URI and a Destination URI has the effect of removing a binding to a resource (at the Request-URI) and creating a new binding to that resource (at the Destination URI). Even when the Request-URI identifies a collection, the MOVE operation involves only removing one binding to that collection and adding another.¶

2.5.1. Example: Simple MOVE

As an example, suppose that a MOVE is issued to URI-3 for resource R below (which is also mapped to URI-1 and URI-2), with the Destination header set to URI-X. After successful completion of the MOVE operation, a new binding has been created that creates the URI mapping between URI-X and resource R. The binding corresponding to the final segment of URI-3 has been removed, which also causes the URI mapping between URI-3 and R to be removed. If resource R were a collection, old URI-3-based mappings to members of R would have been removed, and new URI-X-based mappings to members of R would have been created.¶

>> Before Request:

 URI-1   URI-2    URI-3
   |       |        |          
   |       |        |      <---- URI Mappings
   |       |        |
┌─────────────────────┐
│     Resource R      │
└─────────────────────┘

>> After Request:

 URI-1   URI-2    URI-X
   |       |        |          
   |       |        |      <---- URI Mappings
   |       |        |
┌─────────────────────┐
│     Resource R      │
└─────────────────────┘

2.5.2. Example: MOVE Request Causing a Bind Loop

Note that in the presence of collection bindings, a MOVE request can cause the creation of a bind loop.¶

Consider the top-level collections C1 and C2 with URIs "/CollW/" and "/CollX/". C1 also contains an additional binding named "CollY" to C2:

                  ┌──────────────────┐
                  │ Root Collection  │
                  │  bindings:       │
                  │  CollW    CollX  │
                  └──────────────────┘
                      |          |
                      |          |
         ┌──────────────────┐    |
         │ Collection C1    │    |
         │  bindings:       │    |
         │           CollY  │    |
         └──────────────────┘    |
                      |          |
                      |          |
                  ┌──────────────────┐
                  │ Collection C2    │
                  │                  │
                  │                  │
                  └──────────────────┘

In this case, the MOVE request below would cause a bind loop:¶

>> Request:

MOVE /CollW HTTP/1.1
Host: example.com
Destination: /CollX/CollZ

If the request succeeded, the resulting state would be:

                  ┌──────────────────┐
                  │ Root Collection  │
                  │  bindings:       │
                  │           CollX  │
                  └──────────────────┘
                                 |
                                 |
         ┌──────────────────┐    |
         │ Collection C1    │    |
  +----> │  bindings:       │    |
  |      │           CollY  │    |
  |      └──────────────────┘    |
  |                   |          |
  |                   |          |
  |               ┌──────────────────┐
  |               │ Collection C2    │
  |               │  bindings:       │
  |               │ CollZ            │
  |               └──────────────────┘
  |                   |
  |                   |
  +-------------------+

2.6. PROPFIND and Bindings

Consistent with [RFC4918], the value of a dead property MUST be independent of the number of bindings to its host resource or of the path submitted to PROPFIND. On the other hand, the behavior for each live property depends on its individual definition (for example, see [RFC3744], Section 5, Paragraph 2 for a case where the value is independent of its path and bindings, and [RFC4918], Section 8.8 for a discussion about the live properties DAV:getetag and DAV:getlastmodified, which may behave differently).¶

2.7. Determining Whether Two Bindings Are to the Same Resource

It is useful to have some way of determining whether two bindings are to the same resource. Two resources might have identical contents and properties, but not be the same resource (e.g., an update to one resource does not affect the other resource).¶

The REQUIRED DAV:resource-id property defined in Section 3.1 is a resource identifier, which MUST be unique across all resources for all time. If the values of DAV:resource-id returned by PROPFIND requests through two bindings are identical character by character, the client can be assured that the two bindings are to the same resource.¶

The DAV:resource-id property is created, and its value assigned, when the resource is created. The value of DAV:resource-id MUST NOT be changed. Even after the resource is no longer accessible through any URI, that value MUST NOT be reassigned to another resource's DAV:resource-id property.¶

Any method that creates a new resource MUST assign a new, unique value to its DAV:resource-id property. For example, a PUT applied to a null resource, COPY (when not overwriting an existing target) and CHECKIN (see [RFC3253], Section 4.4) must assign a new, unique value to the DAV:resource-id property of the new resource they create.¶

On the other hand, any method that affects an existing resource must not change the value of its DAV:resource-id property. Specifically, a PUT or a COPY that updates an existing resource must not change the value of its DAV:resource-id property. A REBIND, since it does not create a new resource, but only changes the location of an existing resource, must not change the value of the DAV:resource-id property.¶

2.8. Discovering the Bindings to a Resource

An OPTIONAL DAV:parent-set property on a resource provides a list of the bindings that associate a collection and a URI segment with that resource. If the DAV:parent-set property exists on a given resource, it MUST contain a complete list of all bindings to that resource that the client is authorized to see. When deciding whether to support the DAV:parent-set property, server implementers / administrators should balance the benefits it provides against the cost of maintaining the property and the security risks enumerated in Sections 12.4 and 12.5.¶