Internet Engineering Task Force (IETF) G. Clemm
Request for Comments: 5842 IBM
Category: Experimental J. Crawford
ISSN: 2070-1721 IBM Research
J. Reschke, Ed.
greenbytes
J. Whitehead
U.C. Santa Cruz
April 2010
Internet Engineering Task Force (IETF) G. Clemm
Request for Comments: 5842 IBM
Category: Experimental J. Crawford
ISSN: 2070-1721 IBM Research
J. Reschke, Ed.
greenbytes
J. Whitehead
U.C. Santa Cruz
April 2010
Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
Web分布式创作和版本控制（WebDAV）的绑定扩展
Abstract
摘要
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.
此规范定义了绑定，以及用于创建同一资源的多个绑定的绑定方法。创建到资源的新绑定会导致至少一个新URI映射到该资源。服务器需要确保允许创建的任何绑定的完整性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5842.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5842.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Method Preconditions and Postconditions ....................6
2. Overview of Bindings ............................................7
2.1. Bindings to Collections ....................................7
2.1.1. Bind Loops ..........................................8
2.2. URI Mappings Created by a New Binding ......................8
2.3. COPY and Bindings ..........................................9
2.3.1. Example: COPY with "Depth: infinity" in
Presence of Bind Loops .............................11
2.3.2. Example: COPY Updating Multiple Bindings ...........13
2.3.3. Example: COPY with "Depth: infinity" with
Multiple Bindings to a Leaf Resource ...............14
2.4. DELETE and Bindings .......................................15
2.5. MOVE and Bindings .........................................15
2.5.1. Example: Simple MOVE ...............................16
2.5.2. Example: MOVE Request Causing a Bind Loop ..........16
2.6. PROPFIND and Bindings .....................................18
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Method Preconditions and Postconditions ....................6
2. Overview of Bindings ............................................7
2.1. Bindings to Collections ....................................7
2.1.1. Bind Loops ..........................................8
2.2. URI Mappings Created by a New Binding ......................8
2.3. COPY and Bindings ..........................................9
2.3.1. Example: COPY with "Depth: infinity" in
Presence of Bind Loops .............................11
2.3.2. Example: COPY Updating Multiple Bindings ...........13
2.3.3. Example: COPY with "Depth: infinity" with
Multiple Bindings to a Leaf Resource ...............14
2.4. DELETE and Bindings .......................................15
2.5. MOVE and Bindings .........................................15
2.5.1. Example: Simple MOVE ...............................16
2.5.2. Example: MOVE Request Causing a Bind Loop ..........16
2.6. PROPFIND and Bindings .....................................18
2.7. Determining Whether Two Bindings Are to the Same
Resource ..................................................18
2.8. Discovering the Bindings to a Resource ....................19
3. Properties .....................................................19
3.1. DAV:resource-id Property ..................................20
3.2. DAV:parent-set Property ...................................20
3.2.1. Example for DAV:parent-set Property ................20
4. BIND Method ....................................................21
4.1. Example: BIND .............................................24
5. UNBIND Method ..................................................24
5.1. Example: UNBIND ...........................................26
6. REBIND Method ..................................................26
6.1. Example: REBIND ...........................................28
6.2. Example: REBIND in Presence of Locks and Bind Loops .......29
7. Additional Status Codes ........................................31
7.1. 208 Already Reported ......................................31
7.1.1. Example: PROPFIND by Bind-Aware Client .............32
7.1.2. Example: PROPFIND by Non-Bind-Aware Client .........34
7.2. 508 Loop Detected .........................................34
8. Capability Discovery ...........................................34
8.1. OPTIONS Method ............................................34
8.2. 'DAV' Request Header ......................................34
9. Relationship to Locking in WebDAV ..............................35
9.1. Example: Locking and Multiple Bindings ....................36
10. Relationship to WebDAV Access Control Protocol ................37
11. Relationship to Versioning Extensions to WebDAV ...............37
12. Security Considerations .......................................40
12.1. Privacy Concerns .........................................40
12.2. Bind Loops ...............................................40
12.3. Bindings and Denial of Service ...........................40
12.4. Private Locations May Be Revealed ........................40
12.5. DAV:parent-set and Denial of Service .....................41
13. Internationalization Considerations ...........................41
14. IANA Considerations ...........................................41
15. Acknowledgements ..............................................41
16. References ....................................................41
16.1. Normative References .....................................41
16.2. Informative References ...................................42
Index .............................................................42
2.7. Determining Whether Two Bindings Are to the Same
Resource ..................................................18
2.8. Discovering the Bindings to a Resource ....................19
3. Properties .....................................................19
3.1. DAV:resource-id Property ..................................20
3.2. DAV:parent-set Property ...................................20
3.2.1. Example for DAV:parent-set Property ................20
4. BIND Method ....................................................21
4.1. Example: BIND .............................................24
5. UNBIND Method ..................................................24
5.1. Example: UNBIND ...........................................26
6. REBIND Method ..................................................26
6.1. Example: REBIND ...........................................28
6.2. Example: REBIND in Presence of Locks and Bind Loops .......29
7. Additional Status Codes ........................................31
7.1. 208 Already Reported ......................................31
7.1.1. Example: PROPFIND by Bind-Aware Client .............32
7.1.2. Example: PROPFIND by Non-Bind-Aware Client .........34
7.2. 508 Loop Detected .........................................34
8. Capability Discovery ...........................................34
8.1. OPTIONS Method ............................................34
8.2. 'DAV' Request Header ......................................34
9. Relationship to Locking in WebDAV ..............................35
9.1. Example: Locking and Multiple Bindings ....................36
10. Relationship to WebDAV Access Control Protocol ................37
11. Relationship to Versioning Extensions to WebDAV ...............37
12. Security Considerations .......................................40
12.1. Privacy Concerns .........................................40
12.2. Bind Loops ...............................................40
12.3. Bindings and Denial of Service ...........................40
12.4. Private Locations May Be Revealed ........................40
12.5. DAV:parent-set and Denial of Service .....................41
13. Internationalization Considerations ...........................41
14. IANA Considerations ...........................................41
15. Acknowledgements ..............................................41
16. References ....................................................41
16.1. Normative References .....................................41
16.2. Informative References ...................................42
Index .............................................................42
This specification extends the WebDAV Distributed Authoring Protocol ([RFC4918]) to enable clients to create new access paths to existing resources. This capability is useful for several reasons:
此规范扩展了WebDAV分布式创作协议（[RFC4918]），使客户端能够创建到现有资源的新访问路径。由于以下几个原因，此功能非常有用：
URIs of WebDAV-compliant resources are hierarchical and correspond to a hierarchy of collections in resource space. The WebDAV Distributed Authoring Protocol makes it possible to organize these resources into hierarchies, placing them into groupings, known as collections, which are more easily browsed and manipulated than a single flat collection. However, hierarchies require categorization decisions that locate resources at a single location in the hierarchy, a drawback when a resource has multiple valid categories. For example, in a hierarchy of vehicle descriptions containing collections for cars and boats, a description of a combination car/boat vehicle could belong in either collection. Ideally, the description should be accessible from both. Allowing clients to create new URIs that access the existing resource lets them put that resource into multiple collections.
WebDAV兼容资源的URI是分层的，并对应于资源空间中集合的层次结构。WebDAV分布式创作协议可以将这些资源组织到层次结构中，并将它们放入称为集合的分组中，这些分组比单个平面集合更易于浏览和操作。但是，层次结构要求分类决策将资源定位在层次结构中的单个位置，这是资源具有多个有效类别时的一个缺点。例如，在包含汽车和船只集合的车辆描述层次结构中，汽车/船只组合车辆的描述可以属于任一集合。理想情况下，描述应该可以从两者中访问。允许客户端创建访问现有资源的新URI，可以将该资源放入多个集合中。
Hierarchies also make resource sharing more difficult, since resources that have utility across many collections are still forced into a single collection. For example, the mathematics department at one university might create a collection of information on fractals that contains bindings to some local resources but also provides access to some resources at other universities. For many reasons, it may be undesirable to make physical copies of the shared resources on the local server, for example, to conserve disk space, to respect copyright constraints, or to make any changes in the shared resources visible automatically. Being able to create new access paths to existing resources in other collections or even on other servers is useful for this sort of case.
层次结构还使得资源共享更加困难，因为跨多个集合具有实用性的资源仍然被强制放在单个集合中。例如，一所大学的数学系可能会创建一个关于分形的信息集合，其中包含对一些本地资源的绑定，但也提供对其他大学某些资源的访问。出于许多原因，可能不希望在本地服务器上制作共享资源的物理副本，例如，为了节省磁盘空间、遵守版权限制或使共享资源中的任何更改自动可见。对于这种情况，能够创建到其他集合甚至其他服务器上现有资源的新访问路径非常有用。
The BIND method, defined here, provides a mechanism for allowing clients to create alternative access paths to existing WebDAV resources. HTTP [RFC2616] and WebDAV [RFC4918] methods are able to work because there are mappings between URIs and resources. A method is addressed to a URI, and the server follows the mapping from that URI to a resource, applying the method to that resource. Multiple URIs may be mapped to the same resource, but until now, there has been no way for clients to create additional URIs mapped to existing resources.
这里定义的BIND方法提供了一种机制，允许客户端创建到现有WebDAV资源的替代访问路径。HTTP[RFC2616]和WebDAV[RFC4918]方法能够工作，因为URI和资源之间存在映射。方法被寻址到URI，服务器遵循从该URI到资源的映射，将方法应用到该资源。多个URI可以映射到同一资源，但到目前为止，客户端还没有办法创建映射到现有资源的其他URI。
BIND lets clients associate a new URI with an existing WebDAV resource, and this URI can then be used to submit requests to the resource. Since URIs of WebDAV resources are hierarchical, and correspond to a hierarchy of collections in resource space, the BIND
BIND允许客户端将新URI与现有WebDAV资源关联，然后可以使用此URI向资源提交请求。由于WebDAV资源的URI是分层的，并且对应于资源空间中集合的层次结构，因此绑定
method also has the effect of adding the resource to a collection. As new URIs are associated with the resource, it appears in additional collections.
方法还具有将资源添加到集合的效果。当新URI与资源关联时，它会出现在其他集合中。
A BIND request does not create a new resource, but simply makes a new URI for submitting requests to an existing resource available. The new URI is indistinguishable from any other URI when submitting a request to a resource. Only one round trip is needed to submit a request to the intended target. Servers are required to enforce the integrity of the relationships between the new URIs and the resources associated with them. Consequently, it may be very costly for servers to support BIND requests that cross server boundaries.
绑定请求不会创建新资源，只会创建一个新的URI，用于向现有资源提交请求。在向资源提交请求时，新URI与任何其他URI都无法区分。向预期目标提交请求只需一次往返。服务器需要强制执行新URI和与其关联的资源之间关系的完整性。因此，服务器支持跨越服务器边界的绑定请求的成本可能非常高。
This specification is organized as follows. Section 1.1 defines terminology used in the rest of the specification, while Section 2 overviews bindings. Section 3 defines the new properties needed to support multiple bindings to the same resource. Section 4 specifies the BIND method, used to create multiple bindings to the same resource. Section 5 specifies the UNBIND method, used to remove a binding to a resource. Section 6 specifies the REBIND method, used to move a binding to another collection.
本规范组织如下。第1.1节定义了本规范其余部分中使用的术语，而第2节概述了绑定。第3节定义了支持同一资源的多个绑定所需的新属性。第4节指定了BIND方法，用于创建对同一资源的多个绑定。第5节指定了UNBIND方法，用于删除与资源的绑定。第6节指定了重新绑定方法，用于将绑定移动到另一个集合。
The terminology used here follows and extends that in the WebDAV Distributed Authoring Protocol specification [RFC4918].
这里使用的术语遵循并扩展了WebDAV分布式创作协议规范[RFC4918]中的术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses XML DTD fragments ([XML]) as a notational convention, using the rules defined in Section 17 of [RFC4918].
本文档使用XML DTD片段（[XML]）作为符号约定，使用[RFC4918]第17节中定义的规则。
URI Mapping
URI映射
A relation between an absolute URI and a resource. For an absolute URI U and the resource it identifies R, the URI mapping can be thought of as (U => R). Since a resource can represent items that are not network retrievable as well as those that are, it is possible for a resource to have zero, one, or many URI mappings. Mapping a resource to an "http"-scheme URI makes it possible to submit HTTP requests to the resource using the URI.
绝对URI和资源之间的关系。对于绝对URI U及其标识R的资源，可以将URI映射视为（U=>R）。由于资源可以表示不可网络检索的项以及可网络检索的项，因此资源可能具有零、一或多个URI映射。将资源映射到“http”-方案URI可以使用URI向资源提交http请求。
Path Segment
路径段
Informally, the characters found between slashes ("/") in a URI. Formally, as defined in Section 3.3 of [RFC3986].
非正式地说，URI中斜杠（“/”）之间的字符。正式定义见[RFC3986]第3.3节。
Binding
结合
A relation between a single path segment (in a collection) and a resource. A binding is part of the state of a collection. If two different collections contain a binding between the same path segment and the same resource, these are two distinct bindings. So for a collection C, a path segment S, and a resource R, the binding can be thought of as C:(S -> R). Bindings create URI mappings, and hence allow requests to be sent to a single resource from multiple locations in a URI namespace. For example, given a collection C (accessible through the URI http://www.example.com/CollX), a path segment S (equal to "foo.html"), and a resource R, then creating the binding C: (S -> R) makes it possible to use the URI http://www.example.com/CollX/foo.html to access R.
单个路径段（在集合中）与资源之间的关系。绑定是集合状态的一部分。如果两个不同的集合包含同一路径段和同一资源之间的绑定，则这是两个不同的绑定。因此，对于集合C、路径段S和资源R，可以将绑定视为C:（S->R）。绑定创建URI映射，因此允许将请求从URI命名空间中的多个位置发送到单个资源。例如，给定一个集合C（可通过URI访问http://www.example.com/CollX)，一个路径段S（等于“foo.html”）和一个资源R，然后创建绑定C:（S->R）使使用URI成为可能http://www.example.com/CollX/foo.html 访问R。
Collection
收集
A resource that contains, as part of its state, a set of bindings that identify internal member resources.
作为其状态的一部分，包含一组标识内部成员资源的绑定的资源。
Internal Member URI
内部成员URI
The URI that identifies an internal member of a collection and that consists of the URI for the collection, followed by a slash character ('/'), followed by the path segment of the binding for that internal member.
标识集合内部成员的URI，该URI由集合的URI组成，后跟斜杠字符（“/”），后跟该内部成员绑定的路径段。
Binding Integrity
绑定完整性
The property of a binding that says that:
绑定的属性，表示：
* the binding continues to exist, and
* 绑定继续存在，并且
* the identity of the resource identified by that binding does not change,
* 由该绑定标识的资源的标识不会更改，
unless an explicit request is executed that is defined to delete that binding (examples of requests that delete a binding are DELETE, MOVE, and -- defined later on -- UNBIND and REBIND).
除非执行了定义为删除该绑定的显式请求（删除绑定的请求示例为delete、MOVE和--稍后定义--UNBIND和REBIND）。
See Section 16 of [RFC4918] for the definitions of "precondition" and "postcondition".
“先决条件”和“后决条件”的定义见[RFC4918]第16节。
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.
绑定由各种现有HTTP方法添加和删除。创建新资源（如PUT、COPY和MKCOL）的方法会添加绑定。删除资源的方法（如DELETE）会删除绑定。移动资源（例如，移动）的方法既添加绑定（在目标集合中）又删除绑定（在源集合中）。这里介绍的BIND方法提供了向现有资源添加第二个绑定的机制。通过PUT、COPY或MKCOL添加的初始绑定与通过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.
如果一个绑定由于通过不同的绑定对资源进行操作而被破坏，这将是非常不可取的。特别是，删除与资源的一个绑定（例如，通过删除或移动）不得中断与该资源的另一个绑定，例如，将该绑定转换为悬挂路径段。删除一个绑定后，服务器不得回收系统资源，而保留对资源的其他绑定。换句话说，服务器必须保持绑定的完整性。但是，允许将来的方法定义（例如，销毁方法）具有显式删除所有绑定和/或立即回收系统资源的语义。
Note: the collection model described herein is not compatible with systems in which resources inherit properties based solely on the access path, as the ability to create additional bindings will cause a single resource to appear as member of several different collections at the same time.
注意：本文描述的集合模型与资源仅基于访问路径继承属性的系统不兼容，因为创建附加绑定的能力将导致单个资源同时显示为多个不同集合的成员。
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.
创建到集合的新绑定使与该集合中的绑定关联的每个资源都可以通过新URI访问，从而创建到这些资源的新URI映射，但不创建新绑定。
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
例如，假设为下图中的集合C1创建了一个新的绑定CollY。可以立即使用URI/CollY/x.gif访问资源R1，使用URI/CollY/y.jpg访问资源R2，但没有为这些子资源创建新绑定。这是因为绑定是集合状态的一部分，它们关联一个相对于集合的URI
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.
该集合及其目标资源。无需更改集合C1中的绑定即可使用/CollY/x.gif和/CollY/y.jpg访问其子级。
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| /
| /
| /
+------------------+
| Collection C1 |
| bindings: |
| x.gif y.jpg |
+------------------+
| \
| \
| \
+-------------+ +-------------+
| Resource R1 | | Resource R2 |
+-------------+ +-------------+
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| /
| /
| /
+------------------+
| Collection C1 |
| bindings: |
| x.gif y.jpg |
+------------------+
| \
| \
| \
+-------------+ +-------------+
| Resource R1 | | Resource R2 |
+-------------+ +-------------+
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.
对集合的绑定可能导致循环（“循环”），服务器在处理“Depth:infinity”请求时必须检测循环。尽管存在回路，有时仍可能完成操作。例如，如果服务器使用第7.1节中定义的新状态代码208（已报告），PROPFIND仍然可以成功。
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.
但是，第7.2节中定义了508（检测到循环）状态代码，用于因遇到循环而终止操作的上下文中。
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).
对循环的支持是可选的：服务器可能会拒绝导致创建绑定循环的请求（请参阅第4节中定义的DAV:cycle allowed Premission）。
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.
假设将从“binding Name”到资源R的绑定添加到集合C中。然后，如果C-MAP是在绑定请求之前映射到C的URI集，那么对于C-MAP中的每个URI“C-URI”，URI“C-URI/binding Name”将在绑定请求之后映射到资源R。
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:
例如，如果将从“foo.html”到R的绑定添加到集合C，并且如果将以下URI映射到C：
http://www.example.com/A/1/
http://example.com/A/one/
http://www.example.com/A/1/
http://example.com/A/one/
then the following new mappings to R are introduced:
然后介绍了以下到R的新映射：
http://www.example.com/A/1/foo.html
http://example.com/A/one/foo.html
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.
请注意，如果R是一个集合，则会创建附加的URI映射到R的后代。此外，请注意，如果在集合C中绑定到C本身（或绑定到C的父级），则会引入无限多的映射。
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:
例如，如果将从“我自己”到C的绑定添加到C，则会引入以下无限多个到C的额外映射：
http://www.example.com/A/1/myself http://www.example.com/A/1/myself/myself ...
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:
并且引入了以下无限多个到R的额外映射：
http://www.example.com/A/1/myself/foo.html http://www.example.com/A/1/myself/myself/foo.html ...
http://www.example.com/A/1/myself/foo.html http://www.example.com/A/1/myself/myself/foo.html ...
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.
如[RFC4918]第9.8节所定义，复制会导致复制由请求URI标识的资源，并使用目标标头中指定的URI访问新资源。成功完成复制后，将在目标标头的最后一个路径段和目标资源之间创建新绑定。新绑定被添加到其父集合中，由目标标头减去其最终段来标识。
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).
下图显示了一个示例：假设为资源R（也映射到URI-1和URI-2）向URI-3发布了一个副本，目标标头设置为URI-X。成功完成复制操作后，复制资源R以创建资源R'，并且创建了一个新绑定，该绑定至少创建URI-X和新资源之间的URI映射（尽管也可能创建了其他URI映射）。
URI-1 URI-2 URI-3 URI-X
| | | |
| | | <---- URI Mappings ----> |
| | | |
+---------------------+ +------------------------+
| Resource R | | Resource R' |
+---------------------+ +------------------------+
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.
可能会认为集合上具有“Depth:0”的复制请求会复制其绑定，因为绑定是集合状态的一部分。然而，情况并非如此。[RFC4918]中对深度的定义明确指出，“深度：0”请求不适用于集合的成员。因此，具有“Depth:0”的副本不会复制集合包含的绑定。
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).
如果复制请求导致更新现有资源，则该资源的绑定必须不受复制请求的影响。使用前面的示例，假设向资源R'的URI-X发出复制请求，目标标头设置为URI-2。资源R的内容和死属性将被更新为资源R'的内容和死属性的副本，但从URI-1、URI-2和URI-3到资源R的映射仍然不受影响。如果由于对资源的多个绑定，多个源资源更新单个目标资源，则更新顺序由服务器定义（有关示例，请参阅第2.3.2节）。
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.3节）。
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 |
+-------------+
+------------------+
| 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:
如果将带有“Depth:infinity”的复制请求提交到/CollX，目标为/CollA，则复制操作的结果是将树的副本复制到目标/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 |
+-------------+
+------------------+
| 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.
请注意，这同样适用于更复杂的循环。
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 |
+-------------+ +-------------+ +-------------+
+------------------+
| 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.
将带有“Depth:infinity”的/CollX复制到/CollY不会导致层次结构的更改，资源R3将使用资源R1或资源R2的内容进行更新。
2.3.3. Example: COPY with "Depth: infinity" with Multiple Bindings to a Leaf Resource
2.3.3. 示例：使用“Depth:infinity”复制，并将多个绑定到叶资源
Given the following collection hierarchy:
给定以下集合层次结构：
+------------------+
| Root Collection |
| bindings: |
| CollX |
+------------------+
|
|
|
+----------------+
| Collection C1 |
| bindings: |
| x.gif y.gif |
+----------------+
| |
| |
+-------------+
| Resource R1 |
+-------------+
+------------------+
| 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:
将带有“Depth:infinity”的/CollX复制到/CollY会产生以下集合层次结构：
+------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+------------------+
| \
| \
| \
+----------------+ +-----------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| x.gif y.gif | | x.gif y.gif |
+----------------+ +-----------------+
| | | |
| | | |
+-------------+ +-------------+
| Resource R1 | | Resource R2 |
+-------------+ +-------------+
+------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+------------------+
| \
| \
| \
+----------------+ +-----------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| x.gif y.gif | | x.gif y.gif |
+----------------+ +-----------------+
| | | |
| | | |
+-------------+ +-------------+
| Resource R1 | | Resource R2 |
+-------------+ +-------------+
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).
当一个资源有多个绑定时，应用于该资源的删除不能删除除请求URI标识的绑定之外的任何绑定。例如，假设URI“/a”标识的集合对资源R有一个名为“x”的绑定，而“/b”标识的另一个集合对同一资源R有一个名为“y”的绑定。然后，应用于“/a/x”的删除将从“/a”中删除名为“x”的绑定，但不能从“/b”中删除名为“y”的绑定（即，在删除“/y/b”之后）继续标识资源（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".
将“删除”应用于集合时，它不得修改本身不是要删除的集合成员的任何其他集合的成员身份。例如，如果“/a/../x”和“/b/../y”都标识了同一个集合C，则将“删除”应用于“/a”不得从C或任何其他属于C的集合中删除内部成员，因为这将修改“/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.
如果集合支持取消绑定方法（请参见第5节），则可以将集合内部成员的删除作为取消绑定请求来实现。在这种情况下，将DELETE应用于请求URI的效果是从请求URI所标识的集合中删除请求URI的最后一段所标识的绑定减去其最后一段。尽管[RFC4918]允许删除为非原子操作，但当删除操作作为解除绑定实现时，该操作为原子操作。特别是，资源层次结构上的删除只是删除与请求URI标识的集合的绑定。
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.
当移动应用于资源时，该资源的其他绑定必须不受影响；如果要移动的资源是一个集合，则与该集合的任何成员的绑定必须不受影响。此外，如果MOVE与Overwrite:T一起用于删除现有资源，则为delete指定的约束将适用。
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
如果移动请求的目标集合支持重新绑定方法（参见第6节），则将资源移动到该集合中可以作为重新绑定请求来实现。尽管[RFC4918]允许移动为非原子操作，但当移动操作作为重新绑定实现时，该操作为原子操作。特别是，将移动应用于请求URI和目标URI具有移除到资源的绑定（在请求URI处）并创建新绑定的效果
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.
到该资源（在目标URI处）。即使请求URI标识了一个集合，移动操作也只涉及删除该集合的一个绑定并添加另一个绑定。
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.
例如，假设为下面的资源R（也映射到URI-1和URI-2）向URI-3发出移动，目标标头设置为URI-X。成功完成移动操作后，已创建一个新绑定，用于创建URI-X和资源R之间的URI映射。与URI-3的最后一段相对应的绑定已被删除，这也会导致URI-3和R之间的URI映射被删除。如果资源R是一个集合，那么到R成员的旧的基于URI-3的映射将被删除，而到R成员的新的基于URI-X的映射将被创建。
>> Before Request:
>>在提出要求之前：
URI-1 URI-2 URI-3
| | |
| | | <---- URI Mappings
| | |
+---------------------+
| Resource R |
+---------------------+
URI-1 URI-2 URI-3
| | |
| | | <---- URI Mappings
| | |
+---------------------+
| Resource R |
+---------------------+
>> After Request:
>>经请求：
URI-1 URI-2 URI-X
| | |
| | | <---- URI Mappings
| | |
+---------------------+
| Resource R |
+---------------------+
URI-1 URI-2 URI-X
| | |
| | | <---- URI Mappings
| | |
+---------------------+
| Resource R |
+---------------------+
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:
使用URI“/CyW/”和“/CollX”来考虑顶级集合C1和C2。C1还包含一个名为“CollY”的附加绑定到C2：
+------------------+
| Root Collection |
| bindings: |
| CollW CollX |
+------------------+
| |
| |
+------------------+ |
| Collection C1 | |
| bindings: | |
| CollY | |
+------------------+ |
| |
| |
+------------------+
| Collection 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
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 |
| +------------------+
| |
| |
+-------------------+
+------------------+
| Root Collection |
| bindings: |
| CollX |
+------------------+
|
|
+------------------+ |
| Collection C1 | |
+----> | bindings: | |
| | CollY | |
| +------------------+ |
| | |
| | |
| +------------------+
| | Collection C2 |
| | bindings: |
| | CollZ |
| +------------------+
| |
| |
+-------------------+
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).
与[RFC4918]一致，死属性的值必须独立于到其主机资源的绑定数量或提交给PROPFIND的路径。另一方面，每个活动属性的行为取决于其各自的定义（例如，有关值独立于其路径和绑定的情况，请参见[RFC3744]，第5节第2段，以及[RFC4918]，第8.8节，讨论活动属性DAV:getetag和DAV:getlastmodified，它们的行为可能不同）。
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
第3.1节中定义的所需DAV:resource id属性是一个资源标识符，在所有资源中必须始终唯一。如果PROPFIND返回的DAV:resource id的值
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.
创建资源时，将创建DAV:resource id属性并分配其值。不能更改DAV:资源id的值。即使资源不再可以通过任何URI访问，也不能将该值重新分配给另一个资源的DAV:resource id属性。
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.
任何创建新资源的方法都必须为其DAV:resource id属性分配一个新的唯一值。例如，应用于空资源、复制（不覆盖现有目标时）和签入（请参阅[RFC3253]，第4.4节）的PUT必须为其创建的新资源的DAV:resource id属性分配一个新的唯一值。
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.
另一方面，任何影响现有资源的方法都不能更改其DAV:resource id属性的值。具体而言，更新现有资源的PUT或副本不得更改其DAV:resource id属性的值。重新绑定不能更改DAV:resource id属性的值，因为它不创建新资源，而只更改现有资源的位置。
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.
资源上的可选DAV:parent set属性提供了将集合和URI段和该资源关联的绑定列表。如果给定资源上存在DAV:parent set属性，则该属性必须包含客户端有权查看的该资源的所有绑定的完整列表。在决定是否支持DAV:parent set属性时，服务器实现者/管理员应平衡其提供的好处与维护该属性的成本以及第12.4节和第12.5节中列举的安全风险。
The bind feature introduces the properties defined below.
绑定功能引入了下面定义的属性。
A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined by this document. This allows a binding server to perform efficiently when a naive client, which does not understand the cost of asking a server to compute all possible live properties, issues a DAV:allprop PROPFIND request.
DAV:allprop PROPFIND请求不应返回此文档定义的任何属性。这允许绑定服务器在一个不了解要求服务器计算所有可能的活动属性的成本的简单客户端发出DAV:allprop-PROPFIND请求时高效地执行。
The DAV:resource-id property is a REQUIRED property that enables clients to determine whether two bindings are to the same resource. The value of DAV:resource-id is a URI, and may use any registered URI scheme that guarantees the uniqueness of the value across all resources for all time (e.g., the urn:uuid: URN namespace defined in [RFC4122] or the opaquelocktoken: URI scheme defined in [RFC4918]).
resource id属性是一个必需属性，它使客户端能够确定两个绑定是否指向同一资源。DAV:resource id的值是一个URI，可以使用任何已注册的URI方案来保证该值在所有资源中始终唯一（例如，[RFC4122]中定义的urn:uuid:urn命名空间或[RFC4918]中定义的opaquelocktoken:URI方案）。
<!ELEMENT resource-id (href)>
<!ELEMENT resource-id (href)>
The DAV:parent-set property is an OPTIONAL property that enables clients to discover what collections contain a binding to this resource (i.e., what collections have that resource as an internal member). It contains an href/segment pair for each collection that has a binding to the resource. The href identifies the collection, and the segment identifies the binding name of that resource in that collection.
DAV:parent set属性是一个可选属性，它使客户端能够发现哪些集合包含对此资源的绑定（即，哪些集合将该资源作为内部成员）。它为每个绑定到资源的集合包含一个href/段对。href标识集合，段标识集合中该资源的绑定名称。
A given collection MUST appear only once in the DAV:parent-set for any given binding, even if there are multiple URI mappings to that collection.
给定集合在任何给定绑定的DAV:parent集合中只能出现一次，即使有多个URI映射到该集合也是如此。
<!ELEMENT parent-set (parent)*>
<!ELEMENT parent (href, segment)>
<!ELEMENT segment (#PCDATA)>
<!-- PCDATA value: segment, as defined in Section 3.3 of
[RFC3986] -->
<!ELEMENT parent-set (parent)*>
<!ELEMENT parent (href, segment)>
<!ELEMENT segment (#PCDATA)>
<!-- PCDATA value: segment, as defined in Section 3.3 of
[RFC3986] -->
For example, if collection C1 is mapped to both /CollX and /CollY, and C1 contains a binding named "x.gif" to a resource R1, then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set of R1, but not both. But if C1 also had a binding named "y.gif" to R1, then there would be two entries for C1 in the DAV:parent-set of R1 (i.e., both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, both [/CollY, x.gif] and [/CollY, y.gif]).
例如，如果集合C1同时映射到/CollX和/CollY，并且C1包含一个名为“x.gif”的绑定到资源R1，则[/CollX，x.gif]或[/CollY，x.gif]可以出现在R1的DAV:父集合中，但不能同时出现。但是，如果C1也有一个名为“y.gif”的绑定到R1，那么DAV中C1将有两个条目：R1的父集合（即[/CollX，x.gif]和[/CollX，y.gif]或者[/CollY，x.gif]和[/CollY，y.gif]）。
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| /
| /
| /
+-----------------+
| Collection C1 |
| bindings: |
| x.gif y.gif |
+-----------------+
| |
| |
| |
+-------------+
| Resource R1 |
+-------------+
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| /
| /
| /
+-----------------+
| Collection C1 |
| bindings: |
| x.gif y.gif |
+-----------------+
| |
| |
| |
+-------------+
| Resource R1 |
+-------------+
In this case, one possible value for the DAV:parent-set property on "/CollX/x.gif" would be:
在这种情况下，“/CollX/x.gif”上的DAV:parent set属性的一个可能值为：
<parent-set xmlns="DAV:">
<parent>
<href>/CollX</href>
<segment>x.gif</segment>
</parent>
<parent>
<href>/CollX</href>
<segment>y.gif</segment>
</parent>
</parent-set>
<parent-set xmlns="DAV:">
<parent>
<href>/CollX</href>
<segment>x.gif</segment>
</parent>
<parent>
<href>/CollX</href>
<segment>y.gif</segment>
</parent>
</parent-set>
The BIND method modifies the collection identified by the Request-URI, by adding a new binding from the segment specified in the BIND body to the resource identified in the BIND body.
BIND方法修改由请求URI标识的集合，方法是将一个新绑定从BIND主体中指定的段添加到BIND主体中标识的资源。
If a server cannot guarantee the integrity of the binding, the BIND request MUST fail. Note that it is especially difficult to maintain the integrity of cross-server bindings. Unless the server where the resource resides knows about all bindings on all servers to that resource, it may unwittingly destroy the resource or make it inaccessible without notifying another server that manages a binding to the resource. For example, if server A permits the creation of a
如果服务器不能保证绑定的完整性，则绑定请求必须失败。请注意，维护跨服务器绑定的完整性尤其困难。除非资源所在的服务器知道所有服务器上与该资源的所有绑定，否则它可能会无意中破坏该资源或使其无法访问，而不通知另一台管理与该资源绑定的服务器。例如，如果服务器A允许创建
binding to a resource on server B, server A must notify server B about its binding and must have an agreement with B that B will not destroy the resource while A's binding exists. Otherwise, server B may receive a DELETE request that it thinks removes the last binding to the resource and destroy the resource while A's binding still exists. The precondition DAV:cross-server-binding is defined below for cases where servers fail cross-server BIND requests because they cannot guarantee the integrity of cross-server bindings.
绑定到服务器B上的资源时，服务器a必须将其绑定通知服务器B，并且必须与B达成协议，在a的绑定存在时，B不会销毁资源。否则，服务器B可能会收到一个删除请求，它认为该请求删除了对资源的最后一个绑定，并在a的绑定仍然存在时销毁了资源。对于服务器无法保证跨服务器绑定的完整性而导致跨服务器绑定请求失败的情况，下面定义了先决条件DAV:跨服务器绑定。
By default, if there already is a binding for the specified segment in the collection, the new binding replaces the existing binding. This default binding replacement behavior can be overridden using the Overwrite header defined in Section 10.6 of [RFC4918].
默认情况下，如果集合中已存在指定段的绑定，则新绑定将替换现有绑定。可以使用[RFC4918]第10.6节中定义的覆盖标头覆盖此默认绑定替换行为。
If a BIND request fails, the server state preceding the request MUST be restored. This method is unsafe and idempotent (see [RFC2616], Section 9.1).
如果绑定请求失败，则必须恢复该请求之前的服务器状态。该方法不安全且幂等（见[RFC2616]，第9.1节）。
Marshalling:
编组：
The request MAY include an Overwrite header.
请求可能包括覆盖报头。
The request body MUST be a DAV:bind XML element.
请求主体必须是DAV:bind XML元素。
<!ELEMENT bind (segment, href)>
<!ELEMENT bind (segment, href)>
If the request succeeds, the server MUST return 201 (Created) when a new binding was created and 200 (OK) or 204 (No Content) when an existing binding was replaced.
如果请求成功，则服务器必须在创建新绑定时返回201（已创建），在替换现有绑定时返回200（确定）或204（无内容）。
If a response body for a successful request is included, it MUST be a DAV:bind-response XML element. Note that this document does not define any elements for the BIND response body, but the DAV: bind-response element is defined to ensure interoperability between future extensions that do define elements for the BIND response body.
如果包含成功请求的响应体，则它必须是DAV:bind响应XML元素。请注意，本文档没有为绑定响应体定义任何元素，但定义DAV:BIND-response元素是为了确保将来为绑定响应体定义元素的扩展之间的互操作性。
<!ELEMENT bind-response ANY>
<!ELEMENT bind-response ANY>
Preconditions:
先决条件：
(DAV:bind-into-collection): The Request-URI MUST identify a collection.
（DAV：绑定到集合）：请求URI必须标识集合。
(DAV:bind-source-exists): The DAV:href element MUST identify a resource.
（DAV:bind source exists）：DAV:href元素必须标识资源。
(DAV:binding-allowed): The resource identified by the DAV:href supports multiple bindings to it.
（DAV:binding-allowed）：由DAV:href标识的资源支持对其进行多个绑定。
(DAV:cross-server-binding): If the resource identified by the DAV: href element in the request body is on another server from the collection identified by the Request-URI, the server MUST support cross-server bindings (servers that do not support cross-server bindings can use this condition code to signal the client exactly why the request failed).
（DAV：跨服务器绑定）：如果请求正文中由DAV:href元素标识的资源位于由请求URI标识的集合中的另一台服务器上，则该服务器必须支持跨服务器绑定（不支持跨服务器绑定的服务器可以使用此条件代码向客户端发出请求失败的确切原因的信号）.
(DAV:name-allowed): The name specified by the DAV:segment is available for use as a new binding name.
（DAV:name-allowed）：由DAV:segment指定的名称可用作新的绑定名称。
(DAV:can-overwrite): If the collection already contains a binding with the specified path segment, and if an Overwrite header is included, the value of the Overwrite header MUST be "T".
（DAV:可以覆盖）：如果集合已包含具有指定路径段的绑定，并且包含覆盖标头，则覆盖标头的值必须为“T”。
(DAV:cycle-allowed): If the DAV:href element identifies a collection, and if the Request-URI identifies a collection that is a member of that collection, the server MUST support cycles in the URI namespace (servers that do not support cycles can use this condition code to signal the client exactly why the request failed).
（DAV:cycle allowed）：如果DAV:href元素标识一个集合，并且如果请求URI标识一个属于该集合的集合，则服务器必须支持URI命名空间中的循环（不支持循环的服务器可以使用此条件代码向客户端发信号，说明请求失败的确切原因）。
(DAV:locked-update-allowed): If the collection identified by the Request-URI is write-locked, then the appropriate token MUST be specified in an If request header.
（DAV:locked update allowed）：如果请求URI标识的集合被写锁定，则必须在If请求头中指定适当的令牌。
(DAV:locked-overwrite-allowed): If the collection already contains a binding with the specified path segment, and if that binding is protected by a write lock, then the appropriate token MUST be specified in an If request header.
（DAV:locked overwrite allowed）：如果集合已包含具有指定路径段的绑定，并且该绑定受写锁保护，则必须在If请求标头中指定相应的令牌。
Postconditions:
后条件：
(DAV:new-binding): The collection MUST have a binding that maps the segment specified in the DAV:segment element in the request body to the resource identified by the DAV:href element in the request body.
（DAV:new binding）：集合必须具有一个绑定，该绑定将请求正文中DAV:segment元素中指定的段映射到请求正文中DAV:href元素标识的资源。
>> Request:
>>请求：
BIND /CollY HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 172
BIND /CollY HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 172
<?xml version="1.0" encoding="utf-8" ?>
<D:bind xmlns:D="DAV:">
<D:segment>bar.html</D:segment>
<D:href>http://www.example.com/CollX/foo.html</D:href>
</D:bind>
<?xml version="1.0" encoding="utf-8" ?>
<D:bind xmlns:D="DAV:">
<D:segment>bar.html</D:segment>
<D:href>http://www.example.com/CollX/foo.html</D:href>
</D:bind>
>> Response:
>>答复：
HTTP/1.1 201 Created
Location: http://www.example.com/CollY/bar.html
HTTP/1.1 201 Created
Location: http://www.example.com/CollY/bar.html
The server added a new binding to the collection, "http://www.example.com/CollY", associating "bar.html" with the resource identified by the URI "http://www.example.com/CollX/foo.html". Clients can now use the URI "http://www.example.com/CollY/bar.html" to submit requests to that resource.
服务器向集合添加了新绑定，“http://www.example.com/CollY，将“bar.html”与URI标识的资源相关联http://www.example.com/CollX/foo.html". 客户端现在可以使用URI“http://www.example.com/CollY/bar.html“向该资源提交请求。
The UNBIND method modifies the collection identified by the Request-URI by removing the binding identified by the segment specified in the UNBIND body.
UNBIND方法通过删除UNBIND主体中指定的段所标识的绑定来修改由请求URI标识的集合。
Once a resource is unreachable by any URI mapping, the server MAY reclaim system resources associated with that resource. If UNBIND removes a binding to a resource, but there remain URI mappings to that resource, the server MUST NOT reclaim system resources associated with the resource.
一旦任何URI映射都无法访问资源，服务器就可以回收与该资源关联的系统资源。如果取消绑定删除了与资源的绑定，但仍存在与该资源的URI映射，则服务器不得回收与该资源关联的系统资源。
If an UNBIND request fails, the server state preceding the request MUST be restored. This method is unsafe and idempotent (see [RFC2616], Section 9.1).
如果解除绑定请求失败，则必须恢复请求之前的服务器状态。该方法不安全且幂等（见[RFC2616]，第9.1节）。
Marshalling:
编组：
The request body MUST be a DAV:unbind XML element.
请求主体必须是DAV:unbindXML元素。
<!ELEMENT unbind (segment)>
<!ELEMENT unbind (segment)>
If the request succeeds, the server MUST return 200 (OK) or 204 (No Content) when the binding was successfully deleted.
如果请求成功，则成功删除绑定时，服务器必须返回200（确定）或204（无内容）。
If a response body for a successful request is included, it MUST be a DAV:unbind-response XML element. Note that this document does not define any elements for the UNBIND response body, but the DAV:unbind-response element is defined to ensure interoperability between future extensions that do define elements for the UNBIND response body.
如果包含成功请求的响应主体，则它必须是DAV:unbind response XML元素。请注意，本文档没有为UNBIND响应主体定义任何元素，但是定义DAV:UNBIND响应元素是为了确保将来的扩展之间的互操作性，这些扩展确实为UNBIND响应主体定义了元素。
<!ELEMENT unbind-response ANY>
<!ELEMENT unbind-response ANY>
Preconditions:
先决条件：
(DAV:unbind-from-collection): The Request-URI MUST identify a collection.
（DAV：从集合中解除绑定）：请求URI必须标识集合。
(DAV:unbind-source-exists): The DAV:segment element MUST identify a binding in the collection identified by the Request-URI.
（DAV:unbind source exists）：DAV:segment元素必须在由请求URI标识的集合中标识绑定。
(DAV:locked-update-allowed): If the collection identified by the Request-URI is write-locked, then the appropriate token MUST be specified in the request.
（DAV：允许锁定更新）：如果请求URI标识的集合被写锁定，则必须在请求中指定适当的令牌。
(DAV:protected-url-deletion-allowed): If the binding identified by the segment is protected by a write lock, then the appropriate token MUST be specified in the request.
（DAV：允许删除受保护的url）：如果段标识的绑定受写锁保护，则必须在请求中指定适当的令牌。
Postconditions:
后条件：
(DAV:binding-deleted): The collection MUST NOT have a binding for the segment specified in the DAV:segment element in the request body.
（DAV:binding deleted）：集合不能对请求正文中的DAV:segment元素中指定的段具有绑定。
(DAV:lock-deleted): If the internal member URI of the binding specified by the Request-URI and the DAV:segment element in the request body was protected by a write lock at the time of the request, that write lock must have been deleted by the request.
（DAV:lock deleted）：如果请求URI和请求正文中的DAV:segment元素指定的绑定的内部成员URI在请求时受到写锁的保护，则该写锁必须已被请求删除。
>> Request:
>>请求：
UNBIND /CollX HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 117
UNBIND /CollX HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 117
<?xml version="1.0" encoding="utf-8" ?>
<D:unbind xmlns:D="DAV:">
<D:segment>foo.html</D:segment>
</D:unbind>
<?xml version="1.0" encoding="utf-8" ?>
<D:unbind xmlns:D="DAV:">
<D:segment>foo.html</D:segment>
</D:unbind>
>> Response:
>>答复：
HTTP/1.1 200 OK
HTTP/1.1200ok
The server removed the binding named "foo.html" from the collection, "http://www.example.com/CollX". A request to the resource named "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) response.
服务器从集合中删除了名为“foo.html”的绑定http://www.example.com/CollX". 对名为“”的资源的请求http://www.example.com/CollX/foo.html“将返回404（未找到）响应。
The REBIND method removes a binding to a resource from a collection, and adds a binding to that resource into the collection identified by the Request-URI. The request body specifies the binding to be added (segment) and the old binding to be removed (href). It is effectively an atomic form of a MOVE request, and MUST be treated the same way as MOVE for the purpose of determining access permissions.
REBIND方法从集合中删除与资源的绑定，并将与该资源的绑定添加到由请求URI标识的集合中。请求正文指定要添加的绑定（段）和要删除的旧绑定（href）。它实际上是移动请求的原子形式，在确定访问权限时，必须以与移动相同的方式对待它。
If a REBIND request fails, the server state preceding the request MUST be restored. This method is unsafe and idempotent (see [RFC2616], Section 9.1).
如果重新绑定请求失败，则必须恢复请求之前的服务器状态。该方法不安全且幂等（见[RFC2616]，第9.1节）。
Marshalling:
编组：
The request MAY include an Overwrite header.
请求可能包括覆盖报头。
The request body MUST be a DAV:rebind XML element.
请求主体必须是DAV:rebindXML元素。
<!ELEMENT rebind (segment, href)>
<!ELEMENT rebind (segment, href)>
If the request succeeds, the server MUST return 201 (Created) when a new binding was created and 200 (OK) or 204 (No Content) when an existing binding was replaced.
如果请求成功，则服务器必须在创建新绑定时返回201（已创建），在替换现有绑定时返回200（确定）或204（无内容）。
If a response body for a successful request is included, it MUST be a DAV:rebind-response XML element. Note that this document does not define any elements for the REBIND response body, but the DAV:rebind-response element is defined to ensure interoperability between future extensions that do define elements for the REBIND response body.
如果包含成功请求的响应体，则它必须是DAV:rebind响应XML元素。请注意，本文档没有为重新绑定响应主体定义任何元素，但定义了DAV:REBIND响应元素以确保将来的扩展之间的互操作性，这些扩展确实为重新绑定响应主体定义了元素。
<!ELEMENT rebind-response ANY>
<!ELEMENT rebind-response ANY>
Preconditions:
先决条件：
(DAV:rebind-into-collection): The Request-URI MUST identify a collection.
（DAV：重新绑定到集合）：请求URI必须标识集合。
(DAV:rebind-source-exists): The DAV:href element MUST identify a resource.
（DAV:rebind source exists）：DAV:href元素必须标识资源。
(DAV:cross-server-binding): If the resource identified by the DAV: href element in the request body is on another server from the collection identified by the Request-URI, the server MUST support cross-server bindings (servers that do not support cross-server bindings can use this condition code to signal the client exactly why the request failed).
（DAV：跨服务器绑定）：如果请求正文中由DAV:href元素标识的资源位于由请求URI标识的集合中的另一台服务器上，则该服务器必须支持跨服务器绑定（不支持跨服务器绑定的服务器可以使用此条件代码向客户端发出请求失败的确切原因的信号）.
(DAV:name-allowed): The name specified by the DAV:segment is available for use as a new binding name.
（DAV:name-allowed）：由DAV:segment指定的名称可用作新的绑定名称。
(DAV:can-overwrite): If the collection already contains a binding with the specified path segment, and if an Overwrite header is included, the value of the Overwrite header MUST be "T".
（DAV:可以覆盖）：如果集合已包含具有指定路径段的绑定，并且包含覆盖标头，则覆盖标头的值必须为“T”。
(DAV:cycle-allowed): If the DAV:href element identifies a collection, and if the Request-URI identifies a collection that is a member of that collection, the server MUST support cycles in the URI namespace (servers that do not support cycles can use this condition code to signal the client exactly why the request failed).
（DAV:cycle allowed）：如果DAV:href元素标识一个集合，并且如果请求URI标识一个属于该集合的集合，则服务器必须支持URI命名空间中的循环（不支持循环的服务器可以使用此条件代码向客户端发信号，说明请求失败的确切原因）。
(DAV:locked-update-allowed): If the collection identified by the Request-URI is write-locked, then the appropriate token MUST be specified in the request.
（DAV：允许锁定更新）：如果请求URI标识的集合被写锁定，则必须在请求中指定适当的令牌。
(DAV:protected-url-modification-allowed): If the collection identified by the Request-URI already contains a binding with the specified path segment, and if that binding is protected by a write lock, then the appropriate token MUST be specified in the request.
（DAV：允许受保护的url修改）：如果请求URI标识的集合已包含具有指定路径段的绑定，并且该绑定受写锁保护，则必须在请求中指定适当的令牌。
(DAV:locked-source-collection-update-allowed): If the collection identified by the parent collection prefix of the DAV:href URI is write-locked, then the appropriate token MUST be specified in the request.
（DAV:locked source collection update allowed）：如果由DAV:href URI的父集合前缀标识的集合被写锁定，则必须在请求中指定相应的令牌。
(DAV:protected-source-url-deletion-allowed): If the DAV:href URI is protected by a write lock, then the appropriate token MUST be specified in the request.
（DAV:允许删除受保护的源url）：如果DAV:href URI受写锁保护，则必须在请求中指定相应的令牌。
Postconditions:
后条件：
(DAV:new-binding): The collection MUST have a binding that maps the segment specified in the DAV:segment element in the request body, to the resource that was identified by the DAV:href element in the request body.
（DAV:new binding）：集合必须具有一个绑定，该绑定将请求正文中的DAV:segment元素中指定的段映射到由请求正文中的DAV:href元素标识的资源。
(DAV:binding-deleted): The URL specified in the DAV:href element in the request body MUST NOT be mapped to a resource.
（DAV:binding deleted）：请求正文中DAV:href元素中指定的URL不得映射到资源。
(DAV:lock-deleted): If the URL specified in the DAV:href element in the request body was protected by a write lock at the time of the request, that write lock must have been deleted by the request.
（DAV:lock deleted）：如果请求正文中DAV:href元素中指定的URL在请求时受写锁保护，则该写锁必须已被请求删除。
>> Request:
>>请求：
REBIND /CollX HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 176
REBIND /CollX HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 176
<?xml version="1.0" encoding="utf-8" ?>
<D:rebind xmlns:D="DAV:">
<D:segment>foo.html</D:segment>
<D:href>http://www.example.com/CollY/bar.html</D:href>
</D:rebind>
<?xml version="1.0" encoding="utf-8" ?>
<D:rebind xmlns:D="DAV:">
<D:segment>foo.html</D:segment>
<D:href>http://www.example.com/CollY/bar.html</D:href>
</D:rebind>
>> Response:
>>答复：
HTTP/1.1 200 OK
HTTP/1.1200ok
The server added a new binding to the collection,
"http://www.example.com/CollX", associating "foo.html" with the
resource identified by the URI
"http://www.example.com/CollY/bar.html" and removes the binding named
"bar.html" from the collection identified by the URI
The server added a new binding to the collection,
"http://www.example.com/CollX", associating "foo.html" with the
resource identified by the URI
"http://www.example.com/CollY/bar.html" and removes the binding named
"bar.html" from the collection identified by the URI
"http://www.example.com/CollY". Clients can now use the URI "http://www.example.com/CollX/foo.html" to submit requests to that resource, and requests on the URI "http://www.example.com/CollY/bar.html" will fail with a 404 (Not Found) response.
"http://www.example.com/CollY". 客户端现在可以使用URI“http://www.example.com/CollX/foo.html向该资源提交请求，以及URI上的请求http://www.example.com/CollY/bar.html“将以404（未找到）响应失败。
To illustrate the effects of locks and bind loops on a REBIND operation, consider the following collection:
为了说明锁和绑定循环对重新绑定操作的影响，请考虑以下集合：
+------------------+
| Root Collection |
| bindings: |
| CollW |
+------------------+
|
|
|
+-------------------------------+
| Collection C1 |<--------+
| LOCKED infinity | |
| (lock token L1) | |
| bindings: | |
| CollX CollY | |
+-------------------------------+ |
| | |
| | (creates loop) |
| | |
+-----------------+ +------------------+ |
| Collection C2 | | Collection C3 | |
| (inherit lock) | | (inherit lock) | |
| (lock token L1) | | (lock token L1) | |
| bindings: | | bindings: | |
| {none} | | y.gif CollZ | |
+-----------------+ +------------------+ |
| | |
| +-----+
|
+---------------------------+
| Resource R2 |
| (lock inherited from C1) |
| (lock token L1) |
+---------------------------+
+------------------+
| Root Collection |
| bindings: |
| CollW |
+------------------+
|
|
|
+-------------------------------+
| Collection C1 |<--------+
| LOCKED infinity | |
| (lock token L1) | |
| bindings: | |
| CollX CollY | |
+-------------------------------+ |
| | |
| | (creates loop) |
| | |
+-----------------+ +------------------+ |
| Collection C2 | | Collection C3 | |
| (inherit lock) | | (inherit lock) | |
| (lock token L1) | | (lock token L1) | |
| bindings: | | bindings: | |
| {none} | | y.gif CollZ | |
+-----------------+ +------------------+ |
| | |
| +-----+
|
+---------------------------+
| Resource R2 |
| (lock inherited from C1) |
| (lock token L1) |
+---------------------------+
(where L1 is "urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9").
（其中L1为“urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9”）。
Note that the binding between CollZ and C1 creates a loop in the containment hierarchy. Servers are not required to support such loops, though the server in this example does.
注意，CollZ和C1之间的绑定在包含层次结构中创建了一个循环。虽然本例中的服务器支持这样的循环，但并不要求服务器支持这样的循环。
The REBIND request below will remove the segment "CollZ" from C3 and add a new binding from "CollA" to the collection C2.
下面的重新绑定请求将从C3中删除段“CollZ”，并将新绑定从“CollA”添加到集合C2。
REBIND /CollW/CollX HTTP/1.1
Host: www.example.com
If: (<urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9>)
Content-Type: application/xml; charset="utf-8"
Content-Length: 152
REBIND /CollW/CollX HTTP/1.1
Host: www.example.com
If: (<urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9>)
Content-Type: application/xml; charset="utf-8"
Content-Length: 152
<?xml version="1.0" encoding="utf-8" ?>
<D:rebind xmlns:D="DAV:">
<D:segment>CollA</D:segment>
<D:href>/CollW/CollY/CollZ</D:href>
</D:rebind>
<?xml version="1.0" encoding="utf-8" ?>
<D:rebind xmlns:D="DAV:">
<D:segment>CollA</D:segment>
<D:href>/CollW/CollY/CollZ</D:href>
</D:rebind>
The outcome of the REBIND operation is:
重新绑定操作的结果是：
+------------------+
| Root Collection |
| bindings: |
| CollW |
+------------------+
|
|
|
+-------------------------------+
| Collection C1 |
| LOCKED infinity |
| (lock token L1) |
| bindings: |
| CollX CollY |
+-------------------------------+
| ^ |
| | |
+-----------------+ | +------------------+
| Collection C2 | | | Collection C3 |
|(inherited lock) | | | (inherited lock) |
|(lock token L1) | | | (lock token L1) |
| bindings: | | | bindings: |
| CollA | | | y.gif |
+-----------------+ | +------------------+
| | |
+---------------+ |
(creates loop) |
+---------------------------+
| Resource R2 |
| (inherited lock from C1) |
| (lock token L1) |
+---------------------------+
+------------------+
| Root Collection |
| bindings: |
| CollW |
+------------------+
|
|
|
+-------------------------------+
| Collection C1 |
| LOCKED infinity |
| (lock token L1) |
| bindings: |
| CollX CollY |
+-------------------------------+
| ^ |
| | |
+-----------------+ | +------------------+
| Collection C2 | | | Collection C3 |
|(inherited lock) | | | (inherited lock) |
|(lock token L1) | | | (lock token L1) |
| bindings: | | | bindings: |
| CollA | | | y.gif |
+-----------------+ | +------------------+
| | |
+---------------+ |
(creates loop) |
+---------------------------+
| Resource R2 |
| (inherited lock from C1) |
| (lock token L1) |
+---------------------------+
The 208 (Already Reported) status code can be used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly. For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other bindings will use the 208 status, and no DAV:response elements for their descendants are included.
208（已报告）状态代码可以在DAV:propstat响应元素中使用，以避免重复枚举同一集合的多个绑定的内部成员。对于请求范围内集合的每个绑定，只有一个将报告200状态，而所有其他绑定的后续DAV:response元素将使用208状态，并且不包括其子代的DAV:response元素。
Note that the 208 status will only occur for "Depth: infinity" requests, and that it is of particular importance when the multiple collection bindings cause a bind loop as discussed in Section 2.2.
请注意，208状态只会出现在“Depth:infinity”请求中，并且当多个集合绑定导致绑定循环时（如第2.2节所述），它特别重要。
A client can request the DAV:resource-id property in a PROPFIND request to guarantee that they can accurately reconstruct the binding structure of a collection with multiple bindings to a single resource.
客户机可以在PROPFIND请求中请求DAV:resource id属性，以确保它们能够准确地重建集合的绑定结构，并将多个绑定到单个资源。
For backward compatibility with clients not aware of the 208 status code appearing in multistatus response bodies, it SHOULD NOT be used unless the client has signaled support for this specification using the "DAV" request header (see Section 8.2). Instead, a 508 status should be returned when a binding loop is discovered. This allows the server to return the 508 as the top-level return status, if it discovers it before it started the response, or in the middle of a multistatus, if it discovers it in the middle of streaming out a multistatus response.
对于不知道出现在multistatus响应主体中的208状态代码的客户端的向后兼容性，除非客户端使用“DAV”请求头发出支持该规范的信号（见第8.2节），否则不应使用该代码。相反，当发现绑定循环时，应该返回508状态。这允许服务器返回508作为顶层返回状态，如果它在启动响应之前发现它，或者在多状态的中间，如果发现它在流出多状态响应的中间。
For example, consider a PROPFIND request on /Coll (bound to collection C), where the members of /Coll are /Coll/Foo (bound to resource R) and /Coll/Bar (bound to collection C).
例如，考虑在/COLL（绑定到集合C）上的PROFSET请求，其中Coll的成员是/Coll /FoO（绑定到资源R）和/ Coll / BAR（绑定到集合C）。
>> Request:
>>请求：
PROPFIND /Coll/ HTTP/1.1
Host: www.example.com
Depth: infinity
DAV: bind
Content-Type: application/xml; charset="utf-8"
Content-Length: 152
PROPFIND /Coll/ HTTP/1.1
Host: www.example.com
Depth: infinity
DAV: bind
Content-Type: application/xml; charset="utf-8"
Content-Length: 152
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:displayname/>
<D:resource-id/>
</D:prop>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:displayname/>
<D:resource-id/>
</D:prop>
</D:propfind>
>> Response:
>>答复：
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 1241
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 1241
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/Coll/</D:href>
<D:propstat>
<D:prop>
<D:displayname>Loop Demo</D:displayname>
<D:resource-id>
<D:href
>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
</D:resource-id>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.example.com/Coll/Foo</D:href>
<D:propstat>
<D:prop>
<D:displayname>Bird Inventory</D:displayname>
<D:resource-id>
<D:href
>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9</D:href>
</D:resource-id>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.example.com/Coll/Bar</D:href>
<D:propstat>
<D:prop>
<D:displayname>Loop Demo</D:displayname>
<D:resource-id>
<D:href
>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
</D:resource-id>
</D:prop>
<D:status>HTTP/1.1 208 Already Reported</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/Coll/</D:href>
<D:propstat>
<D:prop>
<D:displayname>Loop Demo</D:displayname>
<D:resource-id>
<D:href
>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
</D:resource-id>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.example.com/Coll/Foo</D:href>
<D:propstat>
<D:prop>
<D:displayname>Bird Inventory</D:displayname>
<D:resource-id>
<D:href
>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9</D:href>
</D:resource-id>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.example.com/Coll/Bar</D:href>
<D:propstat>
<D:prop>
<D:displayname>Loop Demo</D:displayname>
<D:resource-id>
<D:href
>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
</D:resource-id>
</D:prop>
<D:status>HTTP/1.1 208 Already Reported</D:status>
</D:propstat>
</D:response>
</D:multistatus>
In this example, the client isn't aware of the 208 status code introduced by this specification. As the "Depth: infinity" PROPFIND request would cause a loop condition, the whole request is rejected with a 508 status.
在此示例中，客户机不知道此规范引入的208状态代码。由于“Depth:infinity”PROPFIND请求将导致循环条件，因此整个请求将以508状态被拒绝。
>> Request:
>>请求：
PROPFIND /Coll/ HTTP/1.1
Host: www.example.com
Depth: infinity
Content-Type: application/xml; charset="utf-8"
Content-Length: 125
PROPFIND /Coll/ HTTP/1.1
Host: www.example.com
Depth: infinity
Content-Type: application/xml; charset="utf-8"
Content-Length: 125
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop> <D:displayname/> </D:prop>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop> <D:displayname/> </D:prop>
</D:propfind>
>> Response:
>>答复：
HTTP/1.1 508 Loop Detected
检测到HTTP/1.1 508循环
The 508 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with "Depth: infinity". This status indicates that the entire operation failed.
508（检测到循环）状态代码表示服务器终止了操作，因为它在处理“Depth:infinity”请求时遇到无限循环。此状态表示整个操作失败。
If the server supports bindings, it MUST return the compliance class name "bind" as a field in the "DAV" response header (see [RFC4918], Section 10.1) from an OPTIONS request on any resource implemented by that server. A value of "bind" in the "DAV" header MUST indicate that the server supports all MUST-level requirements and REQUIRED features specified in this document.
如果服务器支持绑定，则必须在“DAV”响应头（请参阅[RFC4918]，第10.1节）中从该服务器实现的任何资源上的选项请求返回符合性类名“bind”，作为字段。“DAV”标题中的“bind”值必须表示服务器支持本文档中指定的所有必须级别要求和必需功能。
Clients SHOULD signal support for all MUST-level requirements and REQUIRED features by submitting a "DAV" request header containing the compliance class name "bind". In particular, the client MUST understand the 208 status code defined in Section 7.1.
客户机应通过提交包含合规类名“bind”的“DAV”请求头来表示对所有必须级别的要求和所需功能的支持。特别是，客户必须了解第7.1节中定义的208状态代码。
Locking is an optional feature of WebDAV ([RFC4918]). The base WebDAV specification and this protocol extension have been designed in parallel, making sure that all features of WebDAV can be implemented on a server that implements this protocol as well.
锁定是WebDAV（[RFC4918]）的可选功能。基本WebDAV规范和此协议扩展是并行设计的，确保WebDAV的所有功能也可以在实现此协议的服务器上实现。
Unfortunately, WebDAV uses the term "lock-root" inconsistently. It is introduced in Section 6.1 of [RFC4918], point 2, as:
不幸的是，WebDAV使用的术语“lock root”不一致。[RFC4918]第2点第6.1节对其进行了介绍，如下所示：
2. A resource becomes directly locked when a LOCK request to a URL of that resource creates a new lock. The "lock-root" of the new lock is that URL. If at the time of the request, the URL is not mapped to a resource, a new empty resource is created and directly locked.
2. 当对资源的URL的锁定请求创建新的锁定时，资源将被直接锁定。新锁的“锁根”就是该URL。如果在请求时，URL未映射到资源，则会创建一个新的空资源并直接锁定。
On the other hand, [RFC4918], Section 9.10.1 states:
另一方面，[RFC4918]第9.10.1节规定：
A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The resource identified in the Request-URI becomes the root of the lock.
对现有资源的锁请求将在请求URI标识的资源上创建锁，前提是该资源尚未使用冲突锁锁定。请求URI中标识的资源将成为锁的根。
Servers that implement both WebDAV locking and support for multiple bindings MUST use the first interpretation: the lock-root is the URI through which the lock was created, not a resource. This URI, and potential aliases of this URI ([RFC4918], Section 5), are said to be "protected" by the lock.
实现WebDAV锁定和支持多个绑定的服务器必须使用第一种解释：锁根是创建锁的URI，而不是资源。该URI以及该URI的潜在别名（[RFC4918]，第5节）被称为受锁“保护”。
As defined in the introduction to Section 7 of [RFC4918], write operations that modify the state of a locked resource require that the lock token is submitted with the request. Consistent with WebDAV, the state of the resource consists of the content ("any variant"), dead properties, lockable live properties (item 1), plus, for a collection, all its bindings (item 2). Note that this, by definition, does not depend on the Request-URI to which the write operation is applied (the locked state is a property of the resource, not its URI).
如[RFC4918]第7节介绍中所定义，修改锁定资源状态的写入操作要求将锁定令牌与请求一起提交。与WebDAV一致，资源的状态由内容（“任何变体”）、无效属性、可锁定的活动属性（项目1）以及集合的所有绑定（项目2）组成。请注意，根据定义，这并不取决于应用写入操作的请求URI（锁定状态是资源的属性，而不是其URI）。
However, the lock-root is the URI through which the lock was requested. Thus, the protection defined in item 3 of the list does not apply to additional URIs that may be mapped to the same resource due to the existence of multiple bindings.
但是，锁根是请求锁的URI。因此，列表第3项中定义的保护不适用于由于存在多个绑定而可能映射到同一资源的其他URI。
Consider a root collection "/", containing the two collections C1 and C2, named "/CollX" and "/CollY", and a child resource R, bound to C1 as "/CollX/test" and bound to C2 as "/CollY/test":
考虑根集合“/”，包含两个集合C1和C2，命名为“/Cyx”和“/CyLy”，以及子资源R，绑定到C1为“/COXX/TEST”，并绑定到C2为“/COLLY/TEST”：
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| test | | test |
+---------------+ +---------------+
| |
| |
| |
+------------------+
| Resource R |
+------------------+
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| test | | test |
+---------------+ +---------------+
| |
| |
| |
+------------------+
| Resource R |
+------------------+
Given a host name of "www.example.com", applying a depth-zero write lock to "/CollX/test" will lock the resource R, and the lock-root of this lock will be "http://www.example.com/CollX/test".
给定一个主机名“www.example.com”，对“/CollX/test”应用深度为零的写锁将锁定资源R，该锁的锁根将为”http://www.example.com/CollX/test".
Thus, the following operations will require that the associated lock token is submitted with the "If" request header ([RFC4918], Section 10.4):
因此，以下操作将要求与“如果”请求头一起提交关联的锁令牌（[RFC4918]，第10.4节）：
o a PUT or PROPPATCH request modifying the content or lockable properties of resource R (as R is locked) -- no matter which URI is used as request target, and
o PUT或PROPPATCH请求修改资源R的内容或可锁定属性（当R被锁定时）——无论哪个URI用作请求目标，以及
o a MOVE, REBIND, UNBIND, or DELETE request causing "/CollX/test" not to be mapped to resource R anymore (be it addressed to "/CollX" or "/CollX/test").
o 移动、重新绑定、解除绑定或删除请求，导致“/CollX/test”不再映射到资源R（可以是“/CollX”或“/CollX/test”）。
The following operations will not require submission of the lock token:
以下操作不需要提交锁令牌：
o a DELETE request addressed to "/CollY" or "/CollY/test", as it does not affect the resource R, nor the lock-root,
o 地址为“/CollY”或“/CollY/test”的删除请求，因为它既不影响资源R，也不影响锁根，
o for the same reason, an UNBIND request removing the binding "test" from collection C2, or the binding "CollY" from the root collection, and
o 出于同样的原因，从集合C2中删除绑定“test”或从根集合中删除绑定“CollY”的解除绑定请求，以及
o similarly, a MOVE or REBIND request causing "/CollY/test" not being mapped to resource R anymore.
o 类似地，移动或重新绑定请求导致“/CollY/test”不再映射到资源R。
Note that despite the lock-root being "http://www.example.com/CollX/test", an UNLOCK request can be addressed through any URI mapped to resource R, as UNLOCK operates on the resource identified by the Request-URI, not that URI (see [RFC4918], Section 9.11).
请注意，尽管锁根为“http://www.example.com/CollX/test“，解锁请求可以通过映射到资源R的任何URI寻址，因为解锁操作由请求URI标识的资源，而不是该URI（请参阅[RFC4918]，第9.11节）。
Note that the WebDAV Access Control Protocol has been designed for compatibility with systems that allow multiple URIs to map to the same resource (see [RFC3744], Section 5):
请注意，WebDAV访问控制协议旨在与允许多个URI映射到同一资源的系统兼容（请参阅[RFC3744]，第5节）：
Access control properties (especially DAV:acl and DAV:inherited-acl-set) are defined on the resource identified by the Request-URI of a PROPFIND request. A direct consequence is that if the resource is accessible via multiple URI, the value of access control properties is the same across these URI.
访问控制属性（特别是DAV:acl和DAV:inherited acl set）是在由PROPFIND请求的请求URI标识的资源上定义的。直接的结果是，如果资源可以通过多个URI访问，那么访问控制属性的值在这些URI中是相同的。
Furthermore, note that BIND and REBIND behave the same as MOVE with respect to the DAV:acl property (see [RFC3744], Section 7.3).
此外，请注意，就DAV:acl属性而言，BIND和REBIND的行为与MOVE相同（请参见[RFC3744]，第7.3节）。
Servers that implement Workspaces ([RFC3253], Section 6) and Version-Controlled Collections ([RFC3253], Section 14) already need to implement BIND-like behavior in order to handle UPDATE and UNCHECKOUT semantics.
实现工作区（[RFC3253]，第6节）和版本控制集合（[RFC3253]，第14节）的服务器已经需要实现类似绑定的行为，以便处理更新和取消选中语义。
Consider a workspace "/ws1/", containing the version-controlled, checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/ CollY", and a version-controlled resource R, bound to C1 as "/ws1/ CollX/test":
考虑一个工作区“/WS1/”，包含版本控制的、签出的集合C1和C2，命名为“/WS1/COLX”和“/WS1/COLLY”，以及版本控制的资源R，绑定到C1为“/WS1/COXX/TEST”：
+-------------------------+
| Workspace |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | |
| test | | |
+---------------+ +---------------+
|
|
|
+------------------+
| Resource R |
+------------------+
+-------------------------+
| Workspace |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | |
| test | | |
+---------------+ +---------------+
|
|
|
+------------------+
| Resource R |
+------------------+
Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but undoing the checkout on C1 will undo part of the MOVE request, thus restoring the binding from C1 to R, but keeping the new binding from C2 to R:
将“/ws1/CollX/test”移动到“/ws1/CollY”，签入C2，但撤消C1上的签出将撤消部分移动请求，从而恢复从C1到R的绑定，但保留从C2到R的新绑定：
>> Request:
>>请求：
MOVE /ws1/CollX/test HTTP/1.1
Host: www.example.com
Destination: /ws1/CollY/test
MOVE /ws1/CollX/test HTTP/1.1
Host: www.example.com
Destination: /ws1/CollY/test
>> Response:
>>答复：
HTTP/1.1 204 No Content
HTTP/1.1 204无内容
>> Request:
>>请求：
CHECKIN /ws1/CollY/ HTTP/1.1
Host: www.example.com
CHECKIN /ws1/CollY/ HTTP/1.1
Host: www.example.com
>> Response:
>>答复：
HTTP/1.1 201 Created
Cache-Control: no-cache
Location: http://repo.example.com/his/17/ver/42
HTTP/1.1 201 Created
Cache-Control: no-cache
Location: http://repo.example.com/his/17/ver/42
>> Request:
>>请求：
UNCHECKOUT /ws1/CollX/ HTTP/1.1
Host: www.example.com
UNCHECKOUT /ws1/CollX/ HTTP/1.1
Host: www.example.com
>> Response:
>>答复：
HTTP/1.1 200 OK Cache-Control: no-cache
HTTP/1.1 200正常缓存控制：无缓存
As a result, both C1 and C2 would have a binding to R:
因此，C1和C2都与R有约束力：
+-------------------------+
| Workspace |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| test | | test |
+---------------+ +---------------+
| |
| |
| |
+------------------+
| Resource R |
+------------------+
+-------------------------+
| Workspace |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| test | | test |
+---------------+ +---------------+
| |
| |
| |
+------------------+
| Resource R |
+------------------+
The MOVE semantics defined in Section 3.15 of [RFC3253] already require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the same version history (as exposed in the DAV:version-history property). Furthermore, the UNCHECKOUT semantics (which in this case is similar to UPDATE, see Section 14.11 of [RFC3253]) require:
[RFC3253]第3.15节中定义的移动语义已经要求“/ws1/CollX/test”和“/ws1/CollY/test”具有相同的版本历史记录（如DAV:version history属性中所示）。此外，UNCHECKOUT语义（在本例中类似于更新，参见[RFC3253]第14.11节）要求：
If a new version-controlled member is in a workspace that already has a version-controlled resource for that version history, then the new version-controlled member MUST be just a binding (i.e., another name for) that existing version-controlled resource.
如果新版本受控成员位于已具有该版本历史记录的版本受控资源的工作区中，则新版本受控成员必须只是该现有版本受控资源的绑定（即，另一个名称）。
Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the same resource R, and have identical DAV:resource-id properties.
因此，“/ws1/CollX/test”和“/ws1/CollY/test”将绑定到同一个资源R，并具有相同的DAV:resource id属性。
This section is provided to make WebDAV implementers aware of the security implications of this protocol.
本节旨在使WebDAV实现者了解此协议的安全含义。
All of the security considerations of HTTP/1.1 ([RFC2616], Section 15) and the WebDAV Distributed Authoring Protocol specification ([RFC4918], Section 20) also apply to this protocol specification. In addition, bindings introduce several new security concerns and increase the risk of some existing threats. These issues are detailed below.
HTTP/1.1（[RFC2616]，第15节）和WebDAV分布式创作协议规范（[RFC4918]，第20节）的所有安全注意事项也适用于本协议规范。此外，绑定引入了几个新的安全问题，并增加了一些现有威胁的风险。这些问题详述如下。
In a context where cross-server bindings are supported, creating bindings on a trusted server may make it possible for a hostile agent to induce users to send private information to a target on a different server.
在支持跨服务器绑定的上下文中，在受信任的服务器上创建绑定可能会使恶意代理诱使用户向其他服务器上的目标发送私人信息。
Although bind loops were already possible in HTTP 1.1, the introduction of the BIND method creates a new avenue for clients to create loops accidentally or maliciously. If the binding and its target are on the same server, the server may be able to detect BIND requests that would create loops. Servers are required to detect loops that are caused by bindings to collections during the processing of any requests with "Depth: infinity".
虽然绑定循环在HTTP 1.1中已经是可能的，但bind方法的引入为客户端意外或恶意创建循环创造了新的途径。如果绑定及其目标位于同一台服务器上，则服务器可能能够检测到将创建循环的绑定请求。在处理任何具有“Depth:infinity”的请求期间，服务器需要检测由绑定到集合引起的循环。
Denial-of-service attacks were already possible by posting URIs that were intended for limited use at heavily used Web sites. The introduction of BIND creates a new avenue for similar denial-of-service attacks. If cross-server bindings are supported, clients can now create bindings at heavily used sites to target locations that were not designed for heavy usage.
通过在大量使用的网站上发布受限制使用的URI，已经可以进行拒绝服务攻击。BIND的引入为类似的拒绝服务攻击开辟了一条新途径。如果支持跨服务器绑定，客户机现在可以在使用频繁的站点上创建绑定，以将其绑定到未设计用于大量使用的目标位置。
If the DAV:parent-set property is maintained on a resource, the owners of the bindings risk revealing private locations. The directory structures where bindings are located are available to anyone who has access to the DAV:parent-set property on the resource. Moving a binding may reveal its new location to anyone with access to DAV:parent-set on its resource.
如果在资源上维护DAV:parent set属性，则绑定的所有者有暴露私有位置的风险。任何有权访问资源上DAV:parent set属性的人都可以使用绑定所在的目录结构。移动绑定可能会向任何有权访问其资源上的DAV:parent集的人显示其新位置。
If the server maintains the DAV:parent-set property in response to bindings created in other administrative domains, it is exposed to hostile attempts to make it devote resources to adding bindings to the list.
如果服务器维护DAV:parent set属性以响应在其他管理域中创建的绑定，则会有恶意尝试使其投入资源将绑定添加到列表中。
All internationalization considerations mentioned in Section 19 of [RFC4918] also apply to this document.
[RFC4918]第19节中提到的所有国际化注意事项也适用于本文件。
Section 7 defines the HTTP status codes 208 (Already Reported) and 508 (Loop Detected), which have been added to the HTTP Status Code Registry.
第7节定义了HTTP状态代码208（已报告）和508（检测到循环），它们已添加到HTTP状态代码注册表中。
This document is the collaborative product of the authors and Tyson Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited from thoughtful discussion by Jim Amsden, Peter Carlson, Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Cyrus Daboo, Spencer Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Alexey Melnikov, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and other members of the concluded WebDAV working group.
本文件是作者与泰森·齐哈亚、吉姆·戴维斯、查克·费伊和朱迪思·斯莱因合作的成果。它得益于吉姆·阿姆斯登、彼得·卡尔森、史蒂夫·卡特、肯·科尔、埃利斯·科恩、丹·康诺利、布鲁斯·克拉根、赛勒斯·达布、斯宾塞·道金斯、马克·戴、沃纳·多恩、拉吉夫·杜莱佩、大卫·杜兰德、丽莎·杜肖特、斯特凡·艾辛、罗伊·菲尔丁、雅伦·戈兰、乔·希尔德布兰德、弗雷德·希特、亚历克斯·霍普曼、詹姆斯·亨特、马库斯·贾格、卡恩·霍普曼和其他人的深思熟虑的讨论，Chris Kaler、Manoj Kasichainula、Rohit Khare、Brian Korver、Daniel LaLiberte、Steve Martin、Larry Masinter、Jeff McAffer、Alexey Melnikov、Surendra Koduru Reddy、Max Rible、Sam Ruby、Bradley中士、Nick Shelness、John Stracke、John Tigue、John Turner、Kevin Wiggen以及WebDAV工作组的其他成员。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918]Dusseault，L.，Ed.“Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC4918，2007年6月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126/>.
[XML]Bray，T.，Paoli，J.，Sperberg McQueen，C.，Maler，E.，和F.Yergeau，“可扩展标记语言（XML）1.0（第五版）”，W3C REC-XML-20081126，2008年11月<http://www.w3.org/TR/2008/REC-xml-20081126/>.
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253]Clemm，G.，Amsden，J.，Ellison，T.，Kaler，C.，和J.Whitehead，“WebDAV的版本控制扩展（Web分布式创作和版本控制）”，RFC 3253，2002年3月。
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.
[RFC3744]Clemm，G.，Reschke，J.，Sedlar，E.，和J.Whitehead，“Web分布式创作和版本控制（WebDAV）访问控制协议”，RFC 3744，2004年5月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
Index
指数
2 208 Already Reported (status code) 31, 41
2 208已报告（状态代码）31、41
5 508 Loop Detected (status code) 34, 41
5检测到508环路（状态代码）34、41
B BIND method 21 Marshalling 22 Postconditions 23 Preconditions 22 Binding 6 Binding Integrity 6-7, 21
B绑定方法21编组22后条件23先决条件22绑定6绑定完整性6-7，21
C Collection 6 Condition Names DAV:bind-into-collection (pre) 22 DAV:bind-source-exists (pre) 22 DAV:binding-allowed (pre) 23 DAV:binding-deleted (post) 25, 28 DAV:can-overwrite (pre) 23, 27 DAV:cross-server-binding (pre) 23, 27
C集合6条件名称DAV:绑定到集合（pre）22 DAV:绑定源存在（pre）22 DAV:允许绑定（pre）23 DAV:绑定已删除（post）25,28 DAV:可以覆盖（pre）23,27 DAV:跨服务器绑定（pre）23,27
DAV:cycle-allowed (pre) 23, 27 DAV:lock-deleted (post) 25, 28 DAV:locked-overwrite-allowed (pre) 23 DAV:locked-source-collection-update-allowed (pre) 28 DAV:locked-update-allowed (pre) 23, 25, 27 DAV:name-allowed (pre) 23, 27 DAV:new-binding (post) 23, 28 DAV:protected-source-url-deletion-allowed (pre) 28 DAV:protected-url-deletion-allowed (pre) 25 DAV:protected-url-modification-allowed (pre) 27 DAV:rebind-into-collection (pre) 27 DAV:rebind-source-exists (pre) 27 DAV:unbind-from-collection (pre) 25 DAV:unbind-source-exists (pre) 25
DAV:允许循环（预）23,27 DAV:允许锁定删除（后）25,28 DAV:允许锁定覆盖（前）23 DAV:允许锁定源集合更新（前）28 DAV:允许锁定更新（前）23,25,27 DAV:允许名称（前）23,27 DAV:允许新绑定（后）23,28 DAV:允许保护源url删除（前）28 DAV:允许保护url删除（前）25 DAV:允许修改受保护的url（预）27 DAV:重新绑定到集合（预）27 DAV:重新绑定源存在（预）27 DAV:从集合取消绑定（预）25 DAV:取消绑定源存在（预）25
D DAV header compliance class 'bind' 34 DAV:bind-into-collection precondition 22 DAV:bind-source-exists precondition 22 DAV:binding-allowed precondition 23 DAV:binding-deleted postcondition 25, 28 DAV:can-overwrite precondition 23, 27 DAV:cross-server-binding precondition 23, 27 DAV:cycle-allowed precondition 23, 27 DAV:lock-deleted postcondition 25, 28 DAV:locked-overwrite-allowed precondition 23 DAV:locked-source-collection-update-allowed precondition 28 DAV:locked-update-allowed precondition 23, 25, 27 DAV:name-allowed precondition 23, 27 DAV:new-binding postcondition 23, 28 DAV:parent-set property 20 DAV:protected-source-url-deletion-allowed precondition 28 DAV:protected-url-deletion-allowed precondition 25 DAV:protected-url-modification-allowed precondition 27 DAV:rebind-into-collection precondition 27 DAV:rebind-source-exists precondition 27 DAV:resource-id property 19 DAV:unbind-from-collection precondition 25 DAV:unbind-source-exists precondition 25
D DAV标头符合性类“绑定”34 DAV:绑定到集合前提条件22 DAV:绑定源存在前提条件22 DAV:允许绑定前提条件23 DAV:绑定已删除后条件25，28 DAV:可以覆盖前提条件23，27 DAV:跨服务器绑定前提条件23，27 DAV:允许循环前提条件23，27 DAV:锁定删除的后条件25,28 DAV:锁定覆盖允许的前提条件23 DAV:锁定源集合更新允许的前提条件28 DAV:锁定更新允许的前提条件23,25,27 DAV:名称允许的前提条件23,27 DAV:新绑定后条件23，28 DAV:父集属性20 DAV:允许删除受保护的源url前提条件28 DAV:允许删除受保护的url前提条件25 DAV:允许修改受保护的url前提条件27 DAV:重新绑定到集合前提条件27 DAV:重新绑定源存在前提条件27 DAV:资源id属性19 DAV:取消绑定到集合前提条件25DAV:取消绑定源已存在
I Internal Member URI 6
I内部成员URI 6
L Locking 35
L锁35
M Methods BIND 21 REBIND 26 UNBIND 24
M方法绑定21重新绑定26取消绑定24
P Path Segment 5 Properties DAV:parent-set 20 DAV:resource-id 19
P路径段5属性DAV:父集合20 DAV:资源id 19
R REBIND method 26 Marshalling 26 Postconditions 28 Preconditions 27
R重新绑定方法26编组26后条件28先决条件27
S Status Codes 208 Already Reported 31, 41 508 Loop Detected 34, 41
S状态代码208已报告31,41 508检测到环路34,41
U UNBIND method 24 Marshalling 24 Postconditions 25 Preconditions 25 URI Mapping 5
U解除绑定方法24编组24后条件25先决条件25 URI映射5
Authors' Addresses
作者地址
Geoffrey Clemm IBM 550 King Street Littleton, MA 01460
杰弗里·克莱姆，马萨诸塞州利特尔顿国王街550号，邮编01460
EMail: geoffrey.clemm@us.ibm.com
EMail: geoffrey.clemm@us.ibm.com
Jason Crawford IBM Research P.O. Box 704 Yorktown Heights, NY 10598
纽约约克敦高地704号邮政信箱，邮编10598
EMail: ccjason@us.ibm.com
EMail: ccjason@us.ibm.com
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke（编辑）greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
EMail: julian.reschke@greenbytes.de
EMail: julian.reschke@greenbytes.de
Jim Whitehead UC Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064
吉姆·怀特黑德加州大学圣克鲁斯分校，计算机科学系，加利福尼亚州圣克鲁斯高街1156号，邮编95064
EMail: ejw@cse.ucsc.edu
EMail: ejw@cse.ucsc.edu