Network Working Group Y. Goland
Request for Comments: 2518 Microsoft
Category: Standards Track E. Whitehead
UC Irvine
A. Faizi
Netscape
S. Carter
Novell
D. Jensen
Novell
February 1999
Network Working Group Y. Goland
Request for Comments: 2518 Microsoft
Category: Standards Track E. Whitehead
UC Irvine
A. Faizi
Netscape
S. Carter
Novell
D. Jensen
Novell
February 1999
HTTP Extensions for Distributed Authoring -- WEBDAV
分布式创作的HTTP扩展——WEBDAV
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 Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document specifies 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, namespace manipulation, and resource locking (collision avoidance).
本文档指定了一组辅助于HTTP/1.1的方法、头和内容类型，用于管理资源属性、创建和管理资源集合、命名空间操作和资源锁定（避免冲突）。
Table of Contents
目录
ABSTRACT............................................................1
1 INTRODUCTION .....................................................5
2 NOTATIONAL CONVENTIONS ...........................................7
3 TERMINOLOGY ......................................................7
4 DATA MODEL FOR RESOURCE PROPERTIES ...............................8
4.1 The Resource Property Model ...................................8
4.2 Existing Metadata Proposals ...................................8
4.3 Properties and HTTP Headers ...................................9
4.4 Property Values ...............................................9
4.5 Property Names ...............................................10
4.6 Media Independent Links ......................................10
5 COLLECTIONS OF WEB RESOURCES ....................................11
ABSTRACT............................................................1
1 INTRODUCTION .....................................................5
2 NOTATIONAL CONVENTIONS ...........................................7
3 TERMINOLOGY ......................................................7
4 DATA MODEL FOR RESOURCE PROPERTIES ...............................8
4.1 The Resource Property Model ...................................8
4.2 Existing Metadata Proposals ...................................8
4.3 Properties and HTTP Headers ...................................9
4.4 Property Values ...............................................9
4.5 Property Names ...............................................10
4.6 Media Independent Links ......................................10
5 COLLECTIONS OF WEB RESOURCES ....................................11
5.1 HTTP URL Namespace Model .....................................11
5.2 Collection Resources .........................................11
5.3 Creation and Retrieval of Collection Resources ...............12
5.4 Source Resources and Output Resources ........................13
6 LOCKING .........................................................14
6.1 Exclusive Vs. Shared Locks ...................................14
6.2 Required Support .............................................16
6.3 Lock Tokens ..................................................16
6.4 opaquelocktoken Lock Token URI Scheme ........................16
6.4.1 Node Field Generation Without the IEEE 802 Address ........17
6.5 Lock Capability Discovery ....................................19
6.6 Active Lock Discovery ........................................19
6.7 Usage Considerations .........................................19
7 WRITE LOCK ......................................................20
7.1 Methods Restricted by Write Locks ............................20
7.2 Write Locks and Lock Tokens ..................................20
7.3 Write Locks and Properties ...................................20
7.4 Write Locks and Null Resources ...............................21
7.5 Write Locks and Collections ..................................21
7.6 Write Locks and the If Request Header ........................22
7.6.1 Example - Write Lock ......................................22
7.7 Write Locks and COPY/MOVE ....................................23
7.8 Refreshing Write Locks .......................................23
8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
8.1 PROPFIND .....................................................24
8.1.1 Example - Retrieving Named Properties .....................25
8.1.2 Example - Using allprop to Retrieve All Properties ........26
8.1.3 Example - Using propname to Retrieve all Property Names ...29
8.2 PROPPATCH ....................................................31
8.2.1 Status Codes for use with 207 (Multi-Status) ..............31
8.2.2 Example - PROPPATCH .......................................32
8.3 MKCOL Method .................................................33
8.3.1 Request ...................................................33
8.3.2 Status Codes ..............................................33
8.3.3 Example - MKCOL ...........................................34
8.4 GET, HEAD for Collections ....................................34
8.5 POST for Collections .........................................35
8.6 DELETE .......................................................35
8.6.1 DELETE for Non-Collection Resources .......................35
8.6.2 DELETE for Collections ....................................36
8.7 PUT ..........................................................36
8.7.1 PUT for Non-Collection Resources ..........................36
8.7.2 PUT for Collections .......................................37
8.8 COPY Method ..................................................37
8.8.1 COPY for HTTP/1.1 resources ...............................37
8.8.2 COPY for Properties .......................................38
8.8.3 COPY for Collections ......................................38
8.8.4 COPY and the Overwrite Header .............................39
5.1 HTTP URL Namespace Model .....................................11
5.2 Collection Resources .........................................11
5.3 Creation and Retrieval of Collection Resources ...............12
5.4 Source Resources and Output Resources ........................13
6 LOCKING .........................................................14
6.1 Exclusive Vs. Shared Locks ...................................14
6.2 Required Support .............................................16
6.3 Lock Tokens ..................................................16
6.4 opaquelocktoken Lock Token URI Scheme ........................16
6.4.1 Node Field Generation Without the IEEE 802 Address ........17
6.5 Lock Capability Discovery ....................................19
6.6 Active Lock Discovery ........................................19
6.7 Usage Considerations .........................................19
7 WRITE LOCK ......................................................20
7.1 Methods Restricted by Write Locks ............................20
7.2 Write Locks and Lock Tokens ..................................20
7.3 Write Locks and Properties ...................................20
7.4 Write Locks and Null Resources ...............................21
7.5 Write Locks and Collections ..................................21
7.6 Write Locks and the If Request Header ........................22
7.6.1 Example - Write Lock ......................................22
7.7 Write Locks and COPY/MOVE ....................................23
7.8 Refreshing Write Locks .......................................23
8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
8.1 PROPFIND .....................................................24
8.1.1 Example - Retrieving Named Properties .....................25
8.1.2 Example - Using allprop to Retrieve All Properties ........26
8.1.3 Example - Using propname to Retrieve all Property Names ...29
8.2 PROPPATCH ....................................................31
8.2.1 Status Codes for use with 207 (Multi-Status) ..............31
8.2.2 Example - PROPPATCH .......................................32
8.3 MKCOL Method .................................................33
8.3.1 Request ...................................................33
8.3.2 Status Codes ..............................................33
8.3.3 Example - MKCOL ...........................................34
8.4 GET, HEAD for Collections ....................................34
8.5 POST for Collections .........................................35
8.6 DELETE .......................................................35
8.6.1 DELETE for Non-Collection Resources .......................35
8.6.2 DELETE for Collections ....................................36
8.7 PUT ..........................................................36
8.7.1 PUT for Non-Collection Resources ..........................36
8.7.2 PUT for Collections .......................................37
8.8 COPY Method ..................................................37
8.8.1 COPY for HTTP/1.1 resources ...............................37
8.8.2 COPY for Properties .......................................38
8.8.3 COPY for Collections ......................................38
8.8.4 COPY and the Overwrite Header .............................39
8.8.5 Status Codes ..............................................39
8.8.6 Example - COPY with Overwrite .............................40
8.8.7 Example - COPY with No Overwrite ..........................40
8.8.8 Example - COPY of a Collection ............................41
8.9 MOVE Method ..................................................42
8.9.1 MOVE for Properties .......................................42
8.9.2 MOVE for Collections ......................................42
8.9.3 MOVE and the Overwrite Header .............................43
8.9.4 Status Codes ..............................................43
8.9.5 Example - MOVE of a Non-Collection ........................44
8.9.6 Example - MOVE of a Collection ............................44
8.10 LOCK Method ..................................................45
8.10.1 Operation .................................................46
8.10.2 The Effect of Locks on Properties and Collections .........46
8.10.3 Locking Replicated Resources ..............................46
8.10.4 Depth and Locking .........................................46
8.10.5 Interaction with other Methods ............................47
8.10.6 Lock Compatibility Table ..................................47
8.10.7 Status Codes ..............................................48
8.10.8 Example - Simple Lock Request .............................48
8.10.9 Example - Refreshing a Write Lock .........................49
8.10.10 Example - Multi-Resource Lock Request ....................50
8.11 UNLOCK Method ................................................51
8.11.1 Example - UNLOCK ..........................................52
9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
9.1 DAV Header ...................................................52
9.2 Depth Header .................................................52
9.3 Destination Header ...........................................54
9.4 If Header ....................................................54
9.4.1 No-tag-list Production ....................................55
9.4.2 Tagged-list Production ....................................55
9.4.3 not Production ............................................56
9.4.4 Matching Function .........................................56
9.4.5 If Header and Non-DAV Compliant Proxies ...................57
9.5 Lock-Token Header ............................................57
9.6 Overwrite Header .............................................57
9.7 Status-URI Response Header ...................................57
9.8 Timeout Request Header .......................................58
10 STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
10.1 102 Processing ...............................................59
10.2 207 Multi-Status .............................................59
10.3 422 Unprocessable Entity .....................................60
10.4 423 Locked ...................................................60
10.5 424 Failed Dependency ........................................60
10.6 507 Insufficient Storage .....................................60
11 MULTI-STATUS RESPONSE .........................................60
12 XML ELEMENT DEFINITIONS .......................................61
12.1 activelock XML Element .......................................61
8.8.5 Status Codes ..............................................39
8.8.6 Example - COPY with Overwrite .............................40
8.8.7 Example - COPY with No Overwrite ..........................40
8.8.8 Example - COPY of a Collection ............................41
8.9 MOVE Method ..................................................42
8.9.1 MOVE for Properties .......................................42
8.9.2 MOVE for Collections ......................................42
8.9.3 MOVE and the Overwrite Header .............................43
8.9.4 Status Codes ..............................................43
8.9.5 Example - MOVE of a Non-Collection ........................44
8.9.6 Example - MOVE of a Collection ............................44
8.10 LOCK Method ..................................................45
8.10.1 Operation .................................................46
8.10.2 The Effect of Locks on Properties and Collections .........46
8.10.3 Locking Replicated Resources ..............................46
8.10.4 Depth and Locking .........................................46
8.10.5 Interaction with other Methods ............................47
8.10.6 Lock Compatibility Table ..................................47
8.10.7 Status Codes ..............................................48
8.10.8 Example - Simple Lock Request .............................48
8.10.9 Example - Refreshing a Write Lock .........................49
8.10.10 Example - Multi-Resource Lock Request ....................50
8.11 UNLOCK Method ................................................51
8.11.1 Example - UNLOCK ..........................................52
9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
9.1 DAV Header ...................................................52
9.2 Depth Header .................................................52
9.3 Destination Header ...........................................54
9.4 If Header ....................................................54
9.4.1 No-tag-list Production ....................................55
9.4.2 Tagged-list Production ....................................55
9.4.3 not Production ............................................56
9.4.4 Matching Function .........................................56
9.4.5 If Header and Non-DAV Compliant Proxies ...................57
9.5 Lock-Token Header ............................................57
9.6 Overwrite Header .............................................57
9.7 Status-URI Response Header ...................................57
9.8 Timeout Request Header .......................................58
10 STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
10.1 102 Processing ...............................................59
10.2 207 Multi-Status .............................................59
10.3 422 Unprocessable Entity .....................................60
10.4 423 Locked ...................................................60
10.5 424 Failed Dependency ........................................60
10.6 507 Insufficient Storage .....................................60
11 MULTI-STATUS RESPONSE .........................................60
12 XML ELEMENT DEFINITIONS .......................................61
12.1 activelock XML Element .......................................61
12.1.1 depth XML Element .........................................61
12.1.2 locktoken XML Element .....................................61
12.1.3 timeout XML Element .......................................61
12.2 collection XML Element .......................................62
12.3 href XML Element .............................................62
12.4 link XML Element .............................................62
12.4.1 dst XML Element ...........................................62
12.4.2 src XML Element ...........................................62
12.5 lockentry XML Element ........................................63
12.6 lockinfo XML Element .........................................63
12.7 lockscope XML Element ........................................63
12.7.1 exclusive XML Element .....................................63
12.7.2 shared XML Element ........................................63
12.8 locktype XML Element .........................................64
12.8.1 write XML Element .........................................64
12.9 multistatus XML Element ......................................64
12.9.1 response XML Element ......................................64
12.9.2 responsedescription XML Element ...........................65
12.10 owner XML Element ...........................................65
12.11 prop XML element ............................................66
12.12 propertybehavior XML element ................................66
12.12.1 keepalive XML element ....................................66
12.12.2 omit XML element .........................................67
12.13 propertyupdate XML element ..................................67
12.13.1 remove XML element .......................................67
12.13.2 set XML element ..........................................67
12.14 propfind XML Element ........................................68
12.14.1 allprop XML Element ......................................68
12.14.2 propname XML Element .....................................68
13 DAV PROPERTIES ................................................68
13.1 creationdate Property ........................................69
13.2 displayname Property .........................................69
13.3 getcontentlanguage Property ..................................69
13.4 getcontentlength Property ....................................69
13.5 getcontenttype Property ......................................70
13.6 getetag Property .............................................70
13.7 getlastmodified Property .....................................70
13.8 lockdiscovery Property .......................................71
13.8.1 Example - Retrieving the lockdiscovery Property ...........71
13.9 resourcetype Property ........................................72
13.10 source Property .............................................72
13.10.1 Example - A source Property ..............................72
13.11 supportedlock Property ......................................73
13.11.1 Example - Retrieving the supportedlock Property ..........73
14 INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
15 DAV COMPLIANCE CLASSES ........................................75
15.1 Class 1 ......................................................75
15.2 Class 2 ......................................................75
12.1.1 depth XML Element .........................................61
12.1.2 locktoken XML Element .....................................61
12.1.3 timeout XML Element .......................................61
12.2 collection XML Element .......................................62
12.3 href XML Element .............................................62
12.4 link XML Element .............................................62
12.4.1 dst XML Element ...........................................62
12.4.2 src XML Element ...........................................62
12.5 lockentry XML Element ........................................63
12.6 lockinfo XML Element .........................................63
12.7 lockscope XML Element ........................................63
12.7.1 exclusive XML Element .....................................63
12.7.2 shared XML Element ........................................63
12.8 locktype XML Element .........................................64
12.8.1 write XML Element .........................................64
12.9 multistatus XML Element ......................................64
12.9.1 response XML Element ......................................64
12.9.2 responsedescription XML Element ...........................65
12.10 owner XML Element ...........................................65
12.11 prop XML element ............................................66
12.12 propertybehavior XML element ................................66
12.12.1 keepalive XML element ....................................66
12.12.2 omit XML element .........................................67
12.13 propertyupdate XML element ..................................67
12.13.1 remove XML element .......................................67
12.13.2 set XML element ..........................................67
12.14 propfind XML Element ........................................68
12.14.1 allprop XML Element ......................................68
12.14.2 propname XML Element .....................................68
13 DAV PROPERTIES ................................................68
13.1 creationdate Property ........................................69
13.2 displayname Property .........................................69
13.3 getcontentlanguage Property ..................................69
13.4 getcontentlength Property ....................................69
13.5 getcontenttype Property ......................................70
13.6 getetag Property .............................................70
13.7 getlastmodified Property .....................................70
13.8 lockdiscovery Property .......................................71
13.8.1 Example - Retrieving the lockdiscovery Property ...........71
13.9 resourcetype Property ........................................72
13.10 source Property .............................................72
13.10.1 Example - A source Property ..............................72
13.11 supportedlock Property ......................................73
13.11.1 Example - Retrieving the supportedlock Property ..........73
14 INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
15 DAV COMPLIANCE CLASSES ........................................75
15.1 Class 1 ......................................................75
15.2 Class 2 ......................................................75
16 INTERNATIONALIZATION CONSIDERATIONS ...........................76
17 SECURITY CONSIDERATIONS .......................................77
17.1 Authentication of Clients ....................................77
17.2 Denial of Service ............................................78
17.3 Security through Obscurity ...................................78
17.4 Privacy Issues Connected to Locks ............................78
17.5 Privacy Issues Connected to Properties .......................79
17.6 Reduction of Security due to Source Link .....................79
17.7 Implications of XML External Entities ........................79
17.8 Risks Connected with Lock Tokens .............................80
18 IANA CONSIDERATIONS ...........................................80
19 INTELLECTUAL PROPERTY .........................................81
20 ACKNOWLEDGEMENTS ..............................................82
21 REFERENCES ....................................................82
21.1 Normative References .........................................82
21.2 Informational References .....................................83
22 AUTHORS' ADDRESSES ............................................84
23 APPENDICES ....................................................86
23.1 Appendix 1 - WebDAV Document Type Definition .................86
23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
23.3 Appendix 3 - Notes on Processing XML Elements ................89
23.3.1 Notes on Empty XML Elements ...............................89
23.3.2 Notes on Illegal XML Processing ...........................89
23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
23.4.1 Introduction ..............................................92
23.4.2 Meaning of Qualified Names ................................92
24 FULL COPYRIGHT STATEMENT ......................................94
16 INTERNATIONALIZATION CONSIDERATIONS ...........................76
17 SECURITY CONSIDERATIONS .......................................77
17.1 Authentication of Clients ....................................77
17.2 Denial of Service ............................................78
17.3 Security through Obscurity ...................................78
17.4 Privacy Issues Connected to Locks ............................78
17.5 Privacy Issues Connected to Properties .......................79
17.6 Reduction of Security due to Source Link .....................79
17.7 Implications of XML External Entities ........................79
17.8 Risks Connected with Lock Tokens .............................80
18 IANA CONSIDERATIONS ...........................................80
19 INTELLECTUAL PROPERTY .........................................81
20 ACKNOWLEDGEMENTS ..............................................82
21 REFERENCES ....................................................82
21.1 Normative References .........................................82
21.2 Informational References .....................................83
22 AUTHORS' ADDRESSES ............................................84
23 APPENDICES ....................................................86
23.1 Appendix 1 - WebDAV Document Type Definition .................86
23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
23.3 Appendix 3 - Notes on Processing XML Elements ................89
23.3.1 Notes on Empty XML Elements ...............................89
23.3.2 Notes on Illegal XML Processing ...........................89
23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
23.4.1 Introduction ..............................................92
23.4.2 Meaning of Qualified Names ................................92
24 FULL COPYRIGHT STATEMENT ......................................94
1 Introduction
1导言
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. Also, the ability to link pages of any media type to related pages.
属性：能够创建、删除和查询有关网页的信息，如其作者、创建日期等。此外，还能够将任何媒体类型的网页链接到相关网页。
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.
命名空间操作：指示服务器复制和移动Web资源的能力。
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]。
The sections below provide a detailed introduction to resource properties (section 4), collections of resources (section 5), and locking operations (section 6). These sections introduce the abstractions manipulated by the WebDAV-specific HTTP methods described in section 8, "HTTP Methods for Distributed Authoring".
以下各节详细介绍了资源属性（第4节）、资源集合（第5节）和锁定操作（第6节）。这些部分介绍了由第8节“分布式创作的HTTP方法”中描述的特定于WebDAV的HTTP方法操纵的抽象。
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 Extensible Markup Language (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. As a rule of thumb, parameters are encoded in XML entity bodies when they have unbounded length, or when they may be shown to a human user and hence require encoding in an ISO 10646 character set. Otherwise, parameters are encoded within HTTP headers. Section 9 describes the new HTTP headers used with WebDAV methods.
在HTTP/1.1中，方法参数信息专门编码在HTTP头中。与HTTP/1.1不同，WebDAV以可扩展标记语言（XML）[REC-XML]请求实体体或HTTP头对方法参数信息进行编码。使用XML编码方法参数的动机是能够向现有结构添加额外的XML元素，从而提供可扩展性；通过XML在ISO10646字符集编码信息的能力，提供国际化支持。根据经验，当参数具有无限长时，或者当参数可能显示给人类用户时，需要在ISO 10646字符集中编码时，参数在XML实体体中编码。否则，参数将在HTTP头中编码。第9节描述了WebDAV方法使用的新HTTP头。
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的可扩展性和国际化优势。
XML elements used in this specification are defined in section 12.
本规范中使用的XML元素在第12节中定义。
The XML namespace extension (Appendix 4) is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names.
本规范中还使用了XML名称空间扩展（附录4），以允许添加新的XML元素，而不必担心与其他元素名称冲突。
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. New status codes developed for the WebDAV methods are defined in section 10. Since some WebDAV methods may operate over many
虽然HTTP/1.1提供的状态代码足以描述WebDAV方法遇到的大多数错误情况，但仍有一些错误不属于现有类别。第10节定义了为WebDAV方法开发的新状态代码。由于某些WebDAV方法可能在多个
resources, the Multi-Status response has been introduced to return status information for multiple resources. The Multi-Status response is described in section 11.
资源，引入了多状态响应来返回多个资源的状态信息。第11节描述了多状态响应。
WebDAV employs the property mechanism to store information about the current state of the resource. For example, when a lock is taken out on a resource, a lock information property describes the current state of the lock. Section 13 defines the properties used within the WebDAV specification.
WebDAV使用属性机制来存储有关资源当前状态的信息。例如，在资源上取出锁时，锁信息属性描述锁的当前状态。第13节定义了WebDAV规范中使用的属性。
Finishing off the specification are sections on what it means to be compliant with this specification (section 15), on internationalization support (section 16), and on security (section 17).
规范的结尾部分是关于遵守本规范意味着什么（第15节）、国际化支持（第16节）和安全性（第17节）的部分。
2 Notational Conventions
2符号公约
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 [RFC2068]. Since this augmented BNF uses the basic production rules provided in section 2.2 of [RFC2068], these rules apply to this document as well.
由于本文档描述了HTTP/1.1协议的一组扩展，因此本文中用于描述协议元素的扩展BNF与[RFC2068]第2.1节中所述完全相同。由于此扩充BNF使用了[RFC2068]第2.2节中提供的基本生产规则，因此这些规则也适用于本文件。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
3 Terminology
3术语
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in [RFC2396].
URI/URL—分别是统一资源标识符和统一资源定位器。这些术语（以及它们之间的区别）在[RFC2396]中定义。
Collection - A resource that contains a set of URIs, termed member URIs, which identify member resources and meets the requirements in section 5 of this specification.
集合-包含一组URI（称为成员URI）的资源，用于标识成员资源并满足本规范第5节中的要求。
Member URI - A URI which is a member of the set of URIs contained by a collection.
成员URI—一个URI，它是集合包含的URI集的成员。
Internal Member URI - A Member URI that is immediately relative to the URI of the collection (the definition of immediately relative is given in section 5.2).
内部成员URI—与集合的URI直接相关的成员URI（第5.2节给出了直接相关的定义）。
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 "getcontentlength" property has its value, the length of the entity returned by a GET request, automatically calculated by the server.
Live属性—其语义和语法由服务器强制执行的属性。例如，live“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属性—其语义和语法不由服务器强制执行的属性。服务器只记录死财产的价值；客户机负责维护死属性的语法和语义的一致性。
Null Resource - A resource which responds with a 404 (Not Found) to any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK. A NULL resource MUST NOT appear as a member of its parent collection.
空资源-以404（未找到）响应任何HTTP/1.1或DAV方法（PUT、MKCOL、OPTIONS和LOCK除外）的资源。空资源不得作为其父集合的成员出现。
4 Data Model for Resource Properties
4资源属性的数据模型
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 read-only, 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 have long played an essential role in the maintenance of large document repositories, and many current proposals contain some notion of a property, or discuss web metadata more generally. These include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several proposals on representing relationships within HTML. Work on PICS-NG
长期以来，属性在大型文档存储库的维护中起着至关重要的作用，当前的许多建议都包含一些属性的概念，或者更广泛地讨论web元数据。其中包括PICS[REC-PICS]、PICS-NG、XML、Web集合，以及一些关于在HTML中表示关系的建议。关于PICS-NG的工作
and Web Collections has been subsumed by the Resource Description Framework (RDF) metadata activity of the World Wide Web Consortium. RDF consists of a network-based data model and an XML representation of that model.
万维网联盟的资源描述框架（RDF）元数据活动已经包含了Web集合。RDF由基于网络的数据模型和该模型的XML表示组成。
Some proposals come from a digital library perspective. These include the Dublin Core [RFC2413] metadata set and the Warwick Framework [WF], a container architecture for different metadata schemas. The literature includes many examples of metadata, including MARC [USMARC], a bibliographic metadata format, and a technical report bibliographic format employed by the Dienst system [RFC1807]. Additionally, the proceedings from the first IEEE Metadata conference describe many community-specific metadata sets.
一些建议是从数字图书馆的角度提出的。其中包括都柏林核心[RFC2413]元数据集和Warwick框架[WF]，一种用于不同元数据模式的容器体系结构。文献包括许多元数据示例，包括MARC[USMARC]，一种书目元数据格式，以及Dienst系统[RFC1807]采用的技术报告书目格式。此外，第一届IEEE元数据会议的会议记录描述了许多特定于社区的元数据集。
Participants of the 1996 Metadata II Workshop in Warwick, UK [WF], noted that "new metadata sets will develop as the networked infrastructure matures" and "different communities will propose, design, and be responsible for different types of metadata." These observations can be corroborated by noting that many community-specific sets of metadata already exist, and there is significant motivation for the development of new forms of metadata as many communities increasingly make their data available in digital form, requiring a metadata format to assist data location and cataloging.
1996年在英国华威举办的元数据II研讨会[WF]的与会者指出，“随着网络基础设施的成熟，新的元数据集将不断发展”，“不同的社区将提出、设计并负责不同类型的元数据。”这些观察结果可以通过以下方式得到证实：许多社区特定的元数据集已经存在，而且随着许多社区越来越多地以数字形式提供其数据，需要元数据格式来协助数据定位和编目，开发新形式的元数据具有重大的动机。
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 which 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 when expressed in XML MUST be well formed.
用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 new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. 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,
选择XML是因为它是一种灵活、自描述的结构化数据格式，支持丰富的模式定义，并且支持多个字符集。XML的自描述特性允许通过添加新元素来扩展任何属性的值。较旧的客户端在遇到扩展时不会中断，因为它们仍然拥有原始模式中指定的数据，并且会忽略它们不理解的元素。XML对多个字符集的支持允许在用户熟悉的字符集中编码和读取任何人类可读的属性。XML对多种人类语言的支持，
using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages.
使用“xml:lang”属性，可以处理多种人类语言使用相同字符集的情况。
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 [RFC2396], is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control.
基于URI[RFC2396]的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 which 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.
最后，不可能在单个资源上定义同一属性两次，因为这会导致资源的属性命名空间发生冲突。
Although HTML resources support links to other resources, the Web needs more general support for links between resources of any media type (media types are also known as MIME types, or content types). WebDAV provides such links. A WebDAV link is a special type of property value, formally defined in section 12.4, that allows typed connections to be established between resources of any media type. The property value consists of source and destination Uniform Resource Identifiers (URIs); the property name identifies the link type.
尽管HTML资源支持指向其他资源的链接，但Web需要对任何媒体类型（媒体类型也称为MIME类型或内容类型）的资源之间的链接提供更一般的支持。WebDAV提供了这样的链接。WebDAV链接是一种特殊类型的属性值，在第12.4节中正式定义，它允许在任何媒体类型的资源之间建立类型化连接。属性值由源和目标统一资源标识符（URI）组成；属性名称标识链接类型。
5 Collections of Web Resources
5网络资源集合
This section provides a description of a new type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace. 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命名空间的交互。集合资源的用途是在服务器的命名空间中对类似集合的对象（例如，文件系统目录）进行建模。
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. The root, or top-level collection of the namespace under consideration is exempt from the previous rule.
如果HTTP URL命名空间满足以下条件，则称其为一致的：对于HTTP层次结构中的每个URL，都存在一个包含该URL作为内部成员的集合。所考虑的命名空间的根或顶级集合不受前面规则的约束。
Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL namespace be consistent. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.
HTTP/1.1和WebDAV都不要求整个HTTP URL命名空间保持一致。但是，禁止某些WebDAV方法生成导致命名空间不一致的结果。
Although implicit in [RFC2068] and [RFC2396], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
尽管在[RFC2068]和[RFC2396]中是隐式的，但任何资源（包括集合资源）都可以由多个URI标识。例如，一个资源可以由多个HTTP URL标识。
A collection is a resource whose state consists of at least a list of internal member URIs and a set of properties, but which may have additional state such as entity bodies returned by GET. An internal member URI MUST be immediately relative to a base URI of the collection. That is, the internal member URI is equal to a containing collection's URI plus an additional segment for non-collection resources, or additional segment plus trailing slash "/" for collection resources, where segment is defined in section 3.3 of [RFC2396].
集合是一种资源，其状态至少包括一个内部成员URI列表和一组属性，但可能具有其他状态，如GET返回的实体体。内部成员URI必须直接相对于集合的基URI。也就是说，内部成员URI等于包含集合的URI加上非集合资源的附加段，或附加段加上集合资源的尾部斜杠“/”，其中段在[RFC2396]的第3.3节中定义。
Any given internal member URI MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URI in a collection. Properties defined on collections behave exactly as do properties on non-collection resources.
任何给定的内部成员URI必须只属于该集合一次，即，在一个集合中具有同一URI的多个实例是非法的。集合上定义的属性与非集合资源上定义的属性的行为完全相同。
For all WebDAV compliant resources A and B, identified by URIs U and V, for which U is immediately relative to V, B MUST be a collection that has U as an internal member URI. So, if the resource with URL http://foo.com/bar/blah is WebDAV compliant and if the resource with URL http://foo.com/bar/ is WebDAV compliant then the resource with URL http://foo.com/bar/ must be a collection and must contain URL http://foo.com/bar/blah as an internal member.
对于所有符合WebDAV的资源A和B，由URI U和V标识，其中U直接相对于V，B必须是一个集合，其中U作为内部成员URI。因此，如果资源具有URLhttp://foo.com/bar/blah WebDAV兼容吗？如果资源具有URLhttp://foo.com/bar/ WebDAV是否与URL为的资源兼容http://foo.com/bar/ 必须是集合并且必须包含URLhttp://foo.com/bar/blah 作为内部成员。
Collection resources MAY list the URLs of non-WebDAV compliant children in the HTTP URL namespace hierarchy as internal members but are not required to do so. For example, if the resource with URL http://foo.com/bar/blah is not WebDAV compliant and the URL http://foo.com/bar/ identifies a collection then URL http://foo.com/bar/blah may or may not be an internal member of the collection with URL http://foo.com/bar/.
集合资源可以将HTTP URL命名空间层次结构中不符合WebDAV的子级的URL列为内部成员，但不需要这样做。例如，如果资源具有URLhttp://foo.com/bar/blah 与WebDAV不兼容，并且URLhttp://foo.com/bar/ 标识一个集合，然后单击URLhttp://foo.com/bar/blah 可能是也可能不是URL为的集合的内部成员http://foo.com/bar/.
If a WebDAV compliant resource has no WebDAV compliant children 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 trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names.
有一个惯例是，当引用集合时，如果集合的名称没有尾随斜杠，则会自动追加尾随斜杠。因此，资源可能会接受一个URI，但不带尾随“/”以指向集合。在这种情况下，它应该在响应中返回一个内容位置头，指向以“/”结尾的URI。例如，如果客户端调用http://foo.bar/blah （无尾随斜杠），资源http://foo.bar/blah/ （尾随斜杠）的响应可能与在其上调用操作一样，并且应返回带有http://foo.bar/blah/ 在里面。一般来说，客户机应该使用“/”形式的集合名称。
A resource MAY be a collection but not be WebDAV compliant. That is, the resource may comply with all the rules set out in this specification regarding how a collection is to behave without necessarily supporting all methods that a WebDAV compliant resource is required to support. In such a case the resource may return the DAV:resourcetype property with the value DAV:collection but MUST NOT return a DAV header containing the value "1" on an OPTIONS response.
资源可以是集合，但不符合WebDAV。也就是说，资源可以遵守本规范中规定的关于集合行为的所有规则，而不必支持WebDAV兼容资源需要支持的所有方法。在这种情况下，资源可以返回值为DAV:collection的DAV:resourcetype属性，但不能在选项响应上返回包含值“1”的DAV头。
This document specifies the MKCOL method to create new collection resources, rather than using the existing HTTP/1.1 PUT or POST method, for the following reasons:
本文档指定了MKCOL方法来创建新的集合资源，而不是使用现有的HTTP/1.1 PUT或POST方法，原因如下：
In HTTP/1.1, the PUT method is defined to store the request body at the location specified by the Request-URI. While a description format for a collection can readily be constructed for use with PUT, the implications of sending such a description to the server are undesirable. For example, if a description of a collection that omitted some existing resources were PUT to a server, this might be interpreted as a command to remove those members. This would extend PUT to perform DELETE functionality, which is undesirable since it changes the semantics of PUT, and makes it difficult to control DELETE functionality with an access control scheme based on methods.
在HTTP/1.1中，PUT方法被定义为将请求主体存储在请求URI指定的位置。虽然可以容易地构造集合的描述格式以用于PUT，但将此类描述发送到服务器的含义是不可取的。例如，如果将省略某些现有资源的集合的描述放在服务器上，这可能会被解释为删除这些成员的命令。这将扩展PUT以执行删除功能，这是不可取的，因为它改变了PUT的语义，并且使得难以使用基于方法的访问控制方案来控制删除功能。
While the POST method is sufficiently open-ended that a "create a collection" POST command could be constructed, this is undesirable because it would be difficult to separate access control for collection creation from other uses of POST.
虽然POST方法具有足够的开放性，可以构造“创建集合”POST命令，但这是不可取的，因为很难将集合创建的访问控制与POST的其他用途分开。
The exact definition of the behavior of GET and PUT on collections is defined later in this document.
本文档后面将定义集合上GET和PUT行为的确切定义。
For many resources, the entity returned by a GET method exactly matches the persistent state of the resource, for example, a GIF file stored on a disk. For this simple case, the URI at which a resource is accessed is identical to the URI at which the source (the persistent state) of the resource is accessed. This is also the case for HTML source files that are not processed by the server prior to transmission.
对于许多资源，GET方法返回的实体与资源的持久状态完全匹配，例如，存储在磁盘上的GIF文件。对于这个简单的例子，访问资源的URI与访问资源的源（持久状态）的URI相同。对于传输前未经服务器处理的HTML源文件，情况也是如此。
However, the server can sometimes process HTML resources before they are transmitted as a return entity body. For example, a server-side-include directive within an HTML file might instruct a server to replace the directive with another value, such as the current date. In this case, what is returned by GET (HTML plus date) differs from the persistent state of the resource (HTML plus directive). Typically there is no way to access the HTML resource containing the unprocessed directive.
但是，服务器有时可以在HTML资源作为返回实体传输之前对其进行处理。例如，HTML文件中的服务器端include指令可能会指示服务器用另一个值（如当前日期）替换该指令。在这种情况下，GET（HTML plus date）返回的内容与资源的持久状态（HTML plus指令）不同。通常无法访问包含未处理指令的HTML资源。
Sometimes the entity returned by GET is the output of a data-producing process that is described by one or more source resources (that may not even have a location in the URI namespace). A single data-producing process may dynamically generate the state of a potentially large number of output resources. An example of this is a CGI script that describes a "finger" gateway process that maps part of the namespace of a server into finger requests, such as http://www.foo.bar.org/finger_gateway/user@host.
有时GET返回的实体是由一个或多个源资源（可能在URI命名空间中没有位置）描述的数据生成过程的输出。单个数据生成过程可以动态生成潜在大量输出资源的状态。这方面的一个示例是CGI脚本，它描述了一个“finger”网关进程，该进程将服务器命名空间的一部分映射到finger请求中，例如http://www.foo.bar.org/finger_gateway/user@主持人。
In the absence of distributed authoring capabilities, it is acceptable to have no mapping of source resource(s) to the URI namespace. In fact, preventing access to the source resource(s) has desirable security benefits. However, if remote editing of the source resource(s) is desired, the source resource(s) should be given a location in the URI namespace. This source location should not be one of the locations at which the generated output is retrievable, since in general it is impossible for the server to differentiate requests for source resources from requests for process output resources. There is often a many-to-many relationship between source resources and output resources.
在缺乏分布式创作功能的情况下，不将源资源映射到URI命名空间是可以接受的。事实上，阻止对源资源的访问具有理想的安全好处。但是，如果需要远程编辑源资源，则应在URI命名空间中为源资源指定一个位置。此源位置不应是生成的输出可检索的位置之一，因为服务器通常无法区分对源资源的请求和对进程输出资源的请求。源资源和输出资源之间通常存在多对多关系。
On WebDAV compliant servers the URI of the source resource(s) may be stored in a link on the output resource with type DAV:source (see section 13.10 for a description of the source link property). Storing the source URIs in links on the output resources places the burden of discovering the source on the authoring client. Note that the value of a source link is not guaranteed to point to the correct source. Source links may break or incorrect values may be entered. Also note that not all servers will allow the client to set the source link value. For example a server which generates source links on the fly for its CGI files will most likely not allow a client to set the source link value.
在符合WebDAV的服务器上，源资源的URI可以存储在输出资源上的链接中，类型为DAV:source（有关源链接属性的说明，请参阅第13.10节）。将源URI存储在输出资源上的链接中会给创作客户端带来查找源的负担。请注意，不能保证源链接的值指向正确的源。源链接可能中断或输入了不正确的值。还请注意，并非所有服务器都允许客户端设置源链接值。例如，为其CGI文件动态生成源链接的服务器很可能不允许客户端设置源链接值。
6 Locking
6锁定
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定义锁定。但是，该语法是可扩展的，并允许最终为其他访问类型指定锁定。
The most basic form of lock is an exclusive lock. This is a lock where the access right in question is only granted to a single principal. The need for this arbitration results from a desire to avoid having to merge results.
锁的最基本形式是独占锁。这是一个锁，其中所讨论的访问权仅授予单个主体。这种仲裁的需要源于避免合并结果的愿望。
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 with appropriate access can get the lock.
然而，有时锁的目标不是排除其他人行使访问权，而是为主体提供一种机制，表明他们打算行使其访问权。这种情况下提供了共享锁。共享锁允许多个主体接收锁。因此，任何具有适当访问权限的主体都可以获得锁。
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 owner leaves without unlocking a resource. While both timeouts 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.
之所以包括共享锁，是因为web分布式创作系统的经验表明，独占锁通常过于严格。独占锁用于强制执行特定的编辑过程：取出独占锁、读取资源、执行编辑、写入资源、释放锁。此编辑过程存在一个问题，即锁并非总是正确释放，例如当程序崩溃时，或当锁所有者离开而未解锁资源时。虽然超时和管理操作都可以用来移除违规锁，但在需要时，这两种机制都不可用；超时时间可能很长，或者管理员不可用。
A WebDAV compliant server is not required to support locking in any form. If the server 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中唯一的协商轴。
A lock token is a type of state token, represented as a URI, which identifies a particular lock. A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body, and can also be found through lock discovery on a resource.
锁令牌是一种状态令牌，表示为URI，用于标识特定的锁。锁令牌由响应正文中lockdiscovery属性中的每个成功锁操作返回，也可以通过资源上的锁发现找到。
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.
锁定令牌URI必须在所有资源中始终唯一。这种唯一性约束允许跨资源和服务器提交锁令牌，而无需担心混淆。
This specification provides a lock token URI scheme called opaquelocktoken that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements.
该规范提供了一个名为opaquelocktoken的锁令牌URI方案，该方案满足唯一性要求。但是，资源可以自由返回任何URI方案，只要它满足唯一性要求。
Having a lock token provides no special access rights. Anyone can find out anyone else's lock token by performing lock discovery. Locks MUST be enforced based upon whatever authentication mechanism is used by the server, not based on the secrecy of the token values.
拥有锁令牌不提供特殊的访问权限。任何人都可以通过执行锁发现来查找其他人的锁令牌。必须根据服务器使用的任何身份验证机制强制实施锁，而不是基于令牌值的保密性。
The opaquelocktoken URI scheme is designed to be unique across all resources for all time. Due to this uniqueness quality, a client may submit an opaque lock token in an If header on a resource other than the one that returned it.
opaquelocktoken URI方案设计为在所有资源中始终唯一。由于这种唯一性，客户机可能会在返回它的资源以外的资源的If头中提交不透明锁令牌。
All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource.
所有资源都必须识别opaquelocktoken方案，并且至少要识别锁令牌不引用资源上的未完成锁。
In order to guarantee uniqueness across all resources for all time the opaquelocktoken requires the use of the Universal Unique Identifier (UUID) mechanism, as described in [ISO-11578].
为了保证所有资源在任何时候的唯一性，opaquelocktoken需要使用通用唯一标识符（UUID）机制，如[ISO-11578]所述。
Opaquelocktoken generators, however, have a choice of how they create these tokens. They can either generate a new UUID for every lock token they create or they can create a single UUID and then add extension characters. If the second method is selected then the program generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID.
但是，Opaquelocktoken生成器可以选择如何创建这些令牌。他们可以为创建的每个锁令牌生成新的UUID，也可以创建单个UUID，然后添加扩展字符。如果选择了第二种方法，则生成扩展的程序必须保证同一扩展不会与关联的UUID一起使用两次。
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID, as defined in [ISO-11578]. Note that white space (LWS) is not allowed between elements of this production.
OpaqueLockToken URI=“OpaqueLockToken:”UUID[扩展]；UUID产品是UUID的字符串表示形式，如[ISO-11578]中所定义。请注意，此产品的元素之间不允许有空白（LWS）。
Extension = path ; path is defined in section 3.2.1 of RFC 2068 [RFC2068]
扩展=路径；路径在RFC 2068[RFC2068]第3.2.1节中定义
UUIDs, as defined in [ISO-11578], contain a "node" field that contains one of the IEEE 802 addresses for the server machine. As noted in section 17.8, there are several security risks associated with exposing a machine's IEEE 802 address. This section provides an alternate mechanism for generating the "node" field of a UUID which does not employ an IEEE 802 address. WebDAV servers MAY use this algorithm for creating the node field when generating UUIDs. The text in this section is originally from an Internet-Draft by Paul Leach and Rich Salz, who are noted here to properly attribute their work.
[ISO-11578]中定义的UUID包含一个“节点”字段，该字段包含服务器机器的一个IEEE 802地址。如第17.8节所述，公开机器的IEEE 802地址存在若干安全风险。本节提供了一种替代机制，用于生成不采用IEEE 802地址的UUID的“节点”字段。WebDAV服务器在生成UUID时可以使用此算法创建节点字段。本节中的文本最初来自Paul Leach和Rich Salz的互联网草稿，他们在这里被指出是为了正确地描述他们的作品。
The ideal solution is to obtain a 47 bit cryptographic quality random number, and use it as the low 47 bits of the node ID, with the most significant bit of the first octet of the node ID set to 1. This bit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards; hence, there can never be a conflict between UUIDs generated by machines with and without network cards.
理想的解决方案是获得47位加密质量随机数，并将其用作节点ID的低47位，节点ID的第一个八位组的最高有效位设置为1。该位是单播/多播位，从网卡获取的IEEE 802地址中永远不会设置该位；因此，由具有和不具有网卡的机器生成的UUID之间永远不会存在冲突。
If a system does not have a primitive to generate cryptographic quality random numbers, then in most systems there are usually a fairly large number of sources of randomness available from which one can be generated. Such sources are system specific, but often include:
如果一个系统没有生成密码质量随机数的原语，那么在大多数系统中，通常有相当多的随机性源可供生成。此类来源是特定于系统的，但通常包括：
- the percent of memory in use - the size of main memory in bytes - the amount of free main memory in bytes - the size of the paging or swap file in bytes - free bytes of paging or swap file - the total size of user virtual address space in bytes - the total available user address space bytes - the size of boot disk drive in bytes - the free disk space on boot drive in bytes - the current time - the amount of time since the system booted - the individual sizes of files in various system directories - the creation, last read, and modification times of files in various system directories - the utilization factors of various system resources (heap, etc.) - current mouse cursor position - current caret position - current number of running processes, threads - handles or IDs of the desktop window and the active window - the value of stack pointer of the caller - the process and thread ID of caller - various processor architecture specific performance counters (instructions executed, cache misses, TLB misses)
- 正在使用的内存百分比-以字节为单位的主内存大小-以字节为单位的可用主内存量-以字节为单位的分页或交换文件大小-分页或交换文件的可用字节-以字节为单位的用户虚拟地址空间总大小-以字节为单位的总可用用户地址空间字节-以字节为单位的引导磁盘驱动器大小-可用磁盘启动驱动器上的空间（字节）-当前时间-自系统启动以来的时间量-各种系统目录中文件的大小-各种系统目录中文件的创建、上次读取和修改时间-各种系统资源的利用率（堆等）-当前鼠标光标位置-当前插入符号位置-当前正在运行的进程数、线程数-桌面窗口和活动窗口的句柄或ID-调用者的堆栈指针值-调用者的进程和线程ID-各种处理器体系结构特定的性能计数器（执行的指令、缓存未命中、TLB未命中）
(Note that it is precisely the above kinds of sources of randomness that are used to seed cryptographic quality random number generators on systems without special hardware for their construction.)
（请注意，正是上述类型的随机性源用于在没有专用硬件的系统上为密码质量随机数生成器播种。）
In addition, items such as the computer's name and the name of the operating system, while not strictly speaking random, will help differentiate the results from those obtained by other systems.
此外，诸如计算机名称和操作系统名称等项目虽然严格来说不是随机的，但有助于将结果与其他系统获得的结果区分开来。
The exact algorithm to generate a node ID using these data is system specific, because both the data available and the functions to obtain them are often very system specific. However, assuming that one can concatenate all the values from the randomness sources into a buffer, and that a cryptographic hash function such as MD5 is available, then any 6 bytes of the MD5 hash of the buffer, with the multicast bit (the high bit of the first byte) set will be an appropriately random node ID.
使用这些数据生成节点ID的精确算法是特定于系统的，因为可用数据和获取它们的函数通常都是特定于系统的。然而，假设可以将来自随机性源的所有值连接到缓冲器中，并且诸如MD5之类的加密散列函数可用，则缓冲器的MD5散列的任何6个字节（设置了多播位（第一字节的高位））将是适当的随机节点ID。
Other hash functions, such as SHA-1, can also be used. The only requirement is that the result be suitably random _ in the sense that the outputs from a set uniformly distributed inputs are themselves uniformly distributed, and that a single bit change in the input can be expected to cause half of the output bits to change.
也可以使用其他哈希函数，例如SHA-1。唯一的要求是结果是适当的随机性，即一组均匀分布输入的输出本身是均匀分布的，并且输入中的一个位变化可能会导致一半的输出位变化。
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. Lock capability discovery differs from discovery of supported access control types, since there may be access control types without corresponding lock types. A client can determine what lock types the server supports by retrieving the supportedlock property.
由于服务器锁定支持是可选的，因此尝试锁定服务器上的资源的客户端可以尝试锁定并希望获得最佳效果，或者执行某种形式的发现以确定服务器支持的锁定功能。这称为锁功能发现。锁功能发现不同于受支持的访问控制类型的发现，因为可能存在没有相应锁类型的访问控制类型。客户端可以通过检索supportedlock属性来确定服务器支持的锁类型。
Any DAV compliant resource that supports the LOCK method MUST support the supportedlock property.
任何支持LOCK方法的符合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 lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and where available, provides their lock token.
如果另一个主体锁定了主体希望访问的资源，那么第二个主体能够找出第一个主体是谁是有用的。为此，提供了lockdiscovery属性。此属性列出所有未完成的锁，描述它们的类型，并在可用的情况下提供它们的锁令牌。
Any DAV compliant resource that supports the LOCK method MUST support the lockdiscovery property.
任何支持LOCK方法的符合DAV的资源都必须支持lockdiscovery属性。
Although the locking mechanisms specified here 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. Client A doesn't lock the document, but does a GET and begins editing. Client B does LOCK, performs a GET and begins editing. Client B finishes editing, performs a PUT, then an UNLOCK. Client A performs a PUT, overwriting and losing all of B's changes.
两个客户端A和B对编辑资源“index.html”感兴趣。客户端A是HTTP客户端而不是WebDAV客户端，因此不知道如何执行锁定。客户端A不锁定文档，但执行GET并开始编辑。客户端B锁定、执行GET并开始编辑。客户端B完成编辑，执行PUT，然后执行解锁。客户端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资源之前实施需要锁定的客户端过程来防止覆盖。
7 Write Lock
7写锁
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.
本节描述特定于写锁类型的语义。写锁是锁类型的特定实例，是本规范中描述的唯一锁类型。
A write lock MUST prevent a principal without the lock from successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, or MKCOL on the locked resource. All other current methods, GET in particular, function independently of the lock.
写锁必须防止没有锁的主体在锁定的资源上成功执行PUT、POST、PROPPATCH、lock、UNLOCK、MOVE、DELETE或MKCOL。所有其他当前方法，尤其是GET，都独立于锁运行。
Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.
但是，请注意，在创建新方法时，有必要指定它们如何与写锁交互。
A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal.
成功请求独占或共享写锁必须导致生成与请求主体关联的唯一锁令牌。因此，如果五个主体在同一资源上有一个共享写锁，那么将有五个锁令牌，每个主体一个。
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 to respect locks are guaranteed not to change while write locked.
只有定义为尊重锁的死属性和活属性才能保证在写锁定时不会更改。
It is possible to assert a write lock on a null resource in order to lock the name.
可以在空资源上声明写锁以锁定名称。
A write locked null resource, referred to as a lock-null resource, MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and UNLOCK. A lock-null resource MUST appear as a member of its parent collection. Additionally the lock-null resource MUST have defined on it all mandatory DAV properties. Most of these properties, such as all the get* properties, will have no value as a lock-null resource does not support the GET method. Lock-Null resources MUST have defined values for lockdiscovery and supportedlock properties.
写锁定的空资源（称为锁定空资源）必须以404（未找到）或405（不允许使用方法）响应任何HTTP/1.1或DAV方法，PUT、MKCOL、OPTIONS、PROPFIND、lock和UNLOCK除外。锁空资源必须显示为其父集合的成员。此外，lock null资源必须在其上定义所有必需的DAV属性。大多数属性（如所有get*属性）都没有值，因为lock null资源不支持get方法。Lock Null资源必须具有lockdiscovery和supportedlock属性的定义值。
Until a method such as PUT or MKCOL is successfully executed on the lock-null resource the resource MUST stay in the lock-null state. However, once a PUT or MKCOL is successfully executed on a lock-null resource the resource ceases to be in the lock-null state.
在锁定null资源上成功执行PUT或MKCOL等方法之前，资源必须保持锁定null状态。但是，一旦在锁空资源上成功执行PUT或MKCOL，该资源就不再处于锁空状态。
If the resource is unlocked, for any reason, without a PUT, MKCOL, or similar method having been successfully executed upon it then the resource MUST return to the null state.
如果由于任何原因，资源未被解锁，且未成功执行PUT、MKCOL或类似方法，则资源必须返回null状态。
A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection.
集合上的写锁（无论是由“Depth:0”还是“Depth:infinity”锁请求创建）防止非锁所有者添加或删除集合的成员URI。因此，当主体发出PUT或POST请求以在URI下创建新资源时，该URI需要是写锁定集合的内部成员以保持HTTP命名空间一致性，或者发出DELETE以删除具有URI的资源，该URI是写锁定集合的现有内部成员URI，如果主体对集合没有写锁，则此请求必须失败。
However, if a write lock request is issued to a collection containing member URIs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code.
但是，如果向包含成员URI的集合发出写锁请求，该成员URI标识当前以与写锁冲突的方式锁定的资源，则该请求必须失败，状态代码为423（已锁定）。
If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that
如果锁所有者导致将资源的URI添加为锁定集合的内部成员URI，则必须将新资源自动添加到锁中。这是唯一的机制
allows a resource to be added to a write lock. Thus, 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.
允许将资源添加到写锁。因此，例如，如果集合/a/b/被写锁定，并且资源/c被移动到/a/b/c，则资源/a/b/c将被添加到写锁定。
If a user agent is not required to have knowledge about a lock when requesting an operation on a locked resource, the following scenario might occur. 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 in the If header for all locked resources that a method may interact with or the method MUST fail. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted, one for the source and the other for the destination.
为了防止这些冲突，对于方法可能与之交互或方法必须失败的所有锁定资源，必须由If头中的授权主体提交一个锁令牌。例如，如果要移动资源，并且源和目标都被锁定，则必须提交两个锁定令牌，一个用于源，另一个用于目标。
>>Request
>>请求
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
If: <http://www.ics.uci.edu/users/f/fielding/index.html>
(<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
If: <http://www.ics.uci.edu/users/f/fielding/index.html>
(<opaquelocktoken: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, 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协议范围之外的机制在底层传输层中进行的。
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 "Depth: infinity", then the resource will be added to the lock.
复制方法调用不得复制源上活动的任何写锁。但是，如前所述，如果副本将资源复制到使用“Depth:infinity”锁定的集合中，则资源将添加到锁中。
A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, the resource is subject to being added to an existing lock at the destination, as specified in section 7.5. For example, if the MOVE makes the resource a child of a collection that is locked with "Depth: infinity", then the resource will be added to that collection's lock. Additionally, if a resource locked with "Depth: infinity" is moved to a destination that is within the scope of the same lock (e.g., within the namespace tree covered by the lock), the moved resource will again be a added to the lock. In both these examples, as specified in section 7.6, an If header must be submitted containing a lock token for both the source and destination.
对写锁定资源的成功移动请求不得随资源一起移动写锁定。但是，如第7.5节所述，资源必须添加到目的地的现有锁中。例如，如果移动使资源成为使用“Depth:infinity”锁定的集合的子级，则该资源将添加到该集合的锁中。此外，如果使用“Depth:infinity”锁定的资源被移动到同一个锁范围内的目标（例如，在锁覆盖的命名空间树内），则移动的资源将再次添加到锁中。在这两个示例中，如第7.6节所述，必须提交包含源和目标锁定令牌的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 method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set.
但是，客户机可以提交一个带有If头但没有主体的锁方法。这种形式的锁只能用于“刷新”锁。这意味着，至少必须重新设置与锁相关的任何计时器。
A server may return a Timeout header with a lock refresh that is different than the Timeout header returned when the lock was originally requested. Additionally clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client.
服务器可能会返回一个带有锁刷新的超时标头，该刷新与最初请求锁时返回的超时标头不同。此外，客户端可能会在其锁刷新请求中提交任意值的超时头。服务器通常会忽略客户端提交的超时头。
If an error is received in response to a refresh LOCK request the client SHOULD assume that the lock was not refreshed.
如果在响应刷新锁请求时收到错误，则客户端应假定锁未刷新。
8 HTTP Methods for Distributed Authoring
8种用于分布式创作的HTTP方法
The following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with [REC-XML]. All XML used in either requests or responses MUST be, at minimum, well formed. If a server receives
以下新的HTTP方法使用XML作为请求和响应格式。所有符合DAV的客户端和资源必须使用符合[REC-XML]的XML解析器。请求或响应中使用的所有XML至少必须是格式良好的。如果服务器收到
ill-formed XML in a request it MUST reject the entire request with a 400 (Bad Request). If a client receives ill-formed XML in a response then it MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
请求中的XML格式错误它必须以400（错误请求）拒绝整个请求。如果客户机在响应中接收到格式错误的XML，那么它不能假设任何有关已执行方法的结果的信息，并且应该将服务器视为出现故障。
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 URIs. All DAV compliant resources MUST support the PROPFIND method and the propfind XML element (section 12.14) along with all XML elements defined for use with that element.
PROPFIND方法检索由请求URI标识的资源上定义的属性（如果该资源没有任何内部成员），或者检索由请求URI标识的资源上定义的属性（如果该资源是具有内部成员URI的集合），并可能检索其成员资源。所有符合DAV的资源必须支持PROPFIND方法和PROPFIND XML元素（第12.14节），以及为与该元素一起使用而定义的所有XML元素。
A client may submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND on a collection resource with internal member URIs. DAV compliant servers MUST support the "0", "1" and "infinity" behaviors. By default, the PROPFIND method without a Depth header MUST act as if a "Depth: infinity" header was included.
客户端可以在具有内部成员URI的集合资源上使用PROPFIND提交值为“0”、“1”或“无穷大”的深度标头。符合DAV的服务器必须支持“0”、“1”和“无限”行为。默认情况下，没有深度标头的PROPFIND方法必须像包含“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 request particular property values, all property values, or a list of the names of the resource's properties. A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as a request for the names and values of all properties.
客户机可以在请求方法的主体中提交一个propfind XML元素，描述所请求的信息。可以请求特定属性值、所有属性值或资源属性名称列表。客户可以选择不提交请求正文。必须将空的PROPFIND请求正文视为对所有属性的名称和值的请求。
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 which does not exist is an error and MUST be noted, if the response uses a multistatus XML element, with a response XML element which contains a 404 (Not Found) status value.
如果检索属性时出错，则响应中必须包含正确的错误结果。检索不存在的属性值的请求是错误的，如果响应使用multistatus XML元素，则必须注意包含404（未找到）状态值的响应XML元素。
Consequently, the multistatus XML element for a collection resource with member URIs MUST include a response XML element for each member URI of the collection, to whatever depth was requested. Each response XML element MUST contain an href XML element that gives the URI of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URIs are returned as a flat list whose order of entries is not significant.
因此，具有成员URI的集合资源的multistatus XML元素必须包含集合的每个成员URI的响应XML元素，无论请求的深度如何。每个响应XML元素必须包含一个href XML元素，该元素提供定义prop XML元素中属性的资源的URI。具有内部成员URI的集合资源上PROPFIND的结果将作为一个简单列表返回，该列表的条目顺序不重要。
In the case of allprop and propname, if a principal does not have the right to know whether a particular property exists then the property should be silently excluded from the response.
在allprop和propname的情况下，如果主体无权知道某个特定属性是否存在，则该属性应被静默地从响应中排除。
The results of this method SHOULD NOT be cached.
不应缓存此方法的结果。
>>Request
>>请求
PROPFIND /file HTTP/1.1
Host: www.foo.bar
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
PROPFIND /file HTTP/1.1
Host: www.foo.bar
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://www.foo.bar/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://www.foo.bar/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/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.foo.bar/file</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<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>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foo.bar/file</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<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: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>
In this example, PROPFIND is executed on a non-collection resource http://www.foo.bar/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.foo.bar/file. propfind XML元素指定请求其值的四个属性的名称。在这种情况下，只返回了两个属性，因为发出请求的主体没有足够的访问权限来查看第三个和第四个属性。
>>Request
>>请求
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Depth: 1
Content-Type: text/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: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/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.foo.bar/container/</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foo.bar/container/</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/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>http://www.foo.bar/container/front.html</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/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>
Monday, 12-Jan-98 09:25:56 GMT
</D:getlastmodified>
<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>http://www.foo.bar/container/front.html</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/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>
Monday, 12-Jan-98 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: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.foo.bar/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 properties defined on each resource.
在本例中，对资源调用了PROPFINDhttp://www.foo.bar/container/ 深度标头为1，表示请求应用于资源及其子项；propfind XML元素包含allprop XML元素，表示请求应返回在每个资源上定义的所有属性的名称和值。
The resource http://www.foo.bar/container/ has six properties defined on it:
资源http://www.foo.bar/container/ 在其上定义了六个属性：
http://www.foo.bar/boxschema/bigbox, http://www.foo.bar/boxschema/author, DAV:creationdate, DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
http://www.foo.bar/boxschema/bigbox, http://www.foo.bar/boxschema/author，DAV:creationdate，DAV:displayname，DAV:resourcetype和DAV:supportedlock。
The last four properties are WebDAV-specific, defined in section 13. Since GET is not supported on this resource, the get* properties (e.g., getcontentlength) are not defined on this resource. The DAV-specific properties assert that "container" was created on December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT (creationdate), has a name of "Example collection" (displayname), a collection resource type (resourcetype), and supports exclusive write and shared write locks (supportedlock).
最后四个属性是特定于WebDAV的，定义见第13节。由于此资源不支持GET，因此未在此资源上定义GET*属性（例如getcontentlength）。DAV特定属性断言，“容器”创建于1997年12月1日下午5:42:21，位于格林尼治标准时间（creationdate）以西8小时的时区，名称为“示例集合”（displayname），集合资源类型（resourcetype），并支持独占写锁和共享写锁（supportedlock）。
The resource http://www.foo.bar/container/front.html has nine properties defined on it:
资源http://www.foo.bar/container/front.html 在其上定义了九个属性：
http://www.foo.bar/boxschema/bigbox (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://www.foo.bar/boxschema/bigbox （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 (creationdate), has a name of "Example HTML resource" (displayname), a content length of 4525 bytes (getcontentlength), a MIME type of "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT (getlastmodified), has an empty resource type, meaning that it is not a collection (resourcetype), and supports both exclusive write and shared write locks (supportedlock).
DAV特定属性断言，“front.html”创建于1997年12月1日下午6:27:21，位于格林尼治标准时间（creationdate）以西8小时的时区，名称为“示例html资源”（displayname），内容长度为4525字节（getcontentlength），MIME类型为“text/html”（getcontenttype），实体标记为“zzyzx”（getetag），上次修改时间为1998年1月12日星期一09:25:56 GMT（getlastmodified），资源类型为空，这意味着它不是集合（resourcetype），并且支持独占写锁和共享写锁（supportedlock）。
>>Request
>>请求
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Type: text/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: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://www.foo.bar/container/</href>
<propstat>
<prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/>
<R:author/>
<creationdate/>
<displayname/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>http://www.foo.bar/container/front.html</href>
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://www.foo.bar/container/</href>
<propstat>
<prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/>
<R:author/>
<creationdate/>
<displayname/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>http://www.foo.bar/container/front.html</href>
<propstat>
<prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/>
<creationdate/>
<displayname/>
<getcontentlength/>
<getcontenttype/>
<getetag/>
<getlastmodified/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
<propstat>
<prop xmlns:R="http://www.foo.bar/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.foo.bar/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 progeny should be returned.
在本例中，在集合资源上调用PROPFINDhttp://www.foo.bar/container/，带有包含propname XML元素的propfind XML元素，这意味着应返回所有属性的名称。由于不存在深度标头，因此它假定其默认值为“无穷大”，这意味着应该返回集合及其所有子代上的属性名称。
Consistent with the previous example, resource http://www.foo.bar/container/ has six properties defined on it, http://www.foo.bar/boxschema/bigbox, http://www.foo.bar/boxschema/author, DAV:creationdate, DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
与前面的示例一致，资源http://www.foo.bar/container/ 定义了六个属性，http://www.foo.bar/boxschema/bigbox, http://www.foo.bar/boxschema/author，DAV:creationdate，DAV:displayname，DAV:resourcetype和DAV:supportedlock。
The resource http://www.foo.bar/container/index.html, a member of the "container" collection, has nine properties defined on it, http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
资源http://www.foo.bar/container/index.html，是“container”集合的成员，在其上定义了九个属性，http://www.foo.bar/boxschema/bigbox、DAV:creationdate、DAV:displayname、DAV:getcontentlength、DAV:getcontenttype、DAV:getetag、DAV:getlastmodified、DAV:resourcetype和DAV:supportedlock。
This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain an explicit "shorthand name" (prefix) letter, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace schema.
此示例还演示了XML名称空间范围和默认名称空间的使用。由于“xmlns”属性不包含显式的“速记名称”（前缀）字母，因此默认情况下，名称空间应用于所有封闭的元素。因此，所有没有显式声明它们所属的名称空间的元素都是“DAV:”名称空间模式的成员。
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 of the DAV schema. 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方法，并且必须处理使用DAV模式的propertyupdate、set和remove XML元素指定的指令。当然，此方法中指令的执行受访问控制约束。符合DAV的资源应支持设置任意死属性。
The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. Instruction processing MUST occur in the order instructions are received (i.e., from top to bottom). 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 section 12.13.
PROPPATCH方法的请求消息体必须包含propertyupdate XML元素。指令处理必须按照接收指令的顺序进行（即从上到下）。指令必须全部执行或不执行。因此，如果在处理过程中发生任何错误，则必须撤消所有执行的指令，并返回正确的错误结果。指令处理详细信息可在第12.13节的集合和移除指令定义中找到。
The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response.
以下是本方法207（多状态）响应中预期使用的响应代码示例。但是，请注意，除非明确禁止，否则在207（多状态）响应中可以使用任何2/3/4/5xx系列响应代码。
200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate.
200（确定）-命令成功。由于主体中可能存在集合和移除的混合，因此201（已创建）似乎不合适。
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
403（禁止）-由于服务器选择不指定的原因，客户端无法更改其中一个属性。
409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property. This includes trying to set read-only properties.
409（冲突）-客户端提供了一个语义不适合该属性的值。这包括尝试设置只读属性。
423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it.
423（已锁定）-指定的资源已锁定，客户端不是锁所有者，或者锁类型要求提交锁令牌，但客户端未提交。
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
507（存储不足）-服务器没有足够的空间来记录属性。
>>Request
>>请求
PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://www.w3.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://www.w3.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: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50">
<D:response>
<D:href>http://www.foo.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 can not 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://www.w3.com/standards/z39.50">
<D:response>
<D:href>http://www.foo.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 can not be deleted or
altered.</D:responsedescription>
</D:response>
</D:multistatus>
In this example, the client requests the server to set the value of the http://www.w3.com/standards/z39.50/Authors property, and to remove the property http://www.w3.com/standards/z39.50/Copyright-Owner. 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://www.w3.com/standards/z39.50/Authors 属性，并删除该属性http://www.w3.com/standards/z39.50/Copyright-Owner. 由于无法删除版权所有者的财产，因此不会发生财产修改。Authors属性的424（失败的依赖项）状态代码表示，如果不是因为与删除版权所有者属性冲突，此操作将成功。
The MKCOL method is used to create a new collection. All DAV compliant resources MUST support the MKCOL method.
MKCOL方法用于创建新集合。所有符合DAV的资源都必须支持MKCOL方法。
MKCOL creates a new collection resource at the location specified by the Request-URI. If the resource identified by the Request-URI is non-null then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI a 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 neither /a/b/ nor /a/b/c/ exists, the request must fail.
MKCOL在请求URI指定的位置创建新的集合资源。如果请求URI标识的资源为非空，则MKCOL必须失败。在MKCOL处理期间，服务器必须使请求URI成为其父集合的成员，除非请求URI为“/”。如果不存在这样的祖先，则该方法必须失败。当MKCOL操作创建新的集合资源时，所有祖先必须已经存在，否则该方法必须失败，状态代码为409（冲突）。例如，如果发出创建集合/a/b/c/d/的请求，并且/a/b/和/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 behavior of a MKCOL request when the body is present is 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. The exact behavior of MKCOL for various request media types is undefined in this document, and will be specified in separate documents.
MKCOL请求消息可能包含消息正文。存在主体时，MKCOL请求的行为仅限于创建集合、集合成员、成员主体以及集合或成员的属性。如果服务器收到不支持或不理解的MKCOL请求实体类型，则必须使用415（不支持的媒体类型）状态代码进行响应。本文档未定义各种请求媒体类型的MKCOL的确切行为，将在单独的文档中指定。
Responses from a MKCOL request MUST NOT be cached as MKCOL has non-idempotent semantics.
不能缓存来自MKCOL请求的响应，因为MKCOL具有非幂等语义。
201 (Created) - The collection or structured resource was created in its entirety.
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 namespace, or 2) the parent collection of the Request-URI exists but cannot accept members.
403（禁止）-这表示两种情况中的至少一种：1）服务器不允许在其命名空间中的给定位置创建集合，或2）请求URI的父集合存在但无法接受成员。
405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource.
405（不允许使用方法）-只能对已删除/不存在的资源执行MKCOL。
409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created.
409（冲突）-在创建一个或多个中间集合之前，无法在请求URI处创建集合。
415 (Unsupported Media Type)- The server does not support the request type of the body.
415（不支持的媒体类型）-服务器不支持主体的请求类型。
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.server.org.
本例在服务器www.server.org上创建一个名为/webdisc/xfiles/的集合。
>>Request
>>请求
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org
>>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" [RFC2068]. 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标识的任何信息（以实体的形式）”[RFC2068]。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的语义在应用于集合时不会被修改。
8.6.1 DELETE for Non-Collection Resources
8.6.1 非集合资源的删除
If the DELETE method is issued to a non-collection resource whose URIs are an internal member of one or more collections, then during DELETE processing a server MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member.
如果向URI为一个或多个集合的内部成员的非集合资源发出DELETE方法，则在删除处理过程中，服务器必须从包含请求URI作为成员的集合中删除请求URI标识的资源的任何URI。
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 URIs are to be deleted.
DELETE指示删除请求URI中指定的集合及其内部成员URI标识的所有资源。
If any resource identified by a member URI cannot be deleted then all of the member's ancestors MUST NOT be deleted, so as to maintain namespace consistency.
如果无法删除由成员URI标识的任何资源，则不得删除该成员的所有祖先，以保持命名空间一致性。
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 namespace.
当DELETE方法完成处理后，它必须产生一致的命名空间。
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). 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status). 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.
如果请求URI中标识的资源以外的资源发生错误，则响应必须为207（多状态）。424（失败的依赖项）错误不应在207（多状态）中。它们可以被安全地忽略，因为当客户机收到祖先后代的错误时，客户机将知道无法删除资源的祖先。此外，207（多状态）中不应返回204（无内容）错误。此禁止的原因是204（无内容）是默认的成功代码。
>>Request
>>请求
DELETE /container/ HTTP/1.1
Host: www.foo.bar
DELETE /container/ HTTP/1.1
Host: www.foo.bar
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/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.foo.bar/container/resource3</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
</d:response>
</d:multistatus>
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.foo.bar/container/resource3</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
</d:response>
</d:multistatus>
In this example the attempt to delete http://www.foo.bar/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.foo.bar/container/ also failed. Thus the client knows that the attempt to delete http://www.foo.bar/container/ must have also failed since the parent can not 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.foo.bar/container/resource3 失败，因为它已锁定，并且没有随请求提交锁定令牌。因此，试图删除http://www.foo.bar/container/ 也失败了。因此，客户机知道尝试删除http://www.foo.bar/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（冲突）。
As defined in the HTTP/1.1 specification [RFC2068], the "PUT method requests that the enclosed entity be stored under the supplied Request-URI." Since submission of an entity representing a collection would implicitly encode creation and deletion of resources, this specification intentionally does not define a transmission format for creating a collection using PUT. Instead, the MKCOL method is defined to create collections.
根据HTTP/1.1规范[RFC2068]中的定义，“PUT方法请求将封闭的实体存储在提供的请求URI下。”因为表示集合的实体的提交将隐式编码资源的创建和删除，本规范无意定义使用PUT创建集合的传输格式。相反，定义MKCOL方法来创建集合。
When the PUT operation creates a new non-collection resource all ancestors MUST already exist. If all ancestors do not exist, the method MUST fail with a 409 (Conflict) status code. For example, if resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, then the request must fail.
PUT操作创建新的非集合资源时，所有祖先必须已经存在。如果不存在所有祖先，则该方法必须失败，状态代码为409（冲突）。例如，如果要创建资源/a/b/c/d.html而/a/b/c/不存在，则请求必须失败。
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的资源都必须支持复制方法。但是，对复制方法的支持并不能保证复制资源的能力。例如，不同的程序可以控制同一服务器上的资源。因此，可能无法将资源复制到似乎位于同一服务器上的位置。
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. After a successful COPY invocation, all properties on the source resource MUST be duplicated on the destination resource, subject to modifying headers and XML elements, following the definition for copying properties. 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.
当源资源不是集合时，复制方法的结果是在目标处创建一个新资源，其状态和行为与源资源的状态和行为尽可能匹配。复制调用成功后，源资源上的所有属性都必须复制到目标资源上，并根据复制属性的定义修改头和XML元素。由于服务器控制范围之外的因素（如缺少正确操作所需的资源），目标处的环境可能不同于源处的环境，因此可能无法完全复制目标处资源的行为。对目标资源的后续更改不会修改源资源。对源资源的后续更改不会修改目标资源。
The following section defines how properties on a resource are handled during a COPY operation.
下一节定义在复制操作期间如何处理资源上的属性。
Live properties SHOULD be duplicated as identically behaving live properties at the destination resource. If a property cannot be copied live, then its value MUST be duplicated, octet-for-octet, in an identically named, dead property on the destination resource subject to the effects of the propertybehavior XML element.
活动属性应在目标资源中复制为行为相同的活动属性。如果无法实时复制属性，则其值必须在目标资源上具有相同名称的死属性中以八位字节对八位字节进行复制，并受propertybehavior XML元素的影响。
The propertybehavior XML element can specify that properties are copied on best effort, that all live properties must be successfully copied or the method must fail, or that a specified list of live properties must be successfully copied or the method must fail. The propertybehavior XML element is defined in section 12.12.
propertybehavior XML元素可以指定尽最大努力复制属性，所有活动属性必须成功复制或方法必须失败，或者指定的活动属性列表必须成功复制或方法必须失败。propertybehavior XML元素在第12.12节中定义。
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". DAV compliant servers MUST support the "0" and "infinity" Depth header behaviors.
对于没有深度标头的集合，COPY方法的作用必须与包含值为“infinity”的深度标头一样。客户端可以提交集合副本上的深度标头，其值为“0”或“无限”。符合DAV的服务器必须支持“0”和“无限”深度标头行为。
A COPY of depth infinity 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.
深度无限的副本指示将请求URI标识的集合资源复制到目标标头中URI标识的位置，并通过集合层次结构的所有级别递归地将其所有内部成员资源复制到与其相关的位置。
A COPY of "Depth: 0" only instructs that the collection and its properties but not resources identified by its internal member URIs, are to be copied.
“Depth:0”的副本仅指示复制集合及其属性，而不指示复制由其内部成员URI标识的资源。
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://fun.com/ and the Destination is http://fun.com/b/ then when http://fun.com/a/c/d is processed it must use a Destination of http://fun.com/b/c/d.
目标标头仅指定请求URI的目标URI。当应用于由请求URI标识的集合成员时，将修改Destination的值以反映层次结构中的当前位置。因此，如果Request-URI是/a/，并且带有主机头值http://fun.com/ 目的地是http://fun.com/b/ 那么什么时候http://fun.com/a/c/d 如果已处理，则必须使用的目标http://fun.com/b/c/d.
When the COPY method has completed processing it MUST have created a consistent 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 descendents of an error-causing collection). 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.
复制方法完成处理后，必须在目标位置创建一致的命名空间（有关命名空间一致性的定义，请参见第5.1节）。但是，如果复制内部集合时发生错误，服务器不得复制此集合成员标识的任何资源（即，服务器必须跳过此子树），因为这将创建不一致的命名空间。检测到错误后，复制操作应尽可能多地完成原始复制操作（即，服务器仍应尝试复制其他子树及其成员，这些子树及其成员不是导致错误的集合的后代）。因此，例如，如果对包含集合/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).
如果执行COPY方法时发生错误，且资源不是请求URI中标识的资源，则响应必须为207（多状态）。
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 resource exists at the destination and the Overwrite header is "T" then prior to performing the copy 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”，则操作将失败。
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 pre-existing destination resource.
204（无内容）-源资源已成功复制到预先存在的目标资源。
403 (Forbidden) _ The source and destination URIs are the same.
403（禁止）\源URI和目标URI相同。
409 (Conflict) _ A resource cannot be created at the destination until one or more intermediate collections have been created.
409（冲突）\在创建一个或多个中间集合之前，无法在目标上创建资源。
412 (Precondition Failed) - The server was unable to maintain the liveness of the properties listed in the propertybehavior XML element or the Overwrite header is "F" and the state of the destination resource is non-null.
412（前置条件失败）-服务器无法保持propertybehavior XML元素中列出的属性的活动性，或者覆盖标头为“F”，并且目标资源的状态为非空。
423 (Locked) - The destination resource was locked.
423（已锁定）-目标资源已锁定。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource.
502（坏网关）-当目标服务器位于另一台服务器上且目标服务器拒绝接受资源时，可能会发生这种情况。
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.ics.uci.edu/~fielding/index.html being copied to the location http://www.ics.uci.edu/users/f/fielding/index.html. The 204 (No Content) status code indicates the existing resource at the destination was overwritten.
此示例显示了资源http://www.ics.uci.edu/~fielding/index.html正在复制到该位置http://www.ics.uci.edu/users/f/fielding/index.html. 204（无内容）状态代码表示目标上的现有资源已被覆盖。
>>Request
>>请求
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/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 resource has a non-null state.
以下示例显示了正在执行的相同复制操作，但覆盖标头设置为“F”。由于目标资源的状态为非空，因此返回412（前提条件失败）的响应。
>>Request
>>请求
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
Overwrite: F
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/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.foo.bar
Destination: http://www.foo.bar/othercontainer/
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
COPY /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d="DAV:">
<d:keepalive>*</d:keepalive>
</d:propertybehavior>
<?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d="DAV:">
<d:keepalive>*</d:keepalive>
</d:propertybehavior>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/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.foo.bar/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 412 Precondition Failed</d:status>
</d:response>
</d:multistatus>
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.foo.bar/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 412 Precondition Failed</d:status>
</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, most likely due to a problem with maintaining the liveness of properties (this is specified by the propertybehavior XML element). 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 given in section 8.8.3.
深度标头是不必要的，因为集合上复制的默认行为是充当“Depth:infinity”标头已提交的角色。在本例中，大多数资源以及集合都已成功复制。但是，集合R2失败，很可能是由于维护属性的活动性（这由propertybehavior XML元素指定）的问题。由于复制R2时出错，因此未复制R2的任何成员。然而，由于第8.8.3节中给出的误差最小化规则，这些构件未列出任何误差。
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 atomically. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URIs other than the Request-URI which identify the source resource, to point to the new destination resource. Consequently, 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 DAV compliant resources MUST support the MOVE method. However, support for the MOVE method does not guarantee the ability to move a resource to a particular destination.
非集合资源上的移动操作在逻辑上相当于一个拷贝（copy），然后是一致性维护处理，然后是源的删除，其中所有三个操作都是原子地执行的。一致性维护步骤允许服务器执行由移动引起的更新，例如更新除标识源资源的请求URI之外的所有URI，以指向新的目标资源。因此，目标标头必须出现在所有移动方法上，并且必须符合移动方法的复制部分的所有复制要求。所有符合DAV的资源都必须支持MOVE方法。但是，对MOVE方法的支持并不能保证将资源移动到特定目标的能力。
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.
例如，不同的程序实际上可能控制同一服务器上的不同资源集。因此，可能无法在似乎属于同一服务器的命名空间内移动资源。
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.
如果目标上存在资源，则根据覆盖标头的限制，作为移动操作的副作用，目标资源将被删除。
The behavior of properties on a MOVE, including the effects of the propertybehavior XML element, MUST be the same as specified in section 8.8.2.
移动时属性的行为，包括propertybehavior XML元素的效果，必须与第8.8.2节中规定的相同。
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the URI specified in the Destination header, and all resources identified by its internal member URIs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy.
带有“Depth:infinity”的移动指示将请求URI标识的集合移动到目标标头中指定的URI，并通过集合层次结构的所有级别递归地将其内部成员URI标识的所有资源移动到与其相关的位置。
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 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 descendents 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方法完成处理后，它必须在源和目标上创建一致的名称空间（有关名称空间一致性的定义，请参见第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).
如果请求URI中标识的资源以外的资源发生错误，则响应必须为207（多状态）。
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”，则操作将失败。
201 (Created) - The source resource was successfully moved, and a new resource was created at the destination.
201（已创建）-已成功移动源资源，并在目标位置创建了新资源。
204 (No Content) - The source resource was successfully moved to a pre-existing destination resource.
204（无内容）-源资源已成功移动到预先存在的目标资源。
403 (Forbidden) _ The source and destination URIs are the same.
403（禁止）\源URI和目标URI相同。
409 (Conflict) _ A resource cannot be created at the destination until one or more intermediate collections have been created.
409（冲突）\在创建一个或多个中间集合之前，无法在目标上创建资源。
412 (Precondition Failed) - The server was unable to maintain the liveness of the properties listed in the propertybehavior XML element or the Overwrite header is "F" and the state of the destination resource is non-null.
412（前置条件失败）-服务器无法保持propertybehavior XML元素中列出的属性的活动性，或者覆盖标头为“F”，并且目标资源的状态为非空。
423 (Locked) - The source or the destination resource was locked.
423（已锁定）-源或目标资源已锁定。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource.
502（坏网关）-当目标服务器位于另一台服务器上且目标服务器拒绝接受资源时，可能会发生这种情况。
This example shows resource http://www.ics.uci.edu/~fielding/index.html being moved to the location http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination resource had been non-null. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
此示例显示了资源http://www.ics.uci.edu/~fielding/index.html正在移动到该位置http://www.ics.uci.edu/users/f/fielding/index.html. 如果目标资源为非空，则目标资源的内容将被覆盖。在这种情况下，由于目标资源中没有任何内容，因此响应代码为201（已创建）。
>>Request
>>请求
MOVE /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
MOVE /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
>>Response
>>回应
HTTP/1.1 201 Created
Location: http://www.ics.uci.edu/users/f/fielding/index.html
HTTP/1.1 201 Created
Location: http://www.ics.uci.edu/users/f/fielding/index.html
>>Request
>>请求
MOVE /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Overwrite: F
If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
MOVE /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Overwrite: F
If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d='DAV:'>
<d:keepalive>*</d:keepalive>
</d:propertybehavior>
<?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d='DAV:'>
<d:keepalive>*</d:keepalive>
</d:propertybehavior>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/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.foo.bar/othercontainer/C2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
</d:response>
</d:multistatus>
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d='DAV:'>
<d:response>
<d:href>http://www.foo.bar/othercontainer/C2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
</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.foo.bar/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error copying /container/C2/, none of /container/C2's members were copied. However no errors were listed for those members due to the error minimization rules given in section 8.8.3. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
在本例中，客户机已随请求提交了大量锁令牌。在方法范围内的任何位置，需要为每个被锁定的资源（包括源和目标）提交一个锁令牌。在这种情况下，没有为目标提交正确的锁令牌http://www.foo.bar/othercontainer/C2/. 这意味着无法移动资源/容器/C2/。由于复制/container/C2/时出错，因此未复制/container/C2的任何成员。然而，由于第8.8.3节中给出的误差最小化规则，这些构件未列出任何误差。用户代理身份验证以前是通过HTTP协议范围之外的机制在底层传输层中进行的。
The following sections describe the LOCK method, which is used to take out a lock of any access type. 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方法并且与所请求的锁的访问类型无关的语义。
Any resource which supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein.
任何支持锁方法的资源至少必须支持本文定义的XML请求和响应格式。
A LOCK method invocation creates the lock specified by the lockinfo XML element on the Request-URI. Lock method requests SHOULD have a XML request body which contains an owner XML element for this lock request, unless this is a refresh request. The LOCK request may have a Timeout header.
LOCK方法调用在请求URI上创建由lockinfoxml元素指定的锁。锁方法请求应该有一个XML请求体，其中包含此锁请求的所有者XML元素，除非这是一个刷新请求。锁定请求可能有一个超时标头。
Clients MUST assume that locks may 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, an administrator 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. The response MUST contain the value of the lockdiscovery property in a prop XML element.
客户机必须假设锁可以在任何时候任意消失，而不管超时头中给出的值如何。Timeout标头仅在未发生“异常”情况时指示服务器的行为。例如，管理员可以随时删除锁，或者系统可能会崩溃，从而丢失锁存在的记录。响应必须在prop XML元素中包含lockdiscovery属性的值。
In order to indicate the lock token associated with a newly created lock, a Lock-Token response header MUST be included in the response for every successful LOCK request for a new lock. Note that the Lock-Token header would not be returned in the response for a successful refresh LOCK request because a new lock was not created.
为了指示与新创建的锁关联的锁令牌，对于新锁的每个成功锁请求，必须在响应中包含锁令牌响应头。请注意，由于未创建新锁，因此在成功刷新锁请求的响应中不会返回锁令牌头。
The scope of a lock is the entire state of the resource, including its body and associated properties. As a result, a lock on a resource MUST also lock the resource's properties.
锁的作用域是资源的整个状态，包括其主体和相关属性。因此，对资源的锁定也必须锁定资源的属性。
For collections, a lock also affects the ability to add or remove members. The nature of the effect depends upon the type of access control involved.
对于集合，锁还影响添加或删除成员的能力。影响的性质取决于所涉及的访问控制类型。
A resource may be made available through more than one URI. However locks apply to resources, not URIs. Therefore a LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable.
一个资源可以通过多个URI提供。但是，锁应用于资源，而不是URI。因此，如果资源可寻址的所有URI都不能满足对资源的锁定请求，那么对资源的锁定请求就不能成功。
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 internal members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token which represents all the resources that have been locked. If an UNLOCK is successfully executed on this token, all associated resources are unlocked. If the lock cannot be granted to all resources, a 409 (Conflict) status code MUST be returned with a response entity body containing a multistatus XML element describing which resource(s) prevented the lock from being granted. Hence, partial success is not an option. Either the entire hierarchy is locked or no resources are locked.
如果深度头设置为无穷大，那么请求URI中指定的资源及其所有内部成员（一直到层次结构）都将被锁定。成功的结果必须返回一个表示所有已锁定资源的锁定令牌。如果在此令牌上成功执行解锁，则将解锁所有关联的资源。如果无法将锁授予所有资源，则必须返回409（冲突）状态代码，并返回一个包含multistatus XML元素的响应实体体，该元素描述了哪些资源阻止授予锁。因此，部分成功不是一种选择。要么锁定整个层次结构，要么不锁定任何资源。
If no Depth header is submitted on a LOCK request then the request MUST act as if a "Depth:infinity" had been submitted.
如果锁请求中没有提交深度头，那么请求必须像提交了“深度：无限大”一样。
The interaction of a LOCK with various methods is dependent upon the lock type. However, independent of lock type, a successful DELETE of a resource MUST cause all of its locks to be removed.
锁与各种方法的交互取决于锁的类型。但是，与锁类型无关，成功删除资源必须导致删除其所有锁。
The table below describes the behavior that occurs when a lock request is made on a resource.
下表描述了对资源发出锁定请求时发生的行为。
Current lock state/ | Shared Lock | Exclusive
Lock request | | Lock
=====================+=================+==============
None | True | True
---------------------+-----------------+--------------
Shared Lock | True | False
---------------------+-----------------+--------------
Exclusive Lock | False | False*
------------------------------------------------------
Current lock state/ | Shared Lock | Exclusive
Lock request | | Lock
=====================+=================+==============
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 the lock must not be granted.
资源的当前锁定状态在最左边的列中给出，锁定请求列在第一行中。行和列的交集给出锁定请求的结果。例如，如果资源上持有共享锁，并且请求了独占锁，则表项为“false”，表示不能授予该锁。
200 (OK) - The lock request succeeded and the value of the lockdiscovery property is included in the body.
200（确定）-锁请求成功，并且锁发现属性的值包含在正文中。
412 (Precondition Failed) - The included lock token was not enforceable on this resource or the server could not satisfy the request in the lockinfo XML element.
412（前置条件失败）-包含的锁令牌在此资源上不可执行，或者服务器无法满足lockinfo XML元素中的请求。
423 (Locked) - The resource is locked, so the method has been rejected.
423（已锁定）-资源已锁定，因此该方法已被拒绝。
>>Request
>>请求
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.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://www.ics.uci.edu/~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://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>回应
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200 OK
Content-Type: text/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>
<?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://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This example shows the successful creation of an exclusive write lock on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The resource http://www.ics.uci.edu/~ejw/contact.html contains contact information for the owner 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://webdav.sb.aol.com/workspace/webdav/proposal.doc. 资源http://www.ics.uci.edu/~ejw/contact.html包含锁所有者的联系信息。服务器在此资源上具有基于活动的超时策略，这会导致锁在1周（604800秒）后自动移除。请注意，尚未在授权请求标头中计算nonce、response和不透明字段。
>>Request
>>请求
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
>>回应
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200 OK
Content-Type: text/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>
<?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://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>Infinity</D:depth>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This request would refresh the lock, resetting any time outs. 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: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
LOCK /webdav/ HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
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://www.ics.uci.edu/~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://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>回应
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
<D:response>
<D:href>http://webdav.sb.aol.com/webdav/</D:href>
<D:propstat>
<D:prop><D:lockdiscovery/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</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://webdav.sb.aol.com/webdav/secret</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
<D:response>
<D:href>http://webdav.sb.aol.com/webdav/</D:href>
<D:propstat>
<D:prop><D:lockdiscovery/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
</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://webdav.sb.aol.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the lockdiscovery property for the Request-URI has been included as required. In this example the lockdiscovery property is empty which means that there are no outstanding locks on the resource.
错误是资源上的403（禁止）响应http://webdav.sb.aol.com/webdav/secret. 由于无法锁定此资源，因此未锁定任何资源。还请注意，请求URI的lockdiscovery属性已根据需要包括在内。在本例中，lockdiscovery属性为空，这意味着资源上没有未完成的锁。
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 from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail.
UNLOCK方法从请求URI中移除由锁令牌请求头中的锁令牌标识的锁，以及锁中包含的所有其他资源。如果无法解锁提交的锁定令牌下锁定的所有资源，则解锁请求必须失败。
Any DAV compliant resource which supports the LOCK method MUST support the UNLOCK method.
任何支持锁定方法的符合DAV的资源都必须支持解锁方法。
>>Request
>>请求
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.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 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://webdav.sb.aol.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. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body.
在此示例中，由锁令牌“opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7”标识的锁已成功从资源中删除http://webdav.sb.aol.com/workspace/webdav/info.doc. 如果此锁包含多个资源，则会从锁中包含的所有资源中删除该锁。使用204（无内容）状态代码代替200（确定），因为没有响应实体体。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
在本例中，未在授权请求标头中计算nonce、response和不透明字段。
9 HTTP Headers for Distributed Authoring
9用于分布式创作的HTTP头
DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
This header indicates that the resource supports the DAV schema and protocol as specified. All DAV compliant resources MUST return the DAV header on all OPTIONS responses.
此标头表示资源支持指定的DAV架构和协议。所有符合DAV的资源必须在所有选项响应上返回DAV头。
The value is a list of all compliance classes that the resource supports. Note that above a comma has already been added to the 2. This is because a resource can not be level 2 compliant unless it is also level 1 compliant. Please refer to section 15 for more details. In general, however, support for one compliance class does not entail support for any other.
该值是资源支持的所有符合性类的列表。请注意，上面的逗号已添加到2。这是因为资源不能符合级别2，除非它也符合级别1。有关更多详细信息，请参阅第15节。但是，一般来说，对一个遵从性类的支持并不意味着对任何其他遵从性类的支持。
Depth = "Depth" ":" ("0" | "1" | "infinity")
Depth = "Depth" ":" ("0" | "1" | "infinity")
The Depth header is used with methods executed on resources which 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 immediate children, ("Depth: 1"), or the resource and all its progeny ("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 which 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 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.
因此，例如，复制层次结构的尝试可能会导致部分成员被复制，而部分成员未被复制。
Any headers on a method that has a defined interaction with the Depth header MUST be applied to all resources in the scope of the method except where alternative behavior is explicitly defined. For example, an If-Match header will have its value applied against every resource in the method's scope and will cause the method to fail if the header fails to match.
方法上与深度标头具有定义交互的任何标头都必须应用于该方法范围内的所有资源，除非明确定义了替代行为。例如，If-Match头将对方法作用域中的每个资源应用其值，并且如果头未能匹配，将导致方法失败。
If a resource, source or destination, within the scope of the method with a 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 children. If a resource does not have internal children then the Depth header MUST be ignored.
深度标题仅指定与内部子级相关的方法行为。如果资源没有内部子级，则必须忽略深度标头。
Please note, however, that it is always an error to submit a value for the Depth header that is not allowed by the method's definition. Thus submitting a "Depth: 1" on a COPY, even if the resource does not have internal members, will result in a 400 (Bad Request). The method should fail not because the resource doesn't have internal members, but because of the illegal value in the header.
但是，请注意，提交方法定义不允许的深度标头值始终是错误的。因此，在副本上提交“深度：1”，即使资源没有内部成员，也会导致400（错误请求）。该方法应该失败，不是因为资源没有内部成员，而是因为头中的值非法。
Destination = "Destination" ":" absoluteURI
Destination=“Destination”“：”绝对URI
The Destination header specifies the URI which identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters. Note that the absoluteURI production is defined in [RFC2396].
目标标头指定URI，该URI标识复制和移动等方法的目标资源，这些方法将两个URI作为参数。请注意，[RFC2396]中定义了绝对URI生成。
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List
Tagged-list = Resource 1*List
Resource = Coded-URL
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
State-token = Coded-URL
Coded-URL = "<" absoluteURI ">"
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List
Tagged-list = Resource 1*List
Resource = Coded-URL
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
State-token = Coded-URL
Coded-URL = "<" absoluteURI ">"
The If header is intended to have similar functionality to the If-Match header defined in section 14.25 of [RFC2068]. However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource 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标头的功能与[RFC2068]第14.25节中定义的If匹配标头类似。然而，If报头用于表示状态信息（称为状态令牌）的任何URI，该状态信息与资源以及etag有关。状态令牌的一个典型示例是锁令牌，锁令牌是本规范中定义的唯一状态令牌。
All DAV compliant resources MUST honor the If header.
所有符合DAV的资源都必须遵守If头。
The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). If one of the described state lists matches the state of the resource then the request may succeed.
If标题的目的是描述一系列状态列表。如果应用头的资源的状态与任何指定的状态列表都不匹配，则请求必须以412失败（前提条件失败）。如果所描述的状态列表之一与资源的状态匹配，则请求可能会成功。
Note that the absoluteURI production is defined in [RFC2396].
请注意，[RFC2396]中定义了绝对URI生成。
The No-tag-list production describes a series of state tokens and ETags. If multiple No-tag-list productions are used then one only needs to match the state of the resource for the method to be allowed to continue.
无标记列表产品描述了一系列状态标记和ETag。如果使用了多个无标记列表产品，那么其中一个只需要匹配资源的状态，方法才能继续。
If a method, due to the presence of a Depth or Destination header, is applied to multiple resources then the No-tag-list production MUST be applied to each resource the method is applied to.
如果由于存在深度或目标标头而将某个方法应用于多个资源，则必须将无标记列表生产应用于该方法应用于的每个资源。
If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another
ETag"])
If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another
ETag"])
The previous header would require that any resources within the scope of the method must either be locked with the specified lock token and in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag". To put the matter more plainly one can think of the previous If header as being in the form (or (and <locktoken:a-write-lock-token> ["I am an ETag"]) (and ["I am another ETag"])).
前面的头将要求该方法范围内的任何资源必须使用指定的锁令牌锁定，并且处于由“I am an ETag”ETag标识的状态，或者处于由第二个ETag“I am另一个ETag”标识的状态。更清楚地说，我们可以将前面的If头想象成以下形式（或（和<locktoken:a-write-lock-token>[“我是一个ETag]”）（和[“我是另一个ETag]”）。
The tagged-list production scopes a list production. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any.
带标记的列表生产范围为列表生产。也就是说，它指定遵循资源规范的列表仅适用于指定的资源。资源生产的范围从紧接着资源生产的列表生产开始，到下一个资源生产结束（如果有）。
When the If header is applied to a particular resource, the Tagged-list productions MUST be searched to determine if any of the listed resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section.
当If头应用于特定资源时，必须搜索带标记的列表产品，以确定列出的资源是否与当前方法的操作数资源匹配。如果没有任何资源产品与当前资源匹配，则必须忽略标头。如果其中一个资源产品与所考虑的资源名称不匹配，则必须按照上一节中指定的方式将资源产品后面的列表产品应用于该资源。
The same URI MUST NOT appear more than once in a resource production in an If header.
同一URI在If头的资源生产中不得出现多次。
COPY /resource1 HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/resource2
If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>
[W/"A weak ETag"]) (["strong ETag"])
<http://www.bar.bar/random>(["another strong ETag"])
COPY /resource1 HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/resource2
If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>
[W/"A weak ETag"]) (["strong ETag"])
<http://www.bar.bar/random>(["another strong ETag"])
In this example http://www.foo.bar/resource1 is being copied to http://www.foo.bar/resource2. When the method is first applied to http://www.foo.bar/resource1, resource1 must be in the state specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"]) (["strong ETag"])", that is, it either must be locked with a lock token of "locktoken:a-write-lock-token" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag".
在这个例子中http://www.foo.bar/resource1 正在复制到http://www.foo.bar/resource2. 当该方法首次应用于http://www.foo.bar/resource1，resource1必须处于由“（<locktoken:a-write-lock-token>[W/“弱ETag”]）（[“强ETag”]）”指定的状态，也就是说，它必须使用锁令牌“locktoken:a-write-lock-token”锁定，并且具有弱实体标记W/“弱ETag”，或者它必须具有强实体标记“强ETag”。
That is the only success condition since the resource http://www.bar.bar/random never has the method applied to it (the only other resource listed in the If header) and http://www.foo.bar/resource2 is not listed in the If header.
这是自资源使用以来唯一的成功条件http://www.bar.bar/random 从未将该方法应用于它（If头中列出的唯一其他资源），并且http://www.foo.bar/resource2 未在If标题中列出。
Every state token or ETag is either current, and hence describes the state of a resource, or is not current, and does not describe the state of a resource. The boolean operation of matching a state token or ETag to the current state of a resource thus resolves to a true or false value. The not production is used to reverse that value. The scope of the not production is the state-token or entity-tag immediately following it.
每个状态令牌或ETag要么是当前的，因此描述资源的状态；要么不是当前的，并且不描述资源的状态。因此，将状态标记或ETag与资源的当前状态相匹配的布尔操作将解析为true或false值。“非生产”用于反转该值。not production的范围是紧随其后的状态标记或实体标记。
If: (Not <locktoken:write1> <locktoken:write2>)
If: (Not <locktoken:write1> <locktoken:write2>)
When submitted with a request, this If header requires that all operand resources must not be locked with locktoken:write1 and must be locked with locktoken:write2.
当与请求一起提交时，此If标头要求所有操作数资源不得使用locktoken:write1锁定，且必须使用locktoken:write2锁定。
When performing If header processing, the definition of a matching state token or entity tag is as follows.
在执行If头处理时，匹配状态标记或实体标记的定义如下所示。
Matching entity tag: Where the entity tag matches an entity tag associated with that resource.
匹配实体标记：其中实体标记匹配与该资源关联的实体标记。
Matching state token: Where there is an exact match between the state token in the If header and any state token on the resource.
匹配状态令牌：If头中的状态令牌与资源上的任何状态令牌之间存在精确匹配。
Non-DAV compliant 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 "Cache-Control: no-cache" request header MUST be used 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”请求头。
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 header specifies whether the server should overwrite the state of a non-null destination resource during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the state of the destination resource is non-null. 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 the If-Match: * header of HTTP/1.1, If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE.
Overwrite标头指定服务器是否应在复制或移动期间覆盖非空目标资源的状态。值“F”表示，如果目标资源的状态为非空，则服务器不得执行复制或移动操作。如果复制或移动请求中未包含覆盖标头，则资源必须将该请求视为具有值“T”的覆盖标头。虽然覆盖标头似乎与HTTP/1.1的If Match:*标头的功能重复，但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.
如果由于覆盖标头的值而未执行复制或移动，则该方法必须失败，状态代码为412（前置条件失败）。
All DAV compliant resources MUST support the Overwrite header.
所有符合DAV的资源都必须支持覆盖标头。
The Status-URI response header may be used with the 102 (Processing) status code to inform the client as to the status of a method.
状态URI响应报头可与102（处理）状态代码一起使用，以通知客户端方法的状态。
Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
is defined in 6.1.1 of [RFC2068]
Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
is defined in 6.1.1 of [RFC2068]
The URIs listed in the header are source resources which have been affected by the outstanding method. The status code indicates the resolution of the method on the identified resource. So, for example, if a MOVE method on a collection is outstanding and a 102 (Processing) response with a Status-URI response header is returned, the included URIs will indicate resources that have had move attempted on them and what the result was.
标头中列出的URI是受未完成方法影响的源资源。状态代码表示方法在已识别资源上的分辨率。因此，例如，如果集合上的移动方法未完成，并且返回了带有状态URI响应头的102（处理）响应，则包含的URI将指示已尝试在其上移动的资源以及结果。
TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
DAVTimeOutVal = 1*digit
Other = "Extend" field-value ; See section 4.2 of [RFC2068]
TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
DAVTimeOutVal = 1*digit
Other = "Extend" field-value ; See section 4.2 of [RFC2068]
Clients may include Timeout 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.
客户端的锁请求中可能包含超时头。然而，服务器不需要尊重或甚至考虑这些请求。客户端不得使用锁方法以外的任何方法提交超时请求标头。
A Timeout request header MUST contain at least one TimeType and may contain multiple TimeType entries. The purpose of listing multiple TimeType entries is to indicate multiple different values and value types that are acceptable to the client. The client lists the TimeType entries in order of preference.
超时请求标头必须至少包含一个TimeType，并且可以包含多个TimeType条目。列出多个TimeType条目的目的是指示客户端可以接受的多个不同值和值类型。客户机按首选项的顺序列出时间类型条目。
Timeout response values MUST use a Second value, Infinite, or a TimeType the client has indicated familiarity with. The server may assume a client is familiar with any TimeType submitted in a Timeout header.
超时响应值必须使用第二个值（无限）或客户端表示熟悉的时间类型。服务器可能假定客户机熟悉超时头中提交的任何时间类型。
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。
The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received.
每当锁的所有者向锁的任何成员发送方法（包括不受支持的方法或不成功的方法）时，都应重新启动超时计数器。但是，如果成功接收到刷新锁方法，则必须刷新锁。
If the timeout expires then the lock may be lost. Specifically, if the server wishes to harvest the lock upon time-out, 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. Thus logs should be updated with the disposition of the lock, notifications should be sent, etc., just as they would be for an UNLOCK request.
它凌驾于权威之上。因此，日志应该随着锁的处置而更新，应该发送通知等等，就像解锁请求一样。
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 off-line.
建议服务器密切关注客户端提交的值，因为它们将指示客户端打算执行的活动类型。例如，在浏览器中运行的小程序可能需要锁定资源，但由于运行小程序的环境不稳定，小程序可能会在没有警告的情况下关闭。因此，小程序可能会请求一个相对较小的超时值，以便在小程序死亡时，可以快速获取锁。但是，文档管理系统可能会要求非常长的超时时间，因为它的用户可能计划脱机。
A client MUST NOT assume that just because the time-out has expired the lock has been lost.
客户端不能仅仅因为超时时间已过就认为锁已丢失。
10 Status Code Extensions to HTTP/1.1
HTTP/1.1的10个状态代码扩展
The following status codes are added to those defined in HTTP/1.1 [RFC2068].
以下状态代码添加到HTTP/1.1[RFC2068]中定义的状态代码中。
The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed.
102（处理）状态代码是一个临时响应，用于通知客户端服务器已接受完整的请求，但尚未完成。只有当服务器合理预期请求将花费大量时间完成时，才应发送此状态代码。作为指导，如果方法处理时间超过20秒（合理但任意的值），服务器应返回102（处理）响应。服务器必须在请求完成后发送最终响应。
Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.
方法可能需要很长时间来处理，尤其是支持深度标头的方法。在这种情况下，客户端可能会在等待响应时超时连接。为了防止这种情况，服务器可能会返回102（处理）状态代码，以向客户端指示服务器仍在处理该方法。
The 207 (Multi-Status) status code provides status for multiple independent operations (see section 11 for more information).
207（多状态）状态代码为多个独立操作提供状态（更多信息，请参阅第11节）。
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.
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 which 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（存储不足）状态代码表示无法在资源上执行该方法，因为服务器无法存储成功完成请求所需的表示。这种情况被认为是暂时的。如果收到此状态代码的请求是用户操作的结果，则在单独的用户操作请求之前，不得重复该请求。
11 Multi-Status Response
11多状态响应
The default 207 (Multi-Status) response body is a text/xml or application/xml HTTP entity that contains a single XML element called multistatus, which contains a set of XML elements called response which 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.
默认的207（多状态）响应主体是一个text/xml或application/xml HTTP实体，其中包含一个名为multistatus的xml元素，该元素包含一组名为response的xml元素，其中包含在方法调用期间生成的200、300、400和500系列状态代码。100系列状态代码不应记录在响应XML元素中。
12 XML Element Definitions
12 XML元素定义
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).
在下面的小节中，每个小节的最后一行使用[REC-XML]中定义的格式给出了元素类型声明。“Value”字段（如果存在）指定了对使用BNF的XML元素的允许内容的进一步限制（即，进一步限制PCDATA元素的值）。
Name: activelock Namespace: DAV: Purpose: Describes a lock on a resource.
名称：activelock命名空间：DAV:目的：描述资源上的锁。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?) >
<!元素activelock（锁定范围、锁定类型、深度、所有者？、超时？、锁定令牌？>
Name: depth
Namespace: DAV:
Purpose: The value of the Depth header.
Value: "0" | "1" | "infinity"
Name: depth
Namespace: DAV:
Purpose: The value of the Depth header.
Value: "0" | "1" | "infinity"
<!ELEMENT depth (#PCDATA) >
<!ELEMENT depth (#PCDATA) >
Name: locktoken Namespace: DAV: Purpose: The lock token associated with a lock. Description: The href contains one or more opaque lock token URIs which all refer to the same lock (i.e., the OpaqueLockToken-URI production in section 6.4).
名称：locktoken命名空间：DAV:Purpose:与锁关联的锁令牌。描述：href包含一个或多个不透明锁令牌URI，它们都引用同一个锁（即第6.4节中的OpaqueLockToken URI）。
<!ELEMENT locktoken (href+) >
<!ELEMENT locktoken (href+) >
Name: timeout
Namespace: DAV:
Purpose: The timeout associated with a lock
Value: TimeType ;Defined in section 9.8
Name: timeout
Namespace: DAV:
Purpose: The timeout associated with a lock
Value: TimeType ;Defined in section 9.8
<!ELEMENT timeout (#PCDATA) >
<!ELEMENT timeout (#PCDATA) >
Name: collection Namespace: DAV: Purpose: Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST have this value.
名称：集合命名空间：DAV:Purpose：将关联的资源标识为集合。集合资源的resourcetype属性必须具有此值。
<!ELEMENT collection EMPTY >
<!ELEMENT collection EMPTY >
Name: href
Namespace: DAV:
Purpose: Identifies the content of the element as a URI.
Value: URI ; See section 3.2.1 of [RFC2068]
Name: href
Namespace: DAV:
Purpose: Identifies the content of the element as a URI.
Value: URI ; See section 3.2.1 of [RFC2068]
<!ELEMENT href (#PCDATA)>
<!ELEMENT href (#PCDATA)>
Name: link Namespace: DAV: Purpose: Identifies the property as a link and contains the source and destination of that link. Description: The link XML element is used to provide the sources and destinations of a link. The name of the property containing the link XML element provides the type of the link. Link is a multi-valued element, so multiple links may be used together to indicate multiple links with the same type. The values in the href XML elements inside the src and dst XML elements of the link XML element MUST NOT be rejected if they point to resources which do not exist.
Name:link名称空间：DAV:Purpose：将属性标识为链接，并包含该链接的源和目标。描述：linkxml元素用于提供链接的源和目标。包含链接XML元素的属性的名称提供了链接的类型。链接是一个多值元素，因此多个链接可以一起使用，以表示具有相同类型的多个链接。如果链接XML元素的src和dst XML元素中的href XML元素中的值指向不存在的资源，则不得拒绝这些值。
<!ELEMENT link (src+, dst+) >
<!ELEMENT link (src+, dst+) >
Name: dst Namespace: DAV: Purpose: Indicates the destination of a link Value: URI
Name:dst名称空间：DAV:Purpose:指示链接值的目标：URI
<!ELEMENT dst (#PCDATA) >
<!ELEMENT dst (#PCDATA) >
Name: src Namespace: DAV: Purpose: Indicates the source of a link.
Name:src Namespace:DAV:Purpose:指示链接的源。
Value: URI
值：URI
<!ELEMENT src (#PCDATA) >
<!ELEMENT src (#PCDATA) >
Name: lockentry Namespace: DAV: Purpose: Defines the types of locks that can be used with the resource.
Name:lockentry命名空间：DAV:Purpose：定义可与资源一起使用的锁的类型。
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockentry (lockscope, locktype) >
Name: lockinfo Namespace: DAV: Purpose: The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created.
Name:lockinfo名称空间：DAV:Purpose:lockinfoxml元素与LOCK方法一起使用，以指定客户端希望创建的锁的类型。
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
Name: lockscope Namespace: DAV: Purpose: Specifies whether a lock is an exclusive lock, or a shared lock.
名称：lockscope命名空间：DAV:目的：指定锁是独占锁还是共享锁。
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT lockscope (exclusive | shared) >
Name: exclusive Namespace: DAV: Purpose: Specifies an exclusive lock
名称：独占命名空间：DAV:Purpose:指定独占锁
<!ELEMENT exclusive EMPTY >
<!ELEMENT exclusive EMPTY >
Name: shared Namespace: DAV: Purpose: Specifies a shared lock
名称：共享命名空间：DAV:目的：指定共享锁
<!ELEMENT shared EMPTY >
<!ELEMENT shared EMPTY >
Name: locktype Namespace: DAV: Purpose: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.
Name:locktype命名空间：DAV:Purpose:指定锁的访问类型。目前，该规范只定义了一种锁类型，即写锁。
<!ELEMENT locktype (write) >
<!ELEMENT locktype (write) >
Name: write Namespace: DAV: Purpose: Specifies a write lock.
Name:write命名空间：DAV:Purpose:指定写锁。
<!ELEMENT write EMPTY >
<!ELEMENT write EMPTY >
Name: multistatus Namespace: DAV: Purpose: Contains multiple response messages. Description: The responsedescription 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.
名称：multistatus命名空间：DAV:Purpose:包含多个响应消息。描述：顶层的responsedescription用于提供描述响应总体性质的一般消息。如果此值可用，应用程序可以使用它，而不是显示响应中包含的单个响应描述。
<!ELEMENT multistatus (response+, responsedescription?) >
<!ELEMENT multistatus (response+, responsedescription?) >
Name: response Namespace: DAV: Purpose: Holds a single response describing the effect of a method on resource and/or its properties. Description: A particular href 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.
Name:response Namespace:DAV:Purpose：保存一个响应，描述方法对资源和/或其属性的影响。描述：特定href不能作为multistatus XML元素下响应XML元素的子元素出现多次。为了保持响应线性时间的处理成本，这一要求是必要的。从本质上讲，这避免了必须搜索才能按href将所有响应分组。但是，对于基于href值的订购没有任何要求。
<!ELEMENT response (href, ((href*, status)|(propstat+)),
responsedescription?) >
<!ELEMENT response (href, ((href*, status)|(propstat+)),
responsedescription?) >
Name: propstat Namespace: DAV: Purpose: Groups together a prop and status element that is associated with a particular href element. 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.
Name:propstat名称空间：DAV:Purpose：将与特定href元素关联的prop和status元素分组在一起。描述：propstat XML元素必须包含一个prop XML元素和一个status XML元素。prop XML元素的内容必须仅列出status元素中的结果所应用的属性的名称。
<!ELEMENT propstat (prop, status, responsedescription?) >
<!ELEMENT propstat (prop, status, responsedescription?) >
Name: status
Namespace: DAV:
Purpose: Holds a single HTTP status-line
Value: status-line ;status-line defined in [RFC2068]
Name: status
Namespace: DAV:
Purpose: Holds a single HTTP status-line
Value: status-line ;status-line defined in [RFC2068]
<!ELEMENT status (#PCDATA) >
<!ELEMENT status (#PCDATA) >
Name: responsedescription Namespace: DAV: Purpose: Contains a message that can be displayed to the user explaining the nature of the response. Description: This XML element provides information suitable to be presented to a user.
Name:responsedescription命名空间：DAV:Purpose:包含一条消息，可向用户显示该消息，解释响应的性质。描述：此XML元素提供适合呈现给用户的信息。
<!ELEMENT responsedescription (#PCDATA) >
<!ELEMENT responsedescription (#PCDATA) >
Name: owner Namespace: DAV: Purpose: Provides information about the principal taking out a lock. Description: The owner XML element provides 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 of a homepage) who owns a lock.
Name:owner Namespace:DAV:Purpose:提供有关主体取出锁的信息。描述：ownerXML元素提供足够的信息，可以直接联系主体（如电话号码或电子邮件URI），也可以发现拥有锁的主体（如主页的URL）。
<!ELEMENT owner ANY>
<!ELEMENT owner ANY>
Name: prop Namespace: DAV: Purpose: Contains properties related to a resource. Description: The prop XML element is a generic container for properties defined on resources. All elements inside a prop XML element MUST define properties related to the resource. No other elements may be used inside of a prop element.
Name:prop命名空间：DAV:Purpose:包含与资源相关的属性。描述：prop-XML元素是资源上定义的属性的通用容器。prop XML元素中的所有元素都必须定义与资源相关的属性。支柱元件内部不得使用其他元件。
<!ELEMENT prop ANY>
<!ELEMENT prop ANY>
Name: propertybehavior Namespace: DAV: Purpose: Specifies how properties are handled during a COPY or MOVE. Description: The propertybehavior XML element specifies how properties are handled during a COPY or MOVE. If this XML element is not included in the request body then the server is expected to act as defined by the default property handling behavior of the associated method. All WebDAV compliant resources MUST support the propertybehavior XML element.
名称：propertybehavior命名空间：DAV:目的：指定在复制或移动期间如何处理属性。描述：propertybehavior XML元素指定在复制或移动期间如何处理属性。如果请求主体中不包含此XML元素，则服务器将按照关联方法的默认属性处理行为的定义进行操作。所有符合WebDAV的资源都必须支持propertybehavior XML元素。
<!ELEMENT propertybehavior (omit | keepalive) >
<!ELEMENT propertybehavior (omit | keepalive) >
Name: keepalive Namespace: DAV: Purpose: Specifies requirements for the copying/moving of live properties. Description: If a list of URIs is included as the value of keepalive then the named properties MUST be "live" after they are copied (moved) to the destination resource of a COPY (or MOVE). If the value "*" is given for the keepalive XML element, this designates that all live properties on the source resource MUST be live on the destination. If the requirements specified by the keepalive element can not be honored then the method MUST fail with a 412 (Precondition Failed). All DAV compliant resources MUST support the keepalive XML element for use with the COPY and MOVE methods. Value: "*" ; #PCDATA value can only be "*"
Name:keepalive Namespace:DAV:Purpose:指定复制/移动活动属性的要求。描述：如果URI列表包含为keepalive的值，则命名属性在复制（移动）到副本（或移动）的目标资源后必须是“活动”的。如果为keepalive XML元素提供了值“*”，则这表示源资源上的所有活动属性都必须在目标上活动。如果不能满足keepalive元素指定的要求，则该方法必须失败，并出现412（前提条件失败）。所有符合DAV的资源都必须支持keepalive XML元素，以便与COPY和MOVE方法一起使用。值：“*”#PCDATA值只能是“*”
<!ELEMENT keepalive (#PCDATA | href+) >
<!ELEMENT keepalive (#PCDATA | href+) >
Name: omit Namespace: DAV: Purpose: The omit XML element instructs the server that it should use best effort to copy properties but a failure to copy a property MUST NOT cause the method to fail. Description: The default behavior for a COPY or MOVE is to copy/move all properties or fail the method. In certain circumstances, such as when a server copies a resource over another protocol such as FTP, it may not be possible to copy/move the properties associated with the resource. Thus any attempt to copy/move over FTP would always have to fail because properties could not be moved over, even as dead properties. All DAV compliant resources MUST support the omit XML element on COPY/MOVE methods.
Name:omit Namespace:DAV:Purpose:omit XML元素指示服务器应尽最大努力复制属性，但复制属性失败不得导致方法失败。描述：复制或移动的默认行为是复制/移动所有属性或使方法失败。在某些情况下，例如当服务器通过另一协议（如FTP）复制资源时，可能无法复制/移动与资源关联的属性。因此，任何通过FTP进行复制/移动的尝试都必须失败，因为无法移动属性，即使是死掉的属性。所有符合DAV的资源都必须在复制/移动方法上支持省略XML元素。
<!ELEMENT omit EMPTY >
<!ELEMENT omit EMPTY >
Name: propertyupdate Namespace: DAV: 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. This XML element is multi-valued.
Name:propertyupdate命名空间：DAV:Purpose:包含更改资源属性的请求。描述：此XML元素是修改资源属性所需信息的容器。这个XML元素是多值的。
<!ELEMENT propertyupdate (remove | set)+ >
<!ELEMENT propertyupdate (remove | set)+ >
Name: remove Namespace: DAV: Purpose: Lists the DAV 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.
Name:remove Namespace:DAV:Purpose:列出要从资源中删除的DAV属性。Description:Remove指示应删除prop中指定的属性。指定删除不存在的属性不是错误。remove XML元素内部的prop XML元素中的所有XML元素都必须为空，因为只需要要删除的属性的名称。
<!ELEMENT remove (prop) >
<!ELEMENT remove (prop) >
Name: set Namespace: DAV: Purpose: Lists the DAV property values to be set for a resource.
Name:set Namespace:DAV:Purpose:列出要为资源设置的DAV属性值。
Description: The set XML element MUST contain only a prop XML element. The elements contained by the prop XML element inside the set XML 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 in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND.
描述：set XML元素必须仅包含prop XML元素。set-XML元素中prop-XML元素包含的元素必须指定在由请求URI标识的资源上设置的属性的名称和值。如果属性已存在，则替换其值。属性值中的语言标记信息（在“xml:lang”属性中，如果存在）必须与属性一起永久存储，并且随后必须使用PROPFIND进行检索。
<!ELEMENT set (prop) >
<!ELEMENT set (prop) >
Name: propfind Namespace: DAV: Purpose: Specifies the properties to be returned from a PROPFIND method. Two special elements are specified for use with propfind, allprop and propname. If prop is used inside propfind it MUST only contain property names, not values.
Name:propfind命名空间：DAV:Purpose:指定要从propfind方法返回的属性。为与propfind、allprop和propname一起使用指定了两个特殊元素。如果在propfind中使用prop，则它只能包含属性名，而不能包含值。
<!ELEMENT propfind (allprop | propname | prop) >
<!ELEMENT propfind (allprop | propname | prop) >
Name: allprop Namespace: DAV: Purpose: The allprop XML element specifies that all property names and values on the resource are to be returned.
Name:allprop Namespace:DAV:Purpose:allpropxml元素指定返回资源上的所有属性名和值。
<!ELEMENT allprop EMPTY >
<!ELEMENT allprop EMPTY >
Name: propname Namespace: DAV: Purpose: The propname XML element specifies that only a list of property names on the resource is to be returned.
Name:propname名称空间：DAV:Purpose:propname XML元素指定只返回资源上的属性名列表。
<!ELEMENT propname EMPTY >
<!ELEMENT propname EMPTY >
13 DAV Properties
13 DAV属性
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元素的值）。
Name: creationdate Namespace: DAV: Purpose: Records the time and date the resource was created. Value: date-time ; See Appendix 2 Description: The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created (i.e., the moment it had non-null state).
名称：creationdate命名空间：DAV:目的：记录创建资源的时间和日期。值：日期时间；请参阅附录2说明：应在所有符合DAV的资源上定义creationdate属性。如果存在，则它包含创建资源时的时间戳（即它具有非空状态的时刻）。
<!ELEMENT creationdate (#PCDATA) >
<!ELEMENT creationdate (#PCDATA) >
Name: displayname Namespace: DAV: Purpose: Provides a name for the resource that is suitable for presentation to a user. Description: The displayname property should be defined on all DAV compliant resources. If present, the property contains a description of the resource that is suitable for presentation to a user.
Name:displayname名称空间：DAV:Purpose：提供适合向用户演示的资源的名称。描述：应在所有符合DAV的资源上定义displayname属性。如果存在，则属性包含适合向用户显示的资源描述。
<!ELEMENT displayname (#PCDATA) >
<!ELEMENT displayname (#PCDATA) >
Name: getcontentlanguage Namespace: DAV: Purpose: Contains the Content-Language header returned by a GET without accept headers Description: The getcontentlanguage property MUST be defined on any DAV compliant resource that returns the Content-Language header on a GET. Value: language-tag ;language-tag is defined in section 14.13 of [RFC2068]
名称：getcontentlanguage命名空间：DAV:目的：包含GET返回的内容语言标头，但不包含accept标头说明：必须在GET上返回内容语言标头的任何符合DAV的资源上定义getcontentlanguage属性。值：语言标记；[RFC2068]第14.13节定义了语言标签
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlanguage (#PCDATA) >
Name: getcontentlength Namespace: DAV: Purpose: Contains the Content-Length header returned by a GET without accept headers. Description: The getcontentlength property MUST be defined on any DAV compliant resource that returns the Content-Length header in response to a GET.
Name:getcontentlength命名空间：DAV:Purpose:包含GET返回的内容长度头，但不包含accept头。描述：必须在任何符合DAV的资源上定义getcontentlength属性，该资源返回Content Length标头以响应GET。
Value: content-length ; see section 14.14 of [RFC2068]
值：内容长度；见[RFC2068]第14.14节
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontentlength (#PCDATA) >
Name: getcontenttype Namespace: DAV: Purpose: Contains the Content-Type header returned by a GET without accept headers. Description: This getcontenttype property MUST be defined on any DAV compliant resource that returns the Content-Type header in response to a GET. Value: media-type ; defined in section 3.7 of [RFC2068]
Name:getcontenttype命名空间：DAV:Purpose:包含GET返回的内容类型标头，但不包含accept标头。描述：必须在任何符合DAV的资源上定义此getcontenttype属性，该资源返回内容类型头以响应GET。值：媒体类型；[RFC2068]第3.7节中定义
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getcontenttype (#PCDATA) >
Name: getetag Namespace: DAV: Purpose: Contains the ETag header returned by a GET without accept headers. Description: The getetag property MUST be defined on any DAV compliant resource that returns the Etag header. Value: entity-tag ; defined in section 3.11 of [RFC2068]
Name:getetag名称空间：DAV:Purpose:包含GET返回的ETag头，但不包含accept头。描述：必须在返回Etag头的任何符合DAV的资源上定义getetag属性。值：实体标签；[RFC2068]第3.11节中定义
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getetag (#PCDATA) >
Name: getlastmodified Namespace: DAV: Purpose: Contains the Last-Modified header returned by a GET method without accept headers. Description: Note that the last-modified date on a resource may reflect changes in any part of the state of the resource, not necessarily just a change to the response to the GET method. For example, a change in a property may cause the last-modified date to change. The getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET. Value: HTTP-date ; defined in section 3.3.1 of [RFC2068]
Name:getlastmodified命名空间：DAV:Purpose:包含GET方法返回的上次修改的头，但不包含accept头。描述：请注意，资源的最后修改日期可能反映资源状态的任何部分的更改，而不一定只是对GET方法的响应的更改。例如，属性的更改可能会导致上次修改日期的更改。必须在任何符合DAV的资源上定义getlastmodified属性，该资源返回上次修改的头以响应GET。值：HTTP日期；[RFC2068]第3.3.1节中定义
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT getlastmodified (#PCDATA) >
Name: lockdiscovery Namespace: DAV: Purpose: Describes the active locks on a resource Description: The lockdiscovery property 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. The server is free to withhold any or all of this information if the requesting principal does not have sufficient access rights to see the requested data.
名称：lockdiscovery命名空间：DAV:目的：描述资源上的活动锁描述：lockdiscovery属性返回谁拥有锁、他拥有的锁类型、超时类型和超时剩余时间以及关联的锁令牌的列表。如果请求主体没有足够的访问权限查看请求的数据，服务器可以自由保留任何或所有这些信息。
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT lockdiscovery (activelock)* >
>>Request
>>请求
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml; charset="utf-8"
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/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: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/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.foo.bar/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>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:href>http://www.foo.bar/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>
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<D:href>
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
</D:href>
</D:locktoken>
</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 Namespace: DAV: Purpose: Specifies the nature of the resource. Description: The resourcetype property MUST be defined on all DAV compliant resources. The default value is empty.
名称：resourcetype命名空间：DAV:Purpose:指定资源的性质。描述：必须在所有符合DAV的资源上定义resourcetype属性。默认值为空。
<!ELEMENT resourcetype ANY >
<!ELEMENT resourcetype ANY >
Name: source Namespace: DAV: Purpose: The destination of the source link identifies the resource that contains the unprocessed source of the link's source. Description: The source of the link (src) is typically the URI of the output resource on which the link is defined, and there is typically only one destination (dst) of the link, which is the URI where the unprocessed source of the resource may be accessed. When more than one link destination exists, this specification asserts no policy on ordering.
名称：源命名空间：DAV:目的：源链接的目标标识包含链接源的未处理源的资源。描述：链接源（src）通常是定义链接的输出资源的URI，并且通常只有一个链接目的地（dst），这是可以访问未处理资源源的URI。当存在多个链接目的地时，此规范不主张订购策略。
<!ELEMENT source (link)* >
<!ELEMENT source (link)* >
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
<D:source>
<D:link>
<F:projfiles>Source</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
<D:source>
<D:link>
<F:projfiles>Source</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.c</D:dst>
</D:link>
<D:link>
<F:projfiles>Library</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.lib</D:dst>
</D:link>
<D:link>
<F:projfiles>Makefile</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/makefile</D:dst>
</D:link>
</D:source>
</D:prop>
<D:dst>http://foo.bar/src/main.c</D:dst>
</D:link>
<D:link>
<F:projfiles>Library</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.lib</D:dst>
</D:link>
<D:link>
<F:projfiles>Makefile</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/makefile</D:dst>
</D:link>
</D:source>
</D:prop>
In this example the resource http://foo.bar/program has a source property that contains three links. Each link contains three elements, two of which, src and dst, are part of the DAV schema defined in this document, and one which is defined by the schema http://www.foocorp.com/project/ (Source, Library, and Makefile). A client which only implements the elements in the DAV spec will not understand the foocorp elements and will ignore them, thus seeing the expected source and destination links. An enhanced client may know about the foocorp elements and be able to present the user with additional information about the links. This example demonstrates the power of XML markup, allowing element values to be enhanced without breaking older clients.
在本例中，资源http://foo.bar/program 具有包含三个链接的源属性。每个链接包含三个元素，其中两个元素src和dst是本文档中定义的DAV模式的一部分，另一个元素由模式定义http://www.foocorp.com/project/ （源代码、库和生成文件）。仅实现DAV规范中的元素的客户端将不理解foocorp元素，并将忽略它们，从而看到预期的源和目标链接。增强型客户端可能知道foocorp元素，并能够向用户提供有关链接的附加信息。此示例演示了XML标记的强大功能，允许在不中断旧客户端的情况下增强元素值。
Name: supportedlock Namespace: DAV: Purpose: To provide a listing of the lock capabilities supported by the resource. Description: The supportedlock property of a resource returns a listing of the combinations of scope and access types which 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.
Name:supportedlock命名空间：DAV:Purpose：提供资源支持的锁功能列表。描述：资源的supportedlock属性返回范围和访问类型组合的列表，这些类型可以在资源的锁定请求中指定。请注意，实际内容本身由访问控制控制，因此不需要服务器提供客户端无权查看的信息。
<!ELEMENT supportedlock (lockentry)* >
<!ELEMENT supportedlock (lockentry)* >
>>Request
>>请求
PROPFIND /container/ HTTP/1.1
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml; charset="utf-8"
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/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: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/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.foo.bar/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>
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foo.bar/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>
14 Instructions for Processing XML in DAV
14在DAV中处理XML的说明
All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language.
在处理使用XML作为命令语言的DAV方法时，所有符合DAV的资源都必须忽略任何未知的XML元素及其所有子元素。
This restriction also applies to the processing, by clients, of DAV property values where unknown 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 unknown XML elements.
此限制不适用于在服务器必须记录未知XML元素的服务器上设置死DAV属性。
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的主体时。
Since XML can be transported as text/xml or application/xml, a DAV server MUST accept DAV method requests with XML parameters transported as either text/xml or application/xml, and DAV client MUST accept XML responses using either text/xml or application/xml.
由于XML可以作为text/XML或application/XML传输，因此DAV服务器必须接受以text/XML或application/XML传输的XML参数的DAV方法请求，DAV客户端必须接受使用text/XML或application/XML的XML响应。
15 DAV Compliance Classes
15个DAV合规类
A DAV compliant resource can choose from two 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.
符合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 [RFC2068].
由于本文档描述了HTTP/1.1协议的扩展，因此至少所有符合DAV的资源、客户端和代理都必须符合[RFC2068]。
Compliance classes are not necessarily sequential. A resource that is class 2 compliant must also be class 1 compliant; but if additional compliance classes are defined later, a resource that is class 1, 2, and 4 compliant might not be class 3 compliant. Also note that identifiers other than numbers may be used as compliance class identifiers.
法规遵从性类不一定是连续的。符合类别2的资源也必须符合类别1；但如果以后定义了其他符合性类，则符合类1、2和4的资源可能不符合类3。还请注意，除数字以外的标识符可用作符合性类别标识符。
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 supportedlock property, the lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class "2" compliant resource SHOULD also support the Time-Out request header and the owner XML element.
与class 2兼容的资源必须满足所有class 1要求，并支持LOCK方法、supportedlock属性、lockdiscovery属性、超时响应标头和LOCK Token请求标头。与类“2”兼容的资源还应该支持超时请求头和所有者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”。
16 Internationalization Considerations
16国际化考虑
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 [UTF-8] encoding of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header, as defined in [RFC2376], as well as the XML "encoding" attribute, which together provide charset identification information for MIME and XML processors.
在国际化领域，本规范符合IETF字符集策略[RFC2277]。在本规范中，可以在属性的值或响应实体体中返回的错误消息中找到人类可读的字段。在这两种情况下，人类可读内容都使用XML编码，XML对字符集标记和编码有明确规定，并且要求XML处理器读取至少使用ISO10646多语言平面的UTF-8[UTF-8]编码编码的XML元素。本规范中的XML示例演示了如何使用[RFC2376]中定义的内容类型头的字符集参数以及XML“encoding”属性，它们共同为MIME和XML处理器提供字符集标识信息。
XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. XML uses either IANA registered language tags (see [RFC1766]) or ISO 639 language tags [ISO-639] in the "xml:lang" attribute of an XML element to identify the language of its content and attributes.
XML还提供了语言标记功能，用于指定特定XML元素内容的语言。XML在XML元素的“XML:lang”属性中使用IANA注册的语言标记（请参见[RFC1766]）或ISO 639语言标记[ISO-639]，以标识其内容和属性的语言。
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" [RFC2376] 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媒体类型”[RFC2376]，了解用于XML传输的MIME媒体类型以及内容类型标头的字符集参数的使用说明。
Names used within this specification fall into three categories: names of protocol elements such as methods and headers, names of XML elements, and names of properties. Naming of protocol elements follows the precedent of HTTP, using English names encoded in USASCII for methods and headers. Since these protocol elements are not visible to users, and are in fact simply long token identifiers, they do not need to support encoding in multiple character sets. Similarly, though the names of XML elements used in this specification are English names encoded in UTF-8, these names are not visible to the user, and hence do not need to support multiple character set encodings.
本规范中使用的名称分为三类：协议元素（如方法和头）的名称、XML元素的名称和属性的名称。协议元素的命名遵循HTTP的先例，方法和头使用USASCI编码的英文名称。由于这些协议元素对用户不可见，并且实际上只是长令牌标识符，因此它们不需要支持在多个字符集中编码。类似地，尽管本规范中使用的XML元素名称是以UTF-8编码的英文名称，但这些名称对用户不可见，因此不需要支持多个字符集编码。
The name of a property defined on a resource is a URI. Although some applications (e.g., a generic property viewer) will display property URIs 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 URI to a human-readable field when displaying the property name to a user. It is only in the case where
在资源上定义的属性的名称是URI。尽管某些应用程序（例如，通用属性查看器）将直接向其用户显示属性URI，但预计典型应用程序将使用一组固定的属性，并在向用户显示属性名称时提供从属性名称URI到人类可读字段的映射。只有在
the set of properties is not known ahead of time that an application need display a property name URI to a user. We recommend that applications provide human-readable property names wherever feasible.
属性集在应用程序需要向用户显示属性名URI之前是未知的。我们建议应用程序在可行的情况下提供人类可读的属性名称。
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.
由于客户端和服务器的互操作不需要区域设置信息，因此本规范未指定任何传输此信息的机制。
17 Security Considerations
17安全考虑
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 [RFC2068]) and XML (discussed in [RFC2376]) 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（在[RFC2068]中讨论）和XML（在[RFC2376]中讨论）的所有安全注意事项也适用于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 Basic authentication credentials in a WWW-Authenticate header unless the connection is secure. Examples of secure connections include a Transport Layer Security (TLS) connection employing a strong cipher suite with mutual authentication of client and server, or a connection over a network which is physically secure, for example, an isolated network in a building with restricted access.
通过不安全通道以明文形式发送的密码不足以保护资源的可访问性和完整性，因为密码可能被截获。由于HTTP/1.1的基本身份验证基本上执行密码的明文传输，因此除非连接安全，否则不得使用基本身份验证对服务器的WebDAV客户端进行身份验证。此外，除非连接是安全的，否则WebDAV服务器不得在WWW身份验证标头中发送基本身份验证凭据。安全连接的示例包括使用具有客户端和服务器相互认证的强密码套件的传输层安全（TLS）连接，或通过物理安全的网络的连接，例如，具有受限访问的建筑物中的隔离网络。
WebDAV applications MUST support the Digest authentication scheme [RFC2069]. 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 which is useful in a wide range of scenarios.
WebDAV应用程序必须支持摘要身份验证方案[RFC2069]。由于摘要身份验证验证通信双方都知道共享秘密、密码，而不必以明文形式发送该秘密，因此摘要身份验证避免了基本身份验证中固有的安全问题，同时提供了在广泛场景中有用的身份验证级别。
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允许对系统资源的每个部分进行拒绝服务攻击。
The underlying storage can be attacked by PUTting extremely large files.
通过放置非常大的文件，可以攻击底层存储。
Asking for recursive operations on large collections can attack processing time.
要求对大型集合执行递归操作可能会影响处理时间。
Making multiple pipelined requests on multiple connections can attack network connections.
在多个连接上发出多个流水线请求可能会攻击网络连接。
WebDAV servers need to be aware of the possibility of a denial of service attack at all levels.
WebDAV服务器需要了解所有级别的拒绝服务攻击的可能性。
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 lockdiscovery property on the resource, and can be used by other 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 lockdiscovery property as appropriate. Furthermore, user agents
在提交锁请求时，用户代理还可以提交一个owner XML字段，该字段提供了取锁人的联系信息（在这种情况下，取锁人不是机器人）。此联系人信息存储在资源上的lockdiscovery属性中，其他协作者可以使用它来开始协商对资源的访问。然而，在许多情况下，这种联系信息可能非常隐私，不应广泛传播。服务器应酌情限制对lockdiscovery属性的读取访问。此外，用户代理
SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
应控制是否发送联系信息，如果发送了联系信息，则控制发送的确切信息。
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.
由于属性值通常用于保存文档的作者等信息，因此对资源属性数据的广泛访问可能会引起隐私问题。为了降低通过属性意外释放私人信息的风险，鼓励服务器开发访问控制机制，将对资源主体的读取访问和对资源属性的读取访问分开。这允许用户控制其属性数据的传播，而不会过度限制对资源内容的访问。
HTTP/1.1 warns against providing read access to script code because it may contain sensitive information. Yet WebDAV, via its source link facility, can potentially provide a URI for script resources so they may be authored. For HTTP/1.1, a server could reasonably prevent access to source resources due to the predominance of read-only access. WebDAV, with its emphasis on authoring, encourages read and write access to source resources, and provides the source link facility to identify the source. This reduces the security benefits of eliminating access to source resources. Users and administrators of WebDAV servers should be very cautious when allowing remote authoring of scripts, limiting read and write access to the source resources to authorized principals.
HTTP/1.1警告不要提供对脚本代码的读访问，因为它可能包含敏感信息。然而，WebDAV通过其源链接功能，可以为脚本资源提供一个URI，以便它们可以被编写。对于HTTP/1.1，由于只读访问占主导地位，服务器可以合理地阻止对源资源的访问。WebDAV强调创作，鼓励对源资源进行读写访问，并提供源链接功能来识别源。这降低了消除对源资源访问的安全性好处。当允许远程编写脚本时，WebDAV服务器的用户和管理员应该非常谨慎，将对源资源的读写访问限制为授权主体。
XML supports a facility known as "external entities", defined in section 4.2.2 of [REC-XML], which instruct an XML processor to retrieve and perform an inline include of XML located at a particular URI. 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 [REC-XML]. However, [REC-XML] does state that an XML processor may, at its discretion, include the external XML entity.
XML支持[REC-XML]第4.2.2节中定义的称为“外部实体”的功能，该功能指示XML处理器检索并执行位于特定URI的XML的内联包含。外部XML实体可用于附加或修改与XML文档关联的文档类型声明（DTD）。外部XML实体还可用于在XML文档的内容中包含XML。对于非验证性XML，例如本规范中使用的XML，[REC-XML]不要求包含外部XML实体。但是，[REC-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
外部XML实体没有固有的可信度，并且会受到任何HTTP GET请求特有的所有攻击。此外，在最坏的情况下，外部XML实体可能修改DTD，从而影响XML文档的最终形式
case significantly modifying its semantics, or exposing the XML processor to the security risks discussed in [RFC2376]. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy.
案例会显著修改其语义，或使XML处理器面临[RFC2376]中讨论的安全风险。因此，实现者必须意识到外部XML实体应该被视为不可信的。
There is also the scalability risk that would accompany a widely deployed application which 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 server which fields requests for the resource containing the external XML entity.
使用外部XML实体的广泛部署的应用程序还存在可伸缩性风险。在这种情况下，对于一个外部XML实体可能会有大量的请求，这可能会使任何服务器过载，而这些服务器会为包含外部XML实体的资源请求字段。
This specification, in section 6.4, requires the use of Universal Unique Identifiers (UUIDs) for lock tokens, in order to guarantee their uniqueness across space and time. UUIDs, as defined in [ISO-11578], contain a "node" field which "consists of the IEEE address, usually the host address. For systems with multiple IEEE 802 nodes, any available node address can be used." Since a WebDAV server will issue many locks over its lifetime, the implication is that it will also be publicly exposing its IEEE 802 address.
本规范第6.4节要求对锁令牌使用通用唯一标识符（UUID），以保证它们在空间和时间上的唯一性。[ISO-11578]中定义的UUID包含一个“节点”字段，该字段“由IEEE地址（通常为主机地址）组成。对于具有多个IEEE 802节点的系统，可以使用任何可用的节点地址。”由于WebDAV服务器将在其生存期内发出许多锁，这意味着它也将公开其IEEE 802地址。
There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:
暴露IEEE 802地址有几个风险。使用IEEE 802地址：
* It is possible to track the movement of hardware from subnet to subnet.
* 可以跟踪硬件在子网之间的移动。
* It may be possible to identify the manufacturer of the hardware running a WebDAV server.
* 可以确定运行WebDAV服务器的硬件制造商。
* It may be possible to determine the number of each type of computer running WebDAV.
* 可以确定运行WebDAV的每种类型计算机的数量。
Section 6.4.1 of this specification details an alternate mechanism for generating the "node" field of a UUID without using an IEEE 802 address, which alleviates the risks associated with exposure of IEEE 802 addresses by using an alternate source of uniqueness.
本规范第6.4.1节详细说明了一种替代机制，用于在不使用IEEE 802地址的情况下生成UUID的“节点”字段，该机制通过使用替代唯一性源来减轻与IEEE 802地址暴露相关的风险。
18 IANA Considerations
18 IANA考虑因素
This document defines two namespaces, the namespace of property names, and the namespace of WebDAV-specific XML elements used within property values.
本文档定义了两个名称空间，即属性名称的名称空间和属性值中使用的特定于WebDAV的XML元素的名称空间。
URIs are used for both names, for several reasons. Assignment of a URI does not require a request to a central naming authority, and hence allow WebDAV property names and XML elements to be quickly defined by any WebDAV user or application. URIs also provide a unique address space, ensuring that the distributed users of WebDAV will not have collisions among the property names and XML elements they create.
两个名称都使用URI，原因有几个。URI的分配不需要向中央命名机构发出请求，因此允许任何WebDAV用户或应用程序快速定义WebDAV属性名称和XML元素。URI还提供了唯一的地址空间，确保WebDAV的分布式用户不会在他们创建的属性名和XML元素之间发生冲突。
This specification defines a distinguished set of property names and XML elements that are understood by all WebDAV applications. The property names and XML elements in this specification are all derived from the base URI DAV: by adding a suffix to this URI, for example, DAV:creationdate for the "creationdate" property.
本规范定义了所有WebDAV应用程序都能理解的一组可分辨的属性名和XML元素。本规范中的属性名称和XML元素都是从基本URI DAV:派生而来的，通过向该URI添加后缀，例如，“creationdate”属性的DAV:creationdate。
This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in section 6.4.
本规范还定义了用于锁令牌编码的URI方案，即第6.4节中描述的opaquelocktoken URI方案。
To ensure correct interoperation based on this specification, IANA must reserve the URI namespaces starting with "DAV:" and with "opaquelocktoken:" for use by this specification, its revisions, and related WebDAV specifications.
为了确保基于本规范的正确互操作，IANA必须保留以“DAV:”和“opaquelocktoken:”开头的URI命名空间，以供本规范、其修订版和相关WebDAV规范使用。
19 Intellectual Property
19知识产权
The following notice is copied from RFC 2026 [RFC2026], section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document.
以下通知复制自RFC 2026[RFC2026]第10.4节，并描述了IETF关于针对本文件提出的知识产权索赔的立场。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件中描述的实施或使用其他技术有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
20 Acknowledgements
20致谢
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.
这样的规范在尖锐的批评性评论中蓬勃发展，而在冷漠的忽视中枯萎。作者衷心感谢以下人员的贡献，他们的见解在我们工作的每个阶段都非常宝贵。
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, both in helping the formation of the working group and in patiently coaching the authors along the way. In so many ways he has set high standards we have toiled to meet. The contributions of Judith Slein in clarifying the requirements, and in patiently reviewing draft after draft, both improved this specification and expanded our minds on document management.
这个名单中有两个值得特别提及。拉里·马斯因特（Larry Masinter）的贡献是无价的，无论是在帮助成立工作组方面，还是在一路上耐心地指导作者方面。在许多方面，他设定了我们努力达到的高标准。Judith Slein在澄清需求方面的贡献，以及在耐心地审查一份又一份草案方面的贡献，都改进了本规范并扩展了我们在文档管理方面的思路。
We would also like to thank John Turner for developing the XML DTD.
我们还要感谢John Turner开发XML DTD。
21 References
21参考文献
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766]Alvestrand，H.，“语言识别标签”，RFC1766，1995年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月。
[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月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web Consortium Recommendation REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
[REC-XML]T.Bray，J.Paoli，C.M.Sperberg McQueen，“可扩展标记语言（XML）”，万维网联盟建议REC-XML-19980210。http://www.w3.org/TR/1998/REC-xml-19980210.
[REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
XML". World Wide Web Consortium Recommendation REC-
xml-names-19990114. http://www.w3.org/TR/1999/REC-
xml-names-19990114/
[REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
XML". World Wide Web Consortium Recommendation REC-
xml-names-19990114. http://www.w3.org/TR/1999/REC-
xml-names-19990114/
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P, Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.
[RFC2069]Franks，J.，Hallam Baker，P.，Hostetler，J.，Leach，P，Lootonen，A.，Sink，E.和L.Stewart，“HTTP的扩展：摘要访问认证”，RFC 2069，1997年1月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[ISO-639] ISO (International Organization for Standardization). ISO 639:1988. "Code for the representation of names of languages."
[ISO-639]ISO（国际标准化组织）。ISO 639:1988。“表示语言名称的代码。”
[ISO-8601] ISO (International Organization for Standardization). ISO 8601:1988. "Data elements and interchange formats - Information interchange - Representation of dates and times."
[ISO-8601]ISO（国际标准化组织）。ISO 8601:1988。“数据元和交换格式.信息交换.日期和时间的表示.”
[ISO-11578] ISO (International Organization for Standardization). ISO/IEC 11578:1996. "Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)"
[ISO-11578]ISO（国际标准化组织）。ISO/IEC 11578:1996。“信息技术.开放系统互连.远程过程调用（RPC）”
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]Moats，R.，“瓮语法”，RFC 21411997年5月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, January 1998.
[UTF-8]Yergeau，F.，“UTF-8，Unicode和ISO10646的转换格式”，RFC 2279，1998年1月。
[RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程-第3版”，BCP 9，RFC 2026，1996年10月。
[RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic Records", RFC 1807, June 1995.
[RFC1807]Lasher，R.和D.Cohen，“书目记录的格式”，RFC1807，1995年6月。
[WF] C. Lagoze, "The Warwick Framework: A Container
Architecture for Diverse Sets of Metadata", D-Lib
Magazine, July/August 1996.
http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
[WF] C. Lagoze, "The Warwick Framework: A Container
Architecture for Diverse Sets of Metadata", D-Lib
Magazine, July/August 1996.
http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
[USMARC] Network Development and MARC Standards, Office, ed. 1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC: Cataloging Distribution Service, Library of Congress.
[USMARC]网络开发和MARC标准，办公室，1994年版。“书目数据的USMARC格式”，1994年。华盛顿特区：编目分发服务，国会图书馆。
[REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS Label Distribution Label Syntax and Communication Protocols" Version 1.1, World Wide Web Consortium Recommendation REC-PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
[REC-PICS]J.Miller，T.Krauskopf，P.Resnick，W.Treese，“PICS标签分发标签语法和通信协议”版本1.1，万维网联盟建议REC-PICS-labels-961031。http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
[RFC2291] Slein, J., Vitali, F., Whitehead, E. and D. Durand, "Requirements for 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月。
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core Metadata for Resource Discovery", RFC 2413, September 1998.
[RFC2413]Weibel，S.，Kunze，J.，Lagoze，C.和M.Wolf，“用于资源发现的都柏林核心元数据”，RFC 2413，1998年9月。
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.
[RFC2376]Whitehead，E.和M.Murata，“XML媒体类型”，RFC23761998年7月。
22 Authors' Addresses
22作者地址
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Y.Y.Goland微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: yarong@microsoft.com
EMail: yarong@microsoft.com
E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425
E. J. Whitehead，加利福尼亚大学信息与计算机科学系，欧文·欧文，CA92697－3525
EMail: ejw@ics.uci.edu
EMail: ejw@ics.uci.edu
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043
A.加利福尼亚州东米德尔菲尔德路山景685号Faizi Netscape 94043
EMail: asad@netscape.com
EMail: asad@netscape.com
S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399
S.R.Carter Novell 1555 N.技术路线M/S ORM F111 Orem，UT 84097-2399
EMail: srcarter@novell.com
EMail: srcarter@novell.com
D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399
D.Jensen Novell 1555 N.技术路线M/S ORM F111 Orem，UT 84097-2399
EMail: dcjensen@novell.com
EMail: dcjensen@novell.com
23 Appendices
23附录
This section provides a document type definition, following the rules in [REC-XML], for the XML elements used in the protocol stream and in the values of properties. It collects the element definitions given in sections 12 and 13.
本节按照[REC-XML]中的规则，为协议流和属性值中使用的XML元素提供文档类型定义。它收集了第12节和第13节中给出的元素定义。
<!DOCTYPE webdav-1.0 [
<!DOCTYPE webdav-1.0[
<!--============ XML Elements from Section 12 ==================-->
<!--============ XML Elements from Section 12 ==================-->
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?) >
<!元素activelock（锁定范围、锁定类型、深度、所有者？、超时？、锁定令牌？>
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT locktype (write) >
<!ELEMENT write EMPTY >
<!ELEMENT locktype (write) >
<!ELEMENT write EMPTY >
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT exclusive EMPTY >
<!ELEMENT shared EMPTY >
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT exclusive EMPTY >
<!ELEMENT shared EMPTY >
<!ELEMENT depth (#PCDATA) >
<!ELEMENT depth (#PCDATA) >
<!ELEMENT owner ANY >
<!ELEMENT owner ANY >
<!ELEMENT timeout (#PCDATA) >
<!ELEMENT timeout (#PCDATA) >
<!ELEMENT locktoken (href+) >
<!ELEMENT locktoken (href+) >
<!ELEMENT href (#PCDATA) >
<!ELEMENT href (#PCDATA) >
<!ELEMENT link (src+, dst+) >
<!ELEMENT dst (#PCDATA) >
<!ELEMENT src (#PCDATA) >
<!ELEMENT link (src+, dst+) >
<!ELEMENT dst (#PCDATA) >
<!ELEMENT src (#PCDATA) >
<!ELEMENT multistatus (response+, responsedescription?) >
<!ELEMENT multistatus (response+, responsedescription?) >
<!ELEMENT response (href, ((href*, status)|(propstat+)),
responsedescription?) >
<!ELEMENT status (#PCDATA) >
<!ELEMENT propstat (prop, status, responsedescription?) >
<!ELEMENT responsedescription (#PCDATA) >
<!ELEMENT response (href, ((href*, status)|(propstat+)),
responsedescription?) >
<!ELEMENT status (#PCDATA) >
<!ELEMENT propstat (prop, status, responsedescription?) >
<!ELEMENT responsedescription (#PCDATA) >
<!ELEMENT prop ANY >
<!ELEMENT prop ANY >
<!ELEMENT propertybehavior (omit | keepalive) >
<!ELEMENT omit EMPTY >
<!ELEMENT propertybehavior (omit | keepalive) >
<!ELEMENT omit EMPTY >
<!ELEMENT keepalive (#PCDATA | href+) >
<!ELEMENT keepalive (#PCDATA | href+) >
<!ELEMENT propertyupdate (remove | set)+ >
<!ELEMENT remove (prop) >
<!ELEMENT set (prop) >
<!ELEMENT propertyupdate (remove | set)+ >
<!ELEMENT remove (prop) >
<!ELEMENT set (prop) >
<!ELEMENT propfind (allprop | propname | prop) >
<!ELEMENT allprop EMPTY >
<!ELEMENT propname EMPTY >
<!ELEMENT propfind (allprop | propname | prop) >
<!ELEMENT allprop EMPTY >
<!ELEMENT propname EMPTY >
<!ELEMENT collection EMPTY >
<!ELEMENT collection EMPTY >
<!--=========== Property Elements from Section 13 ===============-->
<!ELEMENT creationdate (#PCDATA) >
<!ELEMENT displayname (#PCDATA) >
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT resourcetype ANY >
<!ELEMENT source (link)* >
<!ELEMENT supportedlock (lockentry)* >
]>
<!--=========== Property Elements from Section 13 ===============-->
<!ELEMENT creationdate (#PCDATA) >
<!ELEMENT displayname (#PCDATA) >
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT resourcetype ANY >
<!ELEMENT source (link)* >
<!ELEMENT supportedlock (lockentry)* >
]>
The creationdate property specifies the use of the ISO 8601 date format [ISO-8601]. This section defines a profile of the ISO 8601 date format for use with this specification. This profile is quoted from an Internet-Draft by Chris Newman, and is mentioned here to properly attribute his work.
creationdate属性指定ISO 8601日期格式[ISO-8601]的使用。本节定义了用于本规范的ISO 8601日期格式的配置文件。本简介引自克里斯·纽曼（Chris Newman）在互联网上的一份草稿，这里提到这篇文章是为了恰当地描述他的作品。
date-time = full-date "T" full-time
日期时间=完整日期“T”完整时间
full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset
完整日期=日期-完整年份“-”日期-月份“-”日期-日期-日期-日期-日期-完整时间=部分时间-时间偏移
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second [time-secfrac]
部分时间=时间小时“：“时间分钟“：“时间秒[时间秒]
Numeric offsets are calculated as local time minus UTC (Coordinated Universal Time). So the equivalent time in UTC can be determined by subtracting the offset from the local time. For example, 18:50:00- 04:00 is the same time as 22:58:00Z.
数字偏移计算为本地时间减去UTC（协调世界时）。因此，UTC的等效时间可以通过从本地时间减去偏移量来确定。例如，18:50:00-04:00与22:58:00Z的时间相同。
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs from an offset of "Z" which implies that UTC is the preferred reference point for the specified time.
如果UTC时间已知，但与本地时间的偏移量未知，则可以用“-00:00”偏移量表示。这与“Z”偏移不同，Z偏移意味着UTC是指定时间的首选参考点。
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元素在语义上是相同的。
It is a violation of the XML specification to use the <A></A> form if the associated DTD declares the element to be EMPTY (e.g., <!ELEMENT A EMPTY>). If such a statement is included, then the empty element format, <A/> must be used. If the element is not declared to be EMPTY, then either form <A></A> or <A/> may be used for empty elements.
如果关联的DTD将元素声明为空（例如，<！element a EMPTY>），则使用<a></a>表单违反了XML规范。如果包含这样的语句，则必须使用空元素格式<a/>。如果元素未声明为空，则可以使用<A></A>或<A/>形式表示空元素。
23.3.2 Notes on Illegal XML Processing
23.3.2 关于非法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 white space, 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.foo.bar/standards/props/">
<E:expired-props/>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.foo.bar/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.foo.bar/standards/props/">
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.foo.bar/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 14, it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal.
由于服务器不理解过期的props元素，根据第14节中指定的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.foo.bar/standards/props/">
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.foo.bar/standards/props/">
<D:propname/>
<E:leave-out>*boss*</E:leave-out>
</D:propfind>
<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。
All DAV compliant systems MUST support the XML namespace extensions as specified in [REC-XML-NAMES].
所有符合DAV的系统必须支持[REC-XML-NAME]中指定的XML命名空间扩展。
[Note to the reader: This section does not appear in [REC-XML-NAMES], but is necessary to avoid ambiguity for WebDAV XML processors.]
[读者注意：本节未出现在[REC-XML-NAME]中，但为避免WebDAV XML处理器的歧义，本节是必要的。]
WebDAV compliant XML processors MUST interpret a qualified name as a URI constructed by appending the LocalPart to the namespace name URI.
WebDAV兼容的XML处理器必须将限定名称解释为通过将LocalPart附加到名称空间名称URI而构造的URI。
Example
实例
<del:glider xmlns:del="http://www.del.jensen.org/">
<del:glidername>
Johnny Updraft
</del:glidername>
<del:glideraccidents/>
</del:glider>
<del:glider xmlns:del="http://www.del.jensen.org/">
<del:glidername>
Johnny Updraft
</del:glidername>
<del:glideraccidents/>
</del:glider>
In this example, the qualified element name "del:glider" is interpreted as the URL "http://www.del.jensen.org/glider".
在本例中，限定元素名“del:glider”被解释为URL“http://www.del.jensen.org/glider".
<bar:glider xmlns:del="http://www.del.jensen.org/">
<bar:glidername>
Johnny Updraft
</bar:glidername>
<bar:glideraccidents/>
</bar:glider>
<bar:glider xmlns:del="http://www.del.jensen.org/">
<bar:glidername>
Johnny Updraft
</bar:glidername>
<bar:glideraccidents/>
</bar:glider>
Even though this example is syntactically different from the previous example, it is semantically identical. Each instance of the namespace name "bar" is replaced with "http://www.del.jensen.org/" and then appended to the local name for each element tag. The resulting tag names in this example are exactly the same as for the previous example.
尽管此示例在语法上与前一示例不同，但在语义上是相同的。命名空间名称“bar”的每个实例都替换为“http://www.del.jensen.org/“然后附加到每个元素标记的本地名称。本例中生成的标记名与上一个示例中的标记名完全相同。
<foo:r xmlns:foo="http://www.del.jensen.org/glide">
<foo:rname>
Johnny Updraft
</foo:rname>
<foo:raccidents/>
</foo:r>
<foo:r xmlns:foo="http://www.del.jensen.org/glide">
<foo:rname>
Johnny Updraft
</foo:rname>
<foo:raccidents/>
</foo:r>
This example is semantically identical to the two previous ones. Each instance of the namespace name "foo" is replaced with "http://www.del.jensen.org/glide" which is then appended to the local name for each element tag, the resulting tag names are identical to those in the previous examples.
此示例在语义上与前两个示例相同。命名空间名称“foo”的每个实例都替换为“http://www.del.jensen.org/glide然后将其附加到每个元素标记的本地名称中，生成的标记名称与前面示例中的相同。
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。