Network Working Group L. Dusseault, Ed.
Request for Comments: 4918 CommerceNet
Obsoletes: 2518 June 2007
Category: Standards Track
Network Working Group L. Dusseault, Ed.
Request for Comments: 4918 CommerceNet
Obsoletes: 2518 June 2007
Category: Standards Track
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
用于Web分布式创作和版本控制（WebDAV）的HTTP扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).
Web分布式创作和版本控制（WebDAV）由一组方法、标题和内容类型组成，这些方法、标题和内容类型是HTTP/1.1的附属内容，用于管理资源属性、创建和管理资源集合、URL命名空间操作和资源锁定（避免冲突）。
RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience.
RFC 2518于1999年2月发布，本规范淘汰了RFC 2518，主要是由于互操作性经验而进行了较小的修订。
Table of Contents
目录
1. Introduction ....................................................7
2. Notational Conventions ..........................................8
3. Terminology .....................................................8
4. Data Model for Resource Properties .............................10
4.1. The Resource Property Model ...............................10
4.2. Properties and HTTP Headers ...............................10
4.3. Property Values ...........................................10
4.3.1. Example - Property with Mixed Content ..............12
4.4. Property Names ............................................14
4.5. Source Resources and Output Resources .....................14
5. Collections of Web Resources ...................................14
5.1. HTTP URL Namespace Model ..................................15
5.2. Collection Resources ......................................15
6. Locking ........................................................17
6.1. Lock Model ................................................18
6.2. Exclusive vs. Shared Locks ................................19
6.3. Required Support ..........................................20
6.4. Lock Creator and Privileges ...............................20
6.5. Lock Tokens ...............................................21
6.6. Lock Timeout ..............................................21
6.7. Lock Capability Discovery .................................22
6.8. Active Lock Discovery .....................................22
7. Write Lock .....................................................23
7.1. Write Locks and Properties ................................24
7.2. Avoiding Lost Updates .....................................24
7.3. Write Locks and Unmapped URLs .............................25
7.4. Write Locks and Collections ...............................26
7.5. Write Locks and the If Request Header .....................28
7.5.1. Example - Write Lock and COPY ......................28
7.5.2. Example - Deleting a Member of a Locked
Collection .........................................29
7.6. Write Locks and COPY/MOVE .................................30
7.7. Refreshing Write Locks ....................................30
8. General Request and Response Handling ..........................31
8.1. Precedence in Error Handling ..............................31
8.2. Use of XML ................................................31
8.3. URL Handling ..............................................32
8.3.1. Example - Correct URL Handling .....................32
8.4. Required Bodies in Requests ...............................33
8.5. HTTP Headers for Use in WebDAV ............................33
8.6. ETag ......................................................33
8.7. Including Error Response Bodies ...........................34
8.8. Impact of Namespace Operations on Cache Validators ........34
9. HTTP Methods for Distributed Authoring .........................35
9.1. PROPFIND Method ...........................................35
9.1.1. PROPFIND Status Codes ..............................37
1. Introduction ....................................................7
2. Notational Conventions ..........................................8
3. Terminology .....................................................8
4. Data Model for Resource Properties .............................10
4.1. The Resource Property Model ...............................10
4.2. Properties and HTTP Headers ...............................10
4.3. Property Values ...........................................10
4.3.1. Example - Property with Mixed Content ..............12
4.4. Property Names ............................................14
4.5. Source Resources and Output Resources .....................14
5. Collections of Web Resources ...................................14
5.1. HTTP URL Namespace Model ..................................15
5.2. Collection Resources ......................................15
6. Locking ........................................................17
6.1. Lock Model ................................................18
6.2. Exclusive vs. Shared Locks ................................19
6.3. Required Support ..........................................20
6.4. Lock Creator and Privileges ...............................20
6.5. Lock Tokens ...............................................21
6.6. Lock Timeout ..............................................21
6.7. Lock Capability Discovery .................................22
6.8. Active Lock Discovery .....................................22
7. Write Lock .....................................................23
7.1. Write Locks and Properties ................................24
7.2. Avoiding Lost Updates .....................................24
7.3. Write Locks and Unmapped URLs .............................25
7.4. Write Locks and Collections ...............................26
7.5. Write Locks and the If Request Header .....................28
7.5.1. Example - Write Lock and COPY ......................28
7.5.2. Example - Deleting a Member of a Locked
Collection .........................................29
7.6. Write Locks and COPY/MOVE .................................30
7.7. Refreshing Write Locks ....................................30
8. General Request and Response Handling ..........................31
8.1. Precedence in Error Handling ..............................31
8.2. Use of XML ................................................31
8.3. URL Handling ..............................................32
8.3.1. Example - Correct URL Handling .....................32
8.4. Required Bodies in Requests ...............................33
8.5. HTTP Headers for Use in WebDAV ............................33
8.6. ETag ......................................................33
8.7. Including Error Response Bodies ...........................34
8.8. Impact of Namespace Operations on Cache Validators ........34
9. HTTP Methods for Distributed Authoring .........................35
9.1. PROPFIND Method ...........................................35
9.1.1. PROPFIND Status Codes ..............................37
9.1.2. Status Codes for Use in 'propstat' Element .........37
9.1.3. Example - Retrieving Named Properties ..............38
9.1.4. Example - Using 'propname' to Retrieve All
Property Names .....................................39
9.1.5. Example - Using So-called 'allprop' ................41
9.1.6. Example - Using 'allprop' with 'include' ...........43
9.2. PROPPATCH Method ..........................................44
9.2.1. Status Codes for Use in 'propstat' Element .........44
9.2.2. Example - PROPPATCH ................................45
9.3. MKCOL Method ..............................................46
9.3.1. MKCOL Status Codes .................................47
9.3.2. Example - MKCOL ....................................47
9.4. GET, HEAD for Collections .................................48
9.5. POST for Collections ......................................48
9.6. DELETE Requirements .......................................48
9.6.1. DELETE for Collections .............................49
9.6.2. Example - DELETE ...................................49
9.7. PUT Requirements ..........................................50
9.7.1. PUT for Non-Collection Resources ...................50
9.7.2. PUT for Collections ................................51
9.8. COPY Method ...............................................51
9.8.1. COPY for Non-collection Resources ..................51
9.8.2. COPY for Properties ................................52
9.8.3. COPY for Collections ...............................52
9.8.4. COPY and Overwriting Destination Resources .........53
9.8.5. Status Codes .......................................54
9.8.6. Example - COPY with Overwrite ......................55
9.8.7. Example - COPY with No Overwrite ...................55
9.8.8. Example - COPY of a Collection .....................56
9.9. MOVE Method ...............................................56
9.9.1. MOVE for Properties ................................57
9.9.2. MOVE for Collections ...............................57
9.9.3. MOVE and the Overwrite Header ......................58
9.9.4. Status Codes .......................................59
9.9.5. Example - MOVE of a Non-Collection .................60
9.9.6. Example - MOVE of a Collection .....................60
9.10. LOCK Method ..............................................61
9.10.1. Creating a Lock on an Existing Resource ...........61
9.10.2. Refreshing Locks ..................................62
9.10.3. Depth and Locking .................................62
9.10.4. Locking Unmapped URLs .............................63
9.10.5. Lock Compatibility Table ..........................63
9.10.6. LOCK Responses ....................................63
9.10.7. Example - Simple Lock Request .....................64
9.10.8. Example - Refreshing a Write Lock .................65
9.10.9. Example - Multi-Resource Lock Request .............66
9.11. UNLOCK Method ............................................68
9.11.1. Status Codes ......................................68
9.1.2. Status Codes for Use in 'propstat' Element .........37
9.1.3. Example - Retrieving Named Properties ..............38
9.1.4. Example - Using 'propname' to Retrieve All
Property Names .....................................39
9.1.5. Example - Using So-called 'allprop' ................41
9.1.6. Example - Using 'allprop' with 'include' ...........43
9.2. PROPPATCH Method ..........................................44
9.2.1. Status Codes for Use in 'propstat' Element .........44
9.2.2. Example - PROPPATCH ................................45
9.3. MKCOL Method ..............................................46
9.3.1. MKCOL Status Codes .................................47
9.3.2. Example - MKCOL ....................................47
9.4. GET, HEAD for Collections .................................48
9.5. POST for Collections ......................................48
9.6. DELETE Requirements .......................................48
9.6.1. DELETE for Collections .............................49
9.6.2. Example - DELETE ...................................49
9.7. PUT Requirements ..........................................50
9.7.1. PUT for Non-Collection Resources ...................50
9.7.2. PUT for Collections ................................51
9.8. COPY Method ...............................................51
9.8.1. COPY for Non-collection Resources ..................51
9.8.2. COPY for Properties ................................52
9.8.3. COPY for Collections ...............................52
9.8.4. COPY and Overwriting Destination Resources .........53
9.8.5. Status Codes .......................................54
9.8.6. Example - COPY with Overwrite ......................55
9.8.7. Example - COPY with No Overwrite ...................55
9.8.8. Example - COPY of a Collection .....................56
9.9. MOVE Method ...............................................56
9.9.1. MOVE for Properties ................................57
9.9.2. MOVE for Collections ...............................57
9.9.3. MOVE and the Overwrite Header ......................58
9.9.4. Status Codes .......................................59
9.9.5. Example - MOVE of a Non-Collection .................60
9.9.6. Example - MOVE of a Collection .....................60
9.10. LOCK Method ..............................................61
9.10.1. Creating a Lock on an Existing Resource ...........61
9.10.2. Refreshing Locks ..................................62
9.10.3. Depth and Locking .................................62
9.10.4. Locking Unmapped URLs .............................63
9.10.5. Lock Compatibility Table ..........................63
9.10.6. LOCK Responses ....................................63
9.10.7. Example - Simple Lock Request .....................64
9.10.8. Example - Refreshing a Write Lock .................65
9.10.9. Example - Multi-Resource Lock Request .............66
9.11. UNLOCK Method ............................................68
9.11.1. Status Codes ......................................68
9.11.2. Example - UNLOCK ..................................69
10. HTTP Headers for Distributed Authoring ........................69
10.1. DAV Header ...............................................69
10.2. Depth Header .............................................70
10.3. Destination Header .......................................71
10.4. If Header ................................................72
10.4.1. Purpose ...........................................72
10.4.2. Syntax ............................................72
10.4.3. List Evaluation ...................................73
10.4.4. Matching State Tokens and ETags ...................74
10.4.5. If Header and Non-DAV-Aware Proxies ...............74
10.4.6. Example - No-tag Production .......................75
10.4.7. Example - Using "Not" with No-tag Production ......75
10.4.8. Example - Causing a Condition to Always
Evaluate to True ..................................75
10.4.9. Example - Tagged List If Header in COPY ...........76
10.4.10. Example - Matching Lock Tokens with
Collection Locks .................................76
10.4.11. Example - Matching ETags on Unmapped URLs ........76
10.5. Lock-Token Header ........................................77
10.6. Overwrite Header .........................................77
10.7. Timeout Request Header ...................................78
11. Status Code Extensions to HTTP/1.1 ............................78
11.1. 207 Multi-Status .........................................78
11.2. 422 Unprocessable Entity .................................78
11.3. 423 Locked ...............................................78
11.4. 424 Failed Dependency ....................................79
11.5. 507 Insufficient Storage .................................79
12. Use of HTTP Status Codes ......................................79
12.1. 412 Precondition Failed ..................................79
12.2. 414 Request-URI Too Long .................................79
13. Multi-Status Response .........................................80
13.1. Response Headers .........................................80
13.2. Handling Redirected Child Resources ......................81
13.3. Internal Status Codes ....................................81
14. XML Element Definitions .......................................81
14.1. activelock XML Element ...................................81
14.2. allprop XML Element ......................................82
14.3. collection XML Element ...................................82
14.4. depth XML Element ........................................82
14.5. error XML Element ........................................82
14.6. exclusive XML Element ....................................83
14.7. href XML Element .........................................83
14.8. include XML Element ......................................83
14.9. location XML Element .....................................83
14.10. lockentry XML Element ...................................84
14.11. lockinfo XML Element ....................................84
14.12. lockroot XML Element ....................................84
9.11.2. Example - UNLOCK ..................................69
10. HTTP Headers for Distributed Authoring ........................69
10.1. DAV Header ...............................................69
10.2. Depth Header .............................................70
10.3. Destination Header .......................................71
10.4. If Header ................................................72
10.4.1. Purpose ...........................................72
10.4.2. Syntax ............................................72
10.4.3. List Evaluation ...................................73
10.4.4. Matching State Tokens and ETags ...................74
10.4.5. If Header and Non-DAV-Aware Proxies ...............74
10.4.6. Example - No-tag Production .......................75
10.4.7. Example - Using "Not" with No-tag Production ......75
10.4.8. Example - Causing a Condition to Always
Evaluate to True ..................................75
10.4.9. Example - Tagged List If Header in COPY ...........76
10.4.10. Example - Matching Lock Tokens with
Collection Locks .................................76
10.4.11. Example - Matching ETags on Unmapped URLs ........76
10.5. Lock-Token Header ........................................77
10.6. Overwrite Header .........................................77
10.7. Timeout Request Header ...................................78
11. Status Code Extensions to HTTP/1.1 ............................78
11.1. 207 Multi-Status .........................................78
11.2. 422 Unprocessable Entity .................................78
11.3. 423 Locked ...............................................78
11.4. 424 Failed Dependency ....................................79
11.5. 507 Insufficient Storage .................................79
12. Use of HTTP Status Codes ......................................79
12.1. 412 Precondition Failed ..................................79
12.2. 414 Request-URI Too Long .................................79
13. Multi-Status Response .........................................80
13.1. Response Headers .........................................80
13.2. Handling Redirected Child Resources ......................81
13.3. Internal Status Codes ....................................81
14. XML Element Definitions .......................................81
14.1. activelock XML Element ...................................81
14.2. allprop XML Element ......................................82
14.3. collection XML Element ...................................82
14.4. depth XML Element ........................................82
14.5. error XML Element ........................................82
14.6. exclusive XML Element ....................................83
14.7. href XML Element .........................................83
14.8. include XML Element ......................................83
14.9. location XML Element .....................................83
14.10. lockentry XML Element ...................................84
14.11. lockinfo XML Element ....................................84
14.12. lockroot XML Element ....................................84
14.13. lockscope XML Element ...................................84
14.14. locktoken XML Element ...................................85
14.15. locktype XML Element ....................................85
14.16. multistatus XML Element .................................85
14.17. owner XML Element .......................................85
14.18. prop XML Element ........................................86
14.19. propertyupdate XML Element ..............................86
14.20. propfind XML Element ....................................86
14.21. propname XML Element ....................................87
14.22. propstat XML Element ....................................87
14.23. remove XML Element ......................................87
14.24. response XML Element ....................................88
14.25. responsedescription XML Element .........................88
14.26. set XML Element .........................................88
14.27. shared XML Element ......................................89
14.28. status XML Element ......................................89
14.29. timeout XML Element .....................................89
14.30. write XML Element .......................................89
15. DAV Properties ................................................90
16. Precondition/Postcondition XML Elements .......................98
17. XML Extensibility in DAV .....................................101
18. DAV Compliance Classes .......................................103
18.1. Class 1 .................................................103
18.2. Class 2 .................................................103
18.3. Class 3 .................................................103
19. Internationalization Considerations ..........................104
20. Security Considerations ......................................105
20.1. Authentication of Clients ...............................105
20.2. Denial of Service .......................................106
20.3. Security through Obscurity ..............................106
20.4. Privacy Issues Connected to Locks .......................106
20.5. Privacy Issues Connected to Properties ..................107
20.6. Implications of XML Entities ............................107
20.7. Risks Connected with Lock Tokens ........................108
20.8. Hosting Malicious Content ...............................108
21. IANA Considerations ..........................................109
21.1. New URI Schemes .........................................109
21.2. XML Namespaces ..........................................109
21.3. Message Header Fields ...................................109
21.3.1. DAV ..............................................109
21.3.2. Depth ............................................110
21.3.3. Destination ......................................110
21.3.4. If ...............................................110
21.3.5. Lock-Token .......................................110
21.3.6. Overwrite ........................................111
21.3.7. Timeout ..........................................111
21.4. HTTP Status Codes .......................................111
22. Acknowledgements .............................................112
14.13. lockscope XML Element ...................................84
14.14. locktoken XML Element ...................................85
14.15. locktype XML Element ....................................85
14.16. multistatus XML Element .................................85
14.17. owner XML Element .......................................85
14.18. prop XML Element ........................................86
14.19. propertyupdate XML Element ..............................86
14.20. propfind XML Element ....................................86
14.21. propname XML Element ....................................87
14.22. propstat XML Element ....................................87
14.23. remove XML Element ......................................87
14.24. response XML Element ....................................88
14.25. responsedescription XML Element .........................88
14.26. set XML Element .........................................88
14.27. shared XML Element ......................................89
14.28. status XML Element ......................................89
14.29. timeout XML Element .....................................89
14.30. write XML Element .......................................89
15. DAV Properties ................................................90
16. Precondition/Postcondition XML Elements .......................98
17. XML Extensibility in DAV .....................................101
18. DAV Compliance Classes .......................................103
18.1. Class 1 .................................................103
18.2. Class 2 .................................................103
18.3. Class 3 .................................................103
19. Internationalization Considerations ..........................104
20. Security Considerations ......................................105
20.1. Authentication of Clients ...............................105
20.2. Denial of Service .......................................106
20.3. Security through Obscurity ..............................106
20.4. Privacy Issues Connected to Locks .......................106
20.5. Privacy Issues Connected to Properties ..................107
20.6. Implications of XML Entities ............................107
20.7. Risks Connected with Lock Tokens ........................108
20.8. Hosting Malicious Content ...............................108
21. IANA Considerations ..........................................109
21.1. New URI Schemes .........................................109
21.2. XML Namespaces ..........................................109
21.3. Message Header Fields ...................................109
21.3.1. DAV ..............................................109
21.3.2. Depth ............................................110
21.3.3. Destination ......................................110
21.3.4. If ...............................................110
21.3.5. Lock-Token .......................................110
21.3.6. Overwrite ........................................111
21.3.7. Timeout ..........................................111
21.4. HTTP Status Codes .......................................111
22. Acknowledgements .............................................112
23. Contributors to This Specification ...........................113
24. Authors of RFC 2518 ..........................................113
25. References ...................................................114
25.1. Normative References.....................................114
25.2. Informative References ..................................115
Appendix A. Notes on Processing XML Elements ....................117
A.1. Notes on Empty XML Elements ..............................117
A.2. Notes on Illegal XML Processing ..........................117
A.3. Example - XML Syntax Error ...............................117
A.4. Example - Unexpected XML Element .........................118
Appendix B. Notes on HTTP Client Compatibility ...................119
Appendix C. The 'opaquelocktoken' Scheme and URIs ................120
Appendix D. Lock-null Resources ..................................120
D.1. Guidance for Clients Using LOCK to Create Resources ......121
Appendix E. Guidance for Clients Desiring to Authenticate ........121
Appendix F. Summary of Changes from RFC 2518 .....................123
F.1. Changes for Both Client and Server Implementations .......123
F.2. Changes for Server Implementations .......................125
F.3. Other Changes ............................................126
23. Contributors to This Specification ...........................113
24. Authors of RFC 2518 ..........................................113
25. References ...................................................114
25.1. Normative References.....................................114
25.2. Informative References ..................................115
Appendix A. Notes on Processing XML Elements ....................117
A.1. Notes on Empty XML Elements ..............................117
A.2. Notes on Illegal XML Processing ..........................117
A.3. Example - XML Syntax Error ...............................117
A.4. Example - Unexpected XML Element .........................118
Appendix B. Notes on HTTP Client Compatibility ...................119
Appendix C. The 'opaquelocktoken' Scheme and URIs ................120
Appendix D. Lock-null Resources ..................................120
D.1. Guidance for Clients Using LOCK to Create Resources ......121
Appendix E. Guidance for Clients Desiring to Authenticate ........121
Appendix F. Summary of Changes from RFC 2518 .....................123
F.1. Changes for Both Client and Server Implementations .......123
F.2. Changes for Server Implementations .......................125
F.3. Other Changes ............................................126
This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote Web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for:
本文档描述了HTTP/1.1协议的扩展，该协议允许客户端执行远程Web内容创作操作。此扩展提供了一组连贯的方法、标头、请求实体正文格式和响应实体正文格式，这些格式提供了以下操作：
Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc.
属性：能够创建、删除和查询有关网页的信息，如其作者、创建日期等。
Collections: The ability to create sets of documents and to retrieve a hierarchical membership listing (like a directory listing in a file system).
集合：创建文档集和检索分层成员列表（如文件系统中的目录列表）的能力。
Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem", in which modifications are lost as first one author, then another, writes changes without merging the other author's changes.
锁定：防止多人同时处理文档的能力。这可以防止“丢失更新问题”，即当第一个作者编写更改时，修改会丢失，然后另一个作者在不合并其他作者的更改的情况下编写更改。
Namespace Operations: The ability to instruct the server to copy and move Web resources, operations that change the mapping from URLs to resources.
命名空间操作：指示服务器复制和移动Web资源的能力，这些操作更改URL到资源的映射。
Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" [RFC2291].
这些操作的要求和基本原理见配套文件“万维网分布式创作和版本控制协议的要求”[RFC2291]。
This document does not specify the versioning operations suggested by [RFC2291]. That work was done in a separate document, "Versioning Extensions to WebDAV" [RFC3253].
本文档未指定[RFC2291]建议的版本控制操作。这项工作是在一个单独的文档“WebDAV的版本控制扩展”[RFC3253]中完成的。
The sections below provide a detailed introduction to various WebDAV abstractions: resource properties (Section 4), collections of resources (Section 5), locks (Section 6) in general, and write locks (Section 7) specifically.
以下各节详细介绍了各种WebDAV抽象：资源属性（第4节）、资源集合（第5节）、锁（第6节）以及写锁（第7节）。
These abstractions are manipulated by the WebDAV-specific HTTP methods (Section 9) and the extra HTTP headers (Section 10) used with WebDAV methods. General considerations for handling HTTP requests and responses in WebDAV are found in Section 8.
这些抽象由WebDAV特定的HTTP方法（第9节）和WebDAV方法使用的额外HTTP头（第10节）操纵。在WebDAV中处理HTTP请求和响应的一般注意事项见第8节。
While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines extra status codes developed for WebDAV methods (Section 11) and describes existing HTTP status codes (Section 12) as used in WebDAV. Since some WebDAV methods may
虽然HTTP/1.1提供的状态代码足以描述WebDAV方法遇到的大多数错误情况，但仍有一些错误不属于现有类别。本规范定义了为WebDAV方法开发的额外状态代码（第11节），并描述了WebDAV中使用的现有HTTP状态代码（第12节）。因为有些WebDAV方法可能
operate over many resources, the Multi-Status response (Section 13) has been introduced to return status information for multiple resources. Finally, this version of WebDAV introduces precondition and postcondition (Section 16) XML elements in error response bodies.
操作多个资源时，引入了多状态响应（第13节），以返回多个资源的状态信息。最后，这个版本的WebDAV在错误响应体中引入了前置条件和后置条件（第16节）XML元素。
WebDAV uses XML ([REC-XML]) for property names and some values, and also uses XML to marshal complicated requests and responses. This specification contains DTD and text definitions of all properties (Section 15) and all other XML elements (Section 14) used in marshalling. WebDAV includes a few special rules on extending WebDAV XML marshalling in backwards-compatible ways (Section 17).
WebDAV使用XML（[REC-XML]）作为属性名和某些值，还使用XML封送复杂的请求和响应。本规范包含编组中使用的所有属性（第15节）和所有其他XML元素（第14节）的DTD和文本定义。WebDAV包括一些关于以向后兼容的方式扩展WebDAV XML编组的特殊规则（第17节）。
Finishing off the specification are sections on what it means for a resource to be compliant with this specification (Section 18), on internationalization support (Section 19), and on security (Section 20).
规范的最后部分是关于资源遵守本规范意味着什么（第18节）、国际化支持（第19节）和安全性（第20节）的章节。
Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in Section 2.1 of [RFC2616], including the rules about implied linear whitespace. Since this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], these rules apply to this document as well. Note this is not the standard BNF syntax used in other RFCs.
由于本文档描述了HTTP/1.1协议的一组扩展，因此本文中用于描述协议元素的扩展BNF与[RFC2616]第2.1节中描述的完全相同，包括关于隐含线性空白的规则。由于此扩充BNF使用[RFC2616]第2.2节中提供的基本生产规则，因此这些规则也适用于本文件。注意，这不是其他RFC中使用的标准BNF语法。
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]中所述进行解释。
Note that in natural language, a property like the "creationdate" property in the "DAV:" XML namespace is sometimes referred to as "DAV:creationdate" for brevity.
请注意，在自然语言中，“DAV:”XML名称空间中的“creationdate”属性为简洁起见，有时称为“DAV:creationdate”。
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in [RFC3986].
URI/URL—分别是统一资源标识符和统一资源定位器。[RFC3986]中定义了这些术语（以及它们之间的区别）。
URI/URL Mapping - A relation between an absolute URI and a resource. Since a resource can represent items that are not network retrievable, as well as those that are, it is possible for a resource to have zero, one, or many URI mappings. Mapping a resource to an "http" scheme URI makes it possible to submit HTTP protocol requests to the resource using the URI.
URI/URL映射—绝对URI和资源之间的关系。由于资源可以表示不可网络检索的项，也可以表示不可网络检索的项，因此资源可能具有零、一或多个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节。
Collection - Informally, a resource that also acts as a container of references to child resources. Formally, a resource that contains a set of mappings between path segments and resources and meets the requirements defined in Section 5.
集合—非正式地说，是一种资源，它还充当子资源引用的容器。形式上，包含路径段和资源之间的一组映射并满足第5节中定义的要求的资源。
Internal Member (of a Collection) - Informally, a child resource of a collection. Formally, a resource referenced by a path segment mapping contained in the collection.
（集合的）内部成员-非正式地说，集合的子资源。形式上，由集合中包含的路径段映射引用的资源。
Internal Member URL (of a Collection) - A URL of an internal member, consisting of the URL of the collection (including trailing slash) plus the path segment identifying the internal member.
内部成员URL（集合的）—内部成员的URL，由集合的URL（包括尾随斜杠）加上标识内部成员的路径段组成。
Member (of a Collection) - Informally, a "descendant" of a collection. Formally, an internal member of the collection, or, recursively, a member of an internal member.
（收藏的）成员——非正式地说，是收藏的“后代”。形式上是集合的内部成员，或者递归地是内部成员的成员。
Member URL (of a Collection) - A URL that is either an internal member URL of the collection itself, or is an internal member URL of a member of that collection.
（集合的）成员URL—是集合本身的内部成员URL或该集合成员的内部成员URL的URL。
Property - A name/value pair that contains descriptive information about a resource.
属性-包含有关资源的描述性信息的名称/值对。
Live Property - A property whose semantics and syntax are enforced by the server. For example, the live property DAV:getcontentlength has its value, the length of the entity returned by a GET request, automatically calculated by the server.
Live属性—其语义和语法由服务器强制执行的属性。例如，live属性DAV:getcontentlength的值是由服务器自动计算的，即GET请求返回的实体的长度。
Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property.
Dead属性—其语义和语法不由服务器强制执行的属性。服务器只记录死财产的价值；客户机负责维护死属性的语法和语义的一致性。
Principal - A distinct human or computational actor that initiates access to network resources.
主体-发起网络资源访问的独特的人类或计算参与者。
State Token - A URI that represents a state of a resource. Lock tokens are the only state tokens defined in this specification.
状态标记-表示资源状态的URI。锁定令牌是本规范中定义的唯一状态令牌。
Properties are pieces of data that describe the state of a resource. Properties are data about data.
属性是描述资源状态的数据片段。属性是关于数据的数据。
Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents.
属性用于分布式创作环境中，以提供高效的资源发现和管理。例如，“subject”属性可能允许按主题对所有资源编制索引，“author”属性可能允许发现作者编写了哪些文档。
The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics.
DAV属性模型由名称/值对组成。属性的名称标识属性的语法和语义，并提供引用其语法和语义的地址。
There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is protected and maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.
财产分为两类：“活的”和“死的”。live属性的语法和语义由服务器强制执行。活动属性包括以下情况：a）属性值由服务器保护和维护，b）属性值由客户端维护，但服务器对提交的值执行语法检查。给定活动属性的所有实例都必须符合与该属性名称关联的定义。死属性的语法和语义由客户端强制执行；服务器只是逐字记录属性的值。
Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments, a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus, a mechanism is needed that allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.
在有限的意义上，属性已经存在于HTTP消息头中。然而，在分布式创作环境中，需要相对大量的属性来描述资源的状态，并且通过HTTP头设置/返回这些属性效率低下。因此，需要一种机制，允许主体识别主体感兴趣的一组属性，并仅设置或检索这些属性。
The value of a property is always a (well-formed) XML fragment.
属性的值始终是（格式良好的）XML片段。
XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self-describing nature allows any property's value to be extended by adding elements. Clients will not break when they encounter extensions because they will still have the data specified in the original schema and MUST ignore elements they do not understand.
选择XML是因为它是一种灵活、自描述的结构化数据格式，支持丰富的模式定义，并且支持多个字符集。XML的自描述特性允许通过添加元素来扩展任何属性的值。客户机在遇到扩展时不会中断，因为它们仍然拥有原始模式中指定的数据，并且必须忽略它们不理解的元素。
XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml: lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so an xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. Note that a property only has one value, in one language (or language MAY be left undefined); a property does not have multiple values in different languages or a single value in multiple languages.
XML对多个字符集的支持允许在用户熟悉的字符集中编码和读取任何人类可读的属性。XML使用“XML:lang”属性支持多种人类语言，处理多种人类语言使用相同字符集的情况。请注意，xml:lang范围是递归的，因此任何包含property name元素的元素上的xml:lang属性都将应用于属性值，除非它已被更具本地范围的属性覆盖。请注意，属性只有一个值，使用一种语言（或语言可能未定义）；属性在不同语言中没有多个值，在多种语言中也没有单个值。
A property is always represented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist:
属性始终由一个由属性名组成的XML元素表示，称为“property name元素”。最简单的示例是空属性，它不同于不存在的属性：
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
The value of the property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. Servers MUST preserve the following XML Information Items (using the terminology from [REC-XML-INFOSET]) in storage and transmission of dead properties:
属性的值显示在property name元素中。该值可以是任何形式良好的XML内容，包括纯文本和混合内容。服务器必须在死属性的存储和传输中保留以下XML信息项（使用[REC-XML-INFOSET]中的术语）：
For the property name Element Information Item itself:
对于属性名称元素信息项本身：
[namespace name]
[名称空间名称]
[local name]
[本地名称]
[attributes] named "xml:lang" or any such attribute in scope
名为“xml:lang”的[属性]或范围中的任何此类属性
[children] of type element or character
元素或字符类型的[子项]
On all Element Information Items in the property value:
在属性值中的所有元素信息项上：
[namespace name]
[名称空间名称]
[local name]
[本地名称]
[attributes]
[属性]
[children] of type element or character
元素或字符类型的[子项]
On Attribute Information Items in the property value:
在属性值中的属性信息项上：
[namespace name]
[名称空间名称]
[local name]
[本地名称]
[normalized value]
[标准化值]
On Character Information Items in the property value:
关于属性值中的字符信息项：
[character code]
[字符代码]
Since prefixes are used in some XML vocabularies (XPath and XML Schema, for example), servers SHOULD preserve, for any Information Item in the value:
由于在某些XML词汇表（例如XPath和XML模式）中使用前缀，服务器应为值中的任何信息项保留：
[prefix]
[前缀]
XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. The above rules would also apply by default to live properties, unless defined otherwise.
上面未列出的XML信息集属性可以由服务器保留，但客户端不能依赖于它们被保留。除非另有定义，否则上述规则默认情况下也适用于活动属性。
Servers MUST ignore the XML attribute xml:space if present and never use it to change whitespace handling. Whitespace in property values is significant.
服务器必须忽略XML属性XML:space（如果存在），并且永远不要使用它来更改空白处理。属性值中的空白非常重要。
Consider a dead property 'author' created by the client as follows:
考虑由客户端创建的死亡属性“作者”如下：
<D:prop xml:lang="en" xmlns:D="DAV:">
<x:author xmlns:x='http://example.com/ns'>
<x:name>Jane Doe</x:name>
<!-- Jane's contact info -->
<x:uri type='email'
added='2005-11-26'>mailto:jane.doe@example.com</x:uri>
<x:uri type='web'
added='2005-11-27'>http://www.example.com</x:uri>
<x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <![CDATA[<RFC2518>]]>.
</x:notes>
</x:author>
</D:prop>
<D:prop xml:lang="en" xmlns:D="DAV:">
<x:author xmlns:x='http://example.com/ns'>
<x:name>Jane Doe</x:name>
<!-- Jane's contact info -->
<x:uri type='email'
added='2005-11-26'>mailto:jane.doe@example.com</x:uri>
<x:uri type='web'
added='2005-11-27'>http://www.example.com</x:uri>
<x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <![CDATA[<RFC2518>]]>.
</x:notes>
</x:author>
</D:prop>
When this property is requested, a server might return:
请求此属性时，服务器可能会返回：
<D:prop xmlns:D='DAV:'><author
xml:lang='en'
xmlns:x='http://example.com/ns'
xmlns='http://example.com/ns'
xmlns:h='http://www.w3.org/1999/xhtml'>
<x:name>Jane Doe</x:name>
<x:uri added="2005-11-26" type="email"
>mailto:jane.doe@example.com</x:uri>
<x:uri added="2005-11-27" type="web"
>http://www.example.com</x:uri>
<x:notes>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <RFC2518>.
</x:notes>
</author>
</D:prop>
<D:prop xmlns:D='DAV:'><author
xml:lang='en'
xmlns:x='http://example.com/ns'
xmlns='http://example.com/ns'
xmlns:h='http://www.w3.org/1999/xhtml'>
<x:name>Jane Doe</x:name>
<x:uri added="2005-11-26" type="email"
>mailto:jane.doe@example.com</x:uri>
<x:uri added="2005-11-27" type="web"
>http://www.example.com</x:uri>
<x:notes>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <RFC2518>.
</x:notes>
</author>
</D:prop>
Note in this example:
在本例中请注意：
o The [prefix] for the property name itself was not preserved, being non-significant, whereas all other [prefix] values have been preserved,
o 属性名称本身的[prefix]未保留，不重要，而所有其他[prefix]值均已保留，
o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and attribute order has not been preserved,
o 属性值已用双引号而不是单引号重写（引号样式不重要），属性顺序未保留，
o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope),
o xml:lang属性已在property name元素本身上返回（设置属性时它在范围内，但只要它在范围内，响应中的确切位置就不重要），
o whitespace between tags has been preserved everywhere (whitespace between attributes not so),
o 标记之间的空白在任何地方都被保留（属性之间的空白并非如此），
o CDATA encapsulation was replaced with character escaping (the reverse would also be legal),
o CDATA封装被替换为字符转义（反之亦然），
o the comment item was stripped (as would have been a processing instruction item).
o 注释项被剥离（与处理指令项一样）。
Implementation note: there are cases such as editing scenarios where clients may require that XML content is preserved character by character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing.
实现说明：在某些情况下，例如编辑场景，客户机可能要求逐个字符保留XML内容（例如属性排序或引用样式）。在这种情况下，客户端应该考虑通过使用仅在XML解析中具有特殊意义的所有字符来使用纯文本属性值。
A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property.
属性名称是一个通用的唯一标识符，它与提供有关属性语法和语义信息的架构相关联。
Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition.
因为属性的名称是通用唯一的，所以客户端可以依赖于跨多个资源、同一个服务器和不同服务器上的特定属性的一致行为，只要该属性在所讨论的资源上是“活动的”，并且活动属性的实现忠实于其定义。
The XML namespace mechanism, which is based on URIs ([RFC3986]), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control.
基于URI（[RFC3986]）的XML命名空间机制用于命名属性，因为它可以防止命名空间冲突，并提供不同程度的管理控制。
The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced that will address issues relating to hierarchical properties.
属性名称空间是平面的；也就是说，没有明确识别属性的层次结构。因此，如果资源上存在属性a和属性a/B，则无法识别这两个属性之间的任何关系。预计最终将产生一个单独的规范，解决与分层属性相关的问题。
Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace.
最后，不可能在单个资源上定义同一属性两次，因为这会导致资源的属性命名空间发生冲突。
Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one, or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.
一些HTTP资源是由服务器动态生成的。对于这些资源，可能在某个地方存在控制资源生成方式的源代码。源文件与输出HTTP资源的关系可能是一对一、一对多、多对一或多对多。HTTP中没有任何机制来确定资源是否是动态的，更不用说它的源文件存在于何处或如何编写它们了。尽管这一问题将得到有效解决，但可互操作的WebDAV实现已被广泛部署，但实际上并没有解决这一问题，只处理静态资源。因此，本规范并未解决源与输出的问题，而是将其推迟到单独的文档中。
This section provides a description of a type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace and with HTTP methods. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace.
本节介绍一种Web资源类型集合，并讨论它与HTTP URL命名空间和HTTP方法的交互。集合资源的用途是在服务器的命名空间中对类似集合的对象（例如，文件系统目录）进行建模。
All DAV-compliant resources MUST support the HTTP URL namespace model specified herein.
所有符合DAV的资源必须支持此处指定的HTTP URL命名空间模型。
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.
HTTP URL命名空间是一个分层命名空间，其中层次结构用“/”字符分隔。
An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member URL. The root, or top-level collection of the namespace under consideration, is exempt from the previous rule. The top-level collection of the namespace under consideration is not necessarily the collection identified by the absolute path '/' -- it may be identified by one or more path segments (e.g., /servlets/webdav/...)
如果HTTP URL命名空间满足以下条件，则称其为一致的：对于HTTP层次结构中的每个URL，都存在一个包含该URL作为内部成员URL的集合。所考虑的命名空间的根或顶级集合不受前面规则的约束。考虑中的命名空间的顶级集合不一定是由绝对路径“/”标识的集合——它可以由一个或多个路径段标识（例如，/servlets/webdav/…）
Neither HTTP/1.1 nor WebDAV requires that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.
HTTP/1.1和WebDAV都不要求整个HTTP URL命名空间保持一致——与WebDAV兼容的资源可能没有父集合。但是，禁止某些WebDAV方法生成导致命名空间不一致的结果。
As is implicit in [RFC2616] and [RFC3986], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
正如[RFC2616]和[RFC3986]中隐含的那样，任何资源（包括集合资源）都可以由多个URI标识。例如，一个资源可以由多个HTTP URL标识。
Collection resources differ from other resources in that they also act as containers. Some HTTP methods apply only to a collection, but some apply to some or all of the resources inside the container defined by the collection. When the scope of a method is not clear, the client can specify what depth to apply. Depth can be either zero levels (only the collection), one level (the collection and directly contained resources), or infinite levels (the collection and all contained resources recursively).
集合资源与其他资源的不同之处在于它们还充当容器。有些HTTP方法仅适用于集合，但有些方法适用于集合定义的容器内的部分或所有资源。当方法的范围不清楚时，客户机可以指定应用的深度。深度可以是零级（仅集合）、一级（集合和直接包含的资源）或无限级（集合和所有包含的资源递归）。
A collection's state consists of at least a set of mappings between path segments and resources, and a set of properties on the collection itself. In this document, a resource B will be said to be contained in the collection resource A if there is a path segment mapping that maps to B and that is contained in A. A collection MUST contain at most one mapping for a given path segment, i.e., it is illegal to have the same path segment mapped to more than one resource.
集合的状态至少包括路径段和资源之间的一组映射，以及集合本身的一组属性。在本文档中，如果存在映射到B且包含在a中的路径段映射，则资源B将被称为包含在集合资源a中。对于给定的路径段，集合必须最多包含一个映射，即，将同一路径段映射到多个资源是非法的。
Properties defined on collections behave exactly as do properties on non-collection resources. A collection MAY have additional state such as entity bodies returned by GET.
集合上定义的属性与非集合资源上定义的属性的行为完全相同。集合可能具有其他状态，例如GET返回的实体体。
For all WebDAV-compliant resources A and B, identified by URLs "U" and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain exactly one mapping from "blah" to B.
对于所有符合WebDAV的资源A和B，分别由URL“U”和“V”标识，“V”等于“U/SEGMENT”，A必须是包含从“SEGMENT”到B的映射的集合。因此，如果资源B具有URL“http://example.com/bar/blah“是否符合WebDAV，如果资源具有URL”http://example.com/bar/“是否符合WebDAV标准，那么资源A必须是一个集合，并且必须正好包含一个从“blah”到B的映射。
Although commonly a mapping consists of a single segment and a resource, in general, a mapping consists of a set of segments and a resource. This allows a server to treat a set of segments as equivalent (i.e., either all of the segments are mapped to the same resource, or none of the segments are mapped to a resource). For example, a server that performs case-folding on segments will treat the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can then use any of these segments to identify the resource. Note that a PROPFIND result will select one of these equivalent segments to identify the mapping, so there will be one PROPFIND response element per mapping, not one per segment in the mapping.
虽然映射通常由单个段和一个资源组成，但通常，映射由一组段和一个资源组成。这允许服务器将一组段视为等效的（即，所有段都映射到同一资源，或者没有一个段映射到资源）。例如，在段上执行大小写折叠的服务器将把段“ab”、“ab”、“ab”和“ab”视为等效的。然后，客户机可以使用这些段中的任何一个来标识资源。请注意，PROPFIND结果将选择其中一个等效段来标识映射，因此每个映射将有一个PROPFIND响应元素，而不是映射中的每个段。
Collection resources MAY have mappings to non-WebDAV-compliant resources in the HTTP URL namespace hierarchy but are not required to do so. For example, if resource X with URL "http://example.com/bar/blah" is not WebDAV compliant and resource A with "URL http://example.com/bar/" identifies a WebDAV collection, then A may or may not have a mapping from "blah" to X.
集合资源可能具有到HTTP URL命名空间层次结构中不符合WebDAV的资源的映射，但不需要这样做。例如，如果资源X带有URL“http://example.com/bar/blah不符合WebDAV，且资源具有“URL”http://example.com/bar/标识WebDAV集合，则a可能有也可能没有从“blah”到X的映射。
If a WebDAV-compliant resource has no WebDAV-compliant internal members in the HTTP URL namespace hierarchy, then the WebDAV-compliant resource is not required to be a collection.
如果符合WebDAV的资源在HTTP URL命名空间层次结构中没有符合WebDAV的内部成员，则不要求符合WebDAV的资源是集合。
There is a standing convention that when a collection is referred to
by its name without a trailing slash, the server MAY handle the
request as if the trailing slash were present. In this case, it
SHOULD return a Content-Location header in the response, pointing to
the URL ending with the "/". For example, if a client invokes a
method on http://example.com/blah (no trailing slash), the server may
respond as if the operation were invoked on http://example.com/blah/
(trailing slash), and should return a Content-Location header with
the value http://example.com/blah/. Wherever a server produces a URL
referring to a collection, the server SHOULD include the trailing
slash. In general, clients SHOULD use the trailing slash form of
collection names. If clients do not use the trailing slash form the
client needs to be prepared to see a redirect response. Clients will
There is a standing convention that when a collection is referred to
by its name without a trailing slash, the server MAY handle the
request as if the trailing slash were present. In this case, it
SHOULD return a Content-Location header in the response, pointing to
the URL ending with the "/". For example, if a client invokes a
method on http://example.com/blah (no trailing slash), the server may
respond as if the operation were invoked on http://example.com/blah/
(trailing slash), and should return a Content-Location header with
the value http://example.com/blah/. Wherever a server produces a URL
referring to a collection, the server SHOULD include the trailing
slash. In general, clients SHOULD use the trailing slash form of
collection names. If clients do not use the trailing slash form the
client needs to be prepared to see a redirect response. Clients will
find the DAV:resourcetype property more reliable than the URL to find out if a resource is a collection.
查找比URL更可靠的DAV:resourcetype属性，以确定资源是否为集合。
Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if an OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections.
客户端必须能够支持WebDAV资源包含在非WebDAV资源中的情况。例如，如果选项响应来自“http://example.com/servlet/dav/collection表示WebDAV支持，客户端不能假定http://example.com/servlet/dav/“或其父项必须是WebDAV集合。
A typical scenario in which mapped URLs do not appear as members of their parent collection is the case where a server allows links or redirects to non-WebDAV resources. For instance, "/col/link" might not appear as a member of "/col/", although the server would respond with a 302 status to a GET request to "/col/link"; thus, the URL "/col/link" would indeed be mapped. Similarly, a dynamically-generated page might have a URL mapping from "/col/index.html", thus this resource might respond with a 200 OK to a GET request yet not appear as a member of "/col/".
映射URL不作为其父集合的成员出现的典型情况是，服务器允许链接或重定向到非WebDAV资源。例如，“/col/link”可能不会显示为“/col/”的成员，但服务器会以302状态响应对“/col/link”的GET请求；因此，URL“/col/link”确实会被映射。类似地，动态生成的页面可能具有来自“/col/index.html”的URL映射，因此此资源可能会对GET请求作出200 OK的响应，但不会显示为“/col/”的成员。
Some mappings to even WebDAV-compliant resources might not appear in the parent collection. An example for this case are servers that support multiple alias URLs for each WebDAV-compliant resource. A server may implement case-insensitive URLs, thus "/col/a" and "/col/A" identify the same resource, yet only either "a" or "A" is reported upon listing the members of "/col". In cases where a server treats a set of segments as equivalent, the server MUST expose only one preferred segment per mapping, consistently chosen, in PROPFIND responses.
甚至到WebDAV兼容资源的某些映射可能不会出现在父集合中。这种情况的一个例子是，服务器支持每个WebDAV兼容资源的多个别名URL。服务器可以实现不区分大小写的URL，因此“/col/A”和“/col/A”标识相同的资源，但在列出“/col”的成员时，仅报告“A”或“A”。在服务器将一组段视为等效段的情况下，服务器必须在PROPFIND响应中为每个映射仅公开一个一致选择的首选段。
The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem.
锁定资源的能力为序列化对该资源的访问提供了一种机制。使用锁，创作客户端可以合理地保证另一主体在编辑资源时不会修改资源。通过这种方式，客户端可以防止“丢失更新”问题。
This specification allows locks to vary over two client-specified parameters, the number of principals involved (exclusive vs. shared) and the type of access to be granted. This document defines locking for only one access type, write. However, the syntax is extensible, and permits the eventual specification of locking for other access types.
此规范允许锁在两个客户端指定的参数上变化，即所涉及的主体数量（独占与共享）和要授予的访问类型。本文档仅为一种访问类型write定义锁定。但是，该语法是可扩展的，并允许最终为其他访问类型指定锁定。
This section provides a concise model for how locking behaves. Later sections will provide more detail on some of the concepts and refer back to these model statements. Normative statements related to LOCK and UNLOCK method handling can be found in the sections on those methods, whereas normative statements that cover any method are gathered here.
本节提供了锁定行为的简明模型。后面几节将提供一些概念的更多细节，并参考这些模型语句。与锁定和解锁方法处理相关的规范性陈述可以在这些方法的章节中找到，而涵盖任何方法的规范性陈述都收集在这里。
1. A lock either directly or indirectly locks a resource.
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未映射到资源，则会创建一个新的空资源并直接锁定。
3. An exclusive lock (Section 6.2) conflicts with any other kind of lock on the same resource, whether either lock is direct or indirect. A server MUST NOT create conflicting locks on a resource.
3. 独占锁（第6.2节）与同一资源上的任何其他类型的锁冲突，无论是直接锁还是间接锁。服务器不得在资源上创建冲突锁。
4. For a collection that is locked with a depth-infinity lock L, all member resources are indirectly locked. Changes in membership of such a collection affect the set of indirectly locked resources:
4. 对于使用深度无限锁L锁定的集合，所有成员资源都被间接锁定。此类集合成员资格的更改会影响间接锁定的资源集：
* If a member resource is added to the collection, the new member resource MUST NOT already have a conflicting lock, because the new resource MUST become indirectly locked by L.
* 如果将成员资源添加到集合中，则新成员资源必须没有冲突的锁，因为新资源必须被L间接锁定。
* If a member resource stops being a member of the collection, then the resource MUST no longer be indirectly locked by L.
* 如果成员资源不再是集合的成员，则该资源不能再被L间接锁定。
5. Each lock is identified by a single globally unique lock token (Section 6.5).
5. 每个锁由一个全局唯一的锁令牌标识（第6.5节）。
6. An UNLOCK request deletes the lock with the specified lock token. After a lock is deleted, no resource is locked by that lock.
6. 解锁请求删除具有指定锁令牌的锁。删除锁后，该锁不会锁定任何资源。
7. A lock token is "submitted" in a request when it appears in an "If" header (Section 7, "Write Lock", discusses when token submission is required for write locks).
7. 当锁令牌出现在“If”头中时，它在请求中被“提交”（第7节“写锁”讨论了写锁何时需要提交令牌）。
8. If a request causes the lock-root of any lock to become an unmapped URL, then the lock MUST also be deleted by that request.
8. 如果请求导致任何锁的锁根成为未映射的URL，则该请求还必须删除该锁。
The most basic form of lock is an exclusive lock. Exclusive locks avoid having to deal with content change conflicts, without requiring any coordination other than the methods described in this specification.
锁的最基本形式是独占锁。独占锁避免了必须处理内容更改冲突，而不需要本规范中描述的方法以外的任何协调。
However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal that has both access privileges and a valid lock can use the locked resource.
然而，有时锁的目标不是排除其他人行使访问权，而是为主体提供一种机制，表明他们打算行使其访问权。这种情况下提供了共享锁。共享锁允许多个主体接收锁。因此，任何同时具有访问权限和有效锁的主体都可以使用锁定的资源。
With shared locks, there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set.
对于共享锁，有两个信任集影响资源。第一个信任集由访问权限创建。例如，受信任的主体可能具有写入资源的权限。在那些具有写入资源的访问权限的主体中，取出共享锁的主体集也必须相互信任，从而在访问权限写入集中创建（通常）较小的信任集。
Starting with every possible principal on the Internet, in most situations the vast majority of these principals will not have write access to a given resource. Of the small number who do have write access, some principals may decide to guarantee their edits are free from overwrite conflicts by using exclusive write locks. Others may decide they trust their collaborators will not overwrite their work (the potential set of collaborators being the set of principals who have write permission) and use a shared lock, which informs their collaborators that a principal may be working on the resource.
从Internet上的每一个可能的主体开始，在大多数情况下，这些主体中的绝大多数都没有对给定资源的写访问权限。在少数具有写访问权限的主体中，一些主体可能会决定通过使用独占写锁来确保其编辑不存在覆盖冲突。其他人可能会认为他们信任他们的合作者不会覆盖他们的工作（潜在的合作者集是具有写权限的主体集），并使用共享锁，这会通知他们的合作者主体可能正在处理资源。
The WebDAV extensions to HTTP do not need to provide all of the communications paths necessary for principals to coordinate their activities. When using shared locks, principals may use any out-of-band communication channel to coordinate their work (e.g., face-to-face interaction, written notes, post-it notes on the screen, telephone conversation, email, etc.) The intent of a shared lock is to let collaborators know who else may be working on a resource.
HTTP的WebDAV扩展不需要提供主体协调其活动所需的所有通信路径。当使用共享锁时，主体可以使用任何带外通信通道来协调他们的工作（例如，面对面交流、书面笔记、屏幕上的便利贴、电话对话、电子邮件等）。共享锁的目的是让合作者知道还有谁在使用资源。
Shared locks are included because experience from Web-distributed authoring systems has indicated that exclusive locks are often too rigid. An exclusive lock is used to enforce a particular editing process: take out an exclusive lock, read the resource, perform edits, write the resource, release the lock. This editing process has the problem that locks are not always properly released, for example, when a program crashes or when a lock creator leaves without
之所以包括共享锁，是因为Web分布式创作系统的经验表明，独占锁通常过于严格。独占锁用于强制执行特定的编辑过程：取出独占锁、读取资源、执行编辑、写入资源、释放锁。此编辑过程存在一个问题，即锁不总是正确释放，例如，当程序崩溃或锁创建者离开时没有释放锁
unlocking a resource. While both timeouts (Section 6.6) and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.
解锁资源。虽然超时（第6.6节）和管理措施都可用于移除违规锁，但在需要时，两种机制都不可用；超时时间可能很长，或者管理员不可用。
A successful request for a new shared lock MUST result in the generation of a unique lock associated with the requesting principal. Thus, if five principals have taken out shared write locks on the same resource, there will be five locks and five lock tokens, one for each principal.
成功请求新共享锁必须生成与请求主体关联的唯一锁。因此，如果五个主体在同一资源上取出了共享写锁，那么将有五个锁和五个锁令牌，每个主体一个。
A WebDAV-compliant resource is not required to support locking in any form. If the resource does support locking, it may choose to support any combination of exclusive and shared locks for any access types.
支持任何形式的锁定不需要符合WebDAV的资源。如果资源确实支持锁定，那么它可以选择为任何访问类型支持排他锁和共享锁的任意组合。
The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks, while others only provide support for exclusive write locks, while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.
这种灵活性的原因是锁定策略触及了各种存储库所使用的资源管理和版本控制系统的核心。这些存储库需要控制哪些类型的锁定可用。例如，一些存储库只支持共享写锁，而其他存储库只支持独占写锁，而其他存储库则根本不使用锁。由于每个系统都有足够的差异，因此需要排除某些锁定功能，因此本规范将锁定作为WebDAV中唯一的协商轴。
The creator of a lock has special privileges to use the lock to modify the resource. When a locked resource is modified, a server MUST check that the authenticated principal matches the lock creator (in addition to checking for valid lock token submission).
锁的创建者具有使用锁修改资源的特权。修改锁定的资源时，服务器必须检查经过身份验证的主体是否与锁创建者匹配（除了检查有效的锁令牌提交）。
The server MAY allow privileged users other than the lock creator to destroy a lock (for example, the resource owner or an administrator). The 'unlock' privilege in [RFC3744] was defined to provide that permission.
服务器可能允许除锁创建者之外的特权用户销毁锁（例如，资源所有者或管理员）。[RFC3744]中的“解锁”权限被定义为提供该权限。
There is no requirement for servers to accept LOCK requests from all users or from anonymous users.
服务器不需要接受来自所有用户或匿名用户的锁定请求。
Note that having a lock does not confer full privilege to modify the locked resource. Write access and other privileges MUST be enforced through normal privilege or authentication mechanisms, not based on the possible obscurity of lock token values.
请注意，拥有锁并不授予修改锁定资源的完全权限。必须通过正常的权限或身份验证机制强制执行写访问和其他权限，而不是基于锁令牌值的可能模糊性。
A lock token is a type of state token that identifies a particular lock. Each lock has exactly one unique lock token generated by the server. Clients MUST NOT attempt to interpret lock tokens in any way.
锁令牌是标识特定锁的一种状态令牌。每个锁都有一个由服务器生成的唯一锁令牌。客户端不得试图以任何方式解释锁令牌。
Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. Since lock tokens are unique, a client MAY submit a lock token in an If header on a resource other than the one that returned it.
锁定令牌URI必须在所有资源中始终唯一。这种唯一性约束允许跨资源和服务器提交锁令牌，而无需担心混淆。由于锁令牌是唯一的，客户机可以在If头中提交资源上的锁令牌，而不是返回它的资源。
When a LOCK operation creates a new lock, the new lock token is returned in the Lock-Token response header defined in Section 10.5, and also in the body of the response.
当锁操作创建新锁时，新锁令牌将在第10.5节中定义的锁令牌响应头中以及响应体中返回。
Servers MAY make lock tokens publicly readable (e.g., in the DAV: lockdiscovery property). One use case for making lock tokens readable is so that a long-lived lock can be removed by the resource owner (the client that obtained the lock might have crashed or disconnected before cleaning up the lock). Except for the case of using UNLOCK under user guidance, a client SHOULD NOT use a lock token created by another client instance.
服务器可以使锁令牌公开可读（例如，在DAV:lockdiscovery属性中）。使锁令牌可读的一个用例是，资源所有者可以移除长期存在的锁（获得锁的客户端可能在清理锁之前崩溃或断开连接）。除了在用户指导下使用解锁的情况外，客户端不应使用由另一个客户端实例创建的锁定令牌。
This specification encourages servers to create Universally Unique Identifiers (UUIDs) for lock tokens, and to use the URI form defined by "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]). However, servers are free to use any URI (e.g., from another scheme) so long as it meets the uniqueness requirements. For example, a valid lock token might be constructed using the "opaquelocktoken" scheme defined in Appendix C.
本规范鼓励服务器为锁令牌创建通用唯一标识符（UUID），并使用“通用唯一标识符（UUID）URN命名空间”（[RFC4122]）定义的URI形式。但是，服务器可以自由使用任何URI（例如，来自另一个方案），只要它满足唯一性要求。例如，可以使用附录C中定义的“opaquelocktoken”方案构造有效的锁令牌。
Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
A lock MAY have a limited lifetime. The lifetime is suggested by the client when creating or refreshing the lock, but the server ultimately chooses the timeout value. Timeout is measured in seconds remaining until lock expiration.
锁的使用寿命可能有限。客户机在创建或刷新锁时建议使用寿命，但服务器最终选择超时值。超时以锁定过期前剩余的秒数为单位。
The timeout counter MUST be restarted if a refresh lock request is successful (see Section 9.10.2). The timeout counter SHOULD NOT be restarted at any other time.
如果刷新锁定请求成功，则必须重新启动超时计数器（见第9.10.2节）。不应在任何其他时间重新启动超时计数器。
If the timeout expires, then the lock SHOULD be removed. In this case the server SHOULD act as if an UNLOCK method was executed by the
如果超时过期，则应移除锁。在这种情况下，服务器的行为应该与
server on the resource using the lock token of the timed-out lock, performed with its override authority.
服务器在资源上使用超时锁的锁令牌，使用其覆盖权限执行。
Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going offline.
建议服务器密切关注客户端提交的值，因为它们将指示客户端打算执行的活动类型。例如，在浏览器中运行的小程序可能需要锁定资源，但由于运行小程序的环境不稳定，小程序可能会在没有警告的情况下关闭。因此，小程序可能会请求一个相对较小的超时值，以便在小程序死亡时，可以快速获取锁。但是，文档管理系统可能会要求非常长的超时时间，因为其用户可能计划脱机。
A client MUST NOT assume that just because the timeout has expired, the lock has immediately been removed.
客户机不能仅仅因为超时已过期而认为锁已立即被移除。
Likewise, a client MUST NOT assume that just because the timeout has not expired, the lock still exists. Clients MUST assume that locks can arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if extraordinary circumstances do not occur. For example, a sufficiently privileged user may remove a lock at any time, or the system may crash in such a way that it loses the record of the lock's existence.
同样，客户机不能仅仅因为超时没有过期就认为锁仍然存在。客户机必须假设锁可以在任何时候任意消失，而不管超时头中给定的值如何。Timeout标头仅在未发生异常情况时指示服务器的行为。例如，一个拥有足够特权的用户可以随时移除一个锁，或者系统可能会崩溃，从而丢失锁存在的记录。
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. A client can determine what lock types the server supports by retrieving the DAV:supportedlock property.
由于服务器锁定支持是可选的，因此尝试锁定服务器上的资源的客户端可以尝试锁定并希望获得最佳效果，或者执行某种形式的发现以确定服务器支持的锁定功能。这称为锁功能发现。客户端可以通过检索DAV:supportedlock属性来确定服务器支持的锁类型。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:supportedlock property.
任何支持LOCK方法的符合DAV的资源都必须支持DAV:supportedlock属性。
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the DAV:lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and MAY even provide the lock tokens.
如果另一个主体锁定了主体希望访问的资源，那么第二个主体能够找出第一个主体是谁是有用的。为此，提供了DAV:lockdiscovery属性。此属性列出所有未完成的锁，描述它们的类型，甚至可以提供锁令牌。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:lockdiscovery property.
任何支持LOCK方法的符合DAV的资源都必须支持DAV:lockdiscovery属性。
This section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification.
本节描述特定于写锁类型的语义。写锁是锁类型的特定实例，是本规范中描述的唯一锁类型。
An exclusive write lock protects a resource: it prevents changes by any principal other than the lock creator and in any case where the lock token is not submitted (e.g., by a client process other than the one holding the lock).
独占写锁保护资源：它防止锁创建者以外的任何主体进行更改，并且在锁令牌未提交的任何情况下（例如，由持有锁的客户端进程以外的客户端进程进行更改）。
Clients MUST submit a lock-token they are authorized to use in any request that modifies a write-locked resource. The list of modifications covered by a write-lock include:
客户端必须提交一个锁令牌，他们有权在修改写锁定资源的任何请求中使用该令牌。写入锁包含的修改列表包括：
1. A change to any of the following aspects of any write-locked resource:
1. 对任何写锁定资源的以下任何方面的更改：
* any variant,
* 任何变体，
* any dead property,
* 任何死亡财产，
* any live property that is lockable (a live property is lockable unless otherwise defined.)
* 任何可锁定的活动属性（除非另有定义，否则活动属性是可锁定的。）
2. For collections, any modification of an internal member URI. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. More discussion on write locks and collections is found in Section 7.4.
2. 对于集合，对内部成员URI的任何修改。如果集合的内部成员URI被添加、删除或标识不同的资源，则认为该URI已被修改。有关写锁和集合的更多讨论，请参见第7.4节。
3. A modification of the mapping of the root of the write lock, either to another resource or to no resource (e.g., DELETE).
3. 修改写锁根的映射，要么到另一个资源，要么到无资源（例如，删除）。
Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and MKCOL are affected by write locks. All other HTTP/WebDAV methods defined so far -- GET in particular -- function independently of a write lock.
在HTTP和WebDAV中定义的方法中，PUT、POST、PROPPATCH、LOCK、UNLOCK、MOVE、COPY（针对目标资源）、DELETE和MKCOL受写锁的影响。到目前为止定义的所有其他HTTP/WebDAV方法（特别是GET）都独立于写锁运行。
The next few sections describe in more specific terms how write locks interact with various operations.
接下来的几节将以更具体的术语描述写锁如何与各种操作交互。
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined as lockable are guaranteed not to change while write locked.
虽然那些没有写锁的人可能不会更改资源上的属性，但由于模式的要求，活动属性的值仍然可能更改，即使在锁定时也是如此。只有定义为可锁定的死属性和活属性才能保证在写锁定时不会更改。
Although the write locks provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario:
尽管写锁在防止更新丢失方面提供了一些帮助，但它们不能保证更新永远不会丢失。考虑下面的情景：
Two clients A and B are interested in editing the resource 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking.
两个客户端A和B对编辑资源“index.html”感兴趣。客户端A是HTTP客户端而不是WebDAV客户端，因此不知道如何执行锁定。
Client A doesn't lock the document, but does a GET, and begins editing.
客户端A不锁定文档，但执行GET，并开始编辑。
Client B does LOCK, performs a GET and begins editing.
客户端B锁定、执行GET并开始编辑。
Client B finishes editing, performs a PUT, then an UNLOCK.
客户端B完成编辑，执行PUT，然后执行解锁。
Client A performs a PUT, overwriting and losing all of B's changes.
客户端A执行PUT，覆盖并丢失B的所有更改。
There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK.
WebDAV协议本身无法防止这种情况的原因有很多。首先，它不能强制所有客户端使用锁定，因为它必须与不理解锁定的HTTP客户端兼容。其次，由于存储库实现的多样性，它不能要求服务器支持锁定，其中一些存储库实现依赖于保留和合并，而不是锁定。最后，由于是无状态的，它不能强制执行像LOCK/GET/PUT/UNLOCK这样的操作序列。
WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources.
支持锁定的WebDAV服务器可以通过要求客户端在修改资源之前锁定资源来降低客户端意外覆盖彼此更改的可能性。这样的服务器将有效地防止HTTP 1.0和HTTP 1.1客户端修改资源。
WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking.
WebDAV客户端在与支持锁定的WebDAV服务器交互时，可以通过使用锁定/检索/写入/解锁操作序列（至少在默认情况下）成为好公民。
HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources.
HTTP 1.1客户机可以是好公民，避免覆盖其他客户机的更改，方法是在If Match头中使用实体标记和任何可能修改资源的请求。
Information managers may attempt to prevent overwrites by implementing client-side procedures requiring locking before modifying WebDAV resources.
信息管理器可以通过在修改WebDAV资源之前实施需要锁定的客户端过程来防止覆盖。
WebDAV provides the ability to send a LOCK request to an unmapped URL in order to reserve the name for use. This is a simple way to avoid the lost-update problem on the creation of a new resource (another way is to use If-None-Match header specified in Section 14.26 of [RFC2616]). It has the side benefit of locking the new resource immediately for use of the creator.
WebDAV能够向未映射的URL发送锁定请求，以便保留名称以供使用。这是一种避免在创建新资源时出现更新丢失问题的简单方法（另一种方法是在[RFC2616]第14.26节中指定的标题不匹配时使用）。它的副作用是立即锁定新资源以供创建者使用。
Note that the lost-update problem is not an issue for collections because MKCOL can only be used to create a collection, not to overwrite an existing collection. When trying to lock a collection upon creation, clients can attempt to increase the likelihood of getting the lock by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation, there's no guarantee this will work).
请注意，丢失更新问题不是集合的问题，因为MKCOL只能用于创建集合，而不能覆盖现有集合。当试图在创建集合时锁定集合时，客户端可以尝试通过将MKCOL和lock请求流水线连接在一起来增加获得锁定的可能性（但由于这不会将两个单独的操作转换为一个原子操作，因此无法保证这会起作用）。
A successful lock request to an unmapped URL MUST result in the creation of a locked (non-collection) resource with empty content. Subsequently, a successful PUT request (with the correct lock token) provides the content for the resource. Note that the LOCK request has no mechanism for the client to provide Content-Type or Content-Language, thus the server will use defaults or empty values and rely on the subsequent PUT request for correct values.
对未映射URL的成功锁定请求必须导致创建内容为空的锁定（非集合）资源。随后，成功的PUT请求（使用正确的锁令牌）为资源提供内容。请注意，锁定请求没有让客户端提供内容类型或内容语言的机制，因此服务器将使用默认值或空值，并依赖后续PUT请求获得正确的值。
A resource created with a LOCK is empty but otherwise behaves in every way as a normal resource. It behaves the same way as a resource created by a PUT request with an empty body (and where a Content-Type and Content-Language was not specified), followed by a LOCK request to the same resource. Following from this model, a locked empty resource:
使用锁创建的资源是空的，但在其他方面表现为普通资源。它的行为方式与PUT请求创建的资源相同，PUT请求的正文为空（未指定内容类型和内容语言），然后是对同一资源的锁定请求。根据此模型，锁定了一个空资源：
o Can be read, deleted, moved, and copied, and in all ways behaves as a regular non-collection resource.
o 可以读取、删除、移动和复制，并且在所有方面都可以作为常规的非集合资源。
o Appears as a member of its parent collection.
o 显示为其父集合的成员。
o SHOULD NOT disappear when its lock goes away (clients must therefore be responsible for cleaning up their own mess, as with any other operation or any non-empty resource).
o 不应在其锁消失时消失（因此，客户端必须负责清理自己的混乱，就像任何其他操作或任何非空资源一样）。
o MAY NOT have values for properties like DAV:getcontentlanguage that haven't been specified yet by the client.
o 可能没有客户端尚未指定的属性值，如DAV:getcontentlanguage。
o Can be updated (have content added) with a PUT request.
o 可以使用PUT请求更新（添加内容）。
o MUST NOT be converted into a collection. The server MUST fail a MKCOL request (as it would with a MKCOL request to any existing non-collection resource).
o 不能转换为集合。服务器必须使MKCOL请求失败（就像对任何现有非收集资源的MKCOL请求一样）。
o MUST have defined values for DAV:lockdiscovery and DAV: supportedlock properties.
o 必须为DAV:lockdiscovery和DAV:supportedlock属性定义了值。
o The response MUST indicate that a resource was created, by use of the "201 Created" response code (a LOCK request to an existing resource instead will result in 200 OK). The body must still include the DAV:lockdiscovery property, as with a LOCK request to an existing resource.
o 响应必须指示资源是使用“201 created”响应代码创建的（对现有资源的锁定请求将导致200 OK）。正文仍然必须包括DAV:lockdiscovery属性，就像对现有资源的锁请求一样。
The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH.
客户机在锁定被锁定的空资源后不久将使用PUT和PROPPATCH更新该资源。
Alternatively and for backwards compatibility to [RFC2518], servers MAY implement Lock-Null Resources (LNRs) instead (see definition in Appendix D). Clients can easily interoperate both with servers that support the old model LNRs and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET, and by not relying on specific properties of LNRs.
或者，为了向后兼容[RFC2518]，服务器可以实现锁定空资源（LNR）（参见附录D中的定义）。客户机可以轻松地与支持旧型号LNR和推荐的“锁定的空资源”型号的服务器进行互操作，方法是仅尝试在锁定到未映射URL后放置，而不是MKCOL或GET，并且不依赖LNR的特定属性。
There are two kinds of collection write locks. A depth-0 write lock on a collection protects the collection properties plus the internal member URLs of that one collection, while not protecting the content or properties of member resources (if the collection itself has any entity bodies, those are also protected). A depth-infinity write lock on a collection provides the same protection on that collection and also provides write lock protection on every member resource.
有两种类型的集合写入锁。集合上的深度0写锁保护集合属性以及该集合的内部成员URL，但不保护成员资源的内容或属性（如果集合本身有任何实体体，则这些实体也受保护）。集合上的深度无限写锁对该集合提供相同的保护，还对每个成员资源提供写锁保护。
Expressed otherwise, a write lock of either kind protects any request that would create a new resource in a write locked collection, any request that would remove an internal member URL of a write locked collection, and any request that would change the segment name of any internal member.
否则，任何一种类型的写锁都会保护将在写锁定集合中创建新资源的任何请求、将删除写锁定集合的内部成员URL的任何请求，以及将更改任何内部成员的段名称的任何请求。
Thus, a collection write lock protects all the following actions:
因此，集合写入锁可保护以下所有操作：
o DELETE a collection's direct internal member,
o 删除集合的直接内部成员，
o MOVE an internal member out of the collection,
o 将内部成员移出集合，
o MOVE an internal member into the collection,
o 将内部成员移动到集合中，
o MOVE to rename an internal member within a collection,
o 移动以重命名集合中的内部成员，
o COPY an internal member into a collection, and
o 将内部成员复制到集合中，然后
o PUT or MKCOL request that would create a new internal member.
o 将创建新内部成员的PUT或MKCOL请求。
The collection's lock token is required in addition to the lock token on the internal member itself, if it is locked separately.
如果单独锁定，则除了内部成员本身上的锁定令牌之外，还需要集合的锁定令牌。
In addition, a depth-infinity lock affects all write operations to all members of the locked collection. With a depth-infinity lock, the resource identified by the root of the lock is directly locked, and all its members are indirectly locked.
此外，深度无限锁定会影响对锁定集合的所有成员的所有写入操作。使用深度无限锁，直接锁定由锁根标识的资源，并间接锁定其所有成员。
o Any new resource added as a descendant of a depth-infinity locked collection becomes indirectly locked.
o 作为深度无限锁定集合的后代添加的任何新资源都将被间接锁定。
o Any indirectly locked resource moved out of the locked collection into an unlocked collection is thereafter unlocked.
o 从锁定的集合移出到未锁定的集合中的任何间接锁定的资源随后将被解锁。
o Any indirectly locked resource moved out of a locked source collection into a depth-infinity locked target collection remains indirectly locked but is now protected by the lock on the target collection (the target collection's lock token will thereafter be required to make further changes).
o 从锁定的源集合移出到深度无限锁定的目标集合中的任何间接锁定的资源都将保持间接锁定，但现在受目标集合上的锁的保护（目标集合的锁令牌随后将需要进行进一步更改）。
If a depth-infinity write LOCK request is issued to a collection containing member URLs identifying resources that are currently locked in a manner that conflicts with the new lock (see Section 6.1, point 3), the request MUST fail with a 423 (Locked) status code, and the response SHOULD contain the 'no-conflicting-lock' precondition.
如果向包含成员URL的集合发出深度无限写锁定请求，成员URL标识当前以与新锁定冲突的方式锁定的资源（请参阅第6.1节第3点），则请求必须失败，状态代码为423（已锁定），响应应包含“无冲突锁定”前提条件。
If a lock request causes the URL of a resource to be added as an internal member URL of a depth-infinity locked collection, then the new resource MUST be automatically protected by the lock. For example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c, then resource /a/b/c will be added to the write lock.
如果锁请求导致将资源的URL添加为深度无限锁定集合的内部成员URL，则新资源必须由锁自动保护。例如，如果集合/a/b/被写锁定，并且资源/c被移动到/a/b/c，则资源/a/b/c将被添加到写锁定。
A user agent has to demonstrate knowledge of a lock when requesting an operation on a locked resource. Otherwise, the following scenario might occur. In the scenario, program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization.
当请求对锁定的资源执行操作时，用户代理必须演示有关锁定的知识。否则，可能会出现以下情况。在该场景中，由用户A运行的程序A对资源执行写锁定。同样由用户A运行的程序B不知道程序A取出的锁，但对锁定的资源执行PUT。在这种情况下，PUT成功是因为锁与主体关联，而不是与程序关联，因此程序B可以执行PUT，因为它使用主体a的凭据进行操作。但是，如果程序B知道锁，它就不会覆盖资源，而是会向用户显示一个描述冲突的对话框。由于这种情况，需要一种机制来防止不同的程序意外地忽略具有相同授权的其他程序执行的锁。
In order to prevent these collisions, a lock token MUST be submitted by an authorized principal for all locked resources that a method may change or the method MUST fail. A lock token is submitted when it appears in an If header. For example, if a resource is to be moved and both the source and destination are locked, then two lock tokens must be submitted in the If header, one for the source and the other for the destination.
为了防止这些冲突，授权主体必须为方法可能更改或方法必须失败的所有锁定资源提交一个锁令牌。锁定令牌出现在If头中时提交。例如，如果要移动资源并且源和目标都被锁定，则必须在if头中提交两个锁定令牌，一个用于源，另一个用于目标。
>>Request
>>请求
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
If: <http://www.example.com/users/f/fielding/index.html>
(<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
If: <http://www.example.com/users/f/fielding/index.html>
(<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
>>Response
>>回应
HTTP/1.1 204 No Content
HTTP/1.1 204无内容
In this example, even though both the source and destination are locked, only one lock token must be submitted (the one for the lock on the destination). This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.
在本例中，即使源和目标都已锁定，也只需提交一个锁定令牌（用于目标上的锁定的令牌）。这是因为源资源不被副本修改，因此不受写锁的影响。在此示例中，用户代理身份验证以前是通过HTTP协议范围之外的机制在底层传输层中进行的。
Consider a collection "/locked" with an exclusive, depth-infinity write lock, and an attempt to delete an internal member "/locked/ member":
考虑一个具有“独占深度无限写锁”的“/锁定”集合，并尝试删除内部成员“/锁定/成员”：
>>Request
>>请求
DELETE /locked/member HTTP/1.1
Host: example.com
DELETE /locked/member HTTP/1.1
Host: example.com
>>Response
>>回应
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:lock-token-submitted>
<D:href>/locked/</D:href>
</D:lock-token-submitted>
</D:error>
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:lock-token-submitted>
<D:href>/locked/</D:href>
</D:lock-token-submitted>
</D:error>
Thus, the client would need to submit the lock token with the request to make it succeed. To do that, various forms of the If header (see Section 10.4) could be used.
因此，客户机需要将锁令牌与请求一起提交以使其成功。为此，可以使用各种形式的If头（见第10.4节）。
"No-Tag-List" format:
“无标签列表”格式：
If: (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
If: (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
"Tagged-List" format, for "http://example.com/locked/":
“标记列表”格式，用于http://example.com/locked/":
If: <http://example.com/locked/>
(<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
If: <http://example.com/locked/>
(<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
"Tagged-List" format, for "http://example.com/locked/member":
“标记列表”格式，用于http://example.com/locked/member":
If: <http://example.com/locked/member>
(<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
If: <http://example.com/locked/member>
(<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
Note that, for the purpose of submitting the lock token, the actual form doesn't matter; what's relevant is that the lock token appears in the If header, and that the If header itself evaluates to true.
注意，为了提交锁令牌，实际的形式并不重要；相关的是锁标记出现在If头中，而If头本身的计算结果为true。
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with a depth-infinity lock, then the resource will be added to the lock.
复制方法调用不得复制源上活动的任何写锁。但是，如前所述，如果副本将资源复制到使用深度无限锁锁定的集合中，则资源将添加到锁中。
A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, if there is an existing lock at the destination, the server MUST add the moved resource to the destination lock scope. For example, if the MOVE makes the resource a child of a collection that has a depth-infinity lock, then the resource will be added to that collection's lock. Additionally, if a resource with a depth-infinity lock is moved to a destination that is within the scope of the same lock (e.g., within the URL namespace tree covered by the lock), the moved resource will again be added to the lock. In both these examples, as specified in Section 7.5, an If header must be submitted containing a lock token for both the source and destination.
对写锁定资源的成功移动请求不得随资源一起移动写锁定。但是，如果目标上存在锁，服务器必须将移动的资源添加到目标锁作用域中。例如，如果移动使资源成为具有深度无限锁的集合的子级，则该资源将添加到该集合的锁中。此外，如果将具有深度无限锁定的资源移动到同一锁定范围内的目标（例如，在锁定所覆盖的URL命名空间树内），则移动的资源将再次添加到锁定中。在这两个示例中，如第7.5节所述，必须提交包含源和目标锁定令牌的If头。
A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked.
客户端不得两次提交同一写锁请求。请注意，客户端始终知道它正在重新提交相同的锁定请求，因为它必须在If头中包含锁定令牌，以便对已锁定的资源发出请求。
However, a client may submit a LOCK request with an If header but without a body. A server receiving a LOCK request with no body MUST NOT create a new lock -- this form of the LOCK request is only to be used to "refresh" an existing lock (meaning, at minimum, that any timers associated with the lock MUST be reset).
但是，客户机可以提交带有If头但没有正文的锁请求。接收不带主体的锁请求的服务器不得创建新锁——这种形式的锁请求仅用于“刷新”现有锁（这意味着，至少必须重置与锁关联的任何计时器）。
Clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client, and a server MAY refresh a lock with a timeout period that is different than the previous timeout period used for the lock, provided it advertises the new value in the LOCK refresh response.
客户端可以在其锁刷新请求中提交任意值的超时头。与往常一样，服务器可能会忽略客户端提交的超时头，并且服务器可能会使用与用于锁的前一个超时时间不同的超时时间来刷新锁，前提是它在锁刷新响应中播发新值。
If an error is received in response to a refresh LOCK request, the client MUST NOT assume that the lock was refreshed.
如果在响应中未接收到锁，则必须假定客户端已刷新该锁。
Servers MUST return authorization errors in preference to other errors. This avoids leaking information about protected resources (e.g., a client that finds that a hidden resource exists by seeing a 423 Locked response to an anonymous request to the resource).
服务器必须优先返回授权错误，而不是其他错误。这样可以避免泄漏有关受保护资源的信息（例如，通过查看对资源的匿名请求的423锁定响应而发现存在隐藏资源的客户端）。
In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter information either in an XML ([REC-XML]) request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility; and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support.
在HTTP/1.1中，方法参数信息专门编码在HTTP头中。与HTTP/1.1不同，WebDAV在XML（[REC-XML]）请求实体体或HTTP头中编码方法参数信息。使用XML编码方法参数的动机是能够向现有结构添加额外的XML元素，从而提供可扩展性；通过XML在ISO10646字符集编码信息的能力，提供国际化支持。
In addition to encoding method parameters, XML is used in WebDAV to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input.
除了编码方法参数外，WebDAV中还使用XML对方法的响应进行编码，为方法输出和输入提供了XML的可扩展性和国际化优势。
When XML is used for a request or response body, the Content-Type type SHOULD be application/xml. Implementations MUST accept both text/xml and application/xml in request and response bodies. Use of text/xml is deprecated.
当XML用于请求或响应主体时，内容类型应为application/XML。实现必须在请求和响应主体中同时接受text/xml和application/xml。不推荐使用xml/text。
All DAV-compliant clients and resources MUST use XML parsers that are compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either requests or responses MUST be, at minimum, well formed and use namespaces correctly. If a server receives XML that is not well-formed, then the server MUST reject the entire request with a 400 (Bad Request). If a client receives XML that is not well-formed in a response, then the client MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
所有符合DAV的客户端和资源必须使用符合[REC-XML]和[REC-XML-NAME]的XML解析器。请求或响应中使用的所有XML至少必须格式良好，并正确使用名称空间。如果服务器接收到格式不正确的XML，则服务器必须以400（错误请求）拒绝整个请求。如果客户机接收到响应中格式不正确的XML，则客户机不得对执行方法的结果进行任何假设，并应将服务器视为出现故障。
Note that processing XML submitted by an untrusted source may cause risks connected to privacy, security, and service quality (see Section 20). Servers MAY reject questionable requests (even though they consist of well-formed XML), for instance, with a 400 (Bad Request) status code and an optional response body explaining the problem.
请注意，处理由不受信任的源提交的XML可能会导致与隐私、安全和服务质量相关的风险（请参阅第20节）。服务器可能会拒绝有问题的请求（即使它们由格式良好的XML组成），例如，使用400（错误请求）状态代码和可选的响应主体来解释问题。
URLs appear in many places in requests and responses. Interoperability experience with [RFC2518] showed that many clients parsing Multi-Status responses did not fully implement the full Reference Resolution defined in Section 5 of [RFC3986]. Thus, servers in particular need to be careful in handling URLs in responses, to ensure that clients have enough context to be able to interpret all the URLs. The rules in this section apply not only to resource URLs in the 'href' element in Multi-Status responses, but also to the Destination and If header resource URLs.
URL出现在请求和响应中的许多地方。[RFC2518]的互操作性经验表明，许多解析多状态响应的客户端没有完全实现[RFC3986]第5节中定义的完整参考解析。因此，服务器在处理响应中的URL时尤其需要小心，以确保客户端有足够的上下文来解释所有URL。本节中的规则不仅适用于多状态响应中“href”元素中的资源URL，还适用于目标和If头资源URL。
The sender has a choice between two approaches: using a relative reference, which is resolved against the Request-URI, or a full URI. A server MUST ensure that every 'href' value within a Multi-Status response uses the same format.
发送方可以选择两种方法：使用相对引用（根据请求URI解析）或完整URI。服务器必须确保多状态响应中的每个“href”值使用相同的格式。
WebDAV only uses one form of relative reference in its extensions, the absolute path.
WebDAV在其扩展中只使用一种形式的相对引用，即绝对路径。
Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )
简单引用=绝对URI |（路径绝对[“？”查询]）
The absolute-URI, path-absolute and query productions are defined in Sections 4.3, 3.3, and 3.4 of [RFC3986].
[RFC3986]第4.3、3.3和3.4节定义了绝对URI、绝对路径和查询结果。
Within Simple-ref productions, senders MUST NOT:
在简单引用产品中，发送者不得：
o use dot-segments ("." or ".."), or
o 使用点段（“.”或“.”），或
o have prefixes that do not match the Request-URI (using the comparison rules defined in Section 3.2.3 of [RFC2616]).
o 前缀与请求URI不匹配（使用[RFC2616]第3.2.3节中定义的比较规则）。
Identifiers for collections SHOULD end in a '/' character.
集合的标识符应以“/”字符结尾。
Consider the collection http://example.com/sample/ with the internal member URL http://example.com/sample/a%20test and the PROPFIND request below:
考虑收藏http://example.com/sample/ 使用内部成员URLhttp://example.com/sample/a%20test 以及下面的PROPFIND请求：
>>Request:
>>请求：
PROPFIND /sample/ HTTP/1.1
Host: example.com
Depth: 1
PROPFIND /sample/ HTTP/1.1
Host: example.com
Depth: 1
In this case, the server should return two 'href' elements containing either
在这种情况下，服务器应返回两个“href”元素，其中包含
o 'http://example.com/sample/' and
'http://example.com/sample/a%20test', or
o 'http://example.com/sample/' and
'http://example.com/sample/a%20test', or
o '/sample/' and '/sample/a%20test'
o '/sample/' and '/sample/a%20test'
Note that even though the server may be storing the member resource internally as 'a test', it has to be percent-encoded when used inside a URI reference (see Section 2.1 of [RFC3986]). Also note that a legal URI may still contain characters that need to be escaped within XML character data, such as the ampersand character.
请注意，即使服务器可能在内部将成员资源存储为“测试”，但在URI引用中使用时，必须对其进行百分比编码（请参阅[RFC3986]的第2.1节）。还请注意，合法URI可能仍然包含需要在XML字符数据中转义的字符，例如符号和字符。
Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as the client intended.
其中一些新方法不定义实体。服务器必须检查对主体的所有请求，即使主体不是预期的。在存在请求主体但将被服务器忽略的情况下，服务器必须使用415（不支持的媒体类型）拒绝请求。这会通知客户机（可能正在尝试使用扩展）无法按照客户机的预期处理正文。
HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible (see Section 14.18, [RFC2616]).
HTTP定义了许多可用于WebDAV请求和响应的头。并非所有这些都适用于所有情况，有些交互可能未定义。请注意，如果可能，HTTP 1.1要求在所有响应中使用日期头（请参阅第14.18节[RFC2616]）。
The server MUST do authorization checks before checking any HTTP conditional header.
服务器必须在检查任何HTTP条件头之前进行授权检查。
HTTP 1.1 recommends the use of ETags rather than modification dates, for cache control, and there are even stronger reasons to prefer ETags for authoring. Correct use of ETags is even more important in a distributed authoring environment, because ETags are necessary along with locks to avoid the lost-update problem. A client might fail to renew a lock, for example, when the lock times out and the client is accidentally offline or in the middle of a long upload. When a client fails to renew the lock, it's quite possible the resource can still be relocked and the user can go on editing, as long as no changes were made in the meantime. ETags are required for the client to be able to distinguish this case. Otherwise, the
HTTP 1.1建议使用ETag而不是修改日期来进行缓存控制，并且有更强烈的理由倾向于使用ETag进行创作。在分布式创作环境中，etag的正确使用更为重要，因为etag与锁一起是避免丢失更新问题所必需的。例如，当锁超时和客户端意外脱机或在长时间上传期间，客户端可能无法更新锁。当客户端无法更新锁时，很可能仍然可以重新锁定资源，用户可以继续编辑，只要在此期间没有进行任何更改。客户需要ETag才能区分这种情况。否则
client is forced to ask the user whether to overwrite the resource on the server without even being able to tell the user if it has changed. Timestamps do not solve this problem nearly as well as ETags.
客户端被迫询问用户是否覆盖服务器上的资源，甚至无法告诉用户资源是否已更改。时间戳不能像ETag那样解决这个问题。
Strong ETags are much more useful for authoring use cases than weak ETags (see Section 13.3.3 of [RFC2616]). Semantic equivalence can be a useful concept but that depends on the document type and the application type, and interoperability might require some agreement or standard outside the scope of this specification and HTTP. Note also that weak ETags have certain restrictions in HTTP, e.g., these cannot be used in If-Match headers.
强ETag比弱ETag更适用于编写用例（参见[RFC2616]第13.3.3节）。语义等价可能是一个有用的概念，但这取决于文档类型和应用程序类型，互操作性可能需要一些超出本规范和HTTP范围的协议或标准。还请注意，弱ETag在HTTP中有某些限制，例如，不能在If-Match头中使用这些限制。
Note that the meaning of an ETag in a PUT response is not clearly defined either in this document or in RFC 2616 (i.e., whether the ETag means that the resource is octet-for-octet equivalent to the body of the PUT request, or whether the server could have made minor changes in the formatting or content of the document upon storage). This is an HTTP issue, not purely a WebDAV issue.
请注意，本文档或RFC 2616中均未明确定义PUT响应中ETag的含义（即，ETag是否表示资源是与PUT请求正文等效的八位字节对应的八位字节，或者服务器是否可能在存储时对文档的格式或内容进行了微小更改）。这是一个HTTP问题，而不仅仅是WebDAV问题。
Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or the Last-Modified time) for a resource that has an unchanged body and location. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed.
由于如果ETag发生更改，客户端可能会被迫提示用户或丢弃更改的内容，因此WebDAV服务器不应更改具有未更改正文和位置的资源的ETag（或上次修改的时间）。ETag表示资源的主体或内容的状态。没有类似的方法来判断属性是否已更改。
HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until the specification for Versioning Extensions to WebDAV introduced a mechanism to include more specific information in the body of an error response (Section 1.6 of [RFC3253]). The error body mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This error body mechanism is covered in Section 16.
HTTP和WebDAV在WebDAV版本控制扩展规范引入了一种机制，在错误响应正文中包含更具体的信息（RFC3253第1.6节）之前，没有将大多数错误响应正文用于机器可解析信息。错误主体机制适用于任何可能需要主体但尚未定义主体的错误响应。当状态代码可能意味着很多事情时（例如，400个错误请求可能意味着缺少所需的标头、标头格式不正确或更多），该机制尤其适用。第16节介绍了这种错误主体机制。
Note that the HTTP response headers "Etag" and "Last-Modified" (see [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per resource), and are used by clients for caching. Therefore servers must ensure that executing any operation that affects the URL namespace (such as COPY, MOVE, DELETE, PUT, or MKCOL) does preserve their semantics, in particular:
请注意，HTTP响应头“Etag”和“Last Modified”（请参阅[RFC2616]，第14.19和14.29节）是根据URL（而不是每个资源）定义的，并由客户端用于缓存。因此，服务器必须确保执行任何影响URL命名空间的操作（例如复制、移动、删除、放置或MKCOL）都能保留其语义，特别是：
o For any given URL, the "Last-Modified" value MUST increment every time the representation returned upon GET changes (within the limits of timestamp resolution).
o 对于任何给定的URL，“Last Modified”值必须在每次GET更改时返回表示时递增（在时间戳解析的限制范围内）。
o For any given URL, an "ETag" value MUST NOT be reused for different representations returned by GET.
o 对于任何给定的URL，GET返回的不同表示形式不得重用“ETag”值。
In practice this means that servers
实际上，这意味着服务器
o might have to increment "Last-Modified" timestamps for every resource inside the destination namespace of a namespace operation unless it can do so more selectively, and
o 可能必须为命名空间操作的目标命名空间内的每个资源增加“Last Modified”时间戳，除非它可以更有选择性地这样做，并且
o similarly, might have to re-assign "ETag" values for these resources (unless the server allocates entity tags in a way so that they are unique across the whole URL namespace managed by the server).
o 类似地，可能必须为这些资源重新分配“ETag”值（除非服务器以某种方式分配实体标记，以便它们在服务器管理的整个URL命名空间中是唯一的）。
Note that these considerations also apply to specific use cases, such as using PUT to create a new resource at a URL that has been mapped before, but has been deleted since then.
请注意，这些注意事项也适用于特定用例，例如使用PUT在之前已映射但此后已删除的URL处创建新资源。
Finally, WebDAV properties (such as DAV:getetag and DAV: getlastmodified) that inherit their semantics from HTTP headers must behave accordingly.
最后，从HTTP头继承语义的WebDAV属性（如DAV:getetag和DAV:getlastmodified）必须具有相应的行为。
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs. All DAV-compliant resources MUST support the PROPFIND method and the propfind XML element (Section 14.20) along with all XML elements defined for use with that element.
如果资源没有任何内部成员，则PROPFIND方法检索由请求URI标识的资源上定义的属性；如果资源是具有内部成员URL的集合，则检索由请求URI标识的资源上定义的属性，并可能检索其成员资源。所有符合DAV的资源必须支持PROPFIND方法和PROPFIND XML元素（第14.20节），以及为与该元素一起使用而定义的所有XML元素。
A client MUST submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request. Servers MUST support "0" and "1" depth requests on WebDAV-compliant resources and SHOULD support "infinity" requests. In practice, support for infinite-depth requests MAY be disabled, due to the performance and security concerns associated with this behavior. Servers SHOULD treat a request without a Depth header as if a "Depth: infinity" header was included.
客户端必须通过PROPFIND请求提交值为“0”、“1”或“无穷大”的深度标头。服务器必须支持WebDAV兼容资源上的“0”和“1”深度请求，并应支持“无限”请求。实际上，由于与此行为相关的性能和安全问题，可能会禁用对无限深度请求的支持。服务器应将没有深度标头的请求视为包含“Depth:infinity”标头。
A client may submit a 'propfind' XML element in the body of the request method describing what information is being requested. It is possible to:
客户机可以在请求方法的主体中提交一个“propfind”XML元素，描述所请求的信息。可以：
o Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by the server),
o 通过命名“prop”元素中所需的属性来请求特定属性值（服务器可能会忽略此处属性的顺序），
o Request property values for those properties defined in this specification (at a minimum) plus dead properties, by using the 'allprop' element (the 'include' element can be used with 'allprop' to instruct the server to also include additional live properties that may not have been returned otherwise),
o 通过使用“allprop”元素（include元素可与“allprop”一起使用，指示服务器还包括其他可能未返回的活动属性），请求本规范中定义的属性（至少）的属性值加上死属性，
o Request a list of names of all the properties defined on the resource, by using the 'propname' element.
o 使用“propname”元素请求资源上定义的所有属性的名称列表。
A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request.
客户可以选择不提交请求正文。必须将空的PROPFIND请求正文视为“allprop”请求。
Note that 'allprop' does not return values for all live properties. WebDAV servers increasingly have expensively-calculated or lengthy properties (see [RFC3253] and [RFC3744]) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what live properties exist, and request named properties when retrieving values. For a live property defined elsewhere, that definition can specify whether or not that live property would be returned in 'allprop' requests.
请注意，“allprop”不会返回所有活动属性的值。WebDAV服务器越来越多地具有昂贵的计算或冗长的属性（请参见[RFC3253]和[RFC3744]），并且不返回所有属性。相反，WebDAV客户端可以使用propname请求来发现存在哪些活动属性，并在检索值时请求命名属性。对于在别处定义的活动属性，该定义可以指定是否在“allprop”请求中返回该活动属性。
All servers MUST support returning a response of content type text/ xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties.
所有服务器都必须支持返回内容类型为text/xml或application/xml的响应，该响应包含一个multistatus xml元素，该元素描述检索各种属性的尝试的结果。
If there is an error retrieving a property, then a proper error result MUST be included in the response. A request to retrieve the value of a property that does not exist is an error and MUST be noted with a 'response' XML element that contains a 404 (Not Found) status value.
如果检索属性时出错，则响应中必须包含正确的错误结果。检索不存在的属性值的请求是一个错误，必须使用包含404（未找到）状态值的“response”XML元素进行说明。
Consequently, the 'multistatus' XML element for a collection resource MUST include a 'response' XML element for each member URL of the collection, to whatever depth was requested. It SHOULD NOT include any 'response' elements for resources that are not WebDAV-compliant. Each 'response' element MUST contain an 'href' element that contains the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource are returned as a flat list whose order of entries is not
因此，集合资源的“multistatus”XML元素必须包含集合的每个成员URL的“response”XML元素，无论请求的深度如何。对于不符合WebDAV的资源，它不应包含任何“响应”元素。每个“response”元素必须包含一个“href”元素，该元素包含定义prop-XML元素中属性的资源的URL。集合资源上PROPFIND的结果将作为一个平面列表返回，该列表的条目顺序不相同
significant. Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses.
重要的请注意，对于给定名称的属性，资源可能只有一个值，因此该属性可能仅在PROPFIND响应中显示一次。
Properties may be subject to access control. In the case of 'allprop' and 'propname' requests, if a principal does not have the right to know whether a particular property exists, then the property MAY be silently excluded from the response.
属性可能受访问控制。在“allprop”和“propname”请求的情况下，如果主体无权知道某个特定属性是否存在，则该属性可能会被静默地从响应中排除。
Some PROPFIND results MAY be cached, with care, as there is no cache validation mechanism for most properties. This method is both safe and idempotent (see Section 9.1 of [RFC2616]).
有些PROPFIND结果可能会被缓存，但要小心，因为大多数属性都没有缓存验证机制。该方法既安全又幂等（见[RFC2616]第9.1节）。
This section, as with similar sections for other methods, provides some guidance on error codes and preconditions or postconditions (defined in Section 16) that might be particularly useful with PROPFIND.
本节与其他方法的类似章节一样，提供了一些关于错误代码和前置条件或后置条件（在第16节中定义）的指导，这些可能对PROPFIND特别有用。
403 Forbidden - A server MAY reject PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body.
403禁止-服务器可能会拒绝深度标头为“无穷大”的集合上的PROPFIND请求，在这种情况下，服务器应使用此错误，前提条件代码“PROPFIND finite depth”位于错误体中。
In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
在PROPFIND响应中，有关单个属性的信息在“propstat”元素中返回（参见第14.22节），每个元素包含一个单独的“status”元素，该元素包含关于其中出现的属性的信息。下表总结了“propstat”中使用的最常见状态代码；但是，客户还应准备好处理其他2/3/4/5xx系列状态代码。
200 OK - A property exists and/or its value is successfully returned.
200确定-属性存在和/或其值已成功返回。
401 Unauthorized - The property cannot be viewed without appropriate authorization.
401未经授权-未经适当授权，不得查看该财产。
403 Forbidden - The property cannot be viewed regardless of authentication.
403禁止-无论身份验证如何，都无法查看该属性。
404 Not Found - The property does not exist.
404未找到-属性不存在。
>>Request
>>请求
PROPFIND /file HTTP/1.1
Host: www.example.com
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
PROPFIND /file HTTP/1.1
Host: www.example.com
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:R="http://ns.example.com/boxschema/">
<D:href>http://www.example.com/file</D:href>
<D:propstat>
<D:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Johnson</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to the
DingALing property.
</D:responsedescription>
</D:propstat>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:R="http://ns.example.com/boxschema/">
<D:href>http://www.example.com/file</D:href>
<D:propstat>
<D:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Johnson</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to the
DingALing property.
</D:responsedescription>
</D:propstat>
</D:response>
<D:responsedescription> There has been an access violation error.
</D:responsedescription>
</D:multistatus>
</D:response>
<D:responsedescription> There has been an access violation error.
</D:responsedescription>
</D:multistatus>
In this example, PROPFIND is executed on a non-collection resource http://www.example.com/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case, only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
在本例中，PROPFIND在非集合资源上执行http://www.example.com/file. propfind XML元素指定请求其值的四个属性的名称。在本例中，只返回了两个属性，因为发出请求的主体没有足够的访问权限来查看第三个和第四个属性。
>>Request
>>请求
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:">
<propname/>
</propfind>
<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:">
<propname/>
</propfind>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://www.example.com/container/</href>
<propstat>
<prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<creationdate/>
<displayname/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://www.example.com/container/</href>
<propstat>
<prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<creationdate/>
<displayname/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>http://www.example.com/container/front.html</href>
<propstat>
<prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<creationdate/>
<displayname/>
<getcontentlength/>
<getcontenttype/>
<getetag/>
<getlastmodified/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
</propstat>
</response>
<response>
<href>http://www.example.com/container/front.html</href>
<propstat>
<prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<creationdate/>
<displayname/>
<getcontentlength/>
<getcontenttype/>
<getetag/>
<getlastmodified/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
In this example, PROPFIND is invoked on the collection resource http://www.example.com/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its descendants should be returned.
在本例中，在集合资源上调用PROPFINDhttp://www.example.com/container/，带有包含propname XML元素的propfind XML元素，这意味着应返回所有属性的名称。由于不存在深度标头，因此它假定其默认值为“无穷大”，这意味着应该返回集合及其所有子体上属性的名称。
Consistent with the previous example, resource http://www.example.com/container/ has six properties defined on it: bigbox and author in the "http://ns.example.com/boxschema/" namespace, and creationdate, displayname, resourcetype, and supportedlock in the "DAV:" namespace.
与前面的示例一致，资源http://www.example.com/container/ 定义了六个属性：bigbox和“中的作者”http://ns.example.com/boxschema/命名空间，以及“DAV:”命名空间中的creationdate、displayname、resourcetype和supportedlock。
The resource http://www.example.com/container/index.html, a member of the "container" collection, has nine properties defined on it, bigbox in the "http://ns.example.com/boxschema/" namespace and creationdate, displayname, getcontentlength, getcontenttype, getetag, getlastmodified, resourcetype, and supportedlock in the "DAV:" namespace.
资源http://www.example.com/container/index.html，是“container”集合的成员，在其上定义了九个属性，即http://ns.example.com/boxschema/“DAV:”命名空间中的命名空间和creationdate、displayname、getcontentlength、getcontenttype、getetag、getlastmodified、resourcetype和supportedlock。
This example also demonstrates the use of XML namespace scoping and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all enclosed elements. Hence, all elements that do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.
此示例还演示了XML命名空间范围和默认命名空间的使用。由于“xmlns”属性不包含前缀，因此默认情况下，名称空间应用于所有封闭的元素。因此，所有未显式声明其所属名称空间的元素都是“DAV:”名称空间的成员。
Note that 'allprop', despite its name, which remains for backward-compatibility, does not return every property, but only dead properties and the live properties defined in this specification.
请注意，“allprop”尽管名称为向后兼容，但并不返回每个属性，只返回本规范中定义的死属性和活属性。
>>Request
>>请求
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
</D:propfind>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/container/</D:href>
<D:propstat>
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox><R:BoxType>Box type A</R:BoxType></R:bigbox>
<R:author><R:Name>Hadrian</R:Name></R:author>
<D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
<D:displayname>Example collection</D:displayname>
<D:resourcetype><D:collection/></D:resourcetype>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/container/</D:href>
<D:propstat>
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox><R:BoxType>Box type A</R:BoxType></R:bigbox>
<R:author><R:Name>Hadrian</R:Name></R:author>
<D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
<D:displayname>Example collection</D:displayname>
<D:resourcetype><D:collection/></D:resourcetype>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/container/front.html</D:href>
<D:propstat>
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox><R:BoxType>Box type B</R:BoxType>
</R:bigbox>
<D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate>
<D:displayname>Example HTML resource</D:displayname>
<D:getcontentlength>4525</D:getcontentlength>
<D:getcontenttype>text/html</D:getcontenttype>
<D:getetag>"zzyzx"</D:getetag>
<D:getlastmodified
>Mon, 12 Jan 1998 09:25:56 GMT</D:getlastmodified>
<D:resourcetype/>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/container/front.html</D:href>
<D:propstat>
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox><R:BoxType>Box type B</R:BoxType>
</R:bigbox>
<D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate>
<D:displayname>Example HTML resource</D:displayname>
<D:getcontentlength>4525</D:getcontentlength>
<D:getcontenttype>text/html</D:getcontenttype>
<D:getetag>"zzyzx"</D:getetag>
<D:getlastmodified
>Mon, 12 Jan 1998 09:25:56 GMT</D:getlastmodified>
<D:resourcetype/>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
In this example, PROPFIND was invoked on the resource http://www.example.com/container/ with a Depth header of 1, meaning the request applies to the resource and its children, and a propfind XML element containing the allprop XML element, meaning the request should return the name and value of all the dead properties defined on the resources, plus the name and value of all the properties defined in this specification. This example illustrates the use of relative references in the 'href' elements of the response.
在本例中，对资源调用了PROPFINDhttp://www.example.com/container/ 深度标头为1，表示请求应用于资源及其子项；propfind XML元素包含allprop XML元素，表示请求应返回资源上定义的所有无效属性的名称和值，加上本规范中定义的所有属性的名称和值。此示例说明了在响应的“href”元素中使用相对引用。
The resource http://www.example.com/container/ has six properties defined on it: 'bigbox' and 'author in the "http://ns.example.com/boxschema/" namespace, DAV:creationdate, DAV: displayname, DAV:resourcetype, and DAV:supportedlock.
资源http://www.example.com/container/ 定义了六个属性：“bigbox”和“中的作者”http://ns.example.com/boxschema/命名空间、DAV:creationdate、DAV:displayname、DAV:resourcetype和DAV:supportedlock。
The last four properties are WebDAV-specific, defined in Section 15. Since GET is not supported on this resource, the get* properties (e.g., DAV:getcontentlength) are not defined on this resource. The WebDAV-specific properties assert that "container" was created on December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT (DAV:creationdate), has a name of "Example collection" (DAV: displayname), a collection resource type (DAV:resourcetype), and supports exclusive write and shared write locks (DAV:supportedlock).
最后四个属性是特定于WebDAV的，定义见第15节。由于此资源不支持GET，因此未在此资源上定义GET*属性（例如DAV:getcontentlength）。WebDAV特定属性断言，“容器”创建于1997年12月1日下午5:42:21，位于格林尼治标准时间以西8小时的时区（DAV:creationdate），名称为“示例集合”（DAV:displayname），集合资源类型（DAV:resourcetype），并支持独占写锁和共享写锁（DAV:supportedlock）。
The resource http://www.example.com/container/front.html has nine properties defined on it:
资源http://www.example.com/container/front.html 在其上定义了九个属性：
'bigbox' in the "http://ns.example.com/boxschema/" namespace (another instance of the "bigbox" property type), DAV:creationdate, DAV: displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
“中的“大盒子”http://ns.example.com/boxschema/命名空间（bigbox属性类型的另一个实例）、DAV:creationdate、DAV:displayname、DAV:getcontentlength、DAV:getcontenttype、DAV:getetag、DAV:getlastmodified、DAV:resourcetype和DAV:supportedlock。
The DAV-specific properties assert that "front.html" was created on December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT (DAV:creationdate), has a name of "Example HTML resource" (DAV: displayname), a content length of 4525 bytes (DAV:getcontentlength), a MIME type of "text/html" (DAV:getcontenttype), an entity tag of "zzyzx" (DAV:getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT (DAV:getlastmodified), has an empty resource type, meaning that it is not a collection (DAV:resourcetype), and supports both exclusive write and shared write locks (DAV:supportedlock).
特定于DAV的属性断言，“front.html”创建于1997年12月1日下午6:27:21，位于格林尼治标准时间以西8小时的时区（DAV:creationdate），名称为“示例html资源”（DAV:displayname），内容长度为4525字节（DAV:getcontentlength），MIME类型为“text/html”（DAV:getcontenttype），实体标记为“zzyzx”（DAV:getetag），上次修改时间为1998年1月12日星期一格林尼治标准时间09:25:56（DAV:getlastdimited），资源类型为空，这意味着它不是集合（DAV:resourcetype），并且支持独占写锁和共享写锁（DAV:supportedlock）。
>>Request
>>请求
PROPFIND /mycol/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
PROPFIND /mycol/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:include>
<D:supported-live-property-set/>
<D:supported-report-set/>
</D:include>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:include>
<D:supported-live-property-set/>
<D:supported-report-set/>
</D:include>
</D:propfind>
In this example, PROPFIND is executed on the resource http://www.example.com/mycol/ and its internal member resources. The client requests the values of all live properties defined in this specification, plus all dead properties, plus two more live properties defined in [RFC3253]. The response is not shown.
在本例中，PROPFIND在资源上执行http://www.example.com/mycol/ 以及其内部成员资源。客户机请求本规范中定义的所有活动属性的值，加上所有非活动属性，再加上[RFC3253]中定义的两个活动属性。没有显示响应。
The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI.
PROPPATCH方法处理请求正文中指定的指令，以设置和/或删除由请求URI标识的资源上定义的属性。
All DAV-compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements. Execution of the directives in this method is, of course, subject to access control constraints. DAV-compliant resources SHOULD support the setting of arbitrary dead properties.
所有符合DAV的资源都必须支持PROPPATCH方法，并且必须处理使用propertyupdate、set和remove XML元素指定的指令。当然，此方法中指令的执行受访问控制约束。符合DAV的资源应支持设置任意死属性。
The request message body of a PROPPATCH method MUST contain the propertyupdate XML element.
PROPPATCH方法的请求消息体必须包含propertyupdate XML元素。
Servers MUST process PROPPATCH instructions in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus, if any error occurs during processing, all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in Sections 14.23 and 14.26.
服务器必须按文档顺序处理PROPPATCH指令（与排序无关的正常规则不同）。指令必须全部执行或不执行。因此，如果在处理过程中发生任何错误，则必须撤消所有执行的指令，并返回正确的错误结果。指令处理详细信息可在第14.23节和第14.26节的集合和移除指令定义中找到。
If a server attempts to make any of the property changes in a PROPPATCH request (i.e., the request is not rejected for high-level errors before processing the body), the response MUST be a Multi-Status response as described in Section 9.2.1.
如果服务器试图在PROPPATCH请求中进行任何属性更改（即，在处理正文之前，请求不会因高级错误而被拒绝），则响应必须是第9.2.1节所述的多状态响应。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
该方法是幂等的，但不安全（见[RFC2616]第9.1节）。不得缓存对此方法的响应。
In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
在PROPPATCH响应中，有关单个属性的信息在“propstat”元素中返回（请参见第14.22节），每个元素包含一个单独的“status”元素，其中包含有关其中出现的属性的信息。下表总结了“propstat”中使用的最常见状态代码；但是，客户还应准备好处理其他2/3/4/5xx系列状态代码。
200 (OK) - The property set or change succeeded. Note that if this appears for one property, it appears for every property in the response, due to the atomicity of PROPPATCH.
200（确定）-属性集或更改成功。请注意，由于PROPPATCH的原子性，如果它出现在一个属性上，那么它会出现在响应中的每个属性上。
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
403（禁止）-由于服务器选择不指定的原因，客户端无法更改其中一个属性。
403 (Forbidden): The client has attempted to set a protected property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'cannot-modify-protected-property' inside the response body.
403（禁止）：客户端试图设置受保护的属性，例如DAV:getetag。如果返回此错误，服务器应在响应正文中使用前提条件代码“cannot modify protected property”。
409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property.
409（冲突）-客户端提供了一个语义不适合该属性的值。
424 (Failed Dependency) - The property change could not be made because of another property change that failed.
无法更改另一个属性（424），因此无法更改该属性。
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
507（存储不足）-服务器没有足够的空间来记录属性。
>>Request
>>请求
PROPPATCH /bar.html HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
PROPPATCH /bar.html HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://ns.example.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:Authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:Authors>
</D:prop>
</D:set>
<D:remove>
<D:prop><Z:Copyright-Owner/></D:prop>
</D:remove>
</D:propertyupdate>
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://ns.example.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:Authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:Authors>
</D:prop>
</D:set>
<D:remove>
<D:prop><Z:Copyright-Owner/></D:prop>
</D:remove>
</D:propertyupdate>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:Z="http://ns.example.com/standards/z39.50/">
<D:response>
<D:href>http://www.example.com/bar.html</D:href>
<D:propstat>
<D:prop><Z:Authors/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
<D:propstat>
<D:prop><Z:Copyright-Owner/></D:prop>
<D:status>HTTP/1.1 409 Conflict</D:status>
</D:propstat>
<D:responsedescription> Copyright Owner cannot be deleted or
altered.</D:responsedescription>
</D:response>
</D:multistatus>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:Z="http://ns.example.com/standards/z39.50/">
<D:response>
<D:href>http://www.example.com/bar.html</D:href>
<D:propstat>
<D:prop><Z:Authors/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
<D:propstat>
<D:prop><Z:Copyright-Owner/></D:prop>
<D:status>HTTP/1.1 409 Conflict</D:status>
</D:propstat>
<D:responsedescription> Copyright Owner cannot be deleted or
altered.</D:responsedescription>
</D:response>
</D:multistatus>
In this example, the client requests the server to set the value of the "Authors" property in the "http://ns.example.com/standards/z39.50/" namespace, and to remove the property "Copyright-Owner" in the same namespace. Since the Copyright-Owner property could not be removed, no property modifications occur. The 424 (Failed Dependency) status code for the Authors property indicates this action would have succeeded if it were not for the conflict with removing the Copyright-Owner property.
在本例中，客户端请求服务器在http://ns.example.com/standards/z39.50/，并删除同一命名空间中的属性“版权所有者”。由于无法删除版权所有者的财产，因此不会发生财产修改。Authors属性的424（失败的依赖项）状态代码表示，如果不是因为与删除版权所有者属性冲突，此操作将成功。
MKCOL creates a new collection resource at the location specified by the Request-URI. If the Request-URI is already mapped to a resource, then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI an internal member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the request must fail.
MKCOL在请求URI指定的位置创建新的集合资源。如果请求URI已映射到资源，则MKCOL必须失败。在MKCOL处理期间，服务器必须使请求URI成为其父集合的内部成员，除非请求URI为“/”。如果不存在这样的祖先，则该方法必须失败。当MKCOL操作创建新的集合资源时，所有祖先必须已经存在，否则该方法必须失败，状态代码为409（冲突）。例如，如果发出创建集合/a/b/c/d/的请求，并且/a/b/c/不存在，则该请求必须失败。
When MKCOL is invoked without a request body, the newly created collection SHOULD have no members.
当在没有请求主体的情况下调用MKCOL时，新创建的集合应该没有成员。
A MKCOL request message may contain a message body. The precise behavior of a MKCOL request when the body is present is undefined, but limited to creating collections, members of a collection, bodies of members, and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand, it MUST respond with a 415 (Unsupported Media Type) status code. If the server decides to reject the request based on the presence of an entity or the type of an entity, it should use the 415 (Unsupported Media Type) status code.
MKCOL请求消息可能包含消息正文。存在主体时，MKCOL请求的确切行为尚未定义，但仅限于创建集合、集合成员、成员主体以及集合或成员的属性。如果服务器接收到它不支持或不理解的MKCOL请求实体类型，则必须使用415（不支持的媒体类型）状态代码进行响应。如果服务器基于实体的存在或实体的类型决定拒绝请求，则应使用415（不支持的媒体类型）状态代码。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
该方法是幂等的，但不安全（见[RFC2616]第9.1节）。不得缓存对此方法的响应。
In addition to the general status codes possible, the following status codes have specific applicability to MKCOL:
除可能的通用状态代码外，以下状态代码对MKCOL具有特定的适用性：
201 (Created) - The collection was created.
201（已创建）-已创建集合。
403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its URL namespace, or 2) the parent collection of the Request-URI exists but cannot accept members.
403（禁止）-这表示两种情况中的至少一种：1）服务器不允许在其URL命名空间中的给定位置创建集合，或2）请求URI的父集合存在但无法接受成员。
405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL.
405（不允许使用方法）-只能在未映射的URL上执行MKCOL。
409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409（冲突）-在创建一个或多个中间集合之前，无法在请求URI处创建集合。服务器不能自动创建这些中间集合。
415 (Unsupported Media Type) - The server does not support the request body type (although bodies are legal on MKCOL requests, since this specification doesn't define any, the server is likely not to support any given body type).
415（不支持的媒体类型）-服务器不支持请求主体类型（尽管主体对MKCOL请求是合法的，因为本规范未定义任何主体类型，服务器可能不支持任何给定的主体类型）。
507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
507（存储不足）-执行此方法后，资源没有足够的空间来记录资源的状态。
This example creates a collection called /webdisc/xfiles/ on the server www.example.com.
本例在服务器www.example.com上创建一个名为/webdisc/xfiles/的集合。
>>Request
>>请求
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.example.com
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.example.com
>>Response
>>回应
HTTP/1.1 201 Created
HTTP/1.1201已创建
The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET, when applied to a collection, may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence, it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection.
GET的语义在应用于集合时是不变的，因为GET被定义为“检索请求URI标识的任何信息（以实体的形式）”[RFC2616]。GET应用于集合时，可能返回“index.html”资源的内容、集合内容的人类可读视图或其他所有内容。因此，对集合进行GET的结果可能与集合的成员身份无关。
Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
类似地，由于HEAD的定义是一个没有响应消息体的GET，因此当应用于集合资源时，HEAD的语义不会被修改。
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的语义在应用于集合时不会被修改。
DELETE is defined in [RFC2616], Section 9.7, to "delete the resource identified by the Request-URI". However, WebDAV changes some DELETE handling requirements.
删除在[RFC2616]第9.7节中定义为“删除由请求URI标识的资源”。但是，WebDAV更改了一些删除处理要求。
A server processing a successful DELETE request:
正在处理成功删除请求的服务器：
MUST destroy locks rooted on the deleted resource
必须销毁已删除资源上的根锁
MUST remove the mapping from the Request-URI to any resource.
必须删除从请求URI到任何资源的映射。
Thus, after a successful DELETE operation (and in the absence of other actions), a subsequent GET/HEAD/PROPFIND request to the target Request-URI MUST return 404 (Not Found).
因此，在成功的删除操作之后（并且在没有其他操作的情况下），对目标请求URI的后续GET/HEAD/PROPFIND请求必须返回404（未找到）。
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity.
集合上的DELETE方法必须像对其使用了“Depth:infinity”头一样。客户机不得在集合上提交带有删除的深度标头，该集合具有除无限外的任何值。
DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URLs are to be deleted.
DELETE指示删除请求URI中指定的集合及其内部成员URL标识的所有资源。
If any resource identified by a member URL cannot be deleted, then all of the member's ancestors MUST NOT be deleted, so as to maintain URL namespace consistency.
如果无法删除由成员URL标识的任何资源，则不得删除该成员的所有祖先，以保持URL命名空间的一致性。
Any headers included with DELETE MUST be applied in processing every resource to be deleted.
在处理每个要删除的资源时，必须应用DELETE中包含的任何标题。
When the DELETE method has completed processing, it MUST result in a consistent URL namespace.
DELETE方法完成处理后，必须生成一致的URL命名空间。
If an error occurs deleting a member resource (a resource other than the resource identified in the Request-URI), then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error code, which should help the client understand which resources caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked.
如果删除成员资源（请求URI中标识的资源以外的资源）时出错，则响应可以是207（多状态）。此处使用多状态来指示哪些内部资源无法删除，包括错误代码，这将有助于客户端了解导致故障的资源。例如，如果内部资源被锁定，则多状态主体可以包括状态为423（锁定）的响应。
The server MAY return a 4xx status response, rather than a 207, if the request failed completely.
如果请求完全失败，服务器可能会返回4xx状态响应，而不是207。
424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi-Status) response for DELETE. They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally, 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
424（失败的依赖项）状态代码不应出现在删除的207（多状态）响应中。它们可以被安全地忽略，因为当客户机收到祖先后代的错误时，客户机将知道无法删除资源的祖先。此外，207（多状态）中不应返回204（无内容）错误。此禁止的原因是204（无内容）是默认的成功代码。
>>Request
>>请求
DELETE /container/ HTTP/1.1
Host: www.example.com
DELETE /container/ HTTP/1.1
Host: www.example.com
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.example.com/container/resource3</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.example.com/container/resource3</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
In this example, the attempt to delete http://www.example.com/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.example.com/container/ also failed. Thus, the client knows that the attempt to delete http://www.example.com/container/ must have also failed since the parent cannot be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
在本例中，尝试删除http://www.example.com/container/resource3 失败，因为它已锁定，并且没有随请求提交锁定令牌。因此，试图删除http://www.example.com/container/ 也失败了。因此，客户端知道尝试删除http://www.example.com/container/ 还必须失败，因为除非父项的子项也已删除，否则无法删除父项。即使未包含深度标头，也假定深度为无穷大，因为该方法位于集合上。
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties.
对现有资源执行的PUT将替换该资源的GET响应实体。在PUT处理期间，可以重新计算资源上定义的属性，但不会受到其他影响。例如，如果服务器识别请求主体的内容类型，它可能能够自动提取可以作为属性公开的信息。
A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
如果PUT将导致在没有适当范围的父集合的情况下创建资源，则PUT必须失败，并出现409（冲突）。
A PUT request allows a client to indicate what media type an entity body has, and whether it should change if overwritten. Thus, a client SHOULD provide a Content-Type for a new resource if any is known. If the client does not provide a Content-Type for a new resource, the server MAY create a resource with no Content-Type assigned, or it MAY attempt to assign a Content-Type.
PUT请求允许客户机指示实体主体的媒体类型，以及在被覆盖时是否应更改。因此，客户机应该为新资源（如果已知）提供内容类型。如果客户端未为新资源提供内容类型，则服务器可能会创建未分配内容类型的资源，或者尝试分配内容类型。
Note that although a recipient ought generally to treat metadata supplied with an HTTP request as authoritative, in practice there's no guarantee that a server will accept client-supplied metadata (e.g., any request header beginning with "Content-"). Many servers do not allow configuring the Content-Type on a per-resource basis in the first place. Thus, clients can't always rely on the ability to directly influence the content type by including a Content-Type request header.
请注意，尽管收件人通常应该将HTTP请求提供的元数据视为权威元数据，但实际上并不保证服务器会接受客户端提供的元数据（例如，任何以“Content-”开头的请求标头）。许多服务器首先不允许基于每个资源配置内容类型。因此，客户端不能总是依赖于通过包含内容类型请求头来直接影响内容类型的能力。
This specification does not define the behavior of the PUT method for existing collections. A PUT request to an existing collection MAY be treated as an error (405 Method Not Allowed).
此规范不定义现有集合的PUT方法的行为。对现有集合的PUT请求可能被视为错误（405方法不允许）。
The MKCOL method is defined to create collections.
定义MKCOL方法以创建集合。
The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource.
COPY方法在目标标头中由URI标识的目标资源中创建由请求URI标识的源资源的副本。目标标头必须存在。复制方法的确切行为取决于源资源的类型。
All WebDAV-compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server.
所有符合WebDAV的资源都必须支持复制方法。但是，对复制方法的支持并不能保证复制资源的能力。例如，不同的程序可以控制同一服务器上的资源。因此，可能无法将资源复制到似乎位于同一服务器上的位置。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
该方法是幂等的，但不安全（见[RFC2616]第9.1节）。不得缓存对此方法的响应。
When the source resource is not a collection, the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible. Since the environment at the destination may be different than at the source due to factors outside the scope of control of the server, such as the absence of resources required for correct operation, it may not be possible to completely duplicate the behavior of the resource at the destination. Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource.
当源资源不是集合时，复制方法的结果是在目标处创建一个新资源，其状态和行为与源资源的状态和行为尽可能匹配。由于服务器控制范围之外的因素（如缺少正确操作所需的资源），目标处的环境可能不同于源处的环境，因此可能无法完全复制目标处资源的行为。对目标资源的后续更改不会修改源资源。对源资源的后续更改不会修改目标资源。
After a successful COPY invocation, all dead properties on the source resource SHOULD be duplicated on the destination resource. Live properties described in this document SHOULD be duplicated as identically behaving live properties at the destination resource, but not necessarily with the same values. Servers SHOULD NOT convert live properties into dead properties on the destination resource, because clients may then draw incorrect conclusions about the state or functionality of a resource. Note that some live properties are defined such that the absence of the property has a specific meaning (e.g., a flag with one meaning if present, and the opposite if absent), and in these cases, a successful COPY might result in the property being reported as "Not Found" in subsequent requests.
复制调用成功后，源资源上的所有死属性都应复制到目标资源上。本文档中描述的活动属性应在目标资源中复制为行为相同的活动属性，但不一定具有相同的值。服务器不应将目标资源上的活动属性转换为非活动属性，因为客户端可能会对资源的状态或功能得出错误的结论。请注意，某些活动属性的定义使得属性的缺失具有特定的含义（例如，如果存在一个标志，如果没有，则标志具有一个含义），在这些情况下，成功复制可能会导致在后续请求中报告属性为“未找到”。
When the destination is an unmapped URL, a COPY operation creates a new resource much like a PUT operation does. Live properties that are related to resource creation (such as DAV:creationdate) should have their values set accordingly.
当目标是未映射的URL时，复制操作将创建一个新资源，就像PUT操作一样。与资源创建相关的活动属性（如DAV:creationdate）应相应地设置其值。
The COPY method on a collection without a Depth header MUST act as if a Depth header with value "infinity" was included. A client may submit a Depth header on a COPY on a collection with a value of "0" or "infinity". Servers MUST support the "0" and "infinity" Depth header behaviors on WebDAV-compliant resources.
对于没有深度标头的集合，COPY方法的作用必须与包含值为“infinity”的深度标头一样。客户端可以提交集合副本上的深度标头，其值为“0”或“无限”。服务器必须支持WebDAV兼容资源上的“0”和“无限”深度头行为。
An infinite-depth COPY instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy. Note that an infinite-depth COPY of /A/ into /A/B/ could lead to infinite recursion if not handled correctly.
无限深度复制指示将请求URI标识的集合资源复制到目标标头中URI标识的位置，并通过集合层次结构的所有级别递归地将其所有内部成员资源复制到与其相关的位置。请注意，如果不正确处理/A/到/A/B/的无限深度副本，可能会导致无限递归。
A COPY of "Depth: 0" only instructs that the collection and its properties, but not resources identified by its internal member URLs, are to be copied.
“Depth:0”的副本仅指示复制集合及其属性，而不指示复制由其内部成员URL标识的资源。
Any headers included with a COPY MUST be applied in processing every resource to be copied with the exception of the Destination header.
在处理每个要复制的资源时，必须应用副本中包含的任何头，但目标头除外。
The Destination header only specifies the destination URI for the Request-URI. When applied to members of the collection identified by the Request-URI, the value of Destination is to be modified to reflect the current location in the hierarchy. So, if the Request-URI is /a/ with Host header value http://example.com/ and the
目标标头仅指定请求URI的目标URI。当应用于由请求URI标识的集合成员时，将修改Destination的值以反映层次结构中的当前位置。因此，如果请求URI为/a/且具有主机头值http://example.com/ 和
Destination is http://example.com/b/, then when http://example.com/a/c/d is processed, it must use a Destination of http://example.com/b/c/d.
目的地是http://example.com/b/，那么什么时候http://example.com/a/c/d 如果已处理，则必须使用的目标http://example.com/b/c/d.
When the COPY method has completed processing, it MUST have created a consistent URL namespace at the destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members that are not descendants of an error-causing collection).
复制方法完成处理后，必须在目标位置创建一致的URL命名空间（有关命名空间一致性的定义，请参见第5.1节）。但是，如果复制内部集合时发生错误，服务器不得复制此集合成员标识的任何资源（即，服务器必须跳过此子树），因为这将创建不一致的命名空间。检测到错误后，复制操作应尽可能多地完成原始复制操作（即，服务器仍应尝试复制其他不是导致错误的集合的后代的子树及其成员）。
So, for example, if an infinite-depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non-collection resource as part of an infinite-depth copy, the server SHOULD try to finish as much of the original copy operation as possible.
因此，例如，如果对包含集合/a/b/和/a/c/的集合/a/执行无限深度复制操作，并且复制/a/b/时出错，则仍应尝试复制/a/c/。类似地，在将非集合资源作为无限深度复制的一部分复制时遇到错误，服务器应尽可能多地完成原始复制操作。
If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI, then the response MUST be a 207 (Multi-Status), and the URL of the resource causing the failure MUST appear with the specific error.
如果使用请求URI中标识的资源以外的资源执行复制方法时发生错误，则响应必须为207（多状态），并且导致失败的资源的URL必须与特定错误一起出现。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a COPY method. These responses can be safely omitted because the client will know that the progeny of a resource could not be copied when the client receives an error for the parent. Additionally, 201 (Created)/204 (No Content) status codes SHOULD NOT be returned as values in 207 (Multi-Status) responses from COPY methods. They, too, can be safely omitted because they are the default success codes.
复制方法的207（多状态）响应中不应返回424（失败的依赖项）状态代码。可以安全地忽略这些响应，因为当客户端收到父级错误时，客户端将知道无法复制资源的子代。此外，201（已创建）/204（无内容）状态代码不应作为复制方法的207（多状态）响应中的值返回。它们也可以安全地省略，因为它们是默认的成功代码。
If a COPY request has an Overwrite header with a value of "F", and a resource exists at the Destination URL, the server MUST fail the request.
如果复制请求具有值为“F”的覆盖标头，并且目标URL上存在资源，则服务器必须使请求失败。
When a server executes a COPY request and overwrites a destination resource, the exact behavior MAY depend on many factors, including WebDAV extension capabilities (see particularly [RFC3253]). For
当服务器执行复制请求并覆盖目标资源时，具体行为可能取决于许多因素，包括WebDAV扩展功能（请特别参阅[RFC3253]）。对于
example, when an ordinary resource is overwritten, the server could delete the target resource before doing the copy, or could do an in-place overwrite to preserve live properties.
例如，当覆盖普通资源时，服务器可以在执行复制之前删除目标资源，也可以执行就地覆盖以保留活动属性。
When a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY. Thus, merging the membership of the source and destination collections together in the destination is not a compliant behavior.
覆盖集合时，复制请求成功后目标集合的成员身份必须与复制前的源集合的成员身份相同。因此，将源集合和目标集合的成员身份合并到目标集合中并不是一种兼容行为。
In general, if clients require the state of the destination URL to be wiped out prior to a COPY (e.g., to force live properties to be reset), then the client could send a DELETE to the destination before the COPY request to ensure this reset.
通常，如果客户端要求在复制之前清除目标URL的状态（例如，强制重置活动属性），则客户端可以在复制请求之前向目标发送删除以确保重置。
In addition to the general status codes possible, the following status codes have specific applicability to COPY:
除了可能的通用状态代码外，以下状态代码还具有复制的特定适用性：
201 (Created) - The source resource was successfully copied. The COPY operation resulted in the creation of a new resource.
201（已创建）-已成功复制源资源。复制操作导致创建新资源。
204 (No Content) - The source resource was successfully copied to a preexisting destination resource.
204（无内容）-源资源已成功复制到先前存在的目标资源。
207 (Multi-Status) - Multiple resources were to be affected by the COPY, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. For example, if a destination resource was locked and could not be overwritten, then the destination resource URL appears with the 423 (Locked) status.
207（多状态）-复制将影响多个资源，但其中一些资源上的错误阻止了操作的发生。特定错误消息以及最合适的源URL和目标URL出现在多状态响应的主体中。例如，如果目标资源已锁定且无法覆盖，则目标资源URL将显示为423（锁定）状态。
403 (Forbidden) - The operation is forbidden. A special case for COPY could be that the source and destination resources are the same resource.
403（禁止）-禁止操作。复制的一种特殊情况可能是源资源和目标资源是相同的资源。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409（冲突）-在创建一个或多个中间集合之前，无法在目标上创建资源。服务器不能自动创建这些中间集合。
412 (Precondition Failed) - A precondition header check failed, e.g., the Overwrite header is "F" and the destination URL is already mapped to a resource.
412（前置条件失败）-前置条件标头检查失败，例如，覆盖标头为“F”，且目标URL已映射到资源。
423 (Locked) - The destination resource, or resource within the destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423（已锁定）—目标资源或目标集合中的资源已锁定。此响应应包含“lock token submitted”前提条件元素。
502 (Bad Gateway) - This may occur when the destination is on another server, repository, or URL namespace. Either the source namespace does not support copying to the destination namespace, or the destination namespace refuses to accept the resource. The client may wish to try GET/PUT and PROPFIND/PROPPATCH instead.
502（坏网关）-当目标位于另一台服务器、存储库或URL命名空间上时，可能会发生这种情况。源命名空间不支持复制到目标命名空间，或者目标命名空间拒绝接受资源。客户端可能希望尝试GET/PUT和PROPFIND/PROPPATCH。
507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
507（存储不足）-执行此方法后，目标资源没有足够的空间来记录资源的状态。
This example shows resource http://www.example.com/~fielding/index.html being copied to the location http://www.example.com/users/f/fielding/index.html. The 204 (No Content) status code indicates that the existing resource at the destination was overwritten.
此示例显示了资源http://www.example.com/~fielding/index.html正在复制到该位置http://www.example.com/users/f/fielding/index.html. 204（无内容）状态代码表示目标上的现有资源已被覆盖。
>>Request
>>请求
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
>>Response
>>回应
HTTP/1.1 204 No Content
HTTP/1.1 204无内容
The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 (Precondition Failed) is returned because the destination URL is already mapped to a resource.
以下示例显示了正在执行的相同复制操作，但覆盖标头设置为“F”。由于目标URL已映射到资源，因此返回412响应（前提条件失败）。
>>Request
>>请求
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
Overwrite: F
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
Overwrite: F
>>Response
>>回应
HTTP/1.1 412 Precondition Failed
HTTP/1.1 412前置条件失败
>>Request
>>请求
COPY /container/ HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/othercontainer/
Depth: infinity
COPY /container/ HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/othercontainer/
Depth: infinity
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.example.com/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.example.com/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example, most of the resources, along with the collection, were copied successfully. However, the collection R2 failed because the destination R2 is locked. Because there was an error copying R2, none of R2's members were copied. However, no errors were listed for those members due to the error minimization rules.
深度标头是不必要的，因为集合上复制的默认行为是充当“Depth:infinity”标头已提交的角色。在本例中，大多数资源以及集合都已成功复制。但是，集合R2失败，因为目标R2已锁定。由于复制R2时出错，因此未复制R2的任何成员。但是，由于错误最小化规则，这些成员未列出任何错误。
The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed in a single operation. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URLs, other than the Request-URI that identifies the source resource, to point to the new destination resource.
非集合资源上的移动操作在逻辑上等同于复制（copy），然后是一致性维护处理，然后是源的删除，其中所有三个操作都在一个操作中执行。一致性维护步骤允许服务器执行由移动引起的更新，例如更新除标识源资源的请求URI之外的所有URL，以指向新的目标资源。
The Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV-compliant resources MUST support the MOVE method.
The Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV-compliant resources MUST support the MOVE method.translate error, please retry
Support for the MOVE method does not guarantee the ability to move a resource to a particular destination. For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server.
对MOVE方法的支持不能保证将资源移动到特定目标的能力。例如，不同的程序实际上可能控制同一服务器上的不同资源集。因此，可能无法在似乎属于同一服务器的命名空间内移动资源。
If a resource exists at the destination, the destination resource will be deleted as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
如果目标上存在资源，则根据覆盖标头的限制，作为移动操作的副作用，目标资源将被删除。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
该方法是幂等的，但不安全（见[RFC2616]第9.1节）。不得缓存对此方法的响应。
Live properties described in this document SHOULD be moved along with the resource, such that the resource has identically behaving live properties at the destination resource, but not necessarily with the same values. Note that some live properties are defined such that the absence of the property has a specific meaning (e.g., a flag with one meaning if present, and the opposite if absent), and in these cases, a successful MOVE might result in the property being reported as "Not Found" in subsequent requests. If the live properties will not work the same way at the destination, the server MAY fail the request.
本文档中描述的活动属性应随资源一起移动，以便资源在目标资源中具有行为相同的活动属性，但不一定具有相同的值。请注意，某些活动属性的定义使得属性的缺失具有特定的含义（例如，如果存在一个标志，如果没有，则标志具有一个含义），在这些情况下，成功移动可能会导致在后续请求中将属性报告为“未找到”。如果live属性在目标上的工作方式不同，则服务器可能会使请求失败。
MOVE is frequently used by clients to rename a file without changing its parent collection, so it's not appropriate to reset all live properties that are set at resource creation. For example, the DAV: creationdate property value SHOULD remain the same after a MOVE.
客户端经常使用MOVE重命名文件而不更改其父集合，因此不适合重置在资源创建时设置的所有活动属性。例如，DAV:creationdate属性值在移动后应保持不变。
Dead properties MUST be moved along with the resource.
死属性必须随资源一起移动。
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the address specified in the Destination header, and all resources identified by its internal member URLs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy.
带有“Depth:infinity”的移动指示将由请求URI标识的集合移动到目标标头中指定的地址，并通过集合层次结构的所有级别递归地将由其内部成员URL标识的所有资源移动到与其相关的位置。
The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity".
集合上的MOVE方法必须像对其使用了“Depth:infinity”头一样。客户机在移动集合时不得提交除“无限”以外的任何值的深度标头。
Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header. The behavior of the Destination header is the same as given for COPY on collections.
移动中包含的任何头都必须应用于处理每个要移动的资源，但目标头除外。目标标头的行为与集合上复制的行为相同。
When the MOVE method has completed processing, it MUST have created a consistent URL namespace at both the source and destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members that are not descendants of an error-causing collection). So, for example, if an infinite-depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite-depth move, the server SHOULD try to finish as much of the original move operation as possible.
当MOVE方法完成处理后，它必须在源和目标上都创建了一致的URL命名空间（有关命名空间一致性的定义，请参见第5.1节）。但是，如果在移动内部集合时发生错误，服务器不得移动由失败集合的成员标识的任何资源（即，服务器必须跳过导致错误的子树），因为这将创建不一致的命名空间。在这种情况下，检测到错误后，移动操作应尽可能多地完成原始移动（即，服务器仍应尝试移动其他子树及其成员标识的资源，这些子树和资源不是导致错误的集合的后代）。因此，例如，如果对包含集合/a/b/和/a/c/的集合/a/执行无限深度移动，并且移动/a/b/时出错，则仍应尝试移动/a/c/。类似地，在作为无限深度移动的一部分移动非集合资源时遇到错误后，服务器应尽可能多地完成原始移动操作。
If an error occurs with a resource other than the resource identified in the Request-URI, then the response MUST be a 207 (Multi-Status), and the errored resource's URL MUST appear with the specific error.
如果请求URI中标识的资源以外的资源发生错误，则响应必须为207（多状态），并且出错资源的URL必须与特定错误一起出现。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally, 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
移动方法的207（多状态）响应中不应返回424（失败的依赖项）状态代码。可以安全地忽略这些错误，因为当客户端收到父级错误时，客户端将知道资源的子代无法移动。此外，201（已创建）/204（无内容）响应不应作为来自移动的207（多状态）响应中的值返回。可以安全地忽略这些响应，因为它们是默认的成功代码。
If a resource exists at the destination and the Overwrite header is "T", then prior to performing the move, the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F", then the operation will fail.
如果目标上存在资源且覆盖标头为“T”，则在执行移动之前，服务器必须在目标资源上执行“深度：无穷大”的删除。如果覆盖标头设置为“F”，则操作将失败。
In addition to the general status codes possible, the following status codes have specific applicability to MOVE:
除了可能的通用状态代码外，以下状态代码还具有移动的特定适用性：
201 (Created) - The source resource was successfully moved, and a new URL mapping was created at the destination.
201（已创建）-已成功移动源资源，并在目标位置创建了新的URL映射。
204 (No Content) - The source resource was successfully moved to a URL that was already mapped.
204（无内容）-源资源已成功移动到已映射的URL。
207 (Multi-Status) - Multiple resources were to be affected by the MOVE, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. For example, if a source resource was locked and could not be moved, then the source resource URL appears with the 423 (Locked) status.
207（多状态）-移动将影响多个资源，但其中一些资源上的错误阻止了操作的发生。特定错误消息以及最合适的源URL和目标URL出现在多状态响应的主体中。例如，如果源资源已锁定且无法移动，则源资源URL将显示为423（锁定）状态。
403 (Forbidden) - Among many possible reasons for forbidding a MOVE operation, this status code is recommended for use when the source and destination resources are the same.
403（禁止）-在禁止移动操作的许多可能原因中，建议在源和目标资源相同时使用此状态代码。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. Or, the server was unable to preserve the behavior of the live properties and still move the resource to the destination (see 'preserved-live-properties' postcondition).
409（冲突）-在创建一个或多个中间集合之前，无法在目标上创建资源。服务器不能自动创建这些中间集合。或者，服务器无法保留活动属性的行为，并且仍然将资源移动到目标（请参阅“保留的活动属性”后置条件）。
412 (Precondition Failed) - A condition header failed. Specific to MOVE, this could mean that the Overwrite header is "F" and the destination URL is already mapped to a resource.
412（前提条件失败）-条件标头失败。具体到移动，这可能意味着覆盖标头为“F”，并且目标URL已映射到资源。
423 (Locked) - The source or the destination resource, the source or destination resource parent, or some resource within the source or destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423（已锁定）—源或目标资源、源或目标资源父级或源或目标集合中的某些资源已锁定。此响应应包含“lock token submitted”前提条件元素。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource. This could also occur when the destination is on another sub-section of the same server namespace.
502（坏网关）-当目标服务器位于另一台服务器上且目标服务器拒绝接受资源时，可能会发生这种情况。当目标位于同一服务器命名空间的另一个子节上时，也可能发生这种情况。
This example shows resource http://www.example.com/~fielding/index.html being moved to the location http://www.example.com/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination URL was already mapped to a resource. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
此示例显示了资源http://www.example.com/~fielding/index.html正在移动到该位置http://www.example.com/users/f/fielding/index.html. 如果目标URL已映射到资源，则目标资源的内容将被覆盖。在这种情况下，由于目标资源中没有任何内容，因此响应代码为201（已创建）。
>>Request
>>请求
MOVE /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example/users/f/fielding/index.html
MOVE /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example/users/f/fielding/index.html
>>Response
>>回应
HTTP/1.1 201 Created
Location: http://www.example.com/users/f/fielding/index.html
HTTP/1.1 201 Created
Location: http://www.example.com/users/f/fielding/index.html
>>Request
>>请求
MOVE /container/ HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/othercontainer/
Overwrite: F
If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
MOVE /container/ HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/othercontainer/
Overwrite: F
If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d='DAV:'>
<d:response>
<d:href>http://www.example.com/othercontainer/C2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d='DAV:'>
<d:response>
<d:href>http://www.example.com/othercontainer/C2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
In this example, the client has submitted a number of lock tokens with the request. A lock token will need to be submitted for every resource, both source and destination, anywhere in the scope of the method, that is locked. In this case, the proper lock token was not submitted for the destination http://www.example.com/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error moving /container/C2/, none of /container/C2's members were moved. However, no errors were listed for those members due to the error minimization rules. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
在本例中，客户机已随请求提交了大量锁令牌。在方法范围内的任何位置，需要为每个被锁定的资源（包括源和目标）提交一个锁令牌。在这种情况下，没有为目标提交正确的锁令牌http://www.example.com/othercontainer/C2/. 这意味着无法移动资源/容器/C2/。由于移动/container/C2/时出错，因此未移动/container/C2的任何成员。但是，由于错误最小化规则，这些成员未列出任何错误。用户代理身份验证以前是通过HTTP协议范围之外的机制在底层传输层中进行的。
The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested.
以下各节介绍LOCK方法，该方法用于取出任何访问类型的锁并刷新现有锁。关于LOCK方法的这些部分只描述那些特定于LOCK方法并且与所请求的锁的访问类型无关的语义。
Any resource that supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein.
任何支持锁方法的资源至少必须支持本文定义的XML请求和响应格式。
This method is neither idempotent nor safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
这种方法既不是幂等的，也不是安全的（见[RFC2616]第9.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. LOCK method requests to create a new lock MUST have an XML request body. The server MUST preserve the information provided by the client in the 'owner' element in the LOCK request. The LOCK request MAY have a Timeout header.
对现有资源的锁请求将在请求URI标识的资源上创建锁，前提是该资源尚未使用冲突锁锁定。请求URI中标识的资源将成为锁的根。创建新锁的锁方法请求必须具有XML请求主体。服务器必须在锁请求的“所有者”元素中保留客户端提供的信息。锁定请求可能有一个超时标头。
When a new lock is created, the LOCK response:
创建新锁时，锁响应：
o MUST contain a body with the value of the DAV:lockdiscovery property in a prop XML element. This MUST contain the full information about the lock just granted, while information about other (shared) locks is OPTIONAL.
o 必须在prop XML元素中包含一个具有DAV:lockdiscovery属性值的主体。这必须包含关于刚刚授予的锁的完整信息，而关于其他（共享）锁的信息是可选的。
o MUST include the Lock-Token response header with the token associated with the new lock.
o 必须包括带有与新锁关联的令牌的锁令牌响应标头。
A lock is refreshed by sending a LOCK request to the URL of a resource within the scope of the lock. This request MUST NOT have a body and it MUST specify which lock to refresh by using the 'If' header with a single lock token (only one lock may be refreshed at a time). The request MAY contain a Timeout header, which a server MAY accept to change the duration remaining on the lock to the new value. A server MUST ignore the Depth header on a LOCK refresh.
通过向锁范围内的资源的URL发送锁请求来刷新锁。此请求不能有正文，并且必须通过使用带有单个锁令牌的“If”头指定要刷新的锁（一次只能刷新一个锁）。该请求可能包含超时标头，服务器可以接受该标头以将锁上剩余的持续时间更改为新值。服务器必须在锁刷新时忽略深度标头。
If the resource has other (shared) locks, those locks are unaffected by a lock refresh. Additionally, those locks do not prevent the named lock from being refreshed.
如果资源具有其他（共享）锁，则这些锁不受锁刷新的影响。此外，这些锁不会阻止命名锁被刷新。
The Lock-Token header is not returned in the response for a successful refresh LOCK request, but the LOCK response body MUST contain the new value for the DAV:lockdiscovery property.
成功刷新锁定请求的响应中不会返回锁定令牌头，但锁定响应正文必须包含DAV:lockdiscovery属性的新值。
The Depth header may be used with the LOCK method. Values other than 0 or infinity MUST NOT be used with the Depth header on a LOCK method. All resources that support the LOCK method MUST support the Depth header.
深度标题可与锁定方法一起使用。锁定方法上的深度标头不得使用0或无穷大以外的值。所有支持LOCK方法的资源都必须支持Depth头。
A Depth header of value 0 means to just lock the resource specified by the Request-URI.
值为0的深度头意味着只锁定请求URI指定的资源。
If the Depth header is set to infinity, then the resource specified in the Request-URI along with all its members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token. Similarly, if an UNLOCK is successfully executed on this token, all associated resources are unlocked. Hence, partial success is not an option for LOCK or UNLOCK. Either the entire hierarchy is locked or no resources are locked.
如果深度头被设置为无穷大，那么请求URI中指定的资源及其所有成员（一直到层次结构）都将被锁定。成功的结果必须返回单个锁令牌。类似地，如果在此令牌上成功执行解锁，则将解锁所有相关资源。因此，部分成功不是锁定或解锁的选项。要么锁定整个层次结构，要么不锁定任何资源。
If the lock cannot be granted to all resources, the server MUST return a Multi-Status response with a 'response' element for at least one resource that prevented the lock from being granted, along with a suitable status code for that failure (e.g., 403 (Forbidden) or 423 (Locked)). Additionally, if the resource causing the failure was not the resource requested, then the server SHOULD include a 'response' element for the Request-URI as well, with a 'status' element containing 424 Failed Dependency.
如果无法将锁授予所有资源，则服务器必须返回一个多状态响应，其中至少有一个资源的“响应”元素阻止授予锁，以及该故障的适当状态代码（例如403（禁止）或423（锁定））。此外，如果导致失败的资源不是请求的资源，那么服务器也应该为请求URI包含一个“response”元素，其中一个“status”元素包含424 Failed Dependency。
If no Depth header is submitted on a LOCK request, then the request MUST act as if a "Depth:infinity" had been submitted.
如果锁请求中没有提交深度头，那么请求必须像提交了“Depth:infinity”一样。
A successful LOCK method MUST result in the creation of an empty resource that is locked (and that is not a collection) when a resource did not previously exist at that URL. Later on, the lock may go away but the empty resource remains. Empty resources MUST then appear in PROPFIND responses including that URL in the response scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length
成功的锁定方法必须导致创建一个空资源，该资源在该URL上以前不存在时被锁定（并且不是集合）。稍后，锁可能会消失，但空资源仍然存在。空资源必须出现在PROPFIND响应中，包括响应范围中的URL。服务器必须成功响应对空资源的GET请求，要么使用204无内容响应，要么使用200 OK，内容长度头指示零长度
The table below describes the behavior that occurs when a lock request is made on a resource.
下表描述了对资源发出锁定请求时发生的行为。
+--------------------------+----------------+-------------------+
| Current State | Shared Lock OK | Exclusive Lock OK |
+--------------------------+----------------+-------------------+
| None | True | True |
| Shared Lock | True | False |
| Exclusive Lock | False | False* |
+--------------------------+----------------+-------------------+
+--------------------------+----------------+-------------------+
| Current State | Shared Lock OK | Exclusive Lock OK |
+--------------------------+----------------+-------------------+
| None | True | True |
| Shared Lock | True | False |
| Exclusive Lock | False | False* |
+--------------------------+----------------+-------------------+
Legend: True = lock may be granted. False = lock MUST NOT be granted. *=It is illegal for a principal to request the same lock twice.
图例：True=可以授予锁定。False=不能授予锁定*=主体请求相同的锁两次是非法的。
The current lock state of a resource is given in the leftmost column, and lock requests are listed in the first row. The intersection of a row and column gives the result of a lock request. For example, if a shared lock is held on a resource, and an exclusive lock is requested, the table entry is "false", indicating that the lock must not be granted.
资源的当前锁定状态在最左边的列中给出，锁定请求列在第一行中。行和列的交集给出锁定请求的结果。例如，如果资源上持有一个共享锁，并且请求了一个独占锁，则表项为“false”，表示不能授予该锁。
In addition to the general status codes possible, the following status codes have specific applicability to LOCK:
除了可能的一般状态代码外，以下状态代码还具有特定的锁定适用性：
200 (OK) - The LOCK request succeeded and the value of the DAV: lockdiscovery property is included in the response body.
200（确定）-锁请求成功，响应正文中包含DAV:lockdiscovery属性的值。
201 (Created) - The LOCK request was to an unmapped URL, the request succeeded and resulted in the creation of a new resource, and the value of the DAV:lockdiscovery property is included in the response body.
201（已创建）-锁定请求被映射到未映射的URL，请求成功并导致创建新资源，并且DAV:lockdiscovery属性的值包含在响应正文中。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409（冲突）-在创建一个或多个中间集合之前，无法在目标上创建资源。服务器不能自动创建这些中间集合。
423 (Locked), potentially with 'no-conflicting-lock' precondition code - There is already a lock on the resource that is not compatible with the requested lock (see lock compatibility table above).
423（已锁定），可能带有“无冲突锁”前提条件代码-资源上已存在与请求的锁不兼容的锁（请参阅上面的锁兼容性表）。
412 (Precondition Failed), with 'lock-token-matches-request-uri' precondition code - The LOCK request was made with an If header, indicating that the client wishes to refresh the given lock. However, the Request-URI did not fall within the scope of the lock identified by the token. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
412（前提条件失败），带有“lock token matches request uri”前提条件代码-锁请求是使用If头发出的，表示客户端希望刷新给定的锁。但是，请求URI不在令牌标识的锁的范围内。锁的作用域可能不包括请求URI，或者锁可能已消失，或者令牌可能无效。
>>Request
>>请求
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>回应
HTTP/1.1 200 OK
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200 OK
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This example shows the successful creation of an exclusive write lock on resource http://example.com/workspace/webdav/proposal.doc. The resource http://example.org/~ejw/contact.html contains contact information for the creator of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header.
此示例显示在资源上成功创建独占写锁http://example.com/workspace/webdav/proposal.doc. 资源http://example.org/~ejw/contact.html包含锁创建者的联系信息。服务器在此资源上具有基于活动的超时策略，这会导致锁在1周（604800秒）后自动移除。请注意，尚未在授权请求标头中计算nonce、response和不透明字段。
>>Request
>>请求
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
>>回应
HTTP/1.1 200 OK
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200 OK
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This request would refresh the lock, attempting to reset the timeout to the new value specified in the timeout header. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
此请求将刷新锁，尝试将超时重置为超时标头中指定的新值。请注意，客户端请求无限期超时，但服务器选择忽略该请求。在本例中，未在授权请求标头中计算nonce、response和不透明字段。
>>Request
>>请求
LOCK /webdav/ HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 Depth: infinity Content-Type: application/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...",
LOCK/webdav/HTTP/1.1主机：example.com超时：无限，秒-4100000000深度：无限内容类型：application/xml；charset=“utf-8”内容长度：xxxx授权：摘要用户名=“ejw”，领域=”ejw@example.com“，nonce=“…”，
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D="DAV:">
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D="DAV:">
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://example.com/webdav/secret</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
<D:response>
<D:href>http://example.com/webdav/</D:href>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:response>
</D:multistatus>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://example.com/webdav/secret</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
<D:response>
<D:href>http://example.com/webdav/</D:href>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:response>
</D:multistatus>
This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite-length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock -- in this case, a Web page URL.
此示例显示了对集合及其所有子集合的独占写入锁的请求。在这个请求中，客户机指定它需要无限长的锁（如果可用），否则需要41亿秒的超时（如果可用）。请求实体主体包含解除锁的主体的联系信息——在本例中是一个网页URL。
The error is a 403 (Forbidden) response on the resource http://example.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the a 'response' element for the Request-URI itself has been included as required.
错误是资源上的403（禁止）响应http://example.com/webdav/secret. 由于无法锁定此资源，因此未锁定任何资源。还请注意，请求URI本身的“response”元素已根据需要包括在内。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
在本例中，未在授权请求标头中计算nonce、response和不透明字段。
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock.
UNLOCK方法移除由锁令牌请求标头中的锁令牌标识的锁。请求URI必须标识锁范围内的资源。
Note that use of the Lock-Token header to provide the lock token is not consistent with other state-changing methods, which all require an If header with the lock token. Thus, the If header is not needed to provide the lock token. Naturally, when the If header is present, it has its normal meaning as a conditional header.
请注意，使用锁令牌头来提供锁令牌与其他状态更改方法不一致，这些方法都需要带有锁令牌的If头。因此，不需要If报头来提供锁令牌。当然，当If头出现时，它作为一个条件头有其正常的含义。
For a successful response to this method, the server MUST delete the lock entirely.
要成功响应此方法，服务器必须完全删除锁。
If all resources that have been locked under the submitted lock token cannot be unlocked, then the UNLOCK request MUST fail.
如果无法解锁已在提交的锁定令牌下锁定的所有资源，则解锁请求必须失败。
A successful response to an UNLOCK method does not mean that the resource is necessarily unlocked. It means that the specific lock corresponding to the specified token no longer exists.
对解锁方法的成功响应并不意味着资源必须解锁。这意味着与指定令牌对应的特定锁不再存在。
Any DAV-compliant resource that supports the LOCK method MUST support the UNLOCK method.
任何支持锁定方法的符合DAV的资源都必须支持解锁方法。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
该方法是幂等的，但不安全（见[RFC2616]第9.1节）。不得缓存对此方法的响应。
In addition to the general status codes possible, the following status codes have specific applicability to UNLOCK:
除了可能的一般状态代码外，以下状态代码还具有解锁的特定适用性：
204 (No Content) - Normal success response (rather than 200 OK, since 200 OK would imply a response body, and an UNLOCK success response does not normally contain a body).
204（无内容）-正常成功响应（而不是200 OK，因为200 OK意味着响应主体，解锁成功响应通常不包含主体）。
400 (Bad Request) - No lock token was provided.
400（错误请求）-未提供锁令牌。
403 (Forbidden) - The currently authenticated principal does not have permission to remove the lock.
403（禁止）-当前经过身份验证的主体没有移除锁的权限。
409 (Conflict), with 'lock-token-matches-request-uri' precondition - The resource was not locked, or the request was made to a Request-URI that was not within the scope of the lock.
409（冲突），以“lock token matches request uri”为先决条件-资源未锁定，或者请求的请求uri不在锁的作用域内。
>>Request
>>请求
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: example.com
Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw"
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: example.com
Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw"
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
>>回应
HTTP/1.1 204 No Content
HTTP/1.1 204无内容
In this example, the lock identified by the lock token "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://example.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock.
在此示例中，由锁令牌“urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7”标识的锁已成功从资源中删除http://example.com/workspace/webdav/info.doc. 如果此锁包含多个资源，则会从锁中包含的所有资源中删除该锁。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
在本例中，未在授权请求标头中计算nonce、response和不透明字段。
All DAV headers follow the same basic formatting rules as HTTP headers. This includes rules like line continuation and how to combine (or separate) multiple instances of the same header using commas.
所有DAV头都遵循与HTTP头相同的基本格式规则。这包括诸如行连续性以及如何使用逗号组合（或分离）同一标头的多个实例等规则。
WebDAV adds two new conditional headers to the set defined in HTTP: the If and Overwrite headers.
WebDAV向HTTP中定义的集合添加了两个新的条件头：If和Overwrite头。
DAV = "DAV" ":" #( compliance-class )
compliance-class = ( "1" | "2" | "3" | extend )
extend = Coded-URL | token
; token is defined in RFC 2616, Section 2.2
Coded-URL = "<" absolute-URI ">"
; No linear whitespace (LWS) allowed in Coded-URL
; absolute-URI defined in RFC 3986, Section 4.3
DAV = "DAV" ":" #( compliance-class )
compliance-class = ( "1" | "2" | "3" | extend )
extend = Coded-URL | token
; token is defined in RFC 2616, Section 2.2
Coded-URL = "<" absolute-URI ">"
; No linear whitespace (LWS) allowed in Coded-URL
; absolute-URI defined in RFC 3986, Section 4.3
This general-header appearing in the response indicates that the resource supports the DAV schema and protocol as specified. All DAV-compliant resources MUST return the DAV header with compliance-class "1" on all OPTIONS responses. In cases where WebDAV is only supported in part of the server namespace, an OPTIONS request to non-WebDAV resources (including "/") SHOULD NOT advertise WebDAV support.
响应中出现的这个通用头表示资源支持指定的DAV模式和协议。所有符合DAV的资源必须在所有选项响应上返回符合类为“1”的DAV标头。如果WebDAV仅在部分服务器命名空间中受支持，则对非WebDAV资源（包括“/”）的选项请求不应公布WebDAV支持。
The value is a comma-separated list of all compliance class identifiers that the resource supports. Class identifiers may be Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can appear in any order. Identifiers that are standardized through the IETF RFC process are tokens, but other identifiers SHOULD be Coded-URLs to encourage uniqueness.
该值是资源支持的所有符合性类标识符的逗号分隔列表。类标识符可以是编码的URL或标记（如[RFC2616]所定义）。标识符可以以任何顺序出现。通过IETF RFC过程标准化的标识符是令牌，但其他标识符应编码为URL以鼓励唯一性。
A resource must show class 1 compliance if it shows class 2 or 3 compliance. In general, support for one compliance class does not entail support for any other, and in particular, support for compliance class 3 does not require support for compliance class 2. Please refer to Section 18 for more details on compliance classes defined in this specification.
如果资源符合类别2或3，则它必须符合类别1。一般来说，对一个合规类的支持并不意味着对任何其他合规类的支持，尤其是对合规类3的支持不需要对合规类2的支持。有关本规范中定义的合规性等级的更多详细信息，请参阅第18节。
Note that many WebDAV servers do not advertise WebDAV support in response to "OPTIONS *".
请注意，许多WebDAV服务器不会在响应“选项*”时公布WebDAV支持。
As a request header, this header allows the client to advertise compliance with named features when the server needs that information. Clients SHOULD NOT send this header unless a standards track specification requires it. Any extension that makes use of this as a request header will need to carefully consider caching implications.
作为一个请求头，当服务器需要该信息时，该头允许客户机公布对命名功能的遵从性。除非标准跟踪规范要求，否则客户端不应发送此标头。任何使用此作为请求头的扩展都需要仔细考虑缓存的含义。
Depth = "Depth" ":" ("0" | "1" | "infinity")
Depth = "Depth" ":" ("0" | "1" | "infinity")
The Depth request header is used with methods executed on resources that could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its internal members only ("Depth: 1"), or the resource and all its members ("Depth: infinity").
深度请求头与在可能具有内部成员的资源上执行的方法一起使用，以指示该方法是仅应用于资源（“深度：0”），还是仅应用于资源及其内部成员（“深度：1”），或者应用于资源及其所有成员（“深度：无限”）。
The Depth header is only supported if a method's definition explicitly provides for such support.
只有在方法定义明确提供这种支持时，才支持深度标头。
The following rules are the default behavior for any method that supports the Depth header. A method may override these defaults by defining different behavior in its definition.
以下规则是支持深度标头的任何方法的默认行为。方法可以通过在其定义中定义不同的行为来覆盖这些默认值。
Methods that support the Depth header may choose not to support all of the header's values and may define, on a case-by-case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity", and if a Depth header is not present, it will act as if a "Depth: infinity" header had been applied.
支持深度标头的方法可以选择不支持所有标头的值，并且可以在不存在深度标头的情况下根据具体情况定义方法的行为。例如，MOVE方法只支持“Depth:infinity”，如果不存在Depth标头，它将充当应用了“Depth:infinity”标头的角色。
Clients MUST NOT rely upon methods executing on members of their hierarchies in any particular order or on the execution being atomic unless the particular method explicitly provides such guarantees.
除非特定方法明确提供此类保证，否则客户端不得依赖以任何特定顺序在其层次结构成员上执行的方法，或依赖原子执行的方法。
Upon execution, a method with a Depth header will perform as much of its assigned task as possible and then return a response specifying what it was able to accomplish and what it failed to do.
在执行时，具有深度头的方法将尽可能多地执行其分配的任务，然后返回一个响应，指定它能够完成的任务和失败的任务。
So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not.
因此，例如，复制层次结构的尝试可能会导致部分成员被复制，而部分成员未被复制。
By default, the Depth header does not interact with other headers. That is, each header on a request with a Depth header MUST be applied only to the Request-URI if it applies to any resource, unless specific Depth behavior is defined for that header.
默认情况下，深度标头不与其他标头交互。也就是说，具有深度标头的请求上的每个标头必须仅应用于请求URI（如果它应用于任何资源），除非为该标头定义了特定的深度行为。
If a source or destination resource within the scope of the Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header.
如果深度标头范围内的源或目标资源被锁定，从而阻止方法的成功执行，则该资源的锁定令牌必须与If请求标头中的请求一起提交。
The Depth header only specifies the behavior of the method with regards to internal members. If a resource does not have internal members, then the Depth header MUST be ignored.
深度标题仅指定与内部成员相关的方法行为。如果资源没有内部成员，则必须忽略深度标头。
The Destination request header specifies the URI that identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters.
目标请求标头指定URI，该URI用于标识复制和移动等方法的目标资源，这些方法将两个URI作为参数。
Destination = "Destination" ":" Simple-ref
Destination=“Destination”“：”简单引用
If the Destination value is an absolute-URI (Section 4.3 of [RFC3986]), it may name a different server (or different port or scheme). If the source server cannot attempt a copy to the remote server, it MUST fail the request. Note that copying and moving resources to remote servers is not fully defined in this specification (e.g., specific error conditions).
如果目标值是一个绝对URI（RFC3986的第4.3节），它可以命名不同的服务器（或不同的端口或方案）。如果源服务器无法尝试复制到远程服务器，则必须使请求失败。请注意，本规范未完全定义将资源复制和移动到远程服务器（例如，特定错误条件）。
If the Destination value is too long or otherwise unacceptable, the server SHOULD return 400 (Bad Request), ideally with helpful information in an error body.
如果目标值太长或不可接受，服务器应返回400（错误请求），最好在错误正文中包含有用的信息。
The If request header is intended to have similar functionality to the If-Match header defined in Section 14.24 of [RFC2616]. However, the If header handles any state token as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification.
If请求标头的功能与[RFC2616]第14.24节中定义的If匹配标头类似。但是，If头处理任何状态令牌以及etag。状态令牌的一个典型示例是锁令牌，锁令牌是本规范中定义的唯一状态令牌。
The If header has two distinct purposes:
If标头有两个不同的用途：
o The first purpose is to make a request conditional by supplying a series of state lists with conditions that match tokens and ETags to a specific resource. If this header is evaluated and all state lists fail, then the request MUST fail with a 412 (Precondition Failed) status. On the other hand, the request can succeed only if one of the described state lists succeeds. The success criteria for state lists and matching functions are defined in Sections 10.4.3 and 10.4.4.
o 第一个目的是通过提供一系列状态列表使请求有条件，这些状态列表具有将令牌和ETag与特定资源匹配的条件。如果对该报头求值，并且所有状态列表都失败，则请求必须以412（前置条件失败）状态失败。另一方面，只有当所描述的状态列表之一成功时，请求才能成功。第10.4.3节和第10.4.4节定义了状态列表和匹配功能的成功标准。
o Additionally, the mere fact that a state token appears in an If header means that it has been "submitted" with the request. In general, this is used to indicate that the client has knowledge of that state token. The semantics for submitting a state token depend on its type (for lock tokens, please refer to Section 6).
o 此外，仅在If头中出现一个状态令牌这一事实就意味着它已随请求“提交”。通常，这用于指示客户机知道该状态令牌。提交状态令牌的语义取决于其类型（有关锁令牌，请参阅第6节）。
Note that these two purposes need to be treated distinctly: a state token counts as being submitted independently of whether the server actually has evaluated the state list it appears in, and also independently of whether or not the condition it expressed was found to be true.
请注意，这两个目的需要明确处理：状态令牌被认为是提交的，与服务器是否实际评估了它出现在其中的状态列表无关，也与它表示的条件是否为真无关。
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list )
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list )
No-tag-list = List Tagged-list = Resource-Tag 1*List
无标记列表=列表标记列表=资源标记1*列表
List = "(" 1*Condition ")"
Condition = ["Not"] (State-token | "[" entity-tag "]")
; entity-tag: see Section 3.11 of [RFC2616]
; No LWS allowed between "[", entity-tag and "]"
List = "(" 1*Condition ")"
Condition = ["Not"] (State-token | "[" entity-tag "]")
; entity-tag: see Section 3.11 of [RFC2616]
; No LWS allowed between "[", entity-tag and "]"
State-token = Coded-URL
State-token = Coded-URL
Resource-Tag = "<" Simple-ref ">"
; Simple-ref: see Section 8.3
; No LWS allowed in Resource-Tag
Resource-Tag = "<" Simple-ref ">"
; Simple-ref: see Section 8.3
; No LWS allowed in Resource-Tag
The syntax distinguishes between untagged lists ("No-tag-list") and tagged lists ("Tagged-list"). Untagged lists apply to the resource identified by the Request-URI, while tagged lists apply to the resource identified by the preceding Resource-Tag.
该语法区分未标记列表（“无标记列表”）和标记列表（“标记列表”）。未标记的列表应用于由请求URI标识的资源，而标记的列表应用于由前面的资源标记标识的资源。
A Resource-Tag applies to all subsequent Lists, up to the next Resource-Tag.
资源标记应用于所有后续列表，直到下一个资源标记。
Note that the two list types cannot be mixed within an If header. This is not a functional restriction because the No-tag-list syntax is just a shorthand notation for a Tagged-list production with a Resource-Tag referring to the Request-URI.
请注意，这两种列表类型不能在If标头中混合使用。这不是一个功能限制，因为No-tag-list语法只是带有引用请求URI的资源标记的标记列表产品的简写符号。
Each List consists of one or more Conditions. Each Condition is defined in terms of an entity-tag or state-token, potentially negated by the prefix "Not".
每个列表由一个或多个条件组成。每个条件都是根据实体标记或状态标记定义的，可能会被前缀“Not”否定。
Note that the If header syntax does not allow multiple instances of If headers in a single request. However, the HTTP header syntax allows extending single header values across multiple lines, by inserting a line break followed by whitespace (see [RFC2616], Section 4.2).
请注意，If头语法不允许在单个请求中使用If头的多个实例。但是，HTTP标头语法允许通过插入一个换行符，后跟空格，将单个标头值扩展到多行（请参见[RFC2616]，第4.2节）。
A Condition that consists of a single entity-tag or state-token evaluates to true if the resource matches the described state (where the individual matching functions are defined below in Section 10.4.4). Prefixing it with "Not" reverses the result of the evaluation (thus, the "Not" applies only to the subsequent entity-tag or state-token).
如果资源与所描述的状态匹配，则由单个实体标记或状态标记组成的条件将计算为true（其中单独的匹配函数在下文第10.4.4节中定义）。在其前面加上“Not”将反转计算结果（因此，“Not”仅适用于后续的实体标记或状态标记）。
Each List production describes a series of conditions. The whole list evaluates to true if and only if each condition evaluates to true (that is, the list represents a logical conjunction of Conditions).
每个生产列表都描述了一系列条件。当且仅当每个条件的计算结果为true时，整个列表的计算结果为true（即，该列表表示条件的逻辑连接）。
Each No-tag-list and Tagged-list production may contain one or more Lists. They evaluate to true if and only if any of the contained lists evaluates to true (that is, if there's more than one List, that List sequence represents a logical disjunction of the Lists).
每个无标签列表和标签列表产品可能包含一个或多个列表。当且仅当所包含的任何列表的计算结果为true时，它们才计算为true（即，如果有多个列表，则该列表序列表示列表的逻辑析取）。
Finally, the whole If header evaluates to true if and only if at least one of the No-tag-list or Tagged-list productions evaluates to true. If the header evaluates to false, the server MUST reject the request with a 412 (Precondition Failed) status. Otherwise, execution of the request can proceed as if the header wasn't present.
最后，当且仅当至少一个无标记列表或标记列表产品的计算结果为true时，整个If头的计算结果为true。如果报头的计算结果为false，则服务器必须拒绝状态为412（前提条件失败）的请求。否则，请求的执行可以继续，就好像报头不存在一样。
When performing If header processing, the definition of a matching state token or entity tag is as follows:
在执行If头处理时，匹配状态标记或实体标记的定义如下：
Identifying a resource: The resource is identified by the URI along with the token, in tagged list production, or by the Request-URI in untagged list production.
标识资源：资源在标记列表生产中由URI和令牌标识，或者在未标记列表生产中由请求URI标识。
Matching entity tag: Where the entity tag matches an entity tag associated with the identified resource. Servers MUST use either the weak or the strong comparison function defined in Section 13.3.3 of [RFC2616].
匹配实体标记：其中实体标记与与已标识资源关联的实体标记匹配。服务器必须使用[RFC2616]第13.3.3节中定义的弱比较功能或强比较功能。
Matching state token: Where there is an exact match between the state token in the If header and any state token on the identified resource. A lock state token is considered to match if the resource is anywhere in the scope of the lock.
匹配状态令牌：If头中的状态令牌与已标识资源上的任何状态令牌完全匹配。如果资源在锁的作用域中的任何位置，则认为锁状态令牌匹配。
Handling unmapped URLs: For both ETags and state tokens, treat as if the URL identified a resource that exists but does not have the specified state.
处理未映射的URL：对于ETag和状态标记，将其视为URL标识了存在但不具有指定状态的资源。
Non-DAV-aware proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the client MUST use the "Cache-Control: no-cache" request header so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies, the "Pragma: no-cache" request header MUST be used for the same reason.
不支持DAV的代理将不支持If头，因为它们不理解If头，HTTP要求忽略不理解的头。当与HTTP/1.1代理通信时，客户端必须使用“缓存控制：无缓存”请求头，以防止代理错误地尝试从其缓存为请求提供服务。在处理HTTP/1.0代理时，出于同样的原因，必须使用“Pragma:no cache”请求头。
Because in general clients may not be able to reliably detect non-DAV-aware intermediates, they are advised to always prevent caching using the request directives mentioned above.
由于一般情况下，客户端可能无法可靠地检测不支持DAV的中间体，因此建议它们始终使用上述请求指令防止缓存。
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
["I am an ETag"])
(["I am another ETag"])
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
["I am an ETag"])
(["I am another ETag"])
The previous header would require that the resource identified in the Request-URI be locked with the specified lock token and be in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag".
前一个头将要求使用指定的锁定令牌锁定请求URI中标识的资源，并处于由“I am an ETag”ETag标识的状态，或处于由第二个ETag“I am另一个ETag”标识的状态。
To put the matter more plainly one can think of the previous If header as expressing the condition below:
为了更清楚地说明这一点，可以将上一个If头视为表示以下条件：
( is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND matches-etag("I am an ETag") ) OR ( matches-etag("I am another ETag") )
（与（urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2）锁定并匹配etag（“我是一个etag”））或（匹配etag（“我是另一个etag”））
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
This If header requires that the resource must not be locked with a lock having the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a lock with the lock token urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
此If标头要求不得使用具有锁定令牌urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2的锁锁定资源，并且必须使用具有锁定令牌urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092的锁锁定资源。
There may be cases where a client wishes to submit state tokens, but doesn't want the request to fail just because the state token isn't current anymore. One simple way to do this is to include a Condition that is known to always evaluate to true, such as in:
在某些情况下，客户机希望提交状态令牌，但不希望请求因为状态令牌不再是当前令牌而失败。一种简单的方法是包含一个已知总是计算为true的条件，例如：
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
(Not <DAV:no-lock>)
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
(Not <DAV:no-lock>)
"DAV:no-lock" is known to never represent a current lock token. Lock tokens are assigned by the server, following the uniqueness requirements described in Section 6.5, therefore cannot use the "DAV:" scheme. Thus, by applying "Not" to a state token that is
已知“DAV:无锁”从不表示当前锁令牌。锁令牌由服务器根据第6.5节中描述的唯一性要求分配，因此不能使用“DAV:”方案。因此，通过将“Not”应用于
known not to be current, the Condition always evaluates to true. Consequently, the whole If header will always evaluate to true, and the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 will be submitted in any case.
已知不是当前状态，条件的计算结果始终为true。因此，整个If报头将始终计算为true，并且在任何情况下都将提交锁定令牌urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2。
>>Request
>>请求
COPY /resource1 HTTP/1.1
Host: www.example.com
Destination: /resource2
If: </resource1>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
[W/"A weak ETag"]) (["strong ETag"])
COPY /resource1 HTTP/1.1
Host: www.example.com
Destination: /resource2
If: </resource1>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
[W/"A weak ETag"]) (["strong ETag"])
In this example, http://www.example.com/resource1 is being copied to http://www.example.com/resource2. When the method is first applied to http://www.example.com/resource1, resource1 must be in the state specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A weak ETag"]) (["strong ETag"])". That is, either it must be locked with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag".
在这个例子中，http://www.example.com/resource1 正在复制到http://www.example.com/resource2. 当该方法首次应用于http://www.example.com/resource1，resource1必须处于由“（<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>[W/“弱ETag]”）指定的状态（[“强ETag]”）。也就是说，它必须使用锁令牌“urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2”进行锁定，并具有弱实体标记W/“弱ETag”，或者它必须具有强实体标记“强ETag”。
DELETE /specs/rfc2518.txt HTTP/1.1
Host: www.example.com
If: <http://www.example.com/specs/>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
DELETE /specs/rfc2518.txt HTTP/1.1
Host: www.example.com
If: <http://www.example.com/specs/>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
For this example, the lock token must be compared to the identified resource, which is the 'specs' collection identified by the URL in the tagged list production. If the 'specs' collection is not locked by a lock with the specified lock token, the request MUST fail. Otherwise, this request could succeed, because the If header evaluates to true, and because the lock token for the lock affecting the affected resource has been submitted.
对于本例，必须将锁令牌与标识的资源进行比较，该资源是由标记列表中的URL标识的“specs”集合。如果“specs”集合未被具有指定锁令牌的锁锁定，则请求必须失败。如果请求的锁已提交，则会计算为true，否则会影响请求的锁成功。
Consider a collection "/specs" that does not contain the member "/specs/rfc2518.doc". In this case, the If header
考虑一个不包含成员“/SPECs/RCF2518.doc”的集合“/SCOS”。在本例中，If头
If: </specs/rfc2518.doc> (["4217"])
If: </specs/rfc2518.doc> (["4217"])
will evaluate to false (the URI isn't mapped, thus the resource identified by the URI doesn't have an entity matching the ETag "4217").
将计算为false（URI未映射，因此URI标识的资源没有与ETag“4217”匹配的实体）。
On the other hand, an If header of
另一方面，一个
If: </specs/rfc2518.doc> (Not ["4217"])
If: </specs/rfc2518.doc> (Not ["4217"])
will consequently evaluate to true.
将因此评估为真。
Note that, as defined above in Section 10.4.4, the same considerations apply to matching state tokens.
注意，如上文第10.4.4节所定义，相同的注意事项适用于匹配状态令牌。
Lock-Token = "Lock-Token" ":" Coded-URL
Lock-Token=“Lock-Token”“：”编码的URL
The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed. The lock token in the Lock-Token request header MUST identify a lock that contains the resource identified by Request-URI as a member.
Lock Token请求标头与UNLOCK方法一起使用，以标识要移除的锁。锁令牌请求标头中的锁令牌必须标识一个锁，该锁包含由请求URI标识为成员的资源。
The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.
Lock-Token-response标头与Lock方法一起使用，以指示由于创建新锁的成功锁请求而创建的锁令牌。
Overwrite = "Overwrite" ":" ("T" | "F")
Overwrite = "Overwrite" ":" ("T" | "F")
The Overwrite request header specifies whether the server should overwrite a resource mapped to the destination URL during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the destination URL does map to a resource. If the overwrite header is not included in a COPY or MOVE request, then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of using an "If-Match: *" header (see [RFC2616]), If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE.
覆盖请求标头指定服务器是否应在复制或移动期间覆盖映射到目标URL的资源。值“F”表示，如果目标URL确实映射到资源，则服务器不得执行复制或移动操作。如果复制或移动请求中未包含覆盖标头，则资源必须将该请求视为具有值“T”的覆盖标头。虽然覆盖标头似乎重复了使用“If Match:*”标头（请参见[RFC2616]）的功能，但If Match仅适用于请求URI，而不适用于副本或移动的目标。
If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code. The server MUST do authorization checks before checking this or any conditional header.
如果由于覆盖标头的值而未执行复制或移动，则该方法必须失败，状态代码为412（前置条件失败）。在检查此标头或任何条件标头之前，服务器必须进行授权检查。
All DAV-compliant resources MUST support the Overwrite header.
所有符合DAV的资源都必须支持覆盖标头。
TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite")
; No LWS allowed within TimeType
DAVTimeOutVal = 1*DIGIT
TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite")
; No LWS allowed within TimeType
DAVTimeOutVal = 1*DIGIT
Clients MAY include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method.
客户端的锁请求中可能包含超时请求头。然而，服务器不需要尊重或甚至考虑这些请求。客户端不得使用锁方法以外的任何方法提交超时请求标头。
The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1.
“秒”时间类型指定在服务器上授予锁和自动移除锁之间的秒数。TimeType“Second”的超时值不得大于2^32-1。
See Section 6.6 for a description of lock timeout behavior.
有关锁定超时行为的说明，请参见第6.6节。
The following status codes are added to those defined in HTTP/1.1 [RFC2616].
以下状态代码添加到HTTP/1.1[RFC2616]中定义的状态代码中。
The 207 (Multi-Status) status code provides status for multiple independent operations (see Section 13 for more information).
207（多状态）状态代码为多个独立操作提供状态（更多信息，请参阅第13节）。
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
422（不可处理实体）状态代码意味着服务器理解请求实体的内容类型（因此415（不支持的媒体类型）状态代码不合适），并且请求实体的语法正确（因此400（坏请求）状态代码不合适），但无法处理包含的指令。例如，如果XML请求体包含格式正确（即语法正确）但语义错误的XML指令，则可能会出现这种错误情况。
The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
423（锁定）状态代码表示方法的源或目标资源已锁定。此响应应包含适当的先决条件或后决条件代码，例如“已提交锁令牌”或“无冲突锁”。
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails, then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
424（失败的依赖项）状态代码表示无法对资源执行该方法，因为请求的操作依赖于另一个操作，而该操作失败。例如，如果PROPPATCH方法中的一个命令失败，那么至少其他命令也会失败，出现424（失败的依赖项）。
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
507（存储不足）状态代码表示无法在资源上执行该方法，因为服务器无法存储成功完成请求所需的表示。这种情况被认为是暂时的。如果收到此状态代码的请求是用户操作的结果，则在单独的用户操作请求之前，不得重复该请求。
These HTTP codes are not redefined, but their use is somewhat extended by WebDAV methods and requirements. In general, many HTTP status codes can be used in response to any request, not just in cases described in this document. Note also that WebDAV servers are known to use 300-level redirect responses (and early interoperability tests found clients unprepared to see those responses). A 300-level response MUST NOT be used when the server has created a new resource in response to the request.
这些HTTP代码没有被重新定义，但是WebDAV方法和需求在某种程度上扩展了它们的使用。通常，许多HTTP状态代码可用于响应任何请求，而不仅仅是在本文档中描述的情况下。还要注意的是，已知WebDAV服务器使用300级别的重定向响应（早期的互操作性测试发现客户端对这些响应毫无准备）。当服务器已创建新资源以响应请求时，不得使用300级响应。
Any request can contain a conditional header defined in HTTP (If-Match, If-Modified-Since, etc.) or the "If" or "Overwrite" conditional headers defined in this specification. If the server evaluates a conditional header, and if that condition fails to hold, then this error code MUST be returned. On the other hand, if the client did not include a conditional header in the request, then the server MUST NOT use this status code.
任何请求都可以包含HTTP中定义的条件头（如果匹配、如果自修改等）或本规范中定义的“如果”或“覆盖”条件头。如果服务器计算条件标头，并且如果该条件无法保持，则必须返回此错误代码。另一方面，如果客户端未在请求中包含条件标头，则服务器不得使用此状态代码。
This status code is used in HTTP 1.1 only for Request-URIs, not URIs in other locations.
在HTTP 1.1中，此状态代码仅用于请求URI，而不用于其他位置的URI。
A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate. The default Multi-Status response body is a text/xml or application/xml HTTP entity with a 'multistatus' root element. Further elements contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element.
在多个状态代码可能适用的情况下，多状态响应传递有关多个资源的信息。默认的多状态响应主体是具有“multistatus”根元素的text/xml或application/xml HTTP实体。其他元素包含在方法调用期间生成的200、300、400和500系列状态代码。100系列状态代码不应记录在“响应”XML元素中。
Although '207' is used as the overall response status code, the recipient needs to consult the contents of the multistatus response body for further information about the success or failure of the method execution. The response MAY be used in success, partial success and also in failure situations.
虽然“207”用作总体响应状态代码，但接收者需要查阅multistatus响应主体的内容，以获取有关方法执行成功或失败的更多信息。响应可用于成功、部分成功和失败情况。
The 'multistatus' root element holds zero or more 'response' elements in any order, each with information about an individual resource. Each 'response' element MUST have an 'href' element to identify the resource.
“multistatus”根元素以任意顺序保存零个或多个“response”元素，每个元素都包含有关单个资源的信息。每个“响应”元素必须有一个“href”元素来标识资源。
A Multi-Status response uses one out of two distinct formats for representing the status:
多状态响应使用两种不同格式中的一种来表示状态：
1. A 'status' element as child of the 'response' element indicates the status of the message execution for the identified resource as a whole (for instance, see Section 9.6.2). Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic rules defined in Section 10 of [RFC2616].
1. 作为“response”元素子元素的“status”元素表示整个已标识资源的消息执行状态（例如，请参见第9.6.2节）。一些方法定义提供了有关客户端应准备在响应中查看的特定状态代码的信息。但是，客户机必须能够使用[RFC2616]第10节中定义的通用规则处理其他状态代码。
2. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is described in detail in Sections 9.1 and 9.2.
2. 对于PROPFIND和PROPPATCH，使用“propstat”元素而不是“status”扩展了格式，提供了有关资源的各个属性的信息。该格式特定于PROPFIND和PROPPATCH，第9.1节和第9.2节对此进行了详细描述。
HTTP defines the Location header to indicate a preferred URL for the resource that was addressed in the Request-URI (e.g., in response to successful PUT requests or in redirect responses). However, use of this header creates ambiguity when there are URLs in the body of the response, as with Multi-Status. Thus, use of the Location header with the Multi-Status response is intentionally undefined.
HTTP定义位置头以指示在请求URI中寻址的资源的首选URL（例如，响应成功的PUT请求或重定向响应）。但是，当响应主体中存在URL时，使用此标头会产生歧义，就像使用多状态一样。所以，有意不定义具有多状态响应的位置头的使用。
Redirect responses (300-303, 305, and 307) defined in HTTP 1.1 normally take a Location header to indicate the new URI for the single resource redirected from the Request-URI. Multi-Status responses contain many resource addresses, but the original definition in [RFC2518] did not have any place for the server to provide the new URI for redirected resources. This specification does define a 'location' element for this information (see Section 14.9). Servers MUST use this new element with redirect responses in Multi-Status.
HTTP 1.1中定义的重定向响应（300-303、305和307）通常采用位置头来指示从请求URI重定向的单个资源的新URI。多状态响应包含许多资源地址，但是[RFC2518]中的原始定义没有任何位置让服务器为重定向的资源提供新的URI。本规范确实为该信息定义了“位置”元素（见第14.9节）。服务器必须将此新元素与多状态的重定向响应一起使用。
Clients encountering redirected resources in Multi-Status MUST NOT rely on the 'location' element being present with a new URI. If the element is not present, the client MAY reissue the request to the individual redirected resource, because the response to that request can be redirected with a Location header containing the new URI.
遇到处于多状态的重定向资源的客户端不能依赖具有新URI的“location”元素。如果元素不存在，客户端可能会重新发出对单个重定向资源的请求，因为对该请求的响应可以使用包含新URI的位置头重定向。
Sections 9.2.1, 9.1.2, 9.6.1, 9.8.3, and 9.9.2 define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses.
第9.2.1、9.1.2、9.6.1、9.8.3和9.9.2节定义了多状态响应中使用的各种状态代码。本规范未定义这些响应中可能出现的其他状态代码的含义。
In this section, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). Note that all of the elements defined here may be extended according to the rules defined in Section 17. All elements defined here are in the "DAV:" namespace.
在本节中，每个节的最后一行使用[REC-XML]中定义的格式给出元素类型声明。“Value”字段（如果存在）指定了对使用BNF的XML元素的允许内容的进一步限制（即，进一步限制PCDATA元素的值）。请注意，此处定义的所有元素可根据第17节中定义的规则进行扩展。这里定义的所有元素都在“DAV:”命名空间中。
Name: activelock
名称：activelock
Purpose: Describes a lock on a resource.
目的：描述对资源的锁定。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?, lockroot)>
<!元素activelock（锁范围、锁类型、深度、所有者、超时、锁令牌、锁根）>
Name: allprop
道具：全名
Purpose: Specifies that all names and values of dead properties and the live properties defined by this document existing on the resource are to be returned.
目的：指定要返回此文档定义的资源上现有的死属性和活属性的所有名称和值。
<!ELEMENT allprop EMPTY >
<!ELEMENT allprop EMPTY >
Name: collection
名称：收藏
Purpose: Identifies the associated resource as a collection. The DAV:resourcetype property of a collection resource MUST contain this element. It is normally empty but extensions may add sub-elements.
目的：将关联的资源标识为集合。集合资源的DAV:resourcetype属性必须包含此元素。它通常为空，但扩展可能会添加子元素。
<!ELEMENT collection EMPTY >
<!ELEMENT collection EMPTY >
Name: depth
名称：深度
Purpose: Used for representing depth values in XML content (e.g., in lock information).
用途：用于表示XML内容（如锁信息）中的深度值。
Value: "0" | "1" | "infinity"
Value: "0" | "1" | "infinity"
<!ELEMENT depth (#PCDATA) >
<!ELEMENT depth (#PCDATA) >
Name: error
名称：错误
Purpose: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. In these cases, servers MAY return an XML response body with a document element of 'error', containing child elements identifying particular condition codes.
目的：错误响应，特别是403禁止和409冲突，有时需要更多的信息来指出哪里出了问题。在这些情况下，服务器可能返回一个XML响应体，其中包含一个“error”文档元素，其中包含标识特定条件代码的子元素。
Description: Contains at least one XML element, and MUST NOT contain text or mixed content. Any element that is a child of the 'error' element is considered to be a precondition or postcondition code. Unrecognized elements MUST be ignored.
描述：至少包含一个XML元素，不能包含文本或混合内容。作为“error”元素的子元素的任何元素都被视为先决条件或后决条件代码。必须忽略无法识别的元素。
<!ELEMENT error ANY >
<!ELEMENT error ANY >
Name: exclusive
名称：独家
Purpose: Specifies an exclusive lock.
用途：指定独占锁。
<!ELEMENT exclusive EMPTY >
<!ELEMENT exclusive EMPTY >
Name: href
姓名：href
Purpose: MUST contain a URI or a relative reference.
目的：必须包含URI或相对引用。
Description: There may be limits on the value of 'href' depending on the context of its use. Refer to the specification text where 'href' is used to see what limitations apply in each case.
说明：“href”的值可能有限制，具体取决于其使用的上下文。请参阅使用“href”的规范文本，以了解每种情况下适用的限制。
Value: Simple-ref
值：简单参考
<!ELEMENT href (#PCDATA)>
<!ELEMENT href (#PCDATA)>
Name: include
名称：包括
Purpose: Any child element represents the name of a property to be included in the PROPFIND response. All elements inside an 'include' XML element MUST define properties related to the resource, although possible property names are in no way limited to those property names defined in this document or other standards. This element MUST NOT contain text or mixed content.
用途：任何子元素都表示要包含在PROPFIND响应中的属性的名称。“include”XML元素中的所有元素都必须定义与资源相关的属性，尽管可能的属性名称绝不限于本文档或其他标准中定义的属性名称。此元素不能包含文本或混合内容。
<!ELEMENT include ANY >
<!ELEMENT include ANY >
Name: location
名称：地点
Purpose: HTTP defines the "Location" header (see [RFC2616], Section 14.30) for use with some status codes (such as 201 and the 300 series codes). When these codes are used inside a 'multistatus' element, the 'location' element can be used to provide the accompanying Location header value.
目的：HTTP定义了“位置”标头（参见[RFC2616]，第14.30节），用于某些状态代码（如201和300系列代码）。当在“multistatus”元素内使用这些代码时，“location”元素可用于提供附带的位置标题值。
Description: Contains a single href element with the same value that would be used in a Location header.
描述：包含一个href元素，其值与位置标题中使用的值相同。
<!ELEMENT location (href)>
<!ELEMENT location (href)>
Name: lockentry
姓名：锁入口
Purpose: Defines the types of locks that can be used with the resource.
目的：定义可与资源一起使用的锁的类型。
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockentry (lockscope, locktype) >
Name: lockinfo
姓名：lockinfo
Purpose: The 'lockinfo' XML element is used with a LOCK method to specify the type of lock the client wishes to have created.
用途：“lockinfo”XML元素与LOCK方法一起使用，以指定客户端希望创建的锁的类型。
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
Name: lockroot
姓名：lockroot
Purpose: Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request.
用途：包含锁的根URL，该URL是在锁请求中对资源进行寻址的URL。
Description: The href element contains the root of the lock. The server SHOULD include this in all DAV:lockdiscovery property values and the response to LOCK requests.
描述：href元素包含锁的根。服务器应该在所有DAV:lockdiscovery属性值和对锁请求的响应中包含这一点。
<!ELEMENT lockroot (href) >
<!ELEMENT lockroot (href) >
Name: lockscope
名称：锁镜
Purpose: Specifies whether a lock is an exclusive lock, or a shared lock.
目的：指定锁是独占锁还是共享锁。
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT lockscope (exclusive | shared) >
Name: locktoken
姓名：locktoken
Purpose: The lock token associated with a lock.
用途：与锁关联的锁令牌。
Description: The href contains a single lock token URI, which refers to the lock.
描述：href包含一个锁令牌URI，它引用锁。
<!ELEMENT locktoken (href) >
<!ELEMENT locktoken (href) >
Name: locktype
名称：锁型
Purpose: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.
用途：指定锁的访问类型。目前，该规范只定义了一种锁类型，即写锁。
<!ELEMENT locktype (write) >
<!ELEMENT locktype (write) >
Name: multistatus
姓名:multistatus
Purpose: Contains multiple response messages.
目的：包含多个响应消息。
Description: The 'responsedescription' element at the top level is used to provide a general message describing the overarching nature of the response. If this value is available, an application may use it instead of presenting the individual response descriptions contained within the responses.
描述：顶层的“responsedescription”元素用于提供描述响应总体性质的一般消息。如果此值可用，应用程序可以使用它，而不是显示响应中包含的单个响应描述。
<!ELEMENT multistatus (response*, responsedescription?) >
<!ELEMENT multistatus (response*, responsedescription?) >
Name: owner
姓名：业主
Purpose: Holds client-supplied information about the creator of a lock.
用途：保存客户端提供的有关锁创建者的信息。
Description: Allows a client to provide information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL
描述：允许客户端提供足够的信息，以便直接联系主体（如电话号码或电子邮件URI），或查找主体（如URL）
of a homepage) who created a lock. The value provided MUST be treated as a dead property in terms of XML Information Item preservation. The server MUST NOT alter the value unless the owner value provided by the client is empty. For a certain amount of interoperability between different client implementations, if clients have URI-formatted contact information for the lock creator suitable for user display, then clients SHOULD put those URIs in 'href' child elements of the 'owner' element.
（指主页）谁创建了锁。在XML信息项保存方面，所提供的值必须被视为死属性。除非客户端提供的所有者值为空，否则服务器不得更改该值。对于不同客户端实现之间的一定程度的互操作性，如果客户端具有适合用户显示的锁创建者的URI格式的联系信息，则客户端应将这些URI放在“owner”元素的“href”子元素中。
Extensibility: MAY be extended with child elements, mixed content, text content or attributes.
可扩展性：可以使用子元素、混合内容、文本内容或属性进行扩展。
<!ELEMENT owner ANY >
<!ELEMENT owner ANY >
Name: prop
姓名：道具
Purpose: Contains properties related to a resource.
用途：包含与资源相关的属性。
Description: A generic container for properties defined on resources. All elements inside a 'prop' XML element MUST define properties related to the resource, although possible property names are in no way limited to those property names defined in this document or other standards. This element MUST NOT contain text or mixed content.
描述：资源上定义的属性的通用容器。“prop”XML元素中的所有元素都必须定义与资源相关的属性，尽管可能的属性名称绝不限于本文档或其他标准中定义的属性名称。此元素不能包含文本或混合内容。
<!ELEMENT prop ANY >
<!ELEMENT prop ANY >
Name: propertyupdate
名称：propertyupdate
Purpose: Contains a request to alter the properties on a resource.
目的：包含更改资源属性的请求。
Description: This XML element is a container for the information required to modify the properties on the resource.
描述：此XML元素是修改资源属性所需信息的容器。
<!ELEMENT propertyupdate (remove | set)+ >
<!ELEMENT propertyupdate (remove | set)+ >
Name: propfind
姓名：propfind
Purpose: Specifies the properties to be returned from a PROPFIND method. Four special elements are specified for use with 'propfind': 'prop', 'allprop', 'include', and 'propname'. If 'prop' is used inside 'propfind', it MUST NOT contain property values.
目的：指定要从PROPFIND方法返回的属性。指定了四个与“propfind”一起使用的特殊元素：“prop”、“allprop”、“include”和“propname”。如果“propfind”中使用了“prop”，则它不得包含属性值。
<!ELEMENT propfind ( propname | (allprop, include?) | prop ) >
<!ELEMENT propfind ( propname | (allprop, include?) | prop ) >
Name: propname
姓名：propname
Purpose: Specifies that only a list of property names on the resource is to be returned.
目的：指定仅返回资源上的属性名称列表。
<!ELEMENT propname EMPTY >
<!ELEMENT propname EMPTY >
Name: propstat
姓名：propstat
Purpose: Groups together a prop and status element that is associated with a particular 'href' element.
目的：将与特定“href”元素关联的prop和status元素分组在一起。
Description: The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies. The optional precondition/ postcondition element and 'responsedescription' text also apply to the properties named in 'prop'.
描述：propstat XML元素必须包含一个prop XML元素和一个status XML元素。prop XML元素的内容必须仅列出status元素中的结果所应用的属性的名称。可选的前置条件/后置条件元素和“responsedescription”文本也适用于“prop”中命名的属性。
<!ELEMENT propstat (prop, status, error?, responsedescription?) >
<!ELEMENT propstat (prop, status, error?, responsedescription?) >
Name: remove
名称：删除
Purpose: Lists the properties to be removed from a resource.
目的：列出要从资源中删除的属性。
Description: Remove instructs that the properties specified in prop should be removed. Specifying the removal of a property that does not exist is not an error. All the XML elements in a 'prop' XML element inside of a 'remove' XML element MUST be empty, as only the names of properties to be removed are required.
Description:Remove指示应删除prop中指定的属性。指定删除不存在的属性不是错误。“remove”XML元素中的“prop”XML元素中的所有XML元素都必须为空，因为只需要要删除的属性的名称。
<!ELEMENT remove (prop) >
<!ELEMENT remove (prop) >
Name: response
姓名：回应
Purpose: Holds a single response describing the effect of a method on resource and/or its properties.
目的：保存描述方法对资源和/或其属性的影响的单个响应。
Description: The 'href' element contains an HTTP URL pointing to a WebDAV resource when used in the 'response' container. A particular 'href' value MUST NOT appear more than once as the child of a 'response' XML element under a 'multistatus' XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by 'href'. There are, however, no requirements regarding ordering based on 'href' values. The optional precondition/postcondition element and 'responsedescription' text can provide additional information about this resource relative to the request or result.
描述：“href”元素包含一个HTTP URL，在“response”容器中使用时指向WebDAV资源。特定的“href”值不能作为“multistatus”XML元素下的“response”XML元素的子元素出现多次。为了保持响应线性时间的处理成本，这一要求是必要的。从本质上讲，这避免了必须通过搜索将所有响应按“href”分组。但是，对于基于“href”值的订购没有任何要求。可选的前置条件/后置条件元素和“responsedescription”文本可以提供与请求或结果相关的有关此资源的其他信息。
<!ELEMENT response (href, ((href*, status)|(propstat+)),
error?, responsedescription? , location?) >
<!ELEMENT response (href, ((href*, status)|(propstat+)),
error?, responsedescription? , location?) >
Name: responsedescription
名称：responsedescription
Purpose: Contains information about a status response within a Multi-Status.
目的：包含有关多状态中状态响应的信息。
Description: Provides information suitable to be presented to a user.
描述：提供适合呈现给用户的信息。
<!ELEMENT responsedescription (#PCDATA) >
<!ELEMENT responsedescription (#PCDATA) >
Name: set
名称：集
Purpose: Lists the property values to be set for a resource.
目的：列出要为资源设置的属性值。
Description: The 'set' element MUST contain only a 'prop' element. The elements contained by the 'prop' element inside the 'set' element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists, then its value is replaced. Language tagging information appearing in the scope of the 'prop' element (in the "xml:lang"
说明：“set”元素必须仅包含“prop”元素。“set”元素中的“prop”元素包含的元素必须指定在请求URI标识的资源上设置的属性的名称和值。如果属性已存在，则替换其值。“prop”元素范围内出现的语言标记信息（在“xml:lang”中）
attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND.
属性（如果存在）必须与属性一起持久存储，并且随后必须使用PROPFIND进行检索。
<!ELEMENT set (prop) >
<!ELEMENT set (prop) >
Name: shared
名称：共享
Purpose: Specifies a shared lock.
目的：指定共享锁。
<!ELEMENT shared EMPTY >
<!ELEMENT shared EMPTY >
Name: status
姓名：身份
Purpose: Holds a single HTTP status-line.
用途：保存单个HTTP状态行。
Value: status-line (defined in Section 6.1 of [RFC2616])
值：状态行（定义见[RFC2616]第6.1节）
<!ELEMENT status (#PCDATA) >
<!ELEMENT status (#PCDATA) >
Name: timeout
名称：超时
Purpose: The number of seconds remaining before a lock expires.
用途：锁定过期前剩余的秒数。
Value: TimeType (defined in Section 10.7)
值：时间类型（在第10.7节中定义）
<!ELEMENT timeout (#PCDATA) >
<!ELEMENT timeout (#PCDATA) >
Name: write
姓名：write
Purpose: Specifies a write lock.
目的：指定写入锁定。
<!ELEMENT write EMPTY >
<!ELEMENT write EMPTY >
For DAV properties, the name of the property is also the same as the name of the XML element that contains its value. In the section below, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element).
对于DAV属性，属性的名称也与包含其值的XML元素的名称相同。在下面的小节中，每个小节的最后一行使用[REC-XML]中定义的格式给出了元素类型声明。“Value”字段（如果存在）指定了对使用BNF的XML元素的允许内容的进一步限制（即，进一步限制PCDATA元素的值）。
A protected property is one that cannot be changed with a PROPPATCH request. There may be other requests that would result in a change to a protected property (as when a LOCK request affects the value of DAV:lockdiscovery). Note that a given property could be protected on one type of resource, but not protected on another type of resource.
受保护的属性是不能通过PROPPATCH请求更改的属性。可能还有其他请求会导致对受保护属性的更改（如锁请求影响DAV:lockdiscovery的值时）。请注意，给定的属性可以在一种类型的资源上受保护，但不能在另一种类型的资源上受保护。
A computed property is one with a value defined in terms of a computation (based on the content and other properties of that resource, or even of some other resource). A computed property is always a protected property.
计算属性是指具有根据计算定义的值的属性（基于该资源，甚至某些其他资源的内容和其他属性）。计算属性始终是受保护的属性。
COPY and MOVE behavior refers to local COPY and MOVE operations.
复制和移动行为是指本地复制和移动操作。
For properties defined based on HTTP GET response headers (DAV:get*), the header value could include LWS as defined in [RFC2616], Section 4.2. Server implementors SHOULD strip LWS from these values before using as WebDAV property values.
对于基于HTTP GET响应头（DAV:GET*）定义的属性，头值可以包括[RFC2616]第4.2节中定义的LW。在将LW用作WebDAV属性值之前，服务器实现者应该从这些值中除去LW。
Name: creationdate
姓名：creationdate
Purpose: Records the time and date the resource was created.
目的：记录创建资源的时间和日期。
Value: date-time (defined in [RFC3339], see the ABNF in Section 5.6.)
值：日期时间（定义见[RFC3339]，见第5.6节中的ABNF。）
Protected: MAY be protected. Some servers allow DAV:creationdate to be changed to reflect the time the document was created if that is more meaningful to the user (rather than the time it was uploaded). Thus, clients SHOULD NOT use this property in synchronization logic (use DAV:getetag instead).
受保护：可能受保护。有些服务器允许更改DAV:creationdate以反映文档创建的时间，如果这对用户更有意义（而不是上载的时间）。因此，客户端不应该在同步逻辑中使用此属性（而是使用DAV:getetag）。
COPY/MOVE behavior: This property value SHOULD be kept during a MOVE operation, but is normally re-initialized when a resource is created with a COPY. It should not be set in a COPY.
复制/移动行为：此属性值应在移动操作期间保留，但通常在使用副本创建资源时重新初始化。不应在副本中设置它。
Description: The DAV:creationdate property SHOULD be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created. Servers that are incapable of persistently recording the creation date SHOULD instead leave it undefined (i.e. report "Not Found").
描述：应在所有符合DAV的资源上定义DAV:creationdate属性。如果存在，则它包含创建资源时的时间戳。无法持续记录创建日期的服务器应保留未定义的创建日期（即报告“未找到”）。
<!ELEMENT creationdate (#PCDATA) >
<!ELEMENT creationdate (#PCDATA) >
Name: displayname
名称：displayname
Purpose: Provides a name for the resource that is suitable for presentation to a user.
目的：提供适合向用户演示的资源的名称。
Value: Any text.
值：任何文本。
Protected: SHOULD NOT be protected. Note that servers implementing [RFC2518] might have made this a protected property as this is a new requirement.
受保护：不应受到保护。请注意，实现[RFC2518]的服务器可能会使其成为受保护的属性，因为这是一个新的要求。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
复制/移动行为：此属性值应在复制和移动操作中保留。
Description: Contains a description of the resource that is suitable for presentation to a user. This property is defined on the resource, and hence SHOULD have the same value independent of the Request-URI used to retrieve it (thus, computing this property based on the Request-URI is deprecated). While generic clients might display the property value to end users, client UI designers must understand that the method for identifying resources is still the URL. Changes to DAV:displayname do not issue moves or copies to the server, but simply change a piece of meta-data on the individual resource. Two resources can have the same DAV: displayname value even within the same collection.
描述：包含适合向用户演示的资源的描述。此属性是在资源上定义的，因此应该具有与用于检索它的请求URI无关的相同值（因此，不推荐基于请求URI计算此属性）。虽然通用客户机可能会向最终用户显示属性值，但客户机UI设计者必须了解，标识资源的方法仍然是URL。对DAV:displayname的更改不会向服务器发出移动或复制，而只是更改单个资源上的一段元数据。即使在同一个集合中，两个资源也可以具有相同的DAV:displayname值。
<!ELEMENT displayname (#PCDATA) >
<!ELEMENT displayname (#PCDATA) >
Name: getcontentlanguage
名称：getcontentlanguage
Purpose: Contains the Content-Language header value (from Section 14.12 of [RFC2616]) as it would be returned by a GET without accept headers.
用途：包含内容语言标题值（来自[RFC2616]第14.12节），因为它将由GET返回，而不包含accept标题。
Value: language-tag (language-tag is defined in Section 3.10 of [RFC2616])
值：语言标记（语言标记在[RFC2616]第3.10节中定义）
Protected: SHOULD NOT be protected, so that clients can reset the language. Note that servers implementing [RFC2518] might have made this a protected property as this is a new requirement.
受保护：不应受到保护，以便客户端可以重置语言。请注意，实现[RFC2518]的服务器可能会使其成为受保护的属性，因为这是一个新的要求。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
复制/移动行为：此属性值应在复制和移动操作中保留。
Description: The DAV:getcontentlanguage property MUST be defined on any DAV-compliant resource that returns the Content-Language header on a GET.
描述：必须在任何符合DAV的资源上定义DAV:getcontentlanguage属性，该资源在GET上返回内容语言头。
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlanguage (#PCDATA) >
Name: getcontentlength
名称：getcontentlength
Purpose: Contains the Content-Length header returned by a GET without accept headers.
用途：包含GET返回的内容长度标头，但不包含accept标头。
Value: See Section 14.13 of [RFC2616].
值：见[RFC2616]第14.13节。
Protected: This property is computed, therefore protected.
受保护：此属性已计算，因此受保护。
Description: The DAV:getcontentlength property MUST be defined on any DAV-compliant resource that returns the Content-Length header in response to a GET.
描述：必须在任何符合DAV的资源上定义DAV:getcontentlength属性，该资源返回内容长度头以响应GET。
COPY/MOVE behavior: This property value is dependent on the size of the destination resource, not the value of the property on the source resource.
复制/移动行为：此属性值取决于目标资源的大小，而不是源资源上属性的值。
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontentlength (#PCDATA) >
Name: getcontenttype
名称：getcontenttype
Purpose: Contains the Content-Type header value (from Section 14.17 of [RFC2616]) as it would be returned by a GET without accept headers.
用途：包含内容类型头值（来自[RFC2616]第14.17节），因为它将由GET返回，而不包含accept头。
Value: media-type (defined in Section 3.7 of [RFC2616])
值：介质类型（在[RFC2616]第3.7节中定义）
Protected: Potentially protected if the server prefers to assign content types on its own (see also discussion in Section 9.7.1).
受保护：如果服务器喜欢自己分配内容类型，则可能受到保护（另请参见第9.7.1节中的讨论）。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
复制/移动行为：此属性值应在复制和移动操作中保留。
Description: This property MUST be defined on any DAV-compliant resource that returns the Content-Type header in response to a GET.
描述：必须在任何符合DAV的资源上定义此属性，该资源返回内容类型头以响应GET。
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getcontenttype (#PCDATA) >
Name: getetag
姓名：getetag
Purpose: Contains the ETag header value (from Section 14.19 of [RFC2616]) as it would be returned by a GET without accept headers.
用途：包含ETag头值（来自[RFC2616]第14.19节），因为它将由GET返回，而不包含accept头。
Value: entity-tag (defined in Section 3.11 of [RFC2616])
值：实体标签（定义见[RFC2616]第3.11节）
Protected: MUST be protected because this value is created and controlled by the server.
受保护：必须受保护，因为此值由服务器创建和控制。
COPY/MOVE behavior: This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. Also note the considerations in Section 8.8.
复制/移动行为：此属性值取决于目标资源的最终状态，而不是源资源上属性的值。还应注意第8.8节中的注意事项。
Description: The getetag property MUST be defined on any DAV-compliant resource that returns the Etag header. Refer to Section 3.11 of RFC 2616 for a complete definition of the semantics of an ETag, and to Section 8.6 for a discussion of ETags in WebDAV.
描述：必须在返回Etag头的任何符合DAV的资源上定义getetag属性。有关ETag语义的完整定义，请参阅RFC 2616第3.11节，有关WebDAV中ETag的讨论，请参阅第8.6节。
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getetag (#PCDATA) >
Name: getlastmodified
名称：getlastmodified
Purpose: Contains the Last-Modified header value (from Section 14.29 of [RFC2616]) as it would be returned by a GET method without accept headers.
用途：包含上次修改的头值（来自[RFC2616]第14.29节），因为它将由不带accept头的GET方法返回。
Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616])
值：rfc1123日期（定义见[RFC2616]第3.3.1节）
Protected: SHOULD be protected because some clients may rely on the value for appropriate caching behavior, or on the value of the Last-Modified header to which this property is linked.
受保护：应受到保护，因为某些客户端可能依赖于适当缓存行为的值，或者依赖于此属性链接到的上次修改的标头的值。
COPY/MOVE behavior: This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this can be preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Note that since [RFC2616] requires clients to use ETags where provided, a server implementing ETags can count on clients using a much better mechanism than modification dates for offline synchronization or cache control. Also note the considerations in Section 8.8.
复制/移动行为：此属性值取决于目标资源的上次修改日期，而不是源资源的属性值。请注意，某些服务器实现使用文件系统日期修改值作为DAV:getlastmodified值，即使HTTP Last modified值应该更改，也可以在移动中保留该值。请注意，由于[RFC2616]要求客户机在提供的地方使用ETAG，因此实现ETAG的服务器可以依靠客户机使用比离线同步或缓存控制的修改日期更好的机制。还应注意第8.8节中的注意事项。
Description: The last-modified date on a resource SHOULD only reflect changes in the body (the GET responses) of the resource. A change in a property only SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body. The DAV: getlastmodified property MUST be defined on any DAV-compliant resource that returns the Last-Modified header in response to a GET.
描述：资源的上次修改日期应仅反映资源主体（GET响应）中的更改。仅属性的更改不应导致上次修改日期的更改，因为客户端可能依赖上次修改日期来知道何时覆盖现有主体。必须在任何符合DAV的资源上定义DAV:getlastmodified属性，该资源返回上次修改的头以响应GET。
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT getlastmodified (#PCDATA) >
Name: lockdiscovery
姓名：骆家辉
Purpose: Describes the active locks on a resource
目的：描述资源上的活动锁
Protected: MUST be protected. Clients change the list of locks through LOCK and UNLOCK, not through PROPPATCH.
受保护：必须被保护。客户端通过锁定和解锁来更改锁列表，而不是通过PROPPATCH。
COPY/MOVE behavior: The value of this property depends on the lock state of the destination, not on the locks of the source resource. Recall that locks are not moved in a MOVE operation.
复制/移动行为：此属性的值取决于目标的锁状态，而不是源资源的锁。请记住，在移动操作中不会移动锁。
Description: Returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. Owner information MAY be omitted if it is considered sensitive. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there are one or more locks, an 'activelock' element appears for each lock on the resource. This property is NOT lockable with respect to write locks (Section 7).
描述：返回谁拥有锁、他拥有什么类型的锁、超时类型和超时剩余时间以及关联的锁令牌的列表。如果业主信息被视为敏感信息，则可省略该信息。如果没有锁，但服务器支持锁，则该属性将存在，但不包含任何“activelock”元素。如果有一个或多个锁，则资源上的每个锁都会显示一个“activelock”元素。对于写锁，此属性不可锁定（第7节）。
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT lockdiscovery (activelock)* >
>>Request
>>请求
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Length: xxxx
Content-Type: application/xml; charset="utf-8"
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Length: xxxx
Content-Type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D='DAV:'>
<D:prop><D:lockdiscovery/></D:prop>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D='DAV:'>
<D:prop><D:lockdiscovery/></D:prop>
</D:propfind>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://www.example.com/container/</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</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/container/</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://www.example.com/container/</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
This resource has a single exclusive write lock on it, with an infinite timeout.
此资源上只有一个独占写入锁，具有无限超时。
Name: resourcetype
名称：resourcetype
Purpose: Specifies the nature of the resource.
目的：指定资源的性质。
Protected: SHOULD be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), not by PROPPATCH.
受保护的：应该受到保护。资源类型通常由创建资源的操作（MKCOL vs PUT）决定，而不是由PROPPATCH决定。
COPY/MOVE behavior: Generally a COPY/MOVE of a resource results in the same type of resource at the destination.
复制/移动行为：通常，资源的复制/移动会在目标位置产生相同类型的资源。
Description: MUST be defined on all DAV-compliant resources. Each child element identifies a specific type the resource belongs to, such as 'collection', which is the only resource type defined by this specification (see Section 14.3). If the element contains the 'collection' child element plus additional unrecognized elements, it should generally be treated as a collection. If the element contains no recognized child elements, it should be treated as a non-collection resource. The default value is empty. This element MUST NOT contain text or mixed content. Any custom child element is considered to be an identifier for a resource type.
描述：必须在所有符合DAV的资源上定义。每个子元素标识资源所属的特定类型，如“集合”，这是本规范定义的唯一资源类型（见第14.3节）。如果元素包含“collection”子元素以及其他无法识别的元素，则通常应将其视为集合。如果元素不包含可识别的子元素，则应将其视为非集合资源。默认值为空。此元素不能包含文本或混合内容。任何自定义子元素都被视为资源类型的标识符。
Example: (fictional example to show extensibility)
示例：（显示可扩展性的虚构示例）
<x:resourcetype xmlns:x="DAV:">
<x:collection/>
<f:search-results xmlns:f="http://www.example.com/ns"/>
</x:resourcetype>
<x:resourcetype xmlns:x="DAV:">
<x:collection/>
<f:search-results xmlns:f="http://www.example.com/ns"/>
</x:resourcetype>
Name: supportedlock
名称：supportedlock
Purpose: To provide a listing of the lock capabilities supported by the resource.
目的：提供资源支持的锁功能列表。
Protected: MUST be protected. Servers, not clients, determine what lock mechanisms are supported.
受保护：必须被保护。服务器（而不是客户端）决定支持哪些锁定机制。
COPY/MOVE behavior: This property value is dependent on the kind of locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at the destination.
复制/移动行为：此属性值取决于目标支持的锁的类型，而不是源资源中属性的值。尝试复制到目标的服务器不应尝试在目标上设置此属性。
Description: Returns a listing of the combinations of scope and access types that may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls, so a server is not required to provide information the client is not authorized to see. This property is NOT lockable with respect to write locks (Section 7).
描述：返回可能在资源的锁定请求中指定的范围和访问类型组合的列表。请注意，实际内容本身由访问控制控制，因此不需要服务器提供客户端无权查看的信息。对于写锁，此属性不可锁定（第7节）。
<!ELEMENT supportedlock (lockentry)* >
<!ELEMENT supportedlock (lockentry)* >
>>Request
>>请求
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Length: xxxx
Content-Type: application/xml; charset="utf-8"
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Length: xxxx
Content-Type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop><D:supportedlock/></D:prop>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop><D:supportedlock/></D:prop>
</D:propfind>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
As introduced in Section 8.7, extra information on error conditions can be included in the body of many status responses. This section makes requirements on the use of the error body mechanism and introduces a number of precondition and postcondition codes.
如第8.7节所述，关于错误条件的额外信息可以包含在许多状态响应的主体中。本节对错误主体机制的使用提出了要求，并介绍了一些前置和后置条件代码。
A "precondition" of a method describes the state of the server that must be true for that method to be performed. A "postcondition" of a method describes the state of the server that must be true after that method has been completed.
方法的“先决条件”描述了要执行该方法必须为true的服务器状态。方法的“后置条件”描述了该方法完成后必须为true的服务器状态。
Each precondition and postcondition has a unique XML element associated with it. In a 207 Multi-Status response, the XML element MUST appear inside an 'error' element in the appropriate 'propstat or 'response' element depending on whether the condition applies to one or more properties or to the resource as a whole. In all other error responses where this specification's 'error' body is used, the precondition/postcondition XML element MUST be returned as the child of a top-level 'error' element in the response body, unless otherwise negotiated by the request, along with an appropriate response status. The most common response status codes are 403 (Forbidden) if the request should not be repeated because it will always fail, and 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. The 'error' element MAY contain child elements with specific error information and MAY be extended with any custom child elements.
每个前置条件和后置条件都有一个与之关联的唯一XML元素。在207多状态响应中，XML元素必须出现在相应的“propstat”或“response”元素中的“error”元素中，具体取决于条件是应用于一个或多个属性还是应用于整个资源。在使用本规范的“错误”主体的所有其他错误响应中，必须将前置条件/后置条件XML元素作为响应主体中顶级“错误”元素的子元素返回，除非请求另行协商，并返回相应的响应状态。如果请求因总是失败而不应重复，则最常见的响应状态代码为403（禁止），如果期望用户能够解决冲突并重新提交请求，则最常见的响应状态代码为409（冲突）。“error”元素可以包含具有特定错误信息的子元素，并且可以使用任何自定义子元素进行扩展。
This mechanism does not take the place of using a correct numeric status code as defined here or in HTTP, because the client must always be able to take a reasonable course of action based only on the numeric code. However, it does remove the need to define new numeric codes. The new machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions, so naturally, any group defining a new condition code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups.
此机制不能代替使用此处或HTTP中定义的正确数字状态代码，因为客户端必须始终能够仅基于数字代码采取合理的操作。但是，它确实不需要定义新的数字代码。用于此目的的新机器可读代码是分类为前置条件和后置条件的XML元素，因此，定义新条件代码的任何组都可以使用自己的名称空间。与往常一样，“DAV:”命名空间保留供IETF特许WebDAV工作组使用。
A server supporting this specification SHOULD use the XML error whenever a precondition or postcondition defined in this document is violated. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank. However, a server MAY instead use a custom condition code and other supporting text, because even when clients do not automatically recognize condition codes, they can be quite useful in interoperability testing and debugging.
支持此规范的服务器应在违反此文档中定义的先决条件或后决条件时使用XML错误。对于本文档中未指定的错误条件，服务器可以简单地选择适当的数字状态，并将响应正文留空。但是，服务器可以使用自定义条件代码和其他支持文本，因为即使客户端不能自动识别条件代码，它们在互操作性测试和调试中也非常有用。
Example - Response with precondition code
示例-带前置条件代码的响应
>>Response
>>回应
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:lock-token-submitted>
<D:href>/workspace/webdav/</D:href>
</D:lock-token-submitted>
</D:error>
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:lock-token-submitted>
<D:href>/workspace/webdav/</D:href>
</D:lock-token-submitted>
</D:error>
In this example, a client unaware of a depth-infinity lock on the parent collection "/workspace/webdav/" attempted to modify the collection member "/workspace/webdav/proposal.doc".
在本例中，客户端不知道父集合“/workspace/webdav/”上存在深度无限锁定，因此尝试修改集合成员“/workspace/webdav/proposal.doc”。
Some other useful preconditions and postconditions have been defined in other specifications extending WebDAV, such as [RFC3744] (see particularly Section 7.1.1), [RFC3253], and [RFC3648].
扩展WebDAV的其他规范中定义了一些其他有用的先决条件和后决条件，如[RFC3744]（具体参见第7.1.1节）、[RFC3253]和[RFC3648]。
All these elements are in the "DAV:" namespace. If not specified otherwise, the content for each condition's XML element is defined to be empty.
所有这些元素都在“DAV:”命名空间中。如果没有另外指定，则每个条件的XML元素的内容定义为空。
Name: lock-token-matches-request-uri
名称：锁定令牌与请求uri匹配
Use with: 409 Conflict
与：409冲突一起使用
Purpose: (precondition) -- A request may include a Lock-Token header to identify a lock for the UNLOCK method. However, if the Request-URI does not fall within the scope of the lock identified by the token, the server SHOULD use this error. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
目的：（前提条件）——请求可能包括一个锁令牌头，用于标识解锁方法的锁。但是，如果请求URI不在令牌标识的锁的范围内，服务器应该使用此错误。锁的作用域可能不包括请求URI，或者锁可能已消失，或者令牌可能无效。
Name: lock-token-submitted (precondition)
名称：已提交锁令牌（前提条件）
Use with: 423 Locked
使用时：423锁定
Purpose: The request could not succeed because a lock token should have been submitted. This element, if present, MUST contain at least one URL of a locked resource that prevented the request. In cases of MOVE, COPY, and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource made the request fail -- but the server is only responsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all.
目的：请求无法成功，因为应已提交锁令牌。此元素（如果存在）必须至少包含阻止请求的锁定资源的一个URL。在涉及集合锁的移动、复制和删除情况下，客户机可能很难找出导致请求失败的锁定资源，但服务器只负责返回一个这样的锁定资源。如果服务器知道所有阻止请求成功的锁定资源，则可能会返回这些资源。
<!ELEMENT lock-token-submitted (href+) >
<!ELEMENT lock-token-submitted (href+) >
Name: no-conflicting-lock (precondition)
名称：无冲突锁（前提条件）
Use with: Typically 423 Locked
用于：通常为423锁定
Purpose: A LOCK request failed due the presence of an already existing conflicting lock. Note that a lock can be in conflict although the resource to which the request was directed is only indirectly locked. In this case, the precondition code can be used to inform the client about the resource that is the root of the conflicting lock, avoiding a separate lookup of the "lockdiscovery" property.
目的：由于存在已存在的冲突锁，锁请求失败。请注意，虽然请求指向的资源仅被间接锁定，但锁定可能会发生冲突。在这种情况下，可以使用前提条件代码通知客户机冲突锁的根资源，从而避免单独查找“lockdiscovery”属性。
<!ELEMENT no-conflicting-lock (href)* >
<!ELEMENT no-conflicting-lock (href)* >
Name: no-external-entities
名称：无外部实体
Use with: 403 Forbidden
使用：403禁止
Purpose: (precondition) -- If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error.
目的：（前提条件）——如果服务器拒绝客户机请求，因为请求主体包含外部实体，则服务器应使用此错误。
Name: preserved-live-properties
名称：保留的活动属性
Use with: 409 Conflict
与：409冲突一起使用
Purpose: (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server
用途：（后置条件）--服务器收到了其他有效的移动或复制请求，但无法在目标上以相同的行为维护活动属性。可能是服务器
only supports some live properties in some parts of the repository, or simply has an internal error.
仅支持存储库某些部分中的某些活动属性，或者只是存在内部错误。
Name: propfind-finite-depth
名称：propfind有限深度
Use with: 403 Forbidden
使用：403禁止
Purpose: (precondition) -- This server does not allow infinite-depth PROPFIND requests on collections.
用途：（前提条件）--此服务器不允许对集合进行无限深度的PROPFIND请求。
Name: cannot-modify-protected-property
名称：无法修改受保护的属性
Use with: 403 Forbidden
使用：403禁止
Purpose: (precondition) -- The client attempted to set a protected property in a PROPPATCH (such as DAV:getetag). See also [RFC3253], Section 3.12.
用途：（前提条件）--客户端试图在PROPPATCH（如DAV:getetag）中设置受保护的属性。另见[RFC3253]，第3.12节。
The XML namespace extension ([REC-XML-NAMES]) is used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the "DAV:" namespace SHOULD NOT be used in the request or response body unless that XML element is explicitly defined in an IETF RFC reviewed by a WebDAV working group.
本规范中使用XML名称空间扩展（[REC-XML-NAMES]），以允许添加新的XML元素，而不必担心与其他元素名称冲突。尽管WebDAV请求和响应主体可以通过任意XML元素进行扩展，但消息接收者可以忽略这些元素，但请求或响应主体中不应使用“DAV:”命名空间中的XML元素，除非该XML元素在由WebDAV工作组审查的IETF RFC中明确定义。
For WebDAV to be both extensible and backwards-compatible, both clients and servers need to know how to behave when unexpected or unrecognized command extensions are received. For XML processing, this means that clients and servers MUST process received XML documents as if unexpected elements and attributes (and all children of unrecognized elements) were not there. An unexpected element or attribute includes one that may be used in another context but is not expected here. Ignoring such items for purposes of processing can of course be consistent with logging all information or presenting for debugging.
要使WebDAV既可扩展又向后兼容，客户端和服务器都需要知道在接收到意外或无法识别的命令扩展时如何操作。对于XML处理，这意味着客户端和服务器必须处理接收到的XML文档，就像不存在意外的元素和属性（以及未识别元素的所有子元素）一样。意外的元素或属性包括可在另一个上下文中使用但此处不应使用的元素或属性。为了处理的目的而忽略这些项目当然与记录所有信息或显示以进行调试是一致的。
This restriction also applies to the processing, by clients, of DAV property values where unexpected XML elements SHOULD be ignored unless the property's schema declares otherwise.
此限制还适用于客户端处理DAV属性值，除非属性的架构声明其他内容，否则应忽略意外的XML元素。
This restriction does not apply to setting dead DAV properties on the server where the server MUST record all XML elements.
此限制不适用于在服务器上设置死DAV属性，服务器必须记录所有XML元素。
Additionally, this restriction does not apply to the use of XML where XML happens to be the content type of the entity body, for example, when used as the body of a PUT.
此外，此限制不适用于XML的使用，其中XML恰好是实体主体的内容类型，例如，当用作PUT的主体时。
Processing instructions in XML SHOULD be ignored by recipients. Thus, specifications extending WebDAV SHOULD NOT use processing instructions to define normative behavior.
收件人应忽略XML中的处理说明。因此，扩展WebDAV的规范不应使用处理指令来定义规范行为。
XML DTD fragments are included for all the XML elements defined in this specification. However, correct XML will not be valid according to any DTD due to namespace usage and extension rules. In particular:
XML DTD片段包含在本规范中定义的所有XML元素中。但是，由于名称空间使用和扩展规则，根据任何DTD，正确的XML将无效。特别地：
o Elements (from this specification) are in the "DAV:" namespace,
o 元素（来自本规范）位于“DAV:”命名空间中，
o Element ordering is irrelevant unless otherwise stated,
o 除非另有说明，否则元素顺序无关，
o Extension attributes MAY be added,
o 可以添加扩展属性，
o For element type definitions of "ANY", the normative text definition for that element defines what can be in it and what that means.
o 对于“ANY”的元素类型定义，该元素的规范性文本定义定义了元素中可以包含的内容及其含义。
o For element type definitions of "#PCDATA", extension elements MUST NOT be added.
o 对于“#PCDATA”的元素类型定义，不能添加扩展元素。
o For other element type definitions, including "EMPTY", extension elements MAY be added.
o 对于其他元素类型定义，包括“EMPTY”，可以添加扩展元素。
Note that this means that elements containing elements cannot be extended to contain text, and vice versa.
注意，这意味着包含元素的元素不能扩展为包含文本，反之亦然。
With DTD validation relaxed by the rules above, the constraints described by the DTD fragments are normative (see for example Appendix A). A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD.
由于上述规则放宽了DTD验证，DTD片段描述的约束是规范性的（例如，参见附录A）。具有XML正文的WebDAV消息的收件人不得根据任何硬编码或动态声明的DTD验证XML文档。
Note that this section describes backwards-compatible extensibility rules. There might also be times when an extension is designed not to be backwards-compatible, for example, defining an extension that reuses an XML element defined in this document but omitting one of the child elements required by the DTDs in this specification.
请注意，本节介绍向后兼容的扩展性规则。有时扩展也可能被设计为不向后兼容，例如，定义一个扩展，该扩展重用本文档中定义的XML元素，但省略了本规范中DTD所需的一个子元素。
A DAV-compliant resource can advertise several classes of compliance. A client can discover the compliance classes of a resource by executing OPTIONS on the resource and examining the "DAV" header which is returned. Note particularly that resources, rather than servers, are spoken of as being compliant. That is because theoretically some resources on a server could support different feature sets. For example, a server could have a sub-repository where an advanced feature like versioning was supported, even if that feature was not supported on all sub-repositories.
符合DAV的资源可以公布多个类别的符合性。客户端可以通过对资源执行选项并检查返回的“DAV”头来发现资源的符合性类。请特别注意，资源（而不是服务器）被称为是兼容的。这是因为理论上，服务器上的某些资源可以支持不同的功能集。例如，服务器可以有一个子存储库，其中支持版本控制等高级功能，即使并非所有子存储库都支持该功能。
Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV-compliant resources, clients, and proxies MUST be compliant with [RFC2616].
由于本文档描述了HTTP/1.1协议的扩展，因此至少所有符合DAV的资源、客户端和代理都必须符合[RFC2616]。
A resource that is class 2 or class 3 compliant must also be class 1 compliant.
符合类别2或类别3的资源也必须符合类别1。
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document.
符合1级标准的资源必须满足本文件所有章节中的所有“必须”要求。
Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
符合类别1的资源必须至少在对OPTIONS方法的所有响应的DAV标头中返回值“1”。
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the DAV:supportedlock property, the DAV: lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class 2 compliant resource SHOULD also support the Timeout request header and the 'owner' XML element.
与class 2兼容的资源必须满足所有class 1要求，并支持锁方法、DAV:supportedlock属性、DAV:lockdiscovery属性、超时响应标头和锁令牌请求标头。与class 2兼容的资源还应支持超时请求标头和“owner”XML元素。
Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
与Class 2兼容的资源必须至少在对OPTIONS方法的所有响应上返回DAV头中的值“1”和“2”。
A resource can explicitly advertise its support for the revisions to [RFC2518] made in this document. Class 1 MUST be supported as well. Class 2 MAY be supported. Advertising class 3 support in addition to class 1 and 2 means that the server supports all the requirements in this specification. Advertising class 3 and class 1 support, but not class 2, means that the server supports all the requirements in this specification except possibly those that involve locking support.
资源可以明确宣传其对本文档中[RFC2518]修订的支持。类1也必须得到支持。可能支持第2类。除1级和2级支持外，广告3级支持意味着服务器支持本规范中的所有要求。广告3级和1级支持，而不是2级支持，意味着服务器支持本规范中的所有要求，但可能涉及锁定支持的要求除外。
Example:
例子：
DAV: 1, 3
DAV:1,3
In the realm of internationalization, this specification complies with the IETF Character Set Policy [RFC2277]. In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [RFC3629] and UTF-16 [RFC2781] encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header (defined in [RFC3023]), as well as XML charset declarations.
在国际化领域，本规范符合IETF字符集策略[RFC2277]。在本规范中，可以在属性的值或响应实体体中返回的错误消息中找到人类可读的字段。在这两种情况下，人类可读内容都使用XML编码，XML对字符集标记和编码有明确规定，并且要求XML处理器读取至少使用ISO 10646多语言平面的UTF-8[RFC3629]和UTF-16[RFC2781]编码的XML元素。本规范中的XML示例演示了内容类型头（在[RFC3023]中定义）的字符集参数以及XML字符集声明的使用。
XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. The "xml:lang" attribute appears on an XML element to identify the language of its content and attributes. See [REC-XML] for definitions of values and scoping.
XML还提供了语言标记功能，用于指定特定XML元素内容的语言。“xml:lang”属性出现在xml元素上，以标识其内容和属性的语言。有关值和范围的定义，请参见[REC-XML]。
WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" [RFC3023] for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header.
WebDAV应用程序必须支持XML规范的字符集标记、字符集编码和语言标记功能。强烈建议WebDAV应用程序的实现者阅读“XML媒体类型”[RFC3023]，了解用于XML传输的MIME媒体类型以及内容类型标头的字符集参数的使用说明。
Names used within this specification fall into four categories: names of protocol elements such as methods and headers, names of XML elements, names of properties, and names of conditions. Naming of protocol elements follows the precedent of HTTP, using English names encoded in US-ASCII for methods and headers. Since these protocol elements are not visible to users, and are simply long token identifiers, they do not need to support multiple languages. Similarly, the names of XML elements used in this specification are not visible to the user and hence do not need to support multiple languages.
本规范中使用的名称分为四类：协议元素（如方法和头）的名称、XML元素的名称、属性的名称和条件的名称。协议元素的命名遵循HTTP的先例，方法和头使用US-ASCII编码的英文名称。由于这些协议元素对用户不可见，并且只是长令牌标识符，因此它们不需要支持多种语言。类似地，本规范中使用的XML元素的名称对用户不可见，因此不需要支持多种语言。
WebDAV property names are qualified XML names (pairs of XML namespace name and local name). Although some applications (e.g., a generic property viewer) will display property names directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name and namespace to a human-readable field when displaying the property name
WebDAV属性名称是限定的XML名称（XML命名空间名称和本地名称对）。尽管某些应用程序（例如，通用属性查看器）将直接向其用户显示属性名称，但通常情况下，典型应用程序将使用一组固定的属性，并在显示属性名称时提供从属性名称和命名空间到人类可读字段的映射
to a user. It is only in the case where the set of properties is not known ahead of time that an application need display a property name to a user. We recommend that applications provide human-readable property names wherever feasible.
给用户。只有在属性集事先未知的情况下，应用程序才需要向用户显示属性名称。我们建议应用程序在可行的情况下提供人类可读的属性名称。
For error reporting, we follow the convention of HTTP/1.1 status codes, including with each status code a short, English description of the code (e.g., 423 (Locked)). While the possibility exists that a poorly crafted user agent would display this message to a user, internationalized applications will ignore this message, and display an appropriate message in the user's language and character set.
对于错误报告，我们遵循HTTP/1.1状态代码的约定，包括每个状态代码的简短英文描述（例如423（锁定））。尽管存在这样一种可能性，即一个设计拙劣的用户代理可能会向用户显示此消息，但国际化应用程序将忽略此消息，并以用户的语言和字符集显示适当的消息。
Since interoperation of clients and servers does not require locale information, this specification does not specify any mechanism for transmission of this information.
由于客户端和服务器的互操作不需要区域设置信息，因此本规范未指定任何传输此信息的机制。
This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware.
本节详细介绍了WebDAV应用程序需要注意的安全问题。
All of the security considerations of HTTP/1.1 (discussed in [RFC2616]) and XML (discussed in [RFC3023]) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.
HTTP/1.1（在[RFC2616]中讨论）和XML（在[RFC3023]中讨论）的所有安全注意事项也适用于WebDAV。此外，远程创作中固有的安全风险需要更强的身份验证技术，引入了一些新的隐私问题，并且可能会增加服务器设计不佳带来的危害。这些问题详述如下。
Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication.
由于WebDAV服务器强调创作，因此需要使用身份验证技术，不仅保护对网络资源的访问，还保护资源的完整性。此外，锁定功能的引入需要对身份验证的支持。
A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send a Basic authentication challenge in a WWW-Authenticate header unless the connection is secure. An example of a secure connection would be a Transport Layer Security (TLS) connection employing a strong cipher suite and server authentication.
通过不安全通道以明文形式发送的密码不足以保护资源的可访问性和完整性，因为密码可能被截获。除非使用基本的HTTP/text进行身份验证，否则必须使用基本的WEB/text进行身份验证。1才能进行基本的身份验证。此外，WebDAV服务器不得在WWW Authenticate标头中发送基本身份验证质询，除非连接是安全的。安全连接的一个示例是使用强密码套件和服务器身份验证的传输层安全（TLS）连接。
WebDAV applications MUST support the Digest authentication scheme [RFC2617]. Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication that is useful in a wide range of scenarios.
WebDAV应用程序必须支持摘要身份验证方案[RFC2617]。由于摘要身份验证验证通信双方都知道共享秘密、密码，而不必以明文形式发送该秘密，因此摘要身份验证避免了基本身份验证中固有的安全问题，同时提供了在广泛场景中有用的身份验证级别。
Denial-of-service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial-of-service attacks on every part of a system's resources.
拒绝服务攻击是WebDAV服务器特别关注的问题。WebDAV plus HTTP允许对系统资源的每个部分进行拒绝服务攻击。
o The underlying storage can be attacked by PUTting extremely large files.
o 通过放置非常大的文件，可以攻击底层存储。
o Asking for recursive operations on large collections can attack processing time.
o 要求对大型集合执行递归操作可能会影响处理时间。
o Making multiple pipelined requests on multiple connections can attack network connections.
o 在多个连接上发出多个流水线请求可能会攻击网络连接。
WebDAV servers need to be aware of the possibility of a denial-of-service attack at all levels. The proper response to such an attack MAY be to simply drop the connection. Or, if the server is able to make a response, the server MAY use a 400-level status request such as 400 (Bad Request) and indicate why the request was refused (a 500- level status response would indicate that the problem is with the server, whereas unintentional DoS attacks are something the client is capable of remedying).
WebDAV服务器需要了解所有级别的拒绝服务攻击的可能性。对这种攻击的正确反应可能是简单地断开连接。或者，如果服务器能够做出响应，服务器可以使用400级别的状态请求，例如400（错误请求），并指出请求被拒绝的原因（500级别的状态响应将表明问题出在服务器上，而无意的DoS攻击是客户端能够补救的）。
WebDAV provides, through the PROPFIND method, a mechanism for listing the member resources of a collection. This greatly diminishes the effectiveness of security or privacy techniques that rely only on the difficulty of discovering the names of network resources. Users of WebDAV servers are encouraged to use access control techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.
WebDAV通过PROPFIND方法提供了一种列出集合成员资源的机制。这大大降低了仅依赖于发现网络资源名称的难度的安全或隐私技术的有效性。鼓励WebDAV服务器的用户使用访问控制技术来防止对资源的不必要访问，而不是依赖于其资源名称的相对模糊性。
When submitting a lock request, a user agent may also submit an 'owner' XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a DAV: lockdiscovery property on the resource, and can be used by other
在提交锁请求时，用户代理还可以提交一个“所有者”XML字段，该字段提供了取锁人的联系信息（对于取锁人而不是机器人的情况）。此联系人信息存储在资源的DAV:lockdiscovery属性中，可供其他用户使用
collaborators to begin negotiation over access to the resource. However, in many cases, this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the DAV:lockdiscovery property as appropriate. Furthermore, user agents SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
合作者开始就资源访问进行协商。然而，在许多情况下，这种联系信息可能非常隐私，不应广泛传播。服务器应酌情限制对DAV:lockdiscovery属性的读取访问。此外，用户代理应该控制是否发送了联系信息，如果发送了联系信息，则控制发送的确切信息。
Since property values are typically used to hold information such as the author of a document, there is the possibility that privacy concerns could arise stemming from widespread access to a resource's property data. To reduce the risk of inadvertent release of private information via properties, servers are encouraged to develop access control mechanisms that separate read access to the resource body and read access to the resource's properties. This allows a user to control the dissemination of their property data without overly restricting access to the resource's contents.
由于属性值通常用于保存文档的作者等信息，因此对资源属性数据的广泛访问可能会引起隐私问题。为了降低通过属性意外释放私人信息的风险，鼓励服务器开发访问控制机制，将对资源主体的读取访问和对资源属性的读取访问分开。这允许用户控制其属性数据的传播，而不会过度限制对资源内容的访问。
XML supports a facility known as "external entities", defined in Section 4.2.2 of [REC-XML], which instructs an XML processor to retrieve and include additional XML. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non-validating XML, such as the XML used in this specification, including an external XML entity is not required by XML. However, XML does state that an XML processor may, at its discretion, include the external XML entity.
XML支持[REC-XML]第4.2.2节中定义的称为“外部实体”的功能，该功能指示XML处理器检索并包含其他XML。外部XML实体可用于附加或修改与XML文档关联的文档类型声明（DTD）。外部XML实体还可用于在XML文档的内容中包含XML。对于非验证性XML，例如本规范中使用的XML，XML不需要包含外部XML实体。但是，XML确实声明XML处理器可以自行决定是否包含外部XML实体。
External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case, significantly modifying its semantics or exposing the XML processor to the security risks discussed in [RFC3023]. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy. If a server chooses not to handle external XML entities, it SHOULD respond to requests containing external entities with the 'no-external-entities' condition code.
外部XML实体没有固有的可信度，并且会受到任何HTTP GET请求特有的所有攻击。此外，外部XML实体可能会修改DTD，从而影响XML文档的最终形式，在最坏的情况下，会显著修改其语义或使XML处理器面临[RFC3023]中讨论的安全风险。因此，实现者必须意识到外部XML实体应该被视为不可信的。若服务器选择不处理外部XML实体，则应使用“无外部实体”条件代码响应包含外部实体的请求。
There is also the scalability risk that would accompany a widely deployed application that made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any
使用外部XML实体的广泛部署的应用程序还存在可伸缩性风险。在这种情况下，对于一个外部XML实体可能会有大量的请求，这可能会使任何外部XML实体过载
server that fields requests for the resource containing the external XML entity.
为包含外部XML实体的资源输入请求的服务器。
Furthermore, there's also a risk based on the evaluation of "internal entities" as defined in Section 4.2.2 of [REC-XML]. A small, carefully crafted request using nested internal entities may require enormous amounts of memory and/or processing time to process. Server implementers should be aware of this risk and configure their XML parsers so that requests like these can be detected and rejected as early as possible.
此外，还存在基于[REC-XML]第4.2.2节中定义的“内部实体”评估的风险。使用嵌套内部实体精心编制的小请求可能需要大量内存和/或处理时间。服务器实现者应该意识到这一风险，并配置他们的XML解析器，以便尽早检测和拒绝此类请求。
This specification encourages the use of "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens (Section 6.5), in order to guarantee their uniqueness across space and time. Version 1 UUIDs (defined in Section 4) MAY contain a "node" field that "consists of an IEEE 802 MAC address, usually the host address. For systems with multiple IEEE addresses, any available one can be used". Since a WebDAV server will issue many locks over its lifetime, the implication is that it may also be publicly exposing its IEEE 802 address.
本规范鼓励对锁令牌（第6.5节）使用“通用唯一标识符（UUID）URN命名空间”（[RFC4122]），以保证它们在空间和时间上的唯一性。版本1 UUID（定义见第4节）可能包含“节点”字段，该字段“由IEEE 802 MAC地址组成，通常为主机地址。对于具有多个IEEE地址的系统，可以使用任何可用的地址”。由于WebDAV服务器将在其生命周期内发出许多锁，这意味着它也可能公开其IEEE 802地址。
There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:
暴露IEEE 802地址有几个风险。使用IEEE 802地址：
o It is possible to track the movement of hardware from subnet to subnet.
o 可以跟踪硬件在子网之间的移动。
o It may be possible to identify the manufacturer of the hardware running a WebDAV server.
o 可以确定运行WebDAV服务器的硬件制造商。
o It may be possible to determine the number of each type of computer running WebDAV.
o 可以确定运行WebDAV的每种类型计算机的数量。
This risk only applies to host-address-based UUID versions. Section 4 of [RFC4122] describes several other mechanisms for generating UUIDs that do not involve the host address and therefore do not suffer from this risk.
此风险仅适用于基于主机地址的UUID版本。[RFC4122]的第4节描述了生成UUID的几种其他机制，这些UUID不涉及主机地址，因此不存在这种风险。
HTTP has the ability to host programs that are executed on client machines. These programs can take many forms including Web scripts, executables, plug-in modules, and macros in documents. WebDAV does not change any of the security concerns around these programs, yet often WebDAV is used in contexts where a wide range of users can publish documents on a server. The server might not have a close
HTTP能够承载在客户机上执行的程序。这些程序可以采用多种形式，包括Web脚本、可执行文件、插件模块和文档中的宏。WebDAV并没有改变这些程序的任何安全问题，但WebDAV通常用于各种用户可以在服务器上发布文档的环境中。该服务器可能没有关闭密码
trust relationship with the author that is publishing the document. Servers that allow clients to publish arbitrary content can usefully implement precautions to check that content published to the server is not harmful to other clients. Servers could do this by techniques such as restricting the types of content that is allowed to be published and running virus and malware detection software on published content. Servers can also mitigate the risk by having appropriate access restriction and authentication of users that are allowed to publish content to the server.
与发布文档的作者的信任关系。允许客户端发布任意内容的服务器可以有效地实施预防措施，以检查发布到服务器的内容是否对其他客户端有害。服务器可以通过限制允许发布的内容类型以及在发布的内容上运行病毒和恶意软件检测软件等技术来做到这一点。服务器还可以通过对允许向服务器发布内容的用户进行适当的访问限制和身份验证来降低风险。
This specification defines two URI schemes:
本规范定义了两个URI方案：
1. the "opaquelocktoken" scheme defined in Appendix C, and
1. 附录C中定义的“opaquelocktoken”方案，以及
2. the "DAV" URI scheme, which historically was used in [RFC2518] to disambiguate WebDAV property and XML element names and which continues to be used for that purpose in this specification and others extending WebDAV. Creation of identifiers in the "DAV:" namespace is controlled by the IETF.
2. “DAV”URI方案，过去曾在[RFC2518]中用于消除WebDAV属性和XML元素名称的歧义，并在本规范和其他扩展WebDAV的规范中继续用于此目的。“DAV:”命名空间中标识符的创建由IETF控制。
Note that defining new URI schemes for XML namespaces is now discouraged. "DAV:" was defined before standard best practices emerged.
请注意，现在不鼓励为XML名称空间定义新的URI方案。“DAV:”是在标准最佳实践出现之前定义的。
XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names, or element names.
XML名称空间消除WebDAV属性名称和XML元素的歧义。任何WebDAV用户或应用程序都可以定义新的命名空间，以便创建自定义属性或扩展WebDAV XML语法。IANA不需要管理这样的名称空间、属性名称或元素名称。
The message header fields below should be added to the permanent registry (see [RFC3864]).
下面的消息头字段应添加到永久注册表中（请参见[RFC3864]）。
Header field name: DAV
标题字段名称：DAV
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 10.1)
规范文件：本规范（第10.1节）
Header field name: Depth
标题字段名称：深度
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 10.2)
规范文件：本规范（第10.2节）
Header field name: Destination
标题字段名称：目的地
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 10.3)
规范文件：本规范（第10.3节）
Header field name: If
标题字段名称：如果
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 10.4)
规范文件：本规范（第10.4节）
Header field name: Lock-Token
标题字段名称：锁定令牌
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 10.5)
规范文件：本规范（第10.5节）
Header field name: Overwrite
标题字段名称：覆盖
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 10.6)
规范文件：本规范（第10.6节）
Header field name: Timeout
标题字段名称：超时
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 10.7)
规范文件：本规范（第10.7节）
This specification defines the HTTP status codes
本规范定义了HTTP状态代码
o 207 Multi-Status (Section 11.1)
o 207多状态（第11.1节）
o 422 Unprocessable Entity (Section 11.2),
o 422不可加工实体（第11.2节），
o 423 Locked (Section 11.3),
o 423已锁定（第11.3节），
o 424 Failed Dependency (Section 11.4) and
o 424失败的依赖关系（第11.4节）和
o 507 Insufficient Storage (Section 11.5),
o 507贮存不足（第11.5节），
to be updated in the registry at <http://www.iana.org/assignments/http-status-codes>.
待在注册表中更新，网址为<http://www.iana.org/assignments/http-status-codes>.
Note: the HTTP status code 102 (Processing) has been removed in this specification; its IANA registration should continue to reference RFC 2518.
注意：HTTP状态代码102（处理）已在本规范中删除；其IANA注册应继续参考RFC 2518。
A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work.
这样的规范在尖锐的批评性评论中蓬勃发展，而在冷漠的忽视中枯萎。作者衷心感谢以下人员的贡献，他们的见解在我们工作的每个阶段都非常宝贵。
Contributors to RFC 2518
RFC2518的贡献者
Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
特里·艾伦、哈拉尔·阿尔维斯特兰、吉姆·阿姆斯登、贝基·安德森、艾伦·巴比奇、桑福德·巴尔、迪伦·巴雷尔、伯纳德·切斯特、蒂姆·伯纳斯·李、丹·康诺利、吉姆·坎宁安、罗恩·丹尼尔、吉姆·戴维斯、基思·道森、马克·戴、布赖恩·迪恩、马丁·杜尔斯、大卫·杜兰德、李·法雷尔、查克·费伊、韦斯利·费尔特、罗伊·菲尔丁、马克·费舍尔、艾伦·弗雷尔、，乔治·弗洛伦廷、吉姆·盖蒂、菲尔·哈拉姆·贝克、丹尼斯·汉密尔顿、史蒂夫·亨宁、米德·希梅尔斯坦、亚历克斯·霍普曼、安德烈·范德霍克、本·劳里、保罗·利奇、奥拉·拉西拉、卡伦·麦克阿瑟、史蒂文·马丁、拉里·马斯滕、迈克尔·米林、基思·摩尔、托马斯·纳腾、亨利克·尼尔森、大田健二、鲍勃·帕克、格伦·彼得森、乔恩·拉多夫、萨文·雷迪、，亨利·桑德斯、克里斯托弗·塞瓦尔德、朱迪思·斯莱因、迈克·斯普雷泽、埃纳·斯特夫鲁德、格雷格·斯坦、拉尔夫·斯威克、高桥健二、理查德·泰勒、罗伯特·索、约翰·特纳、桑卡尔·维德·格里斯瓦兰、法比奥·维塔利、格雷戈里·伍德豪斯和劳伦·伍德。
Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable; he both helped the formation of the working group and patiently coached the authors along the way. In so many ways he has set high standards that we have toiled to meet. The contributions of Judith Slein were also invaluable; by clarifying the requirements and in patiently reviewing version after version, she both improved this specification and expanded our minds on document management.
这个名单中有两个值得特别提及。拉里·马斯因特的贡献是无价的；他既帮助成立了工作组，也耐心地指导了作者。在许多方面，他制定了我们努力达到的高标准。朱迪思·斯莱因的贡献也是无价的；通过澄清需求和耐心地审查一个又一个版本，她不仅改进了该规范，还扩展了我们在文档管理方面的思路。
We would also like to thank John Turner for developing the XML DTD.
我们还要感谢John Turner开发XML DTD。
The authors of RFC 2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter, and D. Jensen. Although their names had to be removed due to IETF author count restrictions, they can take credit for the majority of the design of WebDAV.
RFC2518的作者是亚龙·格兰德、吉姆·怀特黑德、A.法兹、史蒂夫·卡特和D.詹森。尽管由于IETF的作者数量限制，他们的名字不得不被删除，但他们可以为WebDAV的大部分设计赢得荣誉。
Additional Acknowledgements for This Specification
对本规范的其他确认
Significant contributors of text for this specification are listed as contributors in the section below. We must also gratefully acknowledge Geoff Clemm, Joel Soderberg, and Dan Brotsky for hashing out specific text on the list or in meetings. Joe Hildebrand and Cullen Jennings helped close many issues. Barry Lind described an additional security consideration and Cullen Jennings provided text
本规范文本的重要贡献者在下面的部分中列为贡献者。我们还必须感谢杰夫·克莱姆（Geoff Clemm）、乔尔·索德伯格（Joel Soderberg）和丹·布罗茨基（Dan Brotsky）在名单上或会议上详细列出了具体文本。乔·希尔德布兰德和卡伦·詹宁斯帮助解决了许多问题。Barry Lind描述了额外的安全考虑，Cullen Jennings提供了文本
for that consideration. Jason Crawford tracked issue status for this document for a period of years, followed by Elias Sinderson.
出于这一考虑。Jason Crawford跟踪了本文件的问题状态达数年之久，Elias Sinderson紧随其后。
Julian Reschke <green/>bytes GmbH Hafenweg 16, 48155 Muenster, Germany EMail: julian.reschke@greenbytes.de
Julian Reschke<green/>bytes GmbH Hafenweg 1648155 Muenster，德国电子邮件：Julian。reschke@greenbytes.de
Elias Sinderson University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: elias@cse.ucsc.edu
埃利亚斯辛德森加利福尼亚大学，圣克鲁斯1156大街，圣克鲁斯，CA 95064电子邮件：elias@cse.ucsc.edu
Jim Whitehead University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: ejw@soe.ucsc.edu
吉姆怀特海加利福尼亚大学，圣克鲁斯1156大街，圣克鲁斯，CA 95064电子邮件：ejw@soe.ucsc.edu
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: yarong@microsoft.com
Y.Y.Goland Microsoft Corporation One Microsoft Way Redmond，WA 98052-6399电子邮件：yarong@microsoft.com
E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 EMail: ejw@ics.uci.edu
E. J. Whitehead，加利福尼亚大学信息与计算机科学系，欧文·欧文，CA92697－3525电子邮件：ejw@ics.uci.edu
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043 EMail: asad@netscape.com
A.加利福尼亚州东米德尔菲尔德路山景城Faizi Netscape 685号94043电子邮件：asad@netscape.com
S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: srcarter@novell.com
S.R.Carter Novell 1555 N.Technology Way M/S ORM F111 Orem，UT 84097-2399电子邮件：srcarter@novell.com
D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: dcjensen@novell.com
D.Jensen Novell 1555 N.Technology Way M/S ORM F111 Orem，UT 84097-2399电子邮件：dcjensen@novell.com
[REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816/>.
[REC-XML]Bray，T.，Paoli，J.，Sperberg McQueen，C.，Maler，E.，和F.Yergeau，“可扩展标记语言（XML）1.0（第四版）”，W3C REC-XML-20060816，2006年8月<http://www.w3.org/TR/2006/REC-xml-20060816/>.
[REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/ REC-xml-infoset-20040204/>.
[REC-XML-INFOSET]Cowan，J.和R.Tobin，“XML信息集（第二版）”，W3C REC-XML-INFOSET-200402042004年2月<http://www.w3.org/TR/2004/ REC-xml-infoset-20040204/>。
[REC-XML-NAMES] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", W3C REC-xml-names-20060816, August 2006, <http:// www.w3.org/TR/2006/REC-xml-names-20060816/>.
[REC-XML-NAMES]Bray，T.，Hollander，D.，Layman，A.，和R.Tobin，“XML 1.0中的名称空间（第二版）”，W3C REC-XML-NAMES-20060816，2006年8月，<http://www.w3.org/TR/2006/REC-XML-NAMES-20060816/>。
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[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月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]Klyne，G.，Ed.和C.Newman，“互联网上的日期和时间：时间戳”，RFC33392002年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[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月。
[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月。
[RFC2291] Slein, J., Vitali, F., Whitehead, E., and D. Durand, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web", RFC 2291, February 1998.
[RFC2291]Slein，J.，Vitali，F.，Whitehead，E.，和D.Durand，“万维网分布式创作和版本控制协议的要求”，RFC 2291，1998年2月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518]Goland，Y.，Whitehead，E.，Faizi，A.，Carter，S.，和D.Jensen，“分布式创作的HTTP扩展——WEBDAV”，RFC25181999年2月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781]Hoffman，P.和F.Yergeau，“UTF-16，ISO 10646编码”，RFC 2781，2000年2月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[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月。
[RFC3648] Whitehead, J. and J. Reschke, Ed., "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol", RFC 3648, December 2003.
[RFC3648]Whitehead，J.和J.Reschke，Ed.，“Web分布式创作和版本控制（WebDAV）有序收集协议”，RFC 3648，2003年12月。
[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月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form <A></A>. The second is to declare an XML element of the form <A/>. The two XML elements are semantically identical.
XML支持两种机制来指示XML元素没有任何内容。第一个是声明格式为<A></A>的XML元素。第二个是声明形式为<A/>的XML元素。这两个XML元素在语义上是相同的。
XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of whitespace, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements.
XML是一种灵活的数据格式，可以轻松提交看似合法但实际上不合法的数据。“接受时要灵活，发送时要严格”的理念仍然适用，但不能不恰当地应用。XML在处理空白、元素排序、插入新元素等问题时非常灵活。这种灵活性不需要扩展，尤其是在元素的含义方面。
There is no kindness in accepting illegal combinations of XML elements. At best, it will cause an unwanted result and at worst it can cause real damage.
接受XML元素的非法组合没有好处。在最好的情况下，它会导致一个不想要的结果，在最坏的情况下，它会造成真正的损害。
The following request body for a PROPFIND method is illegal.
PROPFIND方法的以下请求正文是非法的。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:propname/>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:propname/>
</D:propfind>
The definition of the propfind element only allows for the allprop or the propname element, not both. Thus, the above is an error and must be responded to with a 400 (Bad Request).
propfind元素的定义只允许allprop或propname元素，而不是两者。因此，以上是一个错误，必须用400（错误请求）响应。
Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop.
然而，想象一下，一个服务器想要变得“善良”，并决定选择allprop元素作为真正的元素并响应它。如果服务器将该命令视为allprop，则在带宽有限的线路上运行的客户机（打算执行propname）将大吃一惊。
Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
此外，如果服务器很宽容并决定答复此请求，则结果会随服务器的不同而随机变化，一些服务器执行allprop指令，而另一些服务器执行propname指令。这降低了互操作性，而不是增加互操作性。
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
前面的示例是非法的，因为它包含两个元素，这两个元素被明确禁止同时出现在propfind元素中。然而，XML是一种可扩展语言，因此可以想象定义新元素以与propfind一起使用。下面是PROPFIND的请求主体，与上一个示例一样，不理解过期props元素的服务器必须以400（错误请求）拒绝该请求。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
<E:expired-props/>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
<E:expired-props/>
</D:propfind>
To understand why a 400 (Bad Request) is returned, let us look at the request body as the server unfamiliar with expired-props sees it.
为了理解返回400（错误请求）的原因，让我们看看不熟悉过期道具的服务器看到的请求主体。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
</D:propfind>
As the server does not understand the 'expired-props' element, according to the WebDAV-specific XML processing rules specified in Section 17, it must process the request as if the element were not there. Thus, the server sees an empty propfind, which by the definition of the propfind element is illegal.
由于服务器不理解“expired props”元素，根据第17节中指定的WebDAV特定XML处理规则，它必须像处理元素不存在一样处理请求。因此，服务器会看到一个空的propfind，根据propfind元素的定义，它是非法的。
Please note that had the extension been additive, it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
请注意，如果扩展是附加的，则不一定会导致400（错误请求）。例如，假设PROPFIND的以下请求主体：
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
<D:propname/>
<E:leave-out>*boss*</E:leave-out>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
<D:propname/>
<E:leave-out>*boss*</E:leave-out>
</D:propfind>
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with 'leave-out', the only result would be that the 'leave-out' element would be ignored and a propname would be executed.
上一个示例包含虚构的遗漏元素。其目的是防止返回名称与提交的模式匹配的任何属性。如果将前面的示例提交给不熟悉“lookout”的服务器，那么唯一的结果就是忽略“lookout”元素，并执行propname。
WebDAV was designed to be, and has been found to be, backward-compatible with HTTP 1.1. The PUT and DELETE methods are defined in HTTP and thus may be used by HTTP clients as well as WebDAV-aware clients, but the responses to PUT and DELETE have been extended in this specification in ways that only a WebDAV client would be entirely prepared for. Some theoretical concerns were raised about whether those responses would cause interoperability problems with HTTP-only clients, and this section addresses those concerns.
WebDAV被设计为并且已经被发现与HTTP 1.1向后兼容。PUT和DELETE方法在HTTP中定义，因此可以由HTTP客户端以及WebDAV感知客户端使用，但是在本规范中对PUT和DELETE的响应进行了扩展，只有WebDAV客户端才能完全准备好。对于这些响应是否会导致仅HTTP客户端的互操作性问题，提出了一些理论上的担忧，本节讨论了这些担忧。
Since any HTTP client ought to handle unrecognized 400-level and 500- level status codes as errors, the following new status codes should not present any issues: 422, 423, and 507 (424 is also a new status code but it appears only in the body of a Multistatus response.) So, for example, if an HTTP client attempted to PUT or DELETE a locked resource, the 423 Locked response ought to result in a generic error presented to the user.
由于任何HTTP客户机都应该将无法识别的400级和500级状态代码作为错误处理，因此以下新状态代码不应出现任何问题：422、423和507（424也是一个新状态代码，但它仅出现在Multistatus响应的主体中），如果HTTP客户端试图放置或删除锁定的资源，423锁定响应应该会导致向用户显示一个一般错误。
The 207 Multistatus response is interesting because an HTTP client issuing a DELETE request to a collection might interpret a 207 response as a success, even though it does not realize the resource is a collection and cannot understand that the DELETE operation might have been a complete or partial failure. That interpretation isn't entirely justified, because a 200-level response indicates that the server "received, understood, and accepted" the request, not that the request resulted in complete success.
207 Multistatus响应很有趣，因为向集合发出删除请求的HTTP客户端可能会将207响应解释为成功，即使它没有意识到资源是集合，也无法理解删除操作可能是完全或部分失败。这种解释并不完全合理，因为200级响应表明服务器“接收、理解并接受”了请求，而不是请求导致了完全成功。
One option is that a server could treat a DELETE of a collection as an atomic operation, and use either 204 No Content in case of success, or some appropriate error response (400 or 500 level) for an error. This approach would indeed maximize backward compatibility. However, since interoperability tests and working group discussions have not turned up any instances of HTTP clients issuing a DELETE request against a WebDAV collection, this concern is more theoretical than practical. Thus, servers are likely to be completely successful at interoperating with HTTP clients even if they treat any collection DELETE request as a WebDAV request and send a 207 Multi-Status response.
一种选择是，服务器可以将集合的删除视为原子操作，并在成功的情况下使用204 No内容，或者对错误使用某种适当的错误响应（400或500级别）。这种方法确实可以最大限度地提高向后兼容性。然而，由于互操作性测试和工作组讨论没有发现HTTP客户端对WebDAV集合发出删除请求的任何实例，因此这种担心更多的是理论上的，而不是实际的。因此，即使服务器将任何集合删除请求视为WebDAV请求并发送207多状态响应，它们也可能完全成功地与HTTP客户端进行互操作。
In general, server implementations are encouraged to use the detailed responses and other mechanisms defined in this document rather than make changes for theoretical interoperability concerns.
通常，鼓励服务器实现使用本文档中定义的详细响应和其他机制，而不是对理论上的互操作性问题进行更改。
The 'opaquelocktoken' URI scheme was defined in [RFC2518] (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time.
[RFC2518]中定义了“opaquelocktoken”URI方案（并由IANA注册），以便从UUID中创建语法正确且易于生成的URI，用作锁令牌，并且在所有资源中始终是唯一的。
An opaquelocktoken URI is constructed by concatenating the 'opaquelocktoken' scheme with a UUID, along with an optional extension. Servers can create new UUIDs for each new lock token. If a server wishes to reuse UUIDs, the server MUST add an extension, and the algorithm generating the extension MUST guarantee that the same extension will never be used twice with the associated UUID.
opaquelocktoken URI是通过将“opaquelocktoken”方案与UUID以及可选扩展连接而构建的。服务器可以为每个新的锁令牌创建新的UUID。如果服务器希望重用UUID，则服务器必须添加扩展，生成扩展的算法必须保证同一扩展永远不会与关联的UUID一起使用两次。
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
; UUID is defined in Section 3 of [RFC4122]. Note that LWS
; is not allowed between elements of
; this production.
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
; UUID is defined in Section 3 of [RFC4122]. Note that LWS
; is not allowed between elements of
; this production.
Extension = path ; path is defined in Section 3.3 of [RFC3986]
扩展=路径；路径在[RFC3986]第3.3节中定义
The original WebDAV model for locking unmapped URLs created "lock-null resources". This model was over-complicated and some interoperability and implementation problems were discovered. The new WebDAV model for locking unmapped URLs (see Section 7.3) creates "locked empty resources". Lock-null resources are deprecated. This section discusses the original model briefly because clients MUST be able to handle either model.
用于锁定未映射URL的原始WebDAV模型创建了“锁定空资源”。该模型过于复杂，发现了一些互操作性和实现问题。用于锁定未映射URL的新WebDAV模型（参见第7.3节）创建“锁定的空资源”。不推荐使用锁定空资源。本节简要讨论原始模型，因为客户端必须能够处理任一模型。
In the original "lock-null resource" model, which is no longer recommended for implementation:
在最初的“lock null resource”模型中，不再建议执行该模型：
o A lock-null resource sometimes appeared as "Not Found". The server responds with a 404 or 405 to any method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
o 锁空资源有时显示为“未找到”。服务器以404或405响应除PUT、MKCOL、OPTIONS、PROPFIND、LOCK、UNLOCK之外的任何方法。
o A lock-null resource does however show up as a member of its parent collection.
o 但是，锁空资源确实显示为其父集合的成员。
o The server removes the lock-null resource entirely (its URI becomes unmapped) if its lock goes away before it is converted to a regular resource. Recall that locks go away not only when they expire or are unlocked, but are also removed if a resource is renamed or moved, or if any parent collection is renamed or moved.
o 如果锁在转换为常规资源之前消失，服务器将完全删除锁空资源（其URI将变为未映射）。回想一下，锁不仅在过期或解锁时消失，而且在重命名或移动资源或重命名或移动任何父集合时也会被删除。
o The server converts the lock-null resource into a regular resource if a PUT request to the URL is successful.
o 如果对URL的PUT请求成功，服务器会将lock null资源转换为常规资源。
o The server converts the lock-null resource into a collection if a MKCOL request to the URL is successful (though interoperability experience showed that not all servers followed this requirement).
o 如果对URL的MKCOL请求成功，则服务器将lock null资源转换为集合（尽管互操作性经验表明并非所有服务器都遵循此要求）。
o Property values were defined for DAV:lockdiscovery and DAV: supportedlock properties but not necessarily for other properties like DAV:getcontenttype.
o 为DAV:lockdiscovery和DAV:supportedlock属性定义了属性值，但不一定为其他属性（如DAV:getcontenttype）定义了属性值。
Clients can easily interoperate both with servers that support the old model "lock-null resources" and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET.
客户机可以轻松地与支持旧模式“锁定空资源”和推荐模式“锁定空资源”的服务器进行互操作，只需尝试在锁定未映射URL后放置，而不是MKCOL或GET。
A WebDAV client implemented to this specification might find servers that create lock-null resources (implemented before this specification using [RFC2518]) as well as servers that create locked empty resources. The response to the LOCK request will not indicate what kind of resource was created. There are a few techniques that help the client deal with either type.
根据本规范实现的WebDAV客户端可能会找到创建锁定空资源的服务器（在本规范之前使用[RFC2518]实现）以及创建锁定空资源的服务器。对锁请求的响应不会指示创建了哪种资源。有一些技术可以帮助客户机处理这两种类型。
If the client wishes to avoid accidentally creating either lock-null or empty locked resources, an "If-Match: *" header can be included with LOCK requests to prevent the server from creating a new resource.
如果客户端希望避免意外地创建锁null或空的锁定资源，则可以在锁请求中包含“If Match:*”标头，以防止服务器创建新资源。
If a LOCK request creates a resource and the client subsequently wants to overwrite that resource using a COPY or MOVE request, the client should include an "Overwrite: T" header.
如果锁定请求创建了一个资源，并且客户端随后希望使用复制或移动请求覆盖该资源，那么客户端应该包含一个“overwrite:T”头。
If a LOCK request creates a resource and the client then decides to get rid of that resource, a DELETE request is supposed to fail on a lock-null resource and UNLOCK should be used instead. But with a locked empty resource, UNLOCK doesn't make the resource disappear. Therefore, the client might have to try both requests and ignore an error in one of the two requests.
如果锁请求创建了一个资源，然后客户机决定删除该资源，则删除请求应该在锁空资源上失败，而应该使用UNLOCK。但对于锁定的空资源，解锁不会使资源消失。因此，客户端可能必须尝试这两个请求，并忽略其中一个请求中的错误。
Many WebDAV clients that have already been implemented have account settings (similar to the way email clients store IMAP account settings). Thus, the WebDAV client would be able to authenticate with its first couple requests to the server, provided it had a way to get the authentication challenge from the server with realm name,
许多已经实现的WebDAV客户端都有帐户设置（类似于电子邮件客户端存储IMAP帐户设置的方式）。因此，WebDAV客户端将能够通过其向服务器发出的第一对请求进行身份验证，前提是它有办法从具有领域名称的服务器获取身份验证质询，
nonce, and other challenge information. Note that the results of some requests might vary according to whether or not the client is authenticated -- a PROPFIND might return more visible resources if the client is authenticated, yet not fail if the client is anonymous.
nonce和其他质询信息。请注意，某些请求的结果可能会因客户机是否经过身份验证而有所不同——如果客户机经过身份验证，PROPFIND可能会返回更多可见的资源，但如果客户机是匿名的，则不会失败。
There are a number of ways the client might be able to trigger the server to provide an authentication challenge. This appendix describes a couple approaches that seem particularly likely to work.
客户端可以通过多种方式触发服务器以提供身份验证质询。本附录描述了两种似乎特别可行的方法。
The first approach is to perform a request that ought to require authentication. However, it's possible that a server might handle any request even without authentication, so to be entirely safe, the client could add a conditional header to ensure that even if the request passes permissions checks, it's not actually handled by the server. An example of following this approach would be to use a PUT request with an "If-Match" header with a made-up ETag value. This approach might fail to result in an authentication challenge if the server does not test authorization before testing conditionals as is required (see Section 8.5), or if the server does not need to test authorization.
第一种方法是执行应该需要身份验证的请求。但是，即使没有身份验证，服务器也可能处理任何请求，因此为了完全安全，客户端可以添加一个条件头，以确保即使请求通过权限检查，服务器也不会实际处理该请求。采用这种方法的一个例子是使用一个PUT请求，该请求带有一个带有虚构ETag值的“If Match”头。如果服务器未按要求在测试条件之前测试授权（请参阅第8.5节），或者如果服务器不需要测试授权，则此方法可能无法导致身份验证质询。
Example - forcing auth challenge with write request
示例-使用写入请求强制验证质询
>>Request
>>请求
PUT /forceauth.txt HTTP/1.1
Host: www.example.com
If-Match: "xxx"
Content-Type: text/plain
Content-Length: 0
PUT /forceauth.txt HTTP/1.1
Host: www.example.com
If-Match: "xxx"
Content-Type: text/plain
Content-Length: 0
The second approach is to use an Authorization header (defined in [RFC2617]), which is likely to be rejected by the server but which will then prompt a proper authentication challenge. For example, the client could start with a PROPFIND request containing an Authorization header containing a made-up Basic userid:password string or with actual plausible credentials. This approach relies on the server responding with a "401 Unauthorized" along with a challenge if it receives an Authorization header with an unrecognized username, invalid password, or if it doesn't even handle Basic authentication. This seems likely to work because of the requirements of RFC 2617:
第二种方法是使用授权标头（在[RFC2617]中定义），该标头可能会被服务器拒绝，但随后将提示正确的身份验证质询。例如，客户端可以从包含授权头的PROPFIND请求开始，该授权头包含一个虚构的基本userid:password字符串，或者使用实际的可信凭证。这种方法依赖于服务器以“401 Unauthorized”响应，如果它接收到带有无法识别的用户名、无效密码的授权头，或者如果它甚至不处理基本身份验证，则会发出质询。由于RFC 2617的要求，这似乎可行：
"If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource."
如果源服务器不希望接受随请求一起发送的凭据，则应返回401（未经授权）响应。该响应必须包括WWW Authenticate标头字段，其中至少包含一个适用于请求的资源的（可能是新的）质询
There's a slight problem with implementing that recommendation in some cases, because some servers do not even have challenge information for certain resources. Thus, when there's no way to authenticate to a resource or the resource is entirely publicly available over all accepted methods, the server MAY ignore the Authorization header, and the client will presumably try again later.
在某些情况下，实现该建议会有一个小问题，因为有些服务器甚至没有针对某些资源的质询信息。因此，当无法对资源进行身份验证或资源在所有可接受的方法上完全公开时，服务器可能会忽略授权头，客户端可能会稍后重试。
Example - forcing auth challenge with Authorization header
示例-使用授权标头强制验证质询
>>Request
>>请求
PROPFIND /docs/ HTTP/1.1
Host: www.example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
PROPFIND /docs/ HTTP/1.1
Host: www.example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
[body omitted]
[正文省略]
This section lists major changes between this document and RFC 2518, starting with those that are likely to result in implementation changes. Servers will advertise support for all changes in this specification by returning the compliance class "3" in the DAV response header (see Sections 10.1 and 18.3).
本节列出了本文件与RFC 2518之间的主要变更，首先是可能导致实施变更的变更。服务器将通过在DAV响应头中返回符合性类别“3”来公布对本规范中所有更改的支持（参见第10.1节和第18.3节）。
Collections and Namespace Operations
集合和命名空间操作
o The semantics of PROPFIND 'allprop' (Section 9.1) have been relaxed so that servers return results including, at a minimum, the live properties defined in this specification, but not necessarily return other live properties. The 'allprop' directive therefore means something more like "return all properties that are supposed to be returned when 'allprop' is requested" -- a set of properties that may include custom properties and properties defined in other specifications if those other specifications so require. Related to this, 'allprop' requests can now be extended with the 'include' syntax to include specific named properties,
o PROPFIND“allprop”（第9.1节）的语义已经放宽，以便服务器返回结果，至少包括本规范中定义的活动属性，但不一定返回其他活动属性。因此，“allprop”指令的意思更像是“返回请求“allprop”时应返回的所有属性”——一组属性，如果其他规范要求，这些属性可能包括自定义属性和其他规范中定义的属性。与此相关，“allprop”请求现在可以使用“include”语法进行扩展，以包括特定的命名属性，
thereby avoiding additional requests due to changed 'allprop' semantics.
从而避免了由于“allprop”语义更改而产生的额外请求。
o Servers are now allowed to reject PROPFIND requests with Depth: Infinity. Clients that used this will need to be able to do a series of Depth:1 requests instead.
o 服务器现在可以拒绝深度为无限的PROPFIND请求。使用此功能的客户端需要能够执行一系列深度：1请求。
o Multi-Status response bodies now can transport the value of HTTP's Location response header in the new 'location' element. Clients may use this to avoid additional roundtrips to the server when there is a 'response' element with a 3xx status (see Section 14.24).
o 多状态响应主体现在可以在新的“Location”元素中传输HTTP的位置响应头的值。当存在3xx状态的“响应”元素时，客户端可以使用此选项来避免额外的服务器往返（参见第14.24节）。
o The definition of COPY has been relaxed so that it doesn't require servers to first delete the target resources anymore (this was a known incompatibility with [RFC3253]). See Section 9.8.
o 复制的定义已经放宽，因此不再需要服务器先删除目标资源（这是已知的与[RFC3253]不兼容）。见第9.8节。
Headers and Marshalling
标题和编组
o The Destination and If request headers now allow absolute paths in addition to full URIs (see Section 8.3). This may be useful for clients operating through a reverse proxy that does rewrite the Host request header, but not WebDAV-specific headers.
o 除了完整URI之外，目标和If请求头现在还允许绝对路径（参见第8.3节）。这对于通过反向代理进行操作的客户机可能很有用，反向代理会重写主机请求头，但不会重写特定于WebDAV的头。
o This specification adopts the error marshalling extensions and the "precondition/postcondition" terminology defined in [RFC3253] (see Section 16). Related to that, it adds the "error" XML element inside multistatus response bodies (see Section 14.5, however note that it uses a format different from the one recommended in RFC 3253).
o 本规范采用[RFC3253]中定义的错误编组扩展和“前置/后置条件”术语（见第16节）。与此相关，它在multistatus响应主体中添加了“error”XML元素（请参见第14.5节，但请注意，它使用的格式与RFC 3253中建议的格式不同）。
o Senders and recipients are now required to support the UTF-16 character encoding in XML message bodies (see Section 19).
o 现在要求发送方和接收方在XML消息体中支持UTF-16字符编码（请参阅第19节）。
o Clients are now required to send the Depth header on PROPFIND requests, although servers are still encouraged to support clients that don't.
o 现在要求客户端在PROPFIND请求上发送深度头，尽管仍然鼓励服务器支持不支持深度头的客户端。
Locking
锁定
o RFC 2518's concept of "lock-null resources" (LNRs) has been replaced by a simplified approach, the "locked empty resources" (see Section 7.3). There are some aspects of lock-null resources clients cannot rely on anymore, namely, the ability to use them to create a locked collection or the fact that they disappear upon UNLOCK when no PUT or MKCOL request was issued. Note that servers are still allowed to implement LNRs as per RFC 2518.
o RFC 2518的“锁定空资源”（LNR）概念已被简化方法“锁定空资源”（见第7.3节）取代。锁定空资源的某些方面客户端不能再依赖，即使用它们创建锁定集合的能力，或者在未发出PUT或MKCOL请求时，它们在解锁时消失的事实。注意，根据RFC 2518，仍然允许服务器实现LNR。
o There is no implicit refresh of locks anymore. Locks are only refreshed upon explicit request (see Section 9.10.2).
o 不再有锁的隐式刷新。只有在明确请求时才会刷新锁（见第9.10.2节）。
o Clarified that the DAV:owner value supplied in the LOCK request must be preserved by the server just like a dead property (Section 14.17). Also added the DAV:lockroot element (Section 14.12), which allows clients to discover the root of lock.
o 阐明了锁请求中提供的DAV:owner值必须像死属性一样由服务器保留（第14.17节）。还添加了DAV:lockroot元素（第14.12节），它允许客户端发现锁的根。
Collections and Namespace Operations
集合和命名空间操作
o Due to interoperability problems, allowable formats for contents of 'href' elements in multistatus responses have been limited (see Section 8.3).
o 由于互操作性问题，multistatus响应中允许的“href”元素内容格式受到限制（见第8.3节）。
o Due to lack of implementation, support for the 'propertybehavior' request body for COPY and MOVE has been removed. Instead, requirements for property preservation have been clarified (see Sections 9.8 and 9.9).
o 由于缺少实现，已删除对复制和移动的“propertybehavior”请求主体的支持。相反，已明确了财产保全的要求（见第9.8节和第9.9节）。
Properties
性质
o Strengthened server requirements for storage of property values, in particular persistence of language information (xml:lang), whitespace, and XML namespace information (see Section 4.3).
o 增强了存储属性值的服务器要求，特别是语言信息（xml:lang）、空白和xml命名空间信息的持久性（参见第4.3节）。
o Clarified requirements on which properties should be writable by the client; in particular, setting "DAV:displayname" should be supported by servers (see Section 15).
o 明确客户应书写哪些财产的要求；特别是，服务器应支持设置“DAV:displayname”（参见第15节）。
o Only 'rfc1123-date' productions are legal as values for DAV: getlastmodified (see Section 15.7).
o 只有“rfc1123日期”产品作为DAV:getlastmodified的值是合法的（见第15.7节）。
Headers and Marshalling
标题和编组
o Servers are now required to do authorization checks before processing conditional headers (see Section 8.5).
o 现在要求服务器在处理条件标头之前进行授权检查（参见第8.5节）。
Locking
锁定
o Strengthened requirement to check identity of lock creator when accessing locked resources (see Section 6.4). Clients should be aware that lock tokens returned to other principals can only be used to break a lock, if at all.
o 加强了访问锁定资源时检查锁创建者身份的要求（参见第6.4节）。客户端应该知道，返回给其他主体的锁令牌只能用于断开锁（如果有的话）。
o Section 8.10.4 of [RFC2518] incorrectly required servers to return a 409 status where a 207 status was really appropriate. This has been corrected (Section 9.10).
o [RFC2518]的第8.10.4节错误地要求服务器返回409状态，而207状态才是真正合适的。这一点已得到纠正（第9.10节）。
The definition of collection state has been fixed so it doesn't vary anymore depending on the Request-URI (see Section 5.2).
集合状态的定义已被修复，因此不再因请求URI的不同而有所不同（请参见第5.2节）。
The DAV:source property introduced in Section 4.6 of [RFC2518] was removed due to lack of implementation experience.
[RFC2518]第4.6节中引入的DAV:source属性由于缺乏实施经验而被删除。
The DAV header now allows non-IETF extensions through URIs in addition to compliance class tokens. It also can now be used in requests, although this specification does not define any associated semantics for the compliance classes defined in here (see Section 10.1).
DAV头现在允许通过URI以及合规类令牌进行非IETF扩展。它现在也可以在请求中使用，尽管本规范没有为此处定义的符合性类定义任何相关语义（参见第10.1节）。
In RFC 2518, the definition of the Depth header (Section 9.2) required that, by default, request headers would be applied to each resource in scope. Based on implementation experience, the default has now been reversed (see Section 10.2).
在RFC2518中，深度头的定义（第9.2节）要求，默认情况下，请求头将应用于范围中的每个资源。根据实施经验，默认值现已被撤销（见第10.2节）。
The definitions of HTTP status code 102 ([RFC2518], Section 10.1) and the Status-URI response header (Section 9.7) have been removed due to lack of implementation.
由于缺乏实现，HTTP状态代码102（[RFC2518]，第10.1节）和状态URI响应头（第9.7节）的定义已被删除。
The TimeType format used in the Timeout request header and the "timeout" XML element used to be extensible. Now, only the two formats defined by this specification are allowed (see Section 10.7).
Timeout请求头中使用的TimeType格式和“Timeout”XML元素过去是可扩展的。现在，只允许使用本规范定义的两种格式（见第10.7节）。
Author's Address
作者地址
Lisa Dusseault (editor) CommerceNet 2064 Edgewood Dr. Palo Alto, CA 94303 US
Lisa Dusseault（编辑）CommerceNet 2064 Edgewood Dr.Palo Alto，加利福尼亚州美国94303
EMail: ldusseault@commerce.net
EMail: ldusseault@commerce.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。