Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 5995 greenbytes
Category: Standards Track September 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 5995 greenbytes
Category: Standards Track September 2010
ISSN: 2070-1721
Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections
使用POST向Web分布式创作和版本控制（WebDAV）集合添加成员
Abstract
摘要
The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".
Web分布式创作和版本控制（WebDAV）的超文本传输协议（HTTP）扩展没有定义应用于集合时“POST”方法的行为，因为基本规范（HTTP）为实现者提供了大量关于“POST”语义的自由。
This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as the Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.
这导致了一种情况，即许多WebDAV服务器根本不实现集合的POST，尽管它非常适合用于向集合添加新成员，其中服务器仍控制着新分配的URL。事实上，Atom发布协议（AtomPublishing Protocol，AtomPub）正是为此目的使用POST的。另一方面，基于WebDAV的协议，例如WebDAV的日历扩展（CalDAV），经常要求客户端选择一个唯一的URL，尽管服务器可以轻松地执行该任务。
This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics.
该规范定义了一种发现机制，通过该机制，服务器可以使用上述“添加集合成员”语义公布对POST请求的支持。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc5995.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5995.
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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Protocol Extension ..............................................4
3.1. Definition of "Add-Member" URI .............................5
3.2. Discovery ..................................................6
3.2.1. DAV:add-member Property (Protected) .................6
3.2.2. Example .............................................6
3.3. Relation to AtomPub's "Slug" Header Field ..................7
3.4. Example Operation ..........................................7
4. Additional Semantics for Existing Methods .......................8
4.1. Additional Preconditions ...................................8
4.2. Example: Failed PUT Request ................................8
5. Relationship to WebDAV Access Control Protocol ..................9
6. Internationalization Considerations .............................9
7. Security Considerations .........................................9
8. Acknowledgements ...............................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................11
Index .............................................................11
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Protocol Extension ..............................................4
3.1. Definition of "Add-Member" URI .............................5
3.2. Discovery ..................................................6
3.2.1. DAV:add-member Property (Protected) .................6
3.2.2. Example .............................................6
3.3. Relation to AtomPub's "Slug" Header Field ..................7
3.4. Example Operation ..........................................7
4. Additional Semantics for Existing Methods .......................8
4.1. Additional Preconditions ...................................8
4.2. Example: Failed PUT Request ................................8
5. Relationship to WebDAV Access Control Protocol ..................9
6. Internationalization Considerations .............................9
7. Security Considerations .........................................9
8. Acknowledgements ...............................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................11
Index .............................................................11
The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) ([RFC4918], Section 9.5) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST":
Web分布式创作和版本控制（WebDAV）的超文本传输协议（HTTP）扩展（[RFC4918]，第9.5节）没有定义应用于集合时“POST”方法的行为，因为基本规范（HTTP）为实现者提供了大量关于“POST”语义的自由：
9.5 POST for Collections
9.5 收集邮件
Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus, the semantics of POST are unmodified when applied to a collection.
根据定义，POST执行的实际功能由服务器决定，并且通常取决于特定的资源，因此，POST应用于集合时的行为无法进行有意义的修改，因为它在很大程度上是未定义的。因此，POST的语义在应用于集合时不会被修改。
This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose ([RFC5023], Section 9.2):
这导致了一种情况，即许多WebDAV服务器根本不实现集合的POST，尽管它非常适合用于向集合添加新成员，其中服务器仍控制着新分配的URL。事实上，Atom发布协议（AtomPublishing Protocol，AtomPub）正是为此目的使用POST的（[RFC5023]，第9.2节）：
9.2 Creating Resources with POST
9.2 使用POST创建资源
To add members to a Collection, clients send POST requests to the URI of the Collection.
要向集合添加成员，客户端将POST请求发送到集合的URI。
On the other hand, WebDAV-based protocols, such as Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task ([RFC4791], Section 5.3.2):
另一方面，基于WebDAV的协议，例如WebDAV的日历扩展（CalDAV），经常要求客户端选择唯一的URL，尽管服务器可以轻松执行该任务（[RFC4791]，第5.3.2节）：
5.3.2 Creating Calendar Object Resources
5.3.2 创建日历对象资源
...
...
When servers create new resources, it's not hard for the server to choose an unmapped URI. It's slightly tougher for clients, because a client might not want to examine all resources in the collection and might not want to lock the entire collection to ensure that a new resource isn't created with a name collision. (...)
当服务器创建新资源时，服务器不难选择未映射的URI。对于客户端来说，这稍微有些困难，因为客户端可能不希望检查集合中的所有资源，也可能不希望锁定整个集合以确保创建新资源时不会发生名称冲突。(...)
Letting the server choose the member URI not only is a simplification for certain types of clients, but can also reduce the complexity of the server (in that it doesn't need to persist an additional client-supplied identifier where it already has an internal one like a Universally Unique Identifier (UUID) or a primary key).
让服务器选择成员URI不仅可以简化某些类型的客户端，还可以降低服务器的复杂性（因为它不需要在已经有内部标识符（如通用唯一标识符（UUID）或主键）的情况下保留额外的客户端提供的标识符）。
Note: The vCard Extensions to WebDAV (CardDAV) ([CARDDAV]) suffer from the same issue, and may be able to take advantage of this specification.
注意：WebDAV（CardDAV）（[CardDAV]）的vCard扩展也存在同样的问题，并且可以利用此规范。
This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics.
该规范定义了一种发现机制，通过该机制，服务器可以使用上述“添加集合成员”语义公布对POST请求的支持。
This specification deliberately only addresses the use case of creating new non-collection resources. It was not a goal for this specification to supply the same functionality for creating collection resources (MKCOL) or for other operations that require the client to specify a new URL (LOCK, MOVE, or COPY).
本规范有意只处理创建新的非集合资源的用例。本规范的目标不是为创建集合资源（MKCOL）或其他需要客户端指定新URL（锁定、移动或复制）的操作提供相同的功能。
Note: The author previously proposed a new HTTP method for exactly this purpose ([ADDMEMBER]), but quite a few reviewers pointed out that this would duplicate the original semantics of POST. Thus, this proposal, which avoids adding a new HTTP method, is made.
注意：作者之前提出了一个新的HTTP方法，正是为了达到这个目的（[ADDMEMBER]），但有不少评论员指出，这将复制POST的原始语义。因此，提出了避免添加新HTTP方法的建议。
The terminology used here follows that in the WebDAV 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 purely notational convention. In particular:
本文档使用XML DTD片段（[XML]）作为纯粹的符号约定。特别地：
o Element ordering is irrelevant.
o 元素排序是不相关的。
o Extension elements/attributes (elements/attributes not already defined as valid child elements) may be added anywhere, except when explicitly stated otherwise.
o 扩展元素/属性（尚未定义为有效子元素的元素/属性）可以添加到任何位置，除非另有明确说明。
Note: This specification defines new properties and precondition names in the "DAV:" namespace, which the WebDAV specification reserves for use by the IETF ([RFC4918], Section 21.1). However, there was rough consensus in the WebDAV community that the specification is of general applicability to other WebDAV-related standards efforts, and thus deserves inclusion into the base namespace.
注：本规范在“DAV:”名称空间中定义了新的属性和前提条件名称，WebDAV规范保留该名称空间供IETF使用（[RFC4918]，第21.1节）。然而，WebDAV社区中有一个大致的共识，即该规范对其他WebDAV相关的标准工作具有普遍适用性，因此应该包含在基本名称空间中。
Due to the reasons stated in Section 1, clients cannot rely on a specific server behavior when POST is applied to a collection. This problem is addressed by this specification by allowing servers to advertise a URI that has the desired "add member" semantics.
由于第1节中所述的原因，当POST应用于集合时，客户端不能依赖于特定的服务器行为。此规范通过允许服务器公布具有所需“添加成员”语义的URI来解决此问题。
Servers that already use POST for a different purpose can just expose a separate URI. Other servers can just advertise the collection's own URI, thus avoiding minting another URI for a limited purpose.
已经将POST用于其他目的的服务器可以只公开一个单独的URI。其他服务器可以只公布集合自己的URI，从而避免为有限的目的生成另一个URI。
The "Add-Member" URI of a WebDAV collection is a URI that will accept HTTP POST requests, and will interpret these as requests to store the enclosed entity as a new internal member of the collection (see Section 3 of [RFC4918] for the definition of "internal member"). It MUST identify a resource on the same server as the WebDAV collection (the host and port components ([RFC2616], Section 3.2.2) of the URIs must match).
WebDAV集合的“添加成员”URI是一个URI，它将接受HTTP POST请求，并将这些请求解释为将封闭实体存储为集合的新内部成员的请求（有关“内部成员”的定义，请参见[RFC4918]第3节）。它必须标识与WebDAV集合位于同一服务器上的资源（URI的主机和端口组件（[RFC2616]，第3.2.2节）必须匹配）。
If there are preconditions related to creating a resource in the collection using a PUT request, then those same preconditions apply to the new POST request behavior, and the same HTTP response body will be returned on failure.
如果存在与使用PUT请求在集合中创建资源相关的先决条件，那么这些先决条件将应用于新的POST请求行为，并且在失败时将返回相同的HTTP响应主体。
The URI of the newly created resource is returned in the HTTP Location response header field ([RFC2616], Section 14.30).
新创建的资源的URI在HTTP位置响应头字段（[RFC2616]，第14.30节）中返回。
Note: The fact that a server advertises an "Add-Member" URI does not imply any special semantics of the collection itself. For instance, member URIs assigned by the server are not necessarily unique over time (a member URI may be assigned again to a new resource when it previously was removed).
注意：服务器播发“addmember”URI的事实并不意味着集合本身有任何特殊的语义。例如，服务器分配的成员URI在一段时间内不一定是唯一的（成员URI在以前被删除时可能会再次分配给新资源）。
Note: The "Add-Member" URI can be identical to the collection's URI (in which case the server just advertises the fact that POST to the WebDAV collection's URI is supported as defined within this specification). But it can also be different from it, in which case it doesn't need to have any relation to the collection's URI.
注意：“添加成员”URI可以与集合的URI相同（在这种情况下，服务器只会公布一个事实，即POST到WebDAV集合的URI受此规范中定义的支持）。但它也可以不同于它，在这种情况下，它不需要与集合的URI有任何关系。
Given a collection URI of
给定一个URI集合
/docs/collection/
/docs/collection/
any of the URIs below might occur as "Add-Member" URIs:
以下任何URI都可能作为“添加成员”URI出现：
/docs/collection/
/docs/collection/;post
/docs/collection;post/
/docs/collection/&post
/post-service?path=/collection/
/docs/collection/
/docs/collection/;post
/docs/collection;post/
/docs/collection/&post
/post-service?path=/collection/
The remainder of the document uses the same format just for reasons of consistency; any other HTTP URI on the same server would do as well.
文件的其余部分仅出于一致性原因而使用相同的格式；同一服务器上的任何其他HTTP URI也可以。
DAV:add-member is a protected property (see [RFC4918], Section 15) defined on WebDAV collections, and contains the "Add-Member" URI for that collection (embedded inside a DAV:href element).
DAV:add member是WebDAV集合上定义的受保护属性（请参阅[RFC4918]，第15节），它包含该集合的“add member”URI（嵌入在DAV:href元素中）。
<!ELEMENT add-member (href)>
<!-- href: defined in [RFC4918], Section 14.7 -->
<!ELEMENT add-member (href)>
<!-- href: defined in [RFC4918], Section 14.7 -->
A PROPFIND/allprop request SHOULD NOT return this property (see [RFC4918], Section 9.1). Servers MUST implement the DAV:supported-live-property-set property defined in Section 3.1.4 of [RFC3253], and report the property DAV:add-member as a supported live property.
PROPFIND/allprop请求不应返回此属性（请参阅[RFC4918]，第9.1节）。服务器必须实现[RFC3253]第3.1.4节中定义的DAV:supported live属性集属性，并将属性DAV:add member报告为受支持的live属性。
>>Request
>>请求
PROPFIND /collection/ HTTP/1.1
Host: example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 118
PROPFIND /collection/ HTTP/1.1
Host: example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 118
<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:">
<prop>
<add-member/>
</prop>
</propfind>
<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:">
<prop>
<add-member/>
</prop>
</propfind>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 340
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 340
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>/collection/</href>
<propstat>
<prop>
<add-member>
<href>/collection;add-member/</href>
</add-member>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>/collection/</href>
<propstat>
<prop>
<add-member>
<href>/collection;add-member/</href>
</add-member>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
In this case, the server has minted a separate URI for the purpose of adding new content.
在本例中，服务器创建了一个单独的URI以添加新内容。
In the AtomPub protocol, clients can use the entity header field "Slug" to suggest parts of the URI to be created (see [RFC5023], Section 9.7). Note that servers are free to ignore this suggestion, or to use whatever algorithm makes sense to generate the new URI.
在AtomPub协议中，客户端可以使用实体头字段“Slug”来建议要创建的URI部分（请参见[RFC5023]，第9.7节）。请注意，服务器可以忽略此建议，也可以使用任何有意义的算法来生成新的URI。
The same applies to the extension defined here: clients can use the "Slug" header field, as by definition it is a generic HTTP header field. Servers should process it exactly in the way defined by AtomPub.
这同样适用于这里定义的扩展：客户端可以使用“Slug”头字段，因为根据定义它是一个通用HTTP头字段。服务器应该完全按照AtomPub定义的方式处理它。
>>Request
>>请求
POST /collection;add-member/ HTTP/1.1
Host: example.com
Content-Type: text/plain
Slug: Sample Title
Content-Length: 12
POST /collection;add-member/ HTTP/1.1
Host: example.com
Content-Type: text/plain
Slug: Sample Title
Content-Length: 12
Sample text.
示例文本。
>>Response
>>回应
HTTP/1.1 201 Created
Location: http://example.com/collection/sample%20title
HTTP/1.1 201 Created
Location: http://example.com/collection/sample%20title
One important use case for this specification is collections that act as WebDAV collections for the purpose of read access (PROPFIND Depth 1/Infinity), but which only support internal member URIs assigned by the server. These collections will not allow a client to create a new member using methods like PUT, MKCOL, LOCK, COPY, or MOVE. Therefore, this specification defines a new precondition name ([RFC4918], Section 16) that can be used to provide the client with additional information regarding exactly why the request failed.
本规范的一个重要用例是用作WebDAV集合的集合，用于读取访问（PROPFIND Depth 1/Infinity），但只支持服务器分配的内部成员URI。这些集合不允许客户端使用PUT、MKCOL、LOCK、COPY或MOVE等方法创建新成员。因此，本规范定义了一个新的前提条件名称（[RFC4918]，第16节），可用于向客户机提供有关请求失败的确切原因的附加信息。
Note: Although the precondition defined below can be used for methods other than PUT, the "Add-Member" mechanism defined by this specification deliberately is restricted to PUT.
注意：尽管下面定义的前提条件可用于PUT以外的方法，但本规范定义的“添加成员”机制故意限制为PUT。
(DAV:allow-client-defined-URI): the server allows clients to specify the last path segment for newly created resources.
（DAV：允许客户端定义的URI）：服务器允许客户端为新创建的资源指定最后一个路径段。
The precondition element MAY contain an add-member-uri XML element specifying the "Add-Member" URI associated with the collection, on which the creation of a new child resource was attempted:
前提条件元素可能包含一个add member uri XML元素，指定与集合关联的“add member”uri，在该集合上尝试创建新的子资源：
<!ELEMENT allow-client-defined-uri (add-member?)>
<!ELEMENT allow-client-defined-uri (add-member?)>
In this example, the client tries to use PUT to create a new internal member of /collection/.
在本例中，客户端尝试使用PUT创建/collection/的新内部成员。
>>Request
>>请求
PUT /collection/new.txt HTTP/1.1
Host: example.com
Content-Type: text/plain
Content-Length: 12
PUT /collection/new.txt HTTP/1.1
Host: example.com
Content-Type: text/plain
Content-Length: 12
Sample text.
示例文本。
>>Response
>>回应
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, TRACE, PROPFIND, COPY, MOVE
Content-Type: application/xml; charset=UTF-8
Content-Length: 172
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, TRACE, PROPFIND, COPY, MOVE
Content-Type: application/xml; charset=UTF-8
Content-Length: 172
<error xmlns="DAV:">
<allow-client-defined-uri>
<add-member>
<href>/collection;add-member/</href>
</add-member>
</allow-client-defined-uri>
</error>
<error xmlns="DAV:">
<allow-client-defined-uri>
<add-member>
<href>/collection;add-member/</href>
</add-member>
</allow-client-defined-uri>
</error>
The request fails with a 405 (Method Not Allowed) status, but also provides the reason, and a pointer to the "Add-Member" URI in the response body.
请求失败，状态为405（不允许方法），但也提供了原因，以及响应正文中指向“addmember”URI的指针。
The WebDAV Access Control Protocol specification requires the DAV: bind privilege to be granted on a collection for the client to be able to add new collection members ([RFC3744], Section 3.9). Consistent with that, a server MUST reject a POST request to the Add-Member URI of a collection, unless the principal executing the request is granted DAV:bind privilege on the associated WebDAV collection resource.
WebDAV访问控制协议规范要求对集合授予DAV:bind权限，以便客户端能够添加新的集合成员（[RFC3744]，第3.9节）。与此一致，服务器必须拒绝对集合的添加成员URI的POST请求，除非执行该请求的主体在关联的WebDAV集合资源上被授予DAV:bind权限。
This document does not introduce any new internationalization considerations beyond those discussed in Section 19 of [RFC4918].
除[RFC4918]第19节中讨论的内容外，本文件未引入任何新的国际化考虑因素。
Security considerations applicable to HTTP [RFC2616], WebDAV [RFC4918], and XML [XML] apply for this specification as well, namely, Section 20 of [RFC4918] and Section 7 of [RFC3470].
适用于HTTP[RFC2616]、WebDAV[RFC4918]和XML[XML]的安全注意事项也适用于本规范，即[RFC4918]的第20节和[RFC3470]的第7节。
Furthermore, servers should be aware that deriving the member path from the data being stored in the resource could potentially expose confidential information. This could even be the case when only a hash code of the content is used.
此外，服务器应该知道，从存储在资源中的数据派生成员路径可能会暴露机密信息。当只使用内容的哈希代码时，甚至可能出现这种情况。
In addition, on servers that do not support this specification, a malevolent user could set the DAV:add-member URI as a custom property, tricking other users to post content to an entirely different URI. Clients can protect themselves against this scenario by
此外，在不支持此规范的服务器上，恶意用户可以将DAV:add成员URI设置为自定义属性，诱使其他用户将内容发布到完全不同的URI。客户端可以通过
o not following DAV:add-member URIs to different servers, and/or
o 不遵循DAV：将成员URI添加到不同的服务器，和/或
o verifying that the DAV:add-member property is indeed a live property (this can be achieved by testing the DAV:supported-live-property-set property, or by checking whether DAV:add-member is returned upon PROPFIND/allprop).
o 验证DAV:add-member属性是否确实是活动属性（这可以通过测试DAV:supported-live-property集属性，或者通过检查在PROPFIND/allprop时是否返回DAV:add-member来实现）。
This document has benefited from thoughtful discussion by Cyrus Daboo and Bernard Desruisseaux.
本文件得益于Cyrus Daboo和Bernard Desruisseaux深思熟虑的讨论。
[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月。
[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月。
[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/>.
[ADDMEMBER] Reschke, J., "The HTTP ADDMEMBER Method", Work in Progress, February 2005.
[ADDMEMBER]Reschke，J.，“HTTP ADDMEMBER方法”，正在进行的工作，2005年2月。
[CARDDAV] Daboo, C., "vCard Extensions to WebDAV (CardDAV)", Work in Progress, November 2009.
[CARDDAV]Daboo，C.，“WebDAV的vCard扩展（CARDDAV）”，正在进行的工作，2009年11月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470]Hollenbeck，S.，Rose，M.，和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，2003年1月。
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007.
[RFC4791]Daboo，C.，Desruisseaux，B.，和L.Dusseault，“WebDAV（CalDAV）的日历扩展”，RFC 47912007年3月。
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, October 2007.
[RFC5023]Gregorio，J.，Ed.和B.de hOra，Ed.，“原子发布协议”，RFC 5023，2007年10月。
Index
指数
A Add-Member URI 5
添加成员URI 5
C Condition Names DAV:allow-client-defined-URI (pre) 8 COPY method Additional Preconditions 8
C条件名称DAV:允许客户端定义的URI（pre）8复制方法附加前提条件8
D DAV:allow-client-defined-URI 8
D DAV:允许客户端定义的URI 8
L LOCK method Additional Preconditions 8
L锁定方法附加先决条件8
M MKCOL method Additional Preconditions 8 MOVE method Additional Preconditions 8
M MKCOL方法附加先决条件8移动方法附加先决条件8
P PUT method Additional Preconditions 8
P PUT方法附加前提条件8
Author's Address
作者地址
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
Phone: +49 251 2807760
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Phone: +49 251 2807760
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/