[要約] RFC 4918は、WebDAVのためのHTTP拡張を定義しており、Web上での共同編集やバージョン管理を可能にする。目的は、WebDAVプロトコルの機能を拡張し、効率的なコンテンツ管理と共同作業を実現すること。
Network Working Group L. Dusseault, Ed.
Request for Comments: 4918 CommerceNet
Obsoletes: 2518 June 2007
Category: Standards Track
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
Web分散オーサリングとバージョンの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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).
Web分散オーサリングおよびバージョン化（WebDAV）は、リソースプロパティの管理、URLネームスペース操作、およびリソースロック（衝突回避の管理と管理のためのHTTP/1.1のメソッド、ヘッダー、コンテンツタイプのセットで構成されています。）。
RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience.
RFC 2518は1999年2月に公開され、この仕様は廃止されたRFC 2518で、主に相互運用性の経験が原因で軽微な改訂があります。
Table of Contents
目次
1. Introduction ....................................................7
2. Notational Conventions ..........................................8
3. Terminology .....................................................8
4. Data Model for Resource Properties .............................10
4.1. The Resource Property Model ...............................10
4.2. Properties and HTTP Headers ...............................10
4.3. Property Values ...........................................10
4.3.1. Example - Property with Mixed Content ..............12
4.4. Property Names ............................................14
4.5. Source Resources and Output Resources .....................14
5. Collections of Web Resources ...................................14
5.1. HTTP URL Namespace Model ..................................15
5.2. Collection Resources ......................................15
6. Locking ........................................................17
6.1. Lock Model ................................................18
6.2. Exclusive vs. Shared Locks ................................19
6.3. Required Support ..........................................20
6.4. Lock Creator and Privileges ...............................20
6.5. Lock Tokens ...............................................21
6.6. Lock Timeout ..............................................21
6.7. Lock Capability Discovery .................................22
6.8. Active Lock Discovery .....................................22
7. Write Lock .....................................................23
7.1. Write Locks and Properties ................................24
7.2. Avoiding Lost Updates .....................................24
7.3. Write Locks and Unmapped URLs .............................25
7.4. Write Locks and Collections ...............................26
7.5. Write Locks and the If Request Header .....................28
7.5.1. Example - Write Lock and COPY ......................28
7.5.2. Example - Deleting a Member of a Locked
Collection .........................................29
7.6. Write Locks and COPY/MOVE .................................30
7.7. Refreshing Write Locks ....................................30
8. General Request and Response Handling ..........................31
8.1. Precedence in Error Handling ..............................31
8.2. Use of XML ................................................31
8.3. URL Handling ..............................................32
8.3.1. Example - Correct URL Handling .....................32
8.4. Required Bodies in Requests ...............................33
8.5. HTTP Headers for Use in WebDAV ............................33
8.6. ETag ......................................................33
8.7. Including Error Response Bodies ...........................34
8.8. Impact of Namespace Operations on Cache Validators ........34
9. HTTP Methods for Distributed Authoring .........................35
9.1. PROPFIND Method ...........................................35
9.1.1. PROPFIND Status Codes ..............................37
9.1.2. Status Codes for Use in 'propstat' Element .........37
9.1.3. Example - Retrieving Named Properties ..............38
9.1.4. Example - Using 'propname' to Retrieve All
Property Names .....................................39
9.1.5. Example - Using So-called 'allprop' ................41
9.1.6. Example - Using 'allprop' with 'include' ...........43
9.2. PROPPATCH Method ..........................................44
9.2.1. Status Codes for Use in 'propstat' Element .........44
9.2.2. Example - PROPPATCH ................................45
9.3. MKCOL Method ..............................................46
9.3.1. MKCOL Status Codes .................................47
9.3.2. Example - MKCOL ....................................47
9.4. GET, HEAD for Collections .................................48
9.5. POST for Collections ......................................48
9.6. DELETE Requirements .......................................48
9.6.1. DELETE for Collections .............................49
9.6.2. Example - DELETE ...................................49
9.7. PUT Requirements ..........................................50
9.7.1. PUT for Non-Collection Resources ...................50
9.7.2. PUT for Collections ................................51
9.8. COPY Method ...............................................51
9.8.1. COPY for Non-collection Resources ..................51
9.8.2. COPY for Properties ................................52
9.8.3. COPY for Collections ...............................52
9.8.4. COPY and Overwriting Destination Resources .........53
9.8.5. Status Codes .......................................54
9.8.6. Example - COPY with Overwrite ......................55
9.8.7. Example - COPY with No Overwrite ...................55
9.8.8. Example - COPY of a Collection .....................56
9.9. MOVE Method ...............................................56
9.9.1. MOVE for Properties ................................57
9.9.2. MOVE for Collections ...............................57
9.9.3. MOVE and the Overwrite Header ......................58
9.9.4. Status Codes .......................................59
9.9.5. Example - MOVE of a Non-Collection .................60
9.9.6. Example - MOVE of a Collection .....................60
9.10. LOCK Method ..............................................61
9.10.1. Creating a Lock on an Existing Resource ...........61
9.10.2. Refreshing Locks ..................................62
9.10.3. Depth and Locking .................................62
9.10.4. Locking Unmapped URLs .............................63
9.10.5. Lock Compatibility Table ..........................63
9.10.6. LOCK Responses ....................................63
9.10.7. Example - Simple Lock Request .....................64
9.10.8. Example - Refreshing a Write Lock .................65
9.10.9. Example - Multi-Resource Lock Request .............66
9.11. UNLOCK Method ............................................68
9.11.1. Status Codes ......................................68
9.11.2. Example - UNLOCK ..................................69
10. HTTP Headers for Distributed Authoring ........................69
10.1. DAV Header ...............................................69
10.2. Depth Header .............................................70
10.3. Destination Header .......................................71
10.4. If Header ................................................72
10.4.1. Purpose ...........................................72
10.4.2. Syntax ............................................72
10.4.3. List Evaluation ...................................73
10.4.4. Matching State Tokens and ETags ...................74
10.4.5. If Header and Non-DAV-Aware Proxies ...............74
10.4.6. Example - No-tag Production .......................75
10.4.7. Example - Using "Not" with No-tag Production ......75
10.4.8. Example - Causing a Condition to Always
Evaluate to True ..................................75
10.4.9. Example - Tagged List If Header in COPY ...........76
10.4.10. Example - Matching Lock Tokens with
Collection Locks .................................76
10.4.11. Example - Matching ETags on Unmapped URLs ........76
10.5. Lock-Token Header ........................................77
10.6. Overwrite Header .........................................77
10.7. Timeout Request Header ...................................78
11. Status Code Extensions to HTTP/1.1 ............................78
11.1. 207 Multi-Status .........................................78
11.2. 422 Unprocessable Entity .................................78
11.3. 423 Locked ...............................................78
11.4. 424 Failed Dependency ....................................79
11.5. 507 Insufficient Storage .................................79
12. Use of HTTP Status Codes ......................................79
12.1. 412 Precondition Failed ..................................79
12.2. 414 Request-URI Too Long .................................79
13. Multi-Status Response .........................................80
13.1. Response Headers .........................................80
13.2. Handling Redirected Child Resources ......................81
13.3. Internal Status Codes ....................................81
14. XML Element Definitions .......................................81
14.1. activelock XML Element ...................................81
14.2. allprop XML Element ......................................82
14.3. collection XML Element ...................................82
14.4. depth XML Element ........................................82
14.5. error XML Element ........................................82
14.6. exclusive XML Element ....................................83
14.7. href XML Element .........................................83
14.8. include XML Element ......................................83
14.9. location XML Element .....................................83
14.10. lockentry XML Element ...................................84
14.11. lockinfo XML Element ....................................84
14.12. lockroot XML Element ....................................84
14.13. lockscope XML Element ...................................84
14.14. locktoken XML Element ...................................85
14.15. locktype XML Element ....................................85
14.16. multistatus XML Element .................................85
14.17. owner XML Element .......................................85
14.18. prop XML Element ........................................86
14.19. propertyupdate XML Element ..............................86
14.20. propfind XML Element ....................................86
14.21. propname XML Element ....................................87
14.22. propstat XML Element ....................................87
14.23. remove XML Element ......................................87
14.24. response XML Element ....................................88
14.25. responsedescription XML Element .........................88
14.26. set XML Element .........................................88
14.27. shared XML Element ......................................89
14.28. status XML Element ......................................89
14.29. timeout XML Element .....................................89
14.30. write XML Element .......................................89
15. DAV Properties ................................................90
16. Precondition/Postcondition XML Elements .......................98
17. XML Extensibility in DAV .....................................101
18. DAV Compliance Classes .......................................103
18.1. Class 1 .................................................103
18.2. Class 2 .................................................103
18.3. Class 3 .................................................103
19. Internationalization Considerations ..........................104
20. Security Considerations ......................................105
20.1. Authentication of Clients ...............................105
20.2. Denial of Service .......................................106
20.3. Security through Obscurity ..............................106
20.4. Privacy Issues Connected to Locks .......................106
20.5. Privacy Issues Connected to Properties ..................107
20.6. Implications of XML Entities ............................107
20.7. Risks Connected with Lock Tokens ........................108
20.8. Hosting Malicious Content ...............................108
21. IANA Considerations ..........................................109
21.1. New URI Schemes .........................................109
21.2. XML Namespaces ..........................................109
21.3. Message Header Fields ...................................109
21.3.1. DAV ..............................................109
21.3.2. Depth ............................................110
21.3.3. Destination ......................................110
21.3.4. If ...............................................110
21.3.5. Lock-Token .......................................110
21.3.6. Overwrite ........................................111
21.3.7. Timeout ..........................................111
21.4. HTTP Status Codes .......................................111
22. Acknowledgements .............................................112
23. Contributors to This Specification ...........................113
24. Authors of RFC 2518 ..........................................113
25. References ...................................................114
25.1. Normative References.....................................114
25.2. Informative References ..................................115
Appendix A. Notes on Processing XML Elements ....................117
A.1. Notes on Empty XML Elements ..............................117
A.2. Notes on Illegal XML Processing ..........................117
A.3. Example - XML Syntax Error ...............................117
A.4. Example - Unexpected XML Element .........................118
Appendix B. Notes on HTTP Client Compatibility ...................119
Appendix C. The 'opaquelocktoken' Scheme and URIs ................120
Appendix D. Lock-null Resources ..................................120
D.1. Guidance for Clients Using LOCK to Create Resources ......121
Appendix E. Guidance for Clients Desiring to Authenticate ........121
Appendix F. Summary of Changes from RFC 2518 .....................123
F.1. Changes for Both Client and Server Implementations .......123
F.2. Changes for Server Implementations .......................125
F.3. Other Changes ............................................126
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:
このドキュメントでは、クライアントがリモートWebコンテンツオーサリング操作を実行できるようにするHTTP/1.1プロトコルの拡張機能について説明します。この拡張機能は、次の操作を提供するメソッド、ヘッダー、リクエストエンティティボディフォーマット、および応答エンティティボディフォーマットのコヒーレントセットを提供します。
Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc.
プロパティ：著者、作成日など、Webページに関する情報を作成、削除、照会する機能。
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.
ロック：複数の人がドキュメントに同時に作業するのを防ぐ能力。これにより、「Lost Updateの問題」が防止されます。この著者は、最初の1人の著者として変更され、次に別の著者が他の著者の変更を統合せずに変更を書き込みます。
Namespace Operations: The ability to instruct the server to copy and move Web resources, operations that change the mapping from URLs to resources.
名前空間操作：サーバーにWebリソースをコピーして移動するよう指示する機能、マッピングをURLからリソースに変更する操作。
Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" [RFC2291].
これらの操作の要件と根拠は、コンパニオンドキュメント「World Wide Webの分散オーサリングおよびバージョンプロトコルの要件」[RFC2291]に記載されています。
This document does not specify the versioning operations suggested by [RFC2291]. That work was done in a separate document, "Versioning Extensions to WebDAV" [RFC3253].
このドキュメントでは、[RFC2291]で提案されたバージョン操作は指定されていません。その作業は、「webdavへの拡張機能」[RFC3253] [rfc3253]という別のドキュメントで行われました。
The sections below provide a detailed introduction to various WebDAV abstractions: resource properties (Section 4), collections of resources (Section 5), locks (Section 6) in general, and write locks (Section 7) specifically.
以下のセクションでは、さまざまなWebDAV抽象化の詳細な紹介を示します。リソースプロパティ（セクション4）、リソースのコレクション（セクション5）、ロック（セクション6）一般的に、具体的に書き込みロック（セクション7）。
These abstractions are manipulated by the WebDAV-specific HTTP methods (Section 9) and the extra HTTP headers (Section 10) used with WebDAV methods. General considerations for handling HTTP requests and responses in WebDAV are found in Section 8.
これらの抽象化は、WebDAV固有のHTTPメソッド（セクション9）とWebDAVメソッドで使用される追加のHTTPヘッダー（セクション10）によって操作されます。WebDAVのHTTP要求と応答を処理するための一般的な考慮事項は、セクション8にあります。
While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines extra status codes developed for WebDAV methods (Section 11) and describes existing HTTP status codes (Section 12) as used in WebDAV. Since some WebDAV methods may operate over many resources, the Multi-Status response (Section 13) has been introduced to return status information for multiple resources. Finally, this version of WebDAV introduces precondition and postcondition (Section 16) XML elements in error response bodies.
HTTP/1.1によって提供されるステータスコードは、WebDAVメソッドで遭遇するほとんどのエラー条件を記述するのに十分ですが、既存のカテゴリにきちんと該当しないエラーがいくつかあります。この仕様では、WebDAVメソッド用に開発された追加のステータスコード（セクション11）を定義し、WebDAVで使用されている既存のHTTPステータスコード（セクション12）について説明します。一部のWebDAVメソッドは多くのリソースで動作する可能性があるため、複数のリソースのステータス情報を返すためにマルチステータス応答（セクション13）が導入されています。最後に、このバージョンのWebDavは、エラー応答ボディで前提条件と事後条件（セクション16）XML要素を導入します。
WebDAV uses XML ([REC-XML]) for property names and some values, and also uses XML to marshal complicated requests and responses. This specification contains DTD and text definitions of all properties (Section 15) and all other XML elements (Section 14) used in marshalling. WebDAV includes a few special rules on extending WebDAV XML marshalling in backwards-compatible ways (Section 17).
WebDavは、プロパティ名といくつかの値にXML（[Rec-XML]）を使用し、XMLを使用して複雑なリクエストと応答をマーシャルします。この仕様には、マーシャリングで使用されるすべてのプロパティ（セクション15）および他のすべてのXML要素（セクション14）のDTDおよびテキスト定義が含まれています。WebDavには、WebDav XMLの拡張に関するいくつかの特別なルールが後方互換性のある方法でマーシャリングされています（セクション17）。
Finishing off the specification are sections on what it means for a resource to be compliant with this specification (Section 18), on internationalization support (Section 19), and on security (Section 20).
仕様の仕上げは、この仕様（セクション18）、国際化のサポート（セクション19）、およびセキュリティ（セクション20）に準拠することの意味に関するセクションです。
Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in Section 2.1 of [RFC2616], including the rules about implied linear whitespace. Since this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], these rules apply to this document as well. Note this is not the standard BNF syntax used in other RFCs.
このドキュメントでは、HTTP/1.1プロトコルの一連の拡張機能について説明されているため、ここでプロトコル要素を説明するために使用される拡張BNFは、[RFC2616]のセクション2.1で説明されているものとまったく同じです。この拡張されたBNFは、[RFC2616]のセクション2.2で提供される基本的な生産ルールを使用しているため、これらのルールもこのドキュメントにも適用されます。これは、他のRFCで使用される標準のBNF構文ではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Note that in natural language, a property like the "creationdate" property in the "DAV:" XML namespace is sometimes referred to as "DAV:creationdate" for brevity.
自然言語では、「dav：」の「creationdate」プロパティのようなプロパティは、XMLネームスペースが「dav：creationdate」と呼ばれることもあります。
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in [RFC3986].
URI/URL-それぞれ均一なリソース識別子と均一なリソースロケーター。これらの用語（およびそれらの区別）は[RFC3986]で定義されています。
URI/URL Mapping - A relation between an absolute URI and a resource. Since a resource can represent items that are not network retrievable, as well as those that are, it is possible for a resource to have zero, one, or many URI mappings. Mapping a resource to an "http" scheme URI makes it possible to submit HTTP protocol requests to the resource using the URI.
URI/URLマッピング - 絶対URIとリソースの関係。リソースは、ネットワークを取得できないアイテムと、その場合のアイテムを表すことができるため、リソースがゼロ、1つ、または多くのURIマッピングを持つことができます。リソースを「HTTP」スキームにマッピングすると、URIを使用してHTTPプロトコル要求をリソースに送信できます。
Path Segment - Informally, the characters found between slashes ("/") in a URI. Formally, as defined in Section 3.3 of [RFC3986].
パスセグメント - 非公式には、URIのスラッシュ（ "/"）の間にあるキャラクター。正式には、[RFC3986]のセクション3.3で定義されています。
Collection - Informally, a resource that also acts as a container of references to child resources. Formally, a resource that contains a set of mappings between path segments and resources and meets the requirements defined in Section 5.
コレクション - 非公式には、児童資源への参照のコンテナとしても機能するリソース。正式には、パスセグメントとリソースの間に一連のマッピングを含み、セクション5で定義されている要件を満たすリソース。
Internal Member (of a Collection) - Informally, a child resource of a collection. Formally, a resource referenced by a path segment mapping contained in the collection.
（コレクションの）内部メンバー - 非公式に、コレクションの子リソース。正式には、コレクションに含まれるパスセグメントマッピングによって参照されるリソース。
Internal Member URL (of a Collection) - A URL of an internal member, consisting of the URL of the collection (including trailing slash) plus the path segment identifying the internal member.
内部メンバーURL（コレクションの） - コレクションのURL（トレーリングスラッシュを含む）と内部メンバーを識別するパスセグメントで構成される内部メンバーのURL。
Member (of a Collection) - Informally, a "descendant" of a collection. Formally, an internal member of the collection, or, recursively, a member of an internal member.
メンバー（コレクションの） - 非公式に、コレクションの「子孫」。正式には、コレクションの内部メンバー、または再帰的に内部メンバーのメンバーです。
Member URL (of a Collection) - A URL that is either an internal member URL of the collection itself, or is an internal member URL of a member of that collection.
メンバーURL（コレクションの） - コレクション自体の内部メンバーURLである、またはそのコレクションのメンバーの内部メンバーURLであるURL。
Property - A name/value pair that contains descriptive information about a resource.
プロパティ - リソースに関する記述情報を含む名前/値ペア。
Live Property - A property whose semantics and syntax are enforced by the server. For example, the live property DAV:getcontentlength has its value, the length of the entity returned by a GET request, automatically calculated by the server.
ライブプロパティ - セマンティクスと構文がサーバーによって実施されるプロパティ。たとえば、Live Property DAV：getContentLengthの値は、サーバーによって自動的に計算されたGETリクエストによって返されるエンティティの長さです。
Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property.
Deadプロパティ - サーバーによってセマンティクスと構文が施行されていないプロパティ。サーバーは、死んだプロパティの値のみを記録します。クライアントは、死んだプロパティの構文とセマンティクスの一貫性を維持する責任があります。
Principal - A distinct human or computational actor that initiates access to network resources.
プリンシパル - ネットワークリソースへのアクセスを開始する明確な人間または計算アクター。
State Token - A URI that represents a state of a resource. Lock tokens are the only state tokens defined in this specification.
状態トークン - リソースの状態を表すURI。ロックトークンは、この仕様で定義されている唯一の状態トークンです。
Properties are pieces of data that describe the state of a resource. Properties are data about data.
プロパティは、リソースの状態を記述するデータの部分です。プロパティはデータに関するデータです。
Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents.
プロパティは、リソースの効率的な発見と管理を提供するために、分散オーサリング環境で使用されます。たとえば、「サブジェクト」プロパティは、被験者によるすべてのリソースのインデックス作成を可能にする場合があり、「著者」プロパティは、著者がどの文書を書いたかを発見することを可能にする場合があります。
The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics.
DAVプロパティモデルは、名前/値のペアで構成されています。プロパティの名前は、プロパティの構文とセマンティクスを識別し、その構文とセマンティクスを参照するアドレスを提供します。
There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is protected and maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.
プロパティには2つのカテゴリがあります。「ライブ」と「死んで」。ライブプロパティには、サーバーによって実施された構文とセマンティクスがあります。ライブプロパティには、a）プロパティの値がサーバーによって保護および維持される場合、b）プロパティの値はクライアントによって維持されますが、サーバーは提出された値で構文チェックを実行します。特定のライブプロパティのすべてのインスタンスは、そのプロパティ名に関連付けられた定義に準拠する必要があります。死んだプロパティには、クライアントによって実施された構文とセマンティクスがあります。サーバーは、単にプロパティのVerbatimの値を記録するだけです。
Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments, a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus, a mechanism is needed that allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.
HTTPメッセージヘッダーには、限られた意味で、プロパティがすでに存在しています。ただし、分散したオーサリング環境では、リソースの状態を記述するために比較的多数のプロパティが必要であり、HTTPヘッダーを通じてそれらをすべて設定/返信することは非効率的です。したがって、プリンシパルが関心のある一連のプロパティを識別し、それらのプロパティのみを設定または取得できるようにするメカニズムが必要です。
The value of a property is always a (well-formed) XML fragment.
プロパティの値は、常に（よく形成された）XMLフラグメントです。
XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self-describing nature allows any property's value to be extended by adding elements. Clients will not break when they encounter extensions because they will still have the data specified in the original schema and MUST ignore elements they do not understand.
XMLは、豊富なスキーマ定義をサポートする柔軟で自己記述的な構造化されたデータ形式であり、複数の文字セットのサポートのために選択されています。XMLの自己記述的性質により、要素を追加することにより、プロパティの値を拡張できます。クライアントは、元のスキーマで指定されたデータをまだ持っており、理解できない要素を無視する必要があるため、拡張機能に遭遇したときに壊れません。
XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml: lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so an xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. Note that a property only has one value, in one language (or language MAY be left undefined); a property does not have multiple values in different languages or a single value in multiple languages.
複数の文字セットに対するXMLのサポートにより、ユーザーに馴染みのあるキャラクターセットで、人間の読み取り可能なプロパティをエンコードして読み取ることができます。「XML：Lang」属性を使用して、複数の人間言語に対するXMLのサポートは、同じ文字セットが複数の人間言語で採用されているケースを処理します。XML：Lang Scopeは再帰的であるため、より局所的にスコープされた属性によってオーバーライドされていない限り、プロパティ名要素を含む要素のXML：Lang属性がプロパティ値に適用されることに注意してください。プロパティには1つの値のみがあり、1つの言語（または言語は未定義のままになる場合があります）に注意してください。プロパティは、異なる言語で複数の値を持っていない、または複数の言語で単一の値はありません。
A property is always represented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist:
プロパティは、「プロパティ名要素」と呼ばれるプロパティ名で構成されるXML要素で常に表されます。最も単純な例は空のプロパティで、存在しないプロパティとは異なります。
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
The value of the property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. Servers MUST preserve the following XML Information Items (using the terminology from [REC-XML-INFOSET]) in storage and transmission of dead properties:
プロパティの値は、プロパティ名要素内に表示されます。この値は、テキストのみのコンテンツと混合コンテンツの両方を含む、任意の種類のよく形成されたXMLコンテンツである場合があります。サーバーは、死んだプロパティのストレージと送信で、次のXML情報項目を保存する必要があります（[Rec-XML-Infoset]の用語を使用）：
For the property name Element Information Item itself:
プロパティ名要素情報アイテム自体の場合：
[namespace name]
[名前空間名]
[local name]
[ローカル名]
[attributes] named "xml:lang" or any such attribute in scope
[属性]「xml：lang」またはそのような属性の範囲の名前
[children] of type element or character
[子供]タイプの要素またはキャラクターの
On all Element Information Items in the property value:
プロパティ値のすべての要素情報項目について：
[namespace name]
[名前空間名]
[local name]
[ローカル名]
[attributes]
[属性]
[children] of type element or character
[子供]タイプの要素またはキャラクターの
On Attribute Information Items in the property value:
プロパティ値の属性情報項目について：
[namespace name]
[名前空間名]
[local name]
[ローカル名]
[normalized value]
[正規化された値]
On Character Information Items in the property value:
プロパティ値の文字情報項目について：
[character code]
[文字コード]
Since prefixes are used in some XML vocabularies (XPath and XML Schema, for example), servers SHOULD preserve, for any Information Item in the value:
プレフィックスはいくつかのXML語彙（XPathおよびXMLスキーマなど）で使用されているため、値の情報項目については、サーバーを保持する必要があります。
[prefix]
[プレフィックス]
XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. The above rules would also apply by default to live properties, unless defined otherwise.
上記のXML Infoset属性は、サーバーによって保存される場合がありますが、クライアントは保存されていることに依存してはなりません。特に定義されていない限り、上記のルールはデフォルトでライブプロパティにも適用されます。
Servers MUST ignore the XML attribute xml:space if present and never use it to change whitespace handling. Whitespace in property values is significant.
サーバーは、XML属性XML：存在する場合はスペースを無視する必要があり、それを使用して空白の取り扱いを変更しないでください。プロパティ値の空白は重要です。
Consider a dead property 'author' created by the client as follows:
クライアントが作成した「著者」を次のように考えてみましょう。
<D:prop xml:lang="en" xmlns:D="DAV:">
<x:author xmlns:x='http://example.com/ns'>
<x:name>Jane Doe</x:name>
<!-- Jane's contact info -->
<x:uri type='email'
added='2005-11-26'>mailto:jane.doe@example.com</x:uri>
<x:uri type='web'
added='2005-11-27'>http://www.example.com</x:uri>
<x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <![CDATA[<RFC2518>]]>.
</x:notes>
</x:author>
</D:prop>
When this property is requested, a server might return:
このプロパティが要求されると、サーバーが返される場合があります。
<D:prop xmlns:D='DAV:'><author
xml:lang='en'
xmlns:x='http://example.com/ns'
xmlns='http://example.com/ns'
xmlns:h='http://www.w3.org/1999/xhtml'>
<x:name>Jane Doe</x:name>
<x:uri added="2005-11-26" type="email"
>mailto:jane.doe@example.com</x:uri>
<x:uri added="2005-11-27" type="web"
>http://www.example.com</x:uri>
<x:notes>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <RFC2518>.
</x:notes>
</author>
</D:prop>
Note in this example:
この例に注意してください：
o The [prefix] for the property name itself was not preserved, being non-significant, whereas all other [prefix] values have been preserved,
o プロパティ名自体の[プレフィックス]は保存されておらず、有意ではありませんが、他のすべての[プレフィックス]値は保存されています。
o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and attribute order has not been preserved,
o 属性値は、単一の引用符の代わりに二重引用符で書き直されています（引用符は重要ではありません）、属性順序は保持されていません。
o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope),
o XML：Lang属性はプロパティ名要素自体に返されました（プロパティが設定されたときは範囲でしたが、応答の正確な位置は、範囲内にある限り有意とは見なされません）、
o whitespace between tags has been preserved everywhere (whitespace between attributes not so),
o タグ間のホワイトスペースはどこにでも保存されています（属性間ではない属性間の白い空間）、
o CDATA encapsulation was replaced with character escaping (the reverse would also be legal),
o CDATAのカプセル化は、キャラクターの脱出に置き換えられました（逆も合法です）、
o the comment item was stripped (as would have been a processing instruction item).
o コメント項目は剥がされました（処理命令項目であったように）。
Implementation note: there are cases such as editing scenarios where clients may require that XML content is preserved character by character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing.
実装注：クライアントがXMLコンテンツが文字ごとに保存された文字（属性の順序付けや引用スタイルなど）を要求する場合がある場合、シナリオの編集などのケースがあります。この場合、クライアントは、XML解析で特別な意味を持つすべてのキャラクターを逃れることにより、テキストのみのプロパティ値を使用することを検討する必要があります。
A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property.
プロパティ名は、プロパティの構文とセマンティクスに関する情報を提供するスキーマに関連付けられた普遍的に一意の識別子です。
Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition.
プロパティの名前は普遍的に一意であるため、クライアントは、問題のリソースでそのプロパティが「ライブ」である限り、複数のリソース、同じ、および異なるサーバーにわたる特定のプロパティの一貫した動作に依存できます。生きている財産はその定義に忠実です。
The XML namespace mechanism, which is based on URIs ([RFC3986]), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control.
uris（[rfc3986]）に基づいたXMLネームスペースメカニズムは、名前空間の衝突を防ぎ、さまざまな程度の管理制御を提供するため、プロパティの名前を付けるために使用されます。
The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced that will address issues relating to hierarchical properties.
プロパティネームスペースはフラットです。つまり、プロパティの階層は明示的に認識されていません。したがって、プロパティAとプロパティA/Bがリソースに存在する場合、2つのプロパティ間の関係の認識はありません。最終的には、階層特性に関連する問題に対処する別の仕様が生成されることが予想されます。
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.
最後に、単一のリソースで同じプロパティを2回定義することはできません。これにより、リソースのプロパティネームスペースに衝突が発生するためです。
Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one, or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.
一部のHTTPリソースは、サーバーによって動的に生成されます。これらのリソースについては、おそらくそのリソースがどのように生成されるかを管理するどこかにソースコードが存在すると思われます。ソースファイルとHTTPリソースの出力との関係は、1対1、多く、多く、または多くの関係である場合があります。HTTPには、リソースが動的であるかどうかを判断するメカニズムはありません。ソースファイルがどこに存在するか、どのように作成するかはもちろんです。この問題は有用に解決されますが、相互運用可能なWebDAV実装は、静的リソースのみを扱うことにより、実際にこの問題を解決することなく広く展開されています。したがって、ソースと出力の問題はこの仕様では解決されず、別のドキュメントに延期されています。
This section provides a description of a type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace and with HTTP methods. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace.
このセクションでは、Webリソースの種類、コレクションの説明を提供し、HTTP URLネームスペースとHTTPメソッドとの相互作用について説明します。コレクションリソースの目的は、サーバーの名前空間内でコレクションのようなオブジェクト（ファイルシステムディレクトリなど）をモデル化することです。
All DAV-compliant resources MUST support the HTTP URL namespace model specified herein.
すべてのDAVに準拠したリソースは、ここで指定されているHTTP URL名空間モデルをサポートする必要があります。
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.
HTTP URLネームスペースは、階層が「/」文字で区切られている階層名空間です。
An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member URL. The root, or top-level collection of the namespace under consideration, is exempt from the previous rule. The top-level collection of the namespace under consideration is not necessarily the collection identified by the absolute path '/' -- it may be identified by one or more path segments (e.g., /servlets/webdav/...)
HTTP URLネームスペースは、次の条件を満たしている場合に一貫していると言われています。HTTP階層内のすべてのURLに、そのURLが内部メンバーURLとして含まれるコレクションが存在します。検討中の名前空間のルートまたはトップレベルのコレクションは、前のルールから免除されます。検討中の名前空間のトップレベルのコレクションは、必ずしも絶対パス '/'によって識別されるコレクションではありません - 1つ以上のパスセグメント（例：/servlets/webdav/...）によって識別される場合があります。
Neither HTTP/1.1 nor WebDAV requires that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.
HTTP/1.1もWebDAVも、HTTP URLネームスペース全体が一貫している必要はありません。WebDAV互換リソースには親コレクションがない場合があります。ただし、特定のWebDAVメソッドは、名前空間の矛盾を引き起こす結果を生成することを禁止されています。
As is implicit in [RFC2616] and [RFC3986], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
[RFC2616]および[RFC3986]で暗黙的であるように、収集リソースを含むすべてのリソースは、複数のURIによって識別される場合があります。たとえば、複数のHTTP URLによってリソースを識別できます。
Collection resources differ from other resources in that they also act as containers. Some HTTP methods apply only to a collection, but some apply to some or all of the resources inside the container defined by the collection. When the scope of a method is not clear, the client can specify what depth to apply. Depth can be either zero levels (only the collection), one level (the collection and directly contained resources), or infinite levels (the collection and all contained resources recursively).
収集リソースは、コンテナとしても機能するという点で、他のリソースとは異なります。一部のHTTPメソッドはコレクションにのみ適用されますが、一部はコレクションで定義されているコンテナ内のリソースの一部またはすべてに適用されます。メソッドの範囲が明確でない場合、クライアントは適用する深さを指定できます。深さは、ゼロレベル（コレクションのみ）、1つのレベル（コレクションと直接含まれるリソース）、または無限レベル（コレクションとすべてが再帰的に含まれているリソースを含む）のいずれかです。
A collection's state consists of at least a set of mappings between path segments and resources, and a set of properties on the collection itself. In this document, a resource B will be said to be contained in the collection resource A if there is a path segment mapping that maps to B and that is contained in A. A collection MUST contain at most one mapping for a given path segment, i.e., it is illegal to have the same path segment mapped to more than one resource.
コレクションの状態は、少なくともパスセグメントとリソースの間のマッピングのセットと、コレクション自体のプロパティのセットで構成されています。このドキュメントでは、リソースBがコレクションリソースAに含まれていると言われます。Bへのマップが含まれているパスセグメントマッピングがあり、それがAに含まれる場合、コレクションには、特定のパスセグメントの最大1つのマッピングを含める必要があります。つまり、同じパスセグメントを複数のリソースにマッピングすることは違法です。
Properties defined on collections behave exactly as do properties on non-collection resources. A collection MAY have additional state such as entity bodies returned by GET.
コレクションで定義されているプロパティは、非収集リソースのプロパティとまったく同じように動作します。コレクションには、GETによって返されるエンティティボディなどの追加の状態があります。
For all WebDAV-compliant resources A and B, identified by URLs "U" and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain exactly one mapping from "blah" to B.
「V」が「u/セグメント」に等しくなるように、それぞれ「u」と「v」で識別されるすべてのwebdavに準拠したリソースaおよびbについて、「セグメント」からのマッピングを含むコレクションでなければなりません。B.に、url「http://example.com/bar/blah」を備えたリソースBがWebdavに準拠し、url "http://example.com/bar/"がwebdavに準拠している場合は、リソースの場合、リソースaはコレクションである必要があり、「何とか」からBまでの1つのマッピングを含む必要があります
Although commonly a mapping consists of a single segment and a resource, in general, a mapping consists of a set of segments and a resource. This allows a server to treat a set of segments as equivalent (i.e., either all of the segments are mapped to the same resource, or none of the segments are mapped to a resource). For example, a server that performs case-folding on segments will treat the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can then use any of these segments to identify the resource. Note that a PROPFIND result will select one of these equivalent segments to identify the mapping, so there will be one PROPFIND response element per mapping, not one per segment in the mapping.
一般に、マッピングは単一のセグメントとリソースで構成されていますが、一般に、マッピングはセグメントのセットとリソースで構成されます。これにより、サーバーは一連のセグメントを同等のものとして扱うことができます（つまり、すべてのセグメントが同じリソースにマッピングされるか、セグメントのいずれもリソースにマッピングされません）。たとえば、セグメントでケース折りたたみを実行するサーバーは、セグメント「AB」、「AB」、「AB」、および「AB」を同等のものとして扱います。クライアントは、これらのセグメントのいずれかを使用してリソースを識別できます。Propfind Resultは、これらの同等のセグメントのいずれかを選択してマッピングを識別するため、マッピングごとに1つのPropfind Response要素があり、マッピングの1つのペグメントは1つではありません。
Collection resources MAY have mappings to non-WebDAV-compliant resources in the HTTP URL namespace hierarchy but are not required to do so. For example, if resource X with URL "http://example.com/bar/blah" is not WebDAV compliant and resource A with "URL http://example.com/bar/" identifies a WebDAV collection, then A may or may not have a mapping from "blah" to X.
収集リソースには、HTTP URLネームスペース階層の非WebDAV準拠のリソースへのマッピングがある場合がありますが、そうする必要はありません。たとえば、url "http://example.com/bar/blah"を備えたリソースXがWebdavに準拠していない場合、「url http://example.com/bar/」を使用してリソースAがWebdavコレクションを識別します。または、「何とか」からXへのマッピングがない場合があります。
If a WebDAV-compliant resource has no WebDAV-compliant internal members in the HTTP URL namespace hierarchy, then the WebDAV-compliant resource is not required to be a collection.
WebDAVに準拠したリソースにHTTP URLネームスペース階層にWebDAV準拠の内部メンバーがない場合、WebDAVに準拠したリソースはコレクションである必要はありません。
There is a standing convention that when a collection is referred to by its name without a trailing slash, the server MAY handle the request as if the trailing slash were present. In this case, it SHOULD return a Content-Location header in the response, pointing to the URL ending with the "/". For example, if a client invokes a method on http://example.com/blah (no trailing slash), the server may respond as if the operation were invoked on http://example.com/blah/ (trailing slash), and should return a Content-Location header with the value http://example.com/blah/. Wherever a server produces a URL referring to a collection, the server SHOULD include the trailing slash. In general, clients SHOULD use the trailing slash form of collection names. If clients do not use the trailing slash form the client needs to be prepared to see a redirect response. Clients will find the DAV:resourcetype property more reliable than the URL to find out if a resource is a collection.
コレクションがその名前で後続のスラッシュなしで言及されると、サーバーがトレーリングスラッシュが存在するかのようにリクエストを処理する可能性があるという常立コンベンションがあります。この場合、「/」で終わるURLを指して、応答のコンテンツロケーションヘッダーを返す必要があります。たとえば、クライアントがhttp://example.com/blah（トレーリングスラッシュなし）でメソッドを呼び出した場合、サーバーはhttp://example.com/blah/（トレーリングスラッシュ）で操作が呼び出されたかのように応答する場合があります。、そして、値http://example.com/blah/のコンテンツロケーションヘッダーを返す必要があります。サーバーがコレクションを参照するURLを生成するところならどこでも、サーバーにはトレーリングスラッシュを含める必要があります。一般に、クライアントはコレクション名の後続のスラッシュ形式を使用する必要があります。クライアントがトレーリングスラッシュフォームを使用しない場合、クライアントはリダイレクト応答を確認するために準備する必要があります。クライアントは、リソースがコレクションであるかどうかを確認するために、URLよりも信頼性が高いDAV：ResourceTypeプロパティを見つけます。
Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if an OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections.
クライアントは、WebDAVリソースが非WebDAVリソース内に含まれている場合をサポートできる必要があります。たとえば、「http://example.com/servlet/dav/collection」からのオプション応答がWebdavサポートを示している場合、クライアントは「http://example.com/servlet/dav/」またはその親を必然的に想定できないwebdavコレクションです。
A typical scenario in which mapped URLs do not appear as members of their parent collection is the case where a server allows links or redirects to non-WebDAV resources. For instance, "/col/link" might not appear as a member of "/col/", although the server would respond with a 302 status to a GET request to "/col/link"; thus, the URL "/col/link" would indeed be mapped. Similarly, a dynamically-generated page might have a URL mapping from "/col/index.html", thus this resource might respond with a 200 OK to a GET request yet not appear as a member of "/col/".
マッピングされたURLが親コレクションのメンバーとして表示されない典型的なシナリオは、サーバーが非WebDAVリソースにリンクまたはリダイレクトを許可する場合です。たとえば、「/col/link」は「/col/」のメンバーとして表示されない場合がありますが、サーバーは「/col/link」へのgetリクエストに302ステータスで応答します。したがって、URL「/col/link」が実際にマッピングされます。同様に、動的に生成されたページには、 "/col/index.html"からのURLマッピングがある可能性があるため、このリソースは200 OKでgetリクエストに応答しますが、「/col/」のメンバーとして表示されない場合があります。
Some mappings to even WebDAV-compliant resources might not appear in the parent collection. An example for this case are servers that support multiple alias URLs for each WebDAV-compliant resource. A server may implement case-insensitive URLs, thus "/col/a" and "/col/A" identify the same resource, yet only either "a" or "A" is reported upon listing the members of "/col". In cases where a server treats a set of segments as equivalent, the server MUST expose only one preferred segment per mapping, consistently chosen, in PROPFIND responses.
WebDavに準拠したリソースのいくつかのマッピングは、親コレクションには表示されない場合があります。このケースの例は、各WebDAV準拠リソースの複数のエイリアスURLをサポートするサーバーです。サーバーはケースに依存しないURLを実装する場合があります。したがって、「/col/a」と「/col/a」は同じリソースを識別しますが、「/col」のメンバーをリストすると「a」または「a」のみが報告されます。サーバーが一連のセグメントを同等のものとして扱う場合、サーバーは、プロパンド応答で一貫して選択されたマッピングごとに1つの優先セグメントのみを公開する必要があります。
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.
この仕様により、ロックは、2つのクライアント指定パラメーター、関与するプリンシパルの数（排他的対共有）、および許可されるアクセスの種類を変化させることができます。このドキュメントでは、1つのアクセスタイプのみのロックを定義します。ただし、構文は拡張可能であり、他のアクセスタイプのロックの最終的な仕様を可能にします。
This section provides a concise model for how locking behaves. Later sections will provide more detail on some of the concepts and refer back to these model statements. Normative statements related to LOCK and UNLOCK method handling can be found in the sections on those methods, whereas normative statements that cover any method are gathered here.
このセクションでは、ロックの動作方法に関する簡潔なモデルを提供します。後のセクションでは、いくつかの概念の詳細を説明し、これらのモデルステートメントを参照してください。ロックおよびロック解除方法の処理に関連する規範的なステートメントは、これらの方法のセクションに記載されていますが、任意の方法をカバーする規範的なステートメントはここに収集されます。
1. A lock either directly or indirectly locks a resource.
1. ロックは、直接または間接的にリソースをロックします。
2. A resource becomes directly locked when a LOCK request to a URL of that resource creates a new lock. The "lock-root" of the new lock is that URL. If at the time of the request, the URL is not mapped to a resource, a new empty resource is created and directly locked.
2. そのリソースのURLへのロック要求が新しいロックを作成すると、リソースが直接ロックされます。新しいロックの「ロックルート」はそのURLです。リクエストの時点で、URLがリソースにマッピングされていない場合、新しい空のリソースが作成され、直接ロックされます。
3. An exclusive lock (Section 6.2) conflicts with any other kind of lock on the same resource, whether either lock is direct or indirect. A server MUST NOT create conflicting locks on a resource.
3. 排他的ロック（セクション6.2）は、ロックが直接であろうと間接であろうと、同じリソース上の他の種類のロックと競合します。サーバーは、リソース上に競合するロックを作成してはなりません。
4. For a collection that is locked with a depth-infinity lock L, all member resources are indirectly locked. Changes in membership of such a collection affect the set of indirectly locked resources:
4. 深さの装備ロックLでロックされているコレクションの場合、すべてのメンバーリソースは間接的にロックされています。このようなコレクションのメンバーシップの変更は、間接的にロックされたリソースのセットに影響します。
* If a member resource is added to the collection, the new member resource MUST NOT already have a conflicting lock, because the new resource MUST become indirectly locked by L.
* メンバーリソースがコレクションに追加された場合、新しいリソースがLによって間接的にロックされている必要があるため、新しいメンバーリソースに矛盾するロックがまだ存在してはなりません。
* If a member resource stops being a member of the collection, then the resource MUST no longer be indirectly locked by L.
* メンバーリソースがコレクションのメンバーになるのを停止した場合、リソースをLで間接的にロックする必要はありません。
5. Each lock is identified by a single globally unique lock token (Section 6.5).
5. 各ロックは、単一のグローバルに一意のロックトークン（セクション6.5）によって識別されます。
6. An UNLOCK request deletes the lock with the specified lock token. After a lock is deleted, no resource is locked by that lock.
6. ロック解除要求は、指定されたロックトークンでロックを削除します。ロックが削除された後、そのロックによってロックされたリソースはありません。
7. A lock token is "submitted" in a request when it appears in an "If" header (Section 7, "Write Lock", discusses when token submission is required for write locks).
7. ロックトークンは、「セクション7、「書き込みロック」」の「if」ヘッダーに表示されると、リクエストで「送信」され、書き込みロックにトークンの提出が必要な時期について説明します）。
8. If a request causes the lock-root of any lock to become an unmapped URL, then the lock MUST also be deleted by that request.
8. 要求がロックのロックルートをマップされていないURLにする場合、その要求によってロックも削除する必要があります。
The most basic form of lock is an exclusive lock. Exclusive locks avoid having to deal with content change conflicts, without requiring any coordination other than the methods described in this specification.
ロックの最も基本的な形式は、排他的なロックです。排他的なロックは、この仕様に記載されている方法以外の調整を必要とせずに、コンテンツの変更競合に対処する必要がありません。
However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal that has both access privileges and a valid lock can use the locked resource.
ただし、ロックの目標は、他の人がアクセス権を行使することを排除するのではなく、校長がアクセス権を行使するつもりであることを示すメカニズムを提供することである場合があります。このケースには共有ロックが提供されます。共有ロックにより、複数のプリンシパルがロックを受信できます。したがって、アクセス権限と有効なロックの両方を備えたプリンシパルは、ロックされたリソースを使用できます。
With shared locks, there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set.
共有ロックを使用すると、リソースに影響を与える2つの信頼セットがあります。最初の信頼セットは、アクセス許可によって作成されます。たとえば、信頼できるプリンシパルは、リソースに書き込む許可を持っている場合があります。リソースに書き込むアクセス許可を持つ人々のうち、共有ロックを取り出したプリンシパルのセットもお互いを信頼し、アクセス許可書書き込みセット内に（通常）より小さな信頼セットを作成する必要があります。
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.
インターネット上のすべての可能なプリンシパルから始めて、ほとんどの場合、これらのプリンシパルの大部分は特定のリソースへの書き込みアクセスを持っていません。書き込みアクセスを持っている少数の人のうち、一部のプリンシパルは、独占的な書き込みロックを使用して、編集が競合を上書きできないことを保証することを決定する場合があります。他の人は、協力者が自分の仕事を上書きしないことを信頼していると判断する場合があります（協力者の潜在的なセットは、許可を書く校長のセットです）。共有ロックを使用してください。
The WebDAV extensions to HTTP do not need to provide all of the communications paths necessary for principals to coordinate their activities. When using shared locks, principals may use any out-of-band communication channel to coordinate their work (e.g., face-to-face interaction, written notes, post-it notes on the screen, telephone conversation, email, etc.) The intent of a shared lock is to let collaborators know who else may be working on a resource.
httpへのwebdav拡張機能は、校長がアクティビティを調整するために必要なすべての通信パスを提供する必要はありません。共有ロックを使用する場合、プリンシパルは帯域外の通信チャネルを使用して作業を調整することができます（例：対面の相互作用、書面によるメモ、画面に関するポストイットメモ、電話での会話、電子メールなど）共有ロックの意図は、コラボレーターに他の人がリソースに取り組んでいる可能性があることを知らせることです。
Shared locks are included because experience from Web-distributed authoring systems has indicated that exclusive locks are often too rigid. An exclusive lock is used to enforce a particular editing process: take out an exclusive lock, read the resource, perform edits, write the resource, release the lock. This editing process has the problem that locks are not always properly released, for example, when a program crashes or when a lock creator leaves without unlocking a resource. While both timeouts (Section 6.6) and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.
Web-Distributed Authorling Systemsの経験により、排他的なロックが硬すぎることが多すぎることが示されているため、共有ロックが含まれています。特定の編集プロセスを実施するために排他的ロックを使用します。排他的ロックを取り出し、リソースの読み取り、編集、リソースの書き込み、ロックを解放します。この編集プロセスには、ロックが常に適切にリリースされるとは限らないという問題があります。たとえば、プログラムがクラッシュしたとき、またはロック作成者がリソースのロックを解除せずに離れるときです。タイムアウト（セクション6.6）と管理アクションの両方を使用して、問題のあるロックを削除することができますが、どちらのメカニズムも必要なときに利用できない場合があります。タイムアウトが長い場合があるか、管理者が利用できない場合があります。
A successful request for a new shared lock MUST result in the generation of a unique lock associated with the requesting principal. Thus, if five principals have taken out shared write locks on the same resource, there will be five locks and five lock tokens, one for each principal.
新しい共有ロックのリクエストが成功すると、リクエストプリンシパルに関連付けられた一意のロックの生成につながる必要があります。したがって、5人のプリンシパルが同じリソースで共有の書き込みロックを取り出した場合、各プリンシパルに1つのロックトークンが5つあります。
A WebDAV-compliant resource is not required to support locking in any form. If the resource does support locking, it may choose to support any combination of exclusive and shared locks for any access types.
WebDAVに準拠したリソースは、いかなる形式でもロックをサポートする必要はありません。リソースがロックをサポートしている場合、アクセスタイプの排他的ロックと共有ロックの任意の組み合わせをサポートすることを選択できます。
The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks, while others only provide support for exclusive write locks, while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.
この柔軟性の理由は、ポリシーのロックが、さまざまなストレージリポジトリで採用されているリソース管理およびバージョンシステムのまさに中心に衝突するためです。これらのリポジトリには、どのようなロックが利用可能になるかを制御する必要があります。たとえば、一部のリポジトリは共有の書き込みロックのみをサポートしていますが、他のリポジトリは排他的な書き込みロックのみをサポートしますが、他のリポジトリはロックをまったく使用していません。各システムは特定のロック機能を除外するのに役立つほど十分に異なるため、この仕様はWebDAV内の交渉の唯一の軸としてロックを残します。
The creator of a lock has special privileges to use the lock to modify the resource. When a locked resource is modified, a server MUST check that the authenticated principal matches the lock creator (in addition to checking for valid lock token submission).
ロックの作成者には、ロックを使用してリソースを変更する特別な特権があります。ロックされたリソースが変更された場合、サーバーは、認証されたプリンシパルがロック作成者と一致することを確認する必要があります（有効なロックトークンの提出をチェックすることに加えて）。
The server MAY allow privileged users other than the lock creator to destroy a lock (for example, the resource owner or an administrator). The 'unlock' privilege in [RFC3744] was defined to provide that permission.
サーバーは、ロック作成者以外の特権ユーザーがロックを破壊することを許可する場合があります（たとえば、リソースの所有者や管理者など）。[RFC3744]の「ロック解除」特権は、その許可を提供するために定義されました。
There is no requirement for servers to accept LOCK requests from all users or from anonymous users.
サーバーがすべてのユーザーまたは匿名ユーザーからロック要求を受け入れる必要はありません。
Note that having a lock does not confer full privilege to modify the locked resource. Write access and other privileges MUST be enforced through normal privilege or authentication mechanisms, not based on the possible obscurity of lock token values.
ロックを持つことは、ロックされたリソースを変更するための完全な特権を付与しないことに注意してください。書き込みアクセスおよびその他の特権は、ロックトークン値の不明瞭さの可能性に基づいたものではなく、通常の特権または認証メカニズムを通じて実施する必要があります。
A lock token is a type of state token that identifies a particular lock. Each lock has exactly one unique lock token generated by the server. Clients MUST NOT attempt to interpret lock tokens in any way.
ロックトークンは、特定のロックを識別するステートトークンの一種です。各ロックには、サーバーによって生成された一意のロックトークンが1つあります。クライアントは、ロックトークンを決して解釈しようとしてはなりません。
Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. Since lock tokens are unique, a client MAY submit a lock token in an If header on a resource other than the one that returned it.
ロックトークンURIは、常にすべてのリソースでユニークでなければなりません。この独自性の制約により、混乱を恐れることなく、ロックトークンをリソースとサーバー間で提出することができます。ロックトークンは一意であるため、クライアントは、返品したリソース以外のリソース上のヘッダーにロックトークンを提出することができます。
When a LOCK operation creates a new lock, the new lock token is returned in the Lock-Token response header defined in Section 10.5, and also in the body of the response.
ロック操作が新しいロックを作成すると、新しいロックトークンは、セクション10.5で定義されたロックトークン応答ヘッダーと、応答の本文で返されます。
Servers MAY make lock tokens publicly readable (e.g., in the DAV: lockdiscovery property). One use case for making lock tokens readable is so that a long-lived lock can be removed by the resource owner (the client that obtained the lock might have crashed or disconnected before cleaning up the lock). Except for the case of using UNLOCK under user guidance, a client SHOULD NOT use a lock token created by another client instance.
サーバーは、ロックトークンを公開可能にする場合があります（例：DAV：Lock -Discoveryプロパティ）。ロックトークンを読みやすくするための1つのユースケースは、リソースの所有者（ロックを取得したクライアントがロックをクリーンアップする前にクラッシュまたは切断された可能性がある）が長寿命のロックを削除できるようにすることです。ユーザーガイダンスの下でロック解除を使用する場合を除き、クライアントは別のクライアントインスタンスによって作成されたロックトークンを使用しないでください。
This specification encourages servers to create Universally Unique Identifiers (UUIDs) for lock tokens, and to use the URI form defined by "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]). However, servers are free to use any URI (e.g., from another scheme) so long as it meets the uniqueness requirements. For example, a valid lock token might be constructed using the "opaquelocktoken" scheme defined in Appendix C.
この仕様により、サーバーはロックトークン用の普遍的に一意の識別子（UUIDS）を作成し、「普遍的に一意の識別子（UUID）urnネームスペース」（[RFC4122]）で定義されたURIフォームを使用することを奨励しています。ただし、サーバーは、ユニークネス要件を満たしている限り、URI（例えば、別のスキームから）を無料で使用できます。たとえば、付録Cで定義されている「Opaquelocktoken」スキームを使用して、有効なロックトークンを構築することができます。
Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
A lock MAY have a limited lifetime. The lifetime is suggested by the client when creating or refreshing the lock, but the server ultimately chooses the timeout value. Timeout is measured in seconds remaining until lock expiration.
ロックの寿命は限られている可能性があります。ロックを作成または更新するときに、クライアントが寿命を提案しますが、サーバーは最終的にタイムアウト値を選択します。タイムアウトは、ロックの有効期限が切れるまで残り秒で測定されます。
The timeout counter MUST be restarted if a refresh lock request is successful (see Section 9.10.2). The timeout counter SHOULD NOT be restarted at any other time.
更新ロック要求が成功した場合は、タイムアウトカウンターを再起動する必要があります（セクション9.10.2を参照）。タイムアウトカウンターは、他の時間に再起動しないでください。
If the timeout expires, then the lock SHOULD be removed. In this case the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with its override authority.
タイムアウトの有効期限が切れた場合、ロックを取り外す必要があります。この場合、サーバーは、オーバーライド権限で実行されたタイムアウトロックのロックトークンを使用して、リソース上のサーバーによってロック解除メソッドが実行されたかのように動作する必要があります。
Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going offline.
サーバーは、クライアントが実行しようとするアクティビティのタイプを示すため、クライアントが提出した値に細心の注意を払うことをお勧めします。たとえば、ブラウザで実行されているアプレットはリソースをロックする必要がある場合がありますが、アプレットが実行されている環境の不安定性のため、警告なしにアプレットをオフにすることができます。その結果、アプレットは比較的小さなタイムアウト値を要求する可能性が高いため、アプレットが死んだ場合、ロックをすばやく収集できるようになります。ただし、ドキュメント管理システムは、ユーザーがオフラインになることを計画している可能性があるため、非常に長いタイムアウトを要求する可能性があります。
A client MUST NOT assume that just because the timeout has expired, the lock has immediately been removed.
クライアントは、タイムアウトが期限切れになったからといって、ロックがすぐに削除されたと仮定してはなりません。
Likewise, a client MUST NOT assume that just because the timeout has not expired, the lock still exists. Clients MUST assume that locks can arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if extraordinary circumstances do not occur. For example, a sufficiently privileged user may remove a lock at any time, or the system may crash in such a way that it loses the record of the lock's existence.
同様に、クライアントは、タイムアウトが期限切れになっていないからといって、ロックがまだ存在すると仮定してはなりません。クライアントは、タイムアウトヘッダーで与えられた値に関係なく、いつでもロックが任意に消える可能性があると想定する必要があります。タイムアウトヘッダーは、異常な状況が発生しない場合にのみサーバーの動作を示します。たとえば、十分に特権のあるユーザーは、いつでもロックを削除するか、システムがロックの存在の記録を失うようにクラッシュする場合があります。
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. A client can determine what lock types the server supports by retrieving the DAV:supportedlock property.
サーバーロックサポートはオプションであるため、サーバー上のリソースをロックしようとするクライアントは、ロックを試して最善を希望するか、サーバーがサポートするロック機能を決定するために何らかの形のディスカバリーを実行できます。これは、ロック機能ディスカバリーとして知られています。クライアントは、DAV：SupportEdLockプロパティを取得することにより、サーバーがサポートするロックタイプを決定できます。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:supportedlock property.
ロックメソッドをサポートするDAVに準拠したリソースは、DAV：SupportEdLockプロパティをサポートする必要があります。
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the DAV:lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and MAY even provide the lock tokens.
別のプリンシパルがアクセスを希望するリソースをロックする場合、2番目のプリンシパルが最初のプリンシパルが誰であるかを見つけることができることが役立ちます。この目的のために、DAV：Lock -Discoveryプロパティが提供されます。このプロパティは、すべての未解決のロックをリストし、そのタイプを説明し、ロックトークンを提供することさえあります。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:lockdiscovery property.
ロックメソッドをサポートするDAVに準拠したリソースは、DAV：Lock-Discoveryプロパティをサポートする必要があります。
This section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification.
このセクションでは、書き込みロックタイプに固有のセマンティクスについて説明します。書き込みロックは、ロックタイプの特定のインスタンスであり、この仕様で説明されている唯一のロックタイプです。
An exclusive write lock protects a resource: it prevents changes by any principal other than the lock creator and in any case where the lock token is not submitted (e.g., by a client process other than the one holding the lock).
排他的な書き込みロックはリソースを保護します。ロッククリエーター以外のプリンシパルによる変更を防ぎ、ロックトークンが提出されない場合（たとえば、ロックを保持しているもの以外のクライアントプロセスによって）。
Clients MUST submit a lock-token they are authorized to use in any request that modifies a write-locked resource. The list of modifications covered by a write-lock include:
クライアントは、書き込みロックされたリソースを変更するリクエストで使用することを許可されているロックトークンを提出する必要があります。書き込みロックでカバーされている修正のリストは次のとおりです。
1. A change to any of the following aspects of any write-locked resource:
1. 書き込みロックされたリソースの次の側面のいずれかに変更します。
* any variant,
* 任意のバリアント、
* any dead property,
* 死んだ財産、
* any live property that is lockable (a live property is lockable unless otherwise defined.)
* ロック可能なライブプロパティ（特に定義されていない限り、ライブプロパティはロック可能です。）
2. For collections, any modification of an internal member URI. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. More discussion on write locks and collections is found in Section 7.4.
2. コレクションの場合、内部メンバーURIの変更。コレクションの内部メンバーURIは、別のリソースを追加、削除、または識別すると、変更されると見なされます。書き込みロックとコレクションの詳細については、セクション7.4に記載されています。
3. A modification of the mapping of the root of the write lock, either to another resource or to no resource (e.g., DELETE).
3. 他のリソースまたはリソースなし（削除）のいずれかに、書き込みロックのルートのマッピングの変更。
Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and MKCOL are affected by write locks. All other HTTP/WebDAV methods defined so far -- GET in particular -- function independently of a write lock.
HTTPとWebDav、Put、Pos、Proppatch、Lock、Rock、Move、Copy（宛先リソース用）、削除、およびMKCOLで定義されているメソッドは、書き込みロックの影響を受けます。これまでに定義された他のすべてのHTTP/WebDAVメソッド - 特に入手 - 書き込みロックとは無関係に機能します。
The next few sections describe in more specific terms how write locks interact with various operations.
次のいくつかのセクションでは、書き込みロックがさまざまな操作とどのように相互作用するかをより具体的に説明しています。
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined as lockable are guaranteed not to change while write locked.
書き込みロックのない人は、リソース上のプロパティを変更しない場合がありますが、スキーマの要件により、ロックされていても、ライブプロパティの値が変更される可能性があります。ロック可能として定義されたデッドプロパティとライブプロパティのみが、書き込みのロック中に変更されないように保証されます。
Although the write locks provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario:
書き込みロックは、紛失した更新を防ぐための助けを提供しますが、更新が失われないことを保証することはできません。次のシナリオを検討してください。
Two clients A and B are interested in editing the resource 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking.
2人のクライアントAとBは、リソース「index.html」の編集に関心があります。クライアントAは、WebDAVクライアントではなくHTTPクライアントであるため、ロックを実行する方法がわかりません。
Client A doesn't lock the document, but does a GET, and begins editing.
クライアントAはドキュメントをロックしませんが、getを実行し、編集を開始します。
Client B does LOCK, performs a GET and begins editing.
クライアントBはロックし、GETを実行し、編集を開始します。
Client B finishes editing, performs a PUT, then an UNLOCK.
クライアントBは編集を終了し、プットを実行し、ロックを解除します。
Client A performs a PUT, overwriting and losing all of B's changes.
クライアントAは、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 /ロック解除などの一連の操作を実施することはできません。
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マッチヘッダーのエンティティタグを使用することにより、他のクライアントの変更を上書きすることを避けて、優秀な市民になる可能性があります。
Information managers may attempt to prevent overwrites by implementing client-side procedures requiring locking before modifying WebDAV resources.
情報マネージャーは、WebDAVリソースを変更する前にロックを必要とするクライアント側の手順を実装することにより、上書きを防ぐことができます。
WebDAV provides the ability to send a LOCK request to an unmapped URL in order to reserve the name for use. This is a simple way to avoid the lost-update problem on the creation of a new resource (another way is to use If-None-Match header specified in Section 14.26 of [RFC2616]). It has the side benefit of locking the new resource immediately for use of the creator.
WebDavは、使用のために名前を予約するために、マップされていないURLにロックリクエストを送信する機能を提供します。これは、新しいリソースの作成に関する損失の問題を回避する簡単な方法です（もう1つの方法は、[RFC2616]のセクション14.26で指定されたIF-Noneマッチヘッダーを使用することです）。作成者を使用するために、新しいリソースをすぐにロックするという補足の利点があります。
Note that the lost-update problem is not an issue for collections because MKCOL can only be used to create a collection, not to overwrite an existing collection. When trying to lock a collection upon creation, clients can attempt to increase the likelihood of getting the lock by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation, there's no guarantee this will work).
MKCOLは既存のコレクションを上書きするのではなく、コレクションの作成にのみ使用できるため、コレクションの損失の問題はコレクションの問題ではないことに注意してください。作成時にコレクションをロックしようとすると、クライアントはMKCOLとロックリクエストを一緒にパイプラインすることでロックを取得する可能性を高めようとします（ただし、2つの個別の操作を1つの原子動作に変換しないため、これが機能する保証はありません）。
A successful lock request to an unmapped URL MUST result in the creation of a locked (non-collection) resource with empty content. Subsequently, a successful PUT request (with the correct lock token) provides the content for the resource. Note that the LOCK request has no mechanism for the client to provide Content-Type or Content-Language, thus the server will use defaults or empty values and rely on the subsequent PUT request for correct values.
マップされていないURLへのロック要求が成功すると、空のコンテンツを使用してロックされた（非収集）リソースが作成される必要があります。その後、成功したプットリクエスト（正しいロックトークンを使用）は、リソースのコンテンツを提供します。ロックリクエストには、クライアントがコンテンツタイプまたはコンテンツランゲージを提供するメカニズムがないため、サーバーはデフォルトまたは空の値を使用し、その後の正しい値のリクエストに依存することに注意してください。
A resource created with a LOCK is empty but otherwise behaves in every way as a normal resource. It behaves the same way as a resource created by a PUT request with an empty body (and where a Content-Type and Content-Language was not specified), followed by a LOCK request to the same resource. Following from this model, a locked empty resource:
ロックで作成されたリソースは空ですが、それ以外の場合は通常のリソースとしてあらゆる方法で動作します。空のボディ（およびコンテンツタイプとコンテンツ言語が指定されていない場合）のプットリクエストによって作成されたリソースと同じように動作し、その後、同じリソースへのロックリクエストが続きます。このモデルから、ロックされた空のリソース：
o Can be read, deleted, moved, and copied, and in all ways behaves as a regular non-collection resource.
o 読み取り、削除、移動、コピーすることができ、あらゆる方法で通常の非収集リソースとして動作します。
o Appears as a member of its parent collection.
o 親コレクションのメンバーとして登場します。
o SHOULD NOT disappear when its lock goes away (clients must therefore be responsible for cleaning up their own mess, as with any other operation or any non-empty resource).
o ロックがなくなったときに消えてはいけません（したがって、クライアントは、他の操作や空白のないリソースと同様に、自分の混乱をクリーンアップする責任を負わなければなりません）。
o MAY NOT have values for properties like DAV:getcontentlanguage that haven't been specified yet by the client.
o クライアントがまだ指定していないDAV：GetContentLanguageのようなプロパティの値がない場合があります。
o Can be updated (have content added) with a PUT request.
o プットリクエストで更新（コンテンツを追加します）。
o MUST NOT be converted into a collection. The server MUST fail a MKCOL request (as it would with a MKCOL request to any existing non-collection resource).
o コレクションに変換してはなりません。サーバーは、MKCOLリクエストに失敗する必要があります（既存の非収集リソースへのMKCOLリクエストの場合）。
o MUST have defined values for DAV:lockdiscovery and DAV: supportedlock properties.
o DAVの値を定義している必要があります：Lock -DiscoveryとDAV：SupportEdLockプロパティ。
o The response MUST indicate that a resource was created, by use of the "201 Created" response code (a LOCK request to an existing resource instead will result in 200 OK). The body must still include the DAV:lockdiscovery property, as with a LOCK request to an existing resource.
o 応答は、「201」の応答コードを使用することにより、リソースが作成されたことを示している必要があります（既存のリソースへのロック要求は、代わりに200 OKになります）。既存のリソースへのロックリクエストのように、ボディにはまだDAV：Lock -Discoveryプロパティを含める必要があります。
The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH.
クライアントは、ロックされたロックされたリソースをロックしてすぐに更新し、Putと場合によってはプロップパッチを使用していることが期待されています。
Alternatively and for backwards compatibility to [RFC2518], servers MAY implement Lock-Null Resources (LNRs) instead (see definition in Appendix D). Clients can easily interoperate both with servers that support the old model LNRs and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET, and by not relying on specific properties of LNRs.
あるいは、[RFC2518]との逆方向の互換性については、代わりにロックヌルリソース（LNR）を実装する場合があります（付録Dの定義を参照）。クライアントは、古いモデルLNRSをサポートするサーバーと、MKCOLやGETではなくマップされていないURLにロックした後、LNRの特定のプロパティに依存しないことにより、「ロックされた空のリソース」の推奨モデルをサポートするサーバーと簡単に相互操作できます。
There are two kinds of collection write locks. A depth-0 write lock on a collection protects the collection properties plus the internal member URLs of that one collection, while not protecting the content or properties of member resources (if the collection itself has any entity bodies, those are also protected). A depth-infinity write lock on a collection provides the same protection on that collection and also provides write lock protection on every member resource.
コレクション書き込みロックには2種類あります。コレクションの深さ0の書き込みロックは、コレクションプロパティとその1つのコレクションの内部メンバーURLを保護し、メンバーリソースのコンテンツまたはプロパティを保護しません（コレクション自体にエンティティボディがある場合、それらも保護されています）。コレクションの深さの内容の書き込みロックは、そのコレクションで同じ保護を提供し、すべてのメンバーリソースに書き込みロック保護を提供します。
Expressed otherwise, a write lock of either kind protects any request that would create a new resource in a write locked collection, any request that would remove an internal member URL of a write locked collection, and any request that would change the segment name of any internal member.
それ以外の場合、どちらの種類の書き込みロックが、書き込みロックコレクションに新しいリソースを作成するリクエスト、書き込みロックコレクションの内部メンバーURLを削除するリクエスト、および任意のセグメント名を変更するリクエストを保護します。内部メンバー。
Thus, a collection write lock protects all the following actions:
したがって、コレクション書き込みロックは、次のすべてのアクションを保護します。
o DELETE a collection's direct internal member, o MOVE an internal member out of the collection,
o コレクションの直接的な内部メンバーを削除して、内部メンバーをコレクションから移動させます。
o MOVE an internal member into the collection,
o 内部メンバーをコレクションに移動し、
o MOVE to rename an internal member within a collection,
o コレクション内の内部メンバーの名前を変更するために移動し、
o COPY an internal member into a collection, and
o 内部メンバーをコレクションにコピーします
o PUT or MKCOL request that would create a new internal member.
o 新しい内部メンバーを作成するPutまたはMKCOLリクエスト。
The collection's lock token is required in addition to the lock token on the internal member itself, if it is locked separately.
コレクションのロックトークンは、個別にロックされている場合、内部メンバー自体のロックトークンに加えて必要です。
In addition, a depth-infinity lock affects all write operations to all members of the locked collection. With a depth-infinity lock, the resource identified by the root of the lock is directly locked, and all its members are indirectly locked.
さらに、深さの内容ロックは、ロックされたコレクションのすべてのメンバーに対するすべての書き込み操作に影響します。深さの内容ロックを使用すると、ロックのルートで識別されるリソースが直接ロックされ、そのメンバーはすべて間接的にロックされています。
o Any new resource added as a descendant of a depth-infinity locked collection becomes indirectly locked.
o 深さの内容ロックされたコレクションの子孫として追加された新しいリソースは、間接的にロックされます。
o Any indirectly locked resource moved out of the locked collection into an unlocked collection is thereafter unlocked.
o ロックされたコレクションからロック解除されたコレクションに移動した間、間接的にロックされたリソースは、その後ロック解除されます。
o Any indirectly locked resource moved out of a locked source collection into a depth-infinity locked target collection remains indirectly locked but is now protected by the lock on the target collection (the target collection's lock token will thereafter be required to make further changes).
o 間接的にロックされたリソースは、ロックされたソースコレクションから深さの内容ロックされたターゲットコレクションに移動しましたが、間接的にロックされたままですが、ターゲットコレクションのロックによって保護されています（ターゲットコレクションのロックトークンは、その後、さらなる変更を行う必要があります）。
If a depth-infinity write LOCK request is issued to a collection containing member URLs identifying resources that are currently locked in a manner that conflicts with the new lock (see Section 6.1, point 3), the request MUST fail with a 423 (Locked) status code, and the response SHOULD contain the 'no-conflicting-lock' precondition.
深さと環境の書き込みロック要求が、新しいロックと競合する方法で現在ロックされているリソースを識別するメンバーURLを含むコレクションに発行される場合（セクション6.1、ポイント3を参照）、リクエストは423（ロック）で失敗する必要がありますステータスコード、および応答には、「紛争なし」の前提条件が含まれている必要があります。
If a lock request causes the URL of a resource to be added as an internal member URL of a depth-infinity locked collection, then the new resource MUST be automatically protected by the lock. For example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c, then resource /a/b/c will be added to the write lock.
ロックリクエストがリソースのURLをDepting-Infinityロックコレクションの内部メンバーURLとして追加する場合、新しいリソースはロックによって自動的に保護されなければなりません。たとえば、コレクション/a/b/が書き込みロックされ、リソース/cが/a/b/cに移動されると、リソース/a/b/cが書き込みロックに追加されます。
A user agent has to demonstrate knowledge of a lock when requesting an operation on a locked resource. Otherwise, the following scenario might occur. In the scenario, program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization.
ユーザーエージェントは、ロックされたリソースで操作を要求するときに、ロックの知識を示す必要があります。それ以外の場合、次のシナリオが発生する可能性があります。シナリオでは、ユーザーAが実行するプログラムAは、リソースの書き込みロックを取り出します。また、ユーザーAが実行するプログラムBは、プログラムAによって撮影されたロックに関する知識はありませんが、ロックされたリソースにPutを実行します。このシナリオでは、ロックはプログラムではなくプリンシパルに関連付けられているため、プリンシップBはプリンシパルAの資格情報で作用しているため、Putを実行することが許可されているため、Putは成功します。ただし、プログラムBがロックについて知っていた場合、リソースを上書きしていなかったため、代わりにユーザーへの競合を説明するダイアログボックスを提示することを好みます。このシナリオのため、同じ許可を持つ他のプログラムによって撮影されたロックを誤って無視しないように、さまざまなプログラムを防ぐためにメカニズムが必要です。
In order to prevent these collisions, a lock token MUST be submitted by an authorized principal for all locked resources that a method may change or the method MUST fail. A lock token is submitted when it appears in an If header. For example, if a resource is to be moved and both the source and destination are locked, then two lock tokens must be submitted in the If header, one for the source and the other for the destination.
これらの衝突を防ぐために、メソッドが変更される可能性のあるすべてのロックされたリソースに対して、許可されたプリンシパルによってロックトークンを提出する必要があります。ロックトークンは、IFヘッダーに表示されるときに送信されます。たとえば、リソースを移動し、ソースと宛先の両方がロックされている場合、2つのロックトークンをIFヘッダーに提出する必要があります。1つはソース用、もう1つは宛先用です。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
If: <http://www.example.com/users/f/fielding/index.html>
(<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204コンテンツなし
In this example, even though both the source and destination are locked, only one lock token must be submitted (the one for the lock on the destination). This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.
この例では、ソースと宛先の両方がロックされていても、1つのロックトークンのみを提出する必要があります（宛先のロック用）。これは、ソースリソースがコピーによって変更されておらず、したがって書き込みロックの影響を受けないためです。この例では、ユーザーエージェント認証は、基礎となる輸送層内のHTTPプロトコルの範囲外のメカニズムを介して以前に発生しています。
Consider a collection "/locked" with an exclusive, depth-infinity write lock, and an attempt to delete an internal member "/locked/ member":
排他的で深さの深度書き込みロックを備えた「/ロック」と、内部メンバーを削除する試み "/locked/member"を含むコレクションを検討してください。
>>Request
>>リクエスト
DELETE /locked/member HTTP/1.1 Host: example.com
削除/ロックされた/メンバーhttp/1.1ホスト：example.com
>>Response
>>応答
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:lock-token-submitted>
<D:href>/locked/</D:href>
</D:lock-token-submitted>
</D:error>
Thus, the client would need to submit the lock token with the request to make it succeed. To do that, various forms of the If header (see Section 10.4) could be used.
したがって、クライアントは、それを成功させるための要求でロックトークンを送信する必要があります。そのためには、IFヘッダーのさまざまな形式（セクション10.4を参照）を使用できます。
"No-Tag-List" format:
「ノータグリスト」形式：
If: (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
"Tagged-List" format, for "http://example.com/locked/":
「http://example.com/locked/」の「タグ付きリスト」形式：
If: <http://example.com/locked/>
(<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
"Tagged-List" format, for "http://example.com/locked/member":
「http://example.com/locked/member」の「タグ付きリスト」形式：
If: <http://example.com/locked/member>
(<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
Note that, for the purpose of submitting the lock token, the actual form doesn't matter; what's relevant is that the lock token appears in the If header, and that the If header itself evaluates to true.
ロックトークンを送信する目的では、実際のフォームは重要ではないことに注意してください。関連するのは、ロックトークンがIFヘッダーに表示され、IFヘッダー自体がTrueに評価されることです。
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with a depth-infinity lock, then the resource will be added to the lock.
コピーメソッドの呼び出しは、ソース上でアクティブな書き込みロックを複製してはなりません。ただし、前述のように、コピーがリソースを深さの濃度ロックでロックされたコレクションにコピーした場合、リソースがロックに追加されます。
A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, if there is an existing lock at the destination, the server MUST add the moved resource to the destination lock scope. For example, if the MOVE makes the resource a child of a collection that has a depth-infinity lock, then the resource will be added to that collection's lock. Additionally, if a resource with a depth-infinity lock is moved to a destination that is within the scope of the same lock (e.g., within the URL namespace tree covered by the lock), the moved resource will again be added to the lock. In both these examples, as specified in Section 7.5, an If header must be submitted containing a lock token for both the source and destination.
書き込みロックされたリソースでの成功した移動要求は、リソースで書き込みロックを移動してはなりません。ただし、宛先に既存のロックがある場合、サーバーは移動したリソースを宛先ロックスコープに追加する必要があります。たとえば、この動きにより、リソースが深さの濃度ロックを備えたコレクションの子になった場合、リソースはそのコレクションのロックに追加されます。さらに、深さの密集ロックを備えたリソースが同じロックの範囲内にある宛先に移動した場合（たとえば、ロックで覆われたURLネームスペースツリー内）、移動されたリソースが再びロックに追加されます。セクション7.5で指定されているように、これらの両方の例では、ソースと宛先の両方にロックトークンを含むヘッダーを提出する必要があります。
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.
クライアントは、同じ書き込みロック要求を2回送信してはなりません。クライアントは、すでにロックされているリソースを要求するためにIFヘッダーにロックトークンを含める必要があるため、同じロックリクエストを再送信していることを常に認識していることに注意してください。
However, a client may submit a LOCK request with an If header but without a body. A server receiving a LOCK request with no body MUST NOT create a new lock -- this form of the LOCK request is only to be used to "refresh" an existing lock (meaning, at minimum, that any timers associated with the lock MUST be reset).
ただし、クライアントは、ifヘッダーを使用してボディを使用してロックリクエストを送信することができます。ボディがないロック要求を受信するサーバーは、新しいロックを作成してはなりません - このフォームのロック要求は、既存のロックを「更新」するためにのみ使用されます（少なくとも、ロックに関連するタイマーはすべてリセット）。
Clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client, and a server MAY refresh a lock with a timeout period that is different than the previous timeout period used for the lock, provided it advertises the new value in the LOCK refresh response.
クライアントは、ロックリフレッシュリクエストで任意の価値のタイムアウトヘッダーを送信できます。サーバーは、いつものように、クライアントが提出したタイムアウトヘッダーを無視する場合があり、サーバーは、ロックリフレッシュ応答の新しい値を宣伝する場合、ロックに使用された前回のタイムアウト期間とは異なるタイムアウト期間でロックを更新する場合があります。
If an error is received in response to a refresh LOCK request, the client MUST NOT assume that the lock was refreshed.
更新ロックリクエストに応じてエラーが受信された場合、クライアントはロックが更新されたと仮定してはなりません。
Servers MUST return authorization errors in preference to other errors. This avoids leaking information about protected resources (e.g., a client that finds that a hidden resource exists by seeing a 423 Locked response to an anonymous request to the resource).
サーバーは、他のエラーよりも優先されて承認エラーを返す必要があります。これにより、保護されたリソースに関する情報が漏れなくなります（たとえば、リソースへの匿名のリクエストに対する423のロックされた応答を見ることで隠されたリソースが存在することを発見するクライアント）。
In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter information either in an XML ([REC-XML]) request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility; and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support.
HTTP/1.1では、メソッドパラメーター情報はHTTPヘッダーでのみエンコードされました。HTTP/1.1とは異なり、WebDAVはXML（[rec-xml]）要求エンティティボディ、またはHTTPヘッダーのいずれかでメソッドパラメーター情報をエンコードします。メソッドパラメーターをエンコードするためにXMLを使用することは、既存の構造に追加のXML要素を追加し、拡張性を提供する機能によって動機付けられました。また、ISO 10646文字セットで情報をエンコードするXMLの能力により、国際化のサポートを提供します。
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.
メソッドパラメーターをエンコードすることに加えて、XMLはWebDAVで使用され、メソッドからの応答をエンコードし、メソッド出力のXMLの拡張性と国際化の利点を提供し、入力を提供します。
When XML is used for a request or response body, the Content-Type type SHOULD be application/xml. Implementations MUST accept both text/xml and application/xml in request and response bodies. Use of text/xml is deprecated.
XMLがリクエストまたは応答本体に使用される場合、コンテンツタイプのタイプはアプリケーション/XMLでなければなりません。実装は、リクエストと応答団体でテキスト/XMLとアプリケーション/XMLの両方を受け入れる必要があります。テキスト/XMLの使用は非推奨です。
All DAV-compliant clients and resources MUST use XML parsers that are compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either requests or responses MUST be, at minimum, well formed and use namespaces correctly. If a server receives XML that is not well-formed, then the server MUST reject the entire request with a 400 (Bad Request). If a client receives XML that is not well-formed in a response, then the client MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
すべてのDAVに準拠したクライアントとリソースは、[rec-xml]および[rec-xml-names]に準拠したXMLパーサーを使用する必要があります。いずれかのリクエストまたは応答で使用されるすべてのXMLは、少なくとも適切に形成され、名前空間を正しく使用する必要があります。サーバーがよく形成されていないXMLを受信した場合、サーバーは400（悪い要求）で要求全体を拒否する必要があります。クライアントが応答で十分に形成されていないXMLを受信した場合、クライアントは実行されたメソッドの結果について何も想定してはならず、サーバーを誤動作として扱う必要があります。
Note that processing XML submitted by an untrusted source may cause risks connected to privacy, security, and service quality (see Section 20). Servers MAY reject questionable requests (even though they consist of well-formed XML), for instance, with a 400 (Bad Request) status code and an optional response body explaining the problem.
信頼されていないソースによって提出されたXMLの処理は、プライバシー、セキュリティ、およびサービスの質に関連するリスクを引き起こす可能性があることに注意してください（セクション20を参照）。たとえば、400（悪い要求）ステータスコードと問題を説明するオプションの応答本体を使用して、疑わしいリクエストを拒否する可能性があります（順調に形成されたXMLで構成されていても）。
URLs appear in many places in requests and responses. Interoperability experience with [RFC2518] showed that many clients parsing Multi-Status responses did not fully implement the full Reference Resolution defined in Section 5 of [RFC3986]. Thus, servers in particular need to be careful in handling URLs in responses, to ensure that clients have enough context to be able to interpret all the URLs. The rules in this section apply not only to resource URLs in the 'href' element in Multi-Status responses, but also to the Destination and If header resource URLs.
URLは、リクエストと応答で多くの場所に表示されます。[RFC2518]との相互運用性の経験は、マルチステータス応答を解析する多くのクライアントが[RFC3986]のセクション5で定義された完全な参照解像度を完全に実装しなかったことを示しました。したがって、特にサーバーは、クライアントがすべてのURLを解釈できるように十分なコンテキストを確保するために、応答のURLを処理する際に注意する必要があります。このセクションのルールは、マルチステータス応答の「HREF」要素のリソースURLだけでなく、宛先とヘッダーリソースURLにも適用されます。
The sender has a choice between two approaches: using a relative reference, which is resolved against the Request-URI, or a full URI. A server MUST ensure that every 'href' value within a Multi-Status response uses the same format.
送信者には、リクエスト-URIまたはフルURIに対して解決される相対参照の使用という2つのアプローチから選択できます。サーバーは、マルチステータス応答内のすべての「HREF」値が同じ形式を使用することを確認する必要があります。
WebDAV only uses one form of relative reference in its extensions, the absolute path.
WebDavは、その拡張機能である絶対パスで1つの形式の相対参照のみを使用します。
Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )
simple-ref = absolute-uri |（path-absolute ["？" query]）
The absolute-URI, path-absolute and query productions are defined in Sections 4.3, 3.3, and 3.4 of [RFC3986].
[RFC3986]のセクション4.3、3.3、および3.4で、絶対尿、パスアブソリュート、クエリ作品は定義されています。
Within Simple-ref productions, senders MUST NOT:
単純なREFプロダクションでは、送信者は次のことではありません。
o use dot-segments ("." or ".."), or
o dot-segments（ "。"または ".."）を使用するか
o have prefixes that do not match the Request-URI (using the comparison rules defined in Section 3.2.3 of [RFC2616]).
o リクエスト-URIと一致しないプレフィックスがあります（[RFC2616]のセクション3.2.3で定義されている比較ルールを使用）。
Identifiers for collections SHOULD end in a '/' character.
コレクションの識別子は「/」文字で終了する必要があります。
Consider the collection http://example.com/sample/ with the internal member URL http://example.com/sample/a%20test and the PROPFIND request below:
コレクションhttp://example.com/sample/内部メンバーのurl url http://example.com/sample/a%20testと以下のPropfindリクエストを検討してください。
>>Request:
>>リクエスト：
PROPFIND /sample/ HTTP/1.1 Host: example.com Depth: 1
propfind/sample/http/1.1ホスト：example.com深さ：1
In this case, the server should return two 'href' elements containing either
この場合、サーバーはどちらを含む2つの「HREF」要素を返す必要があります
o 'http://example.com/sample/' and 'http://example.com/sample/a%20test', or
o 'http://example.com/sample/'および 'http://example.com/sample/a%20test'、または
o '/sample/' and '/sample/a%20test'
o '/sample/' and '/sample/a％20test'
Note that even though the server may be storing the member resource internally as 'a test', it has to be percent-encoded when used inside a URI reference (see Section 2.1 of [RFC3986]). Also note that a legal URI may still contain characters that need to be escaped within XML character data, such as the ampersand character.
サーバーがメンバーリソースを「テスト」として内部的に保存している場合でも、URIリファレンス内で使用する場合はパーセントエンコードする必要があることに注意してください（[RFC3986]のセクション2.1を参照）。また、合法的なURIには、アンパサンド文字などのXML文字データ内で逃げる必要がある文字がまだ含まれている場合があることに注意してください。
Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as the client intended.
これらの新しい方法のいくつかは、身体を定義しません。サーバーは、ボディが予想されていない場合でも、ボディのすべての要求を調べる必要があります。要求本体が存在するが、サーバーによって無視される場合、サーバーは415（サポートされていないメディアタイプ）でリクエストを拒否する必要があります。これにより、クライアント（拡張機能を使用しようとしている可能性があります）に、クライアントが意図したようにボディを処理できないことを通知します。
HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible (see Section 14.18, [RFC2616]).
HTTPは、WebDAVリクエストと応答で使用できる多くのヘッダーを定義します。これらすべてがすべての状況で適切であるわけではなく、いくつかの相互作用が未定義になる可能性があります。HTTP 1.1には、可能であればすべての応答で日付ヘッダーが必要であることに注意してください（セクション14.18、[RFC2616]を参照）。
The server MUST do authorization checks before checking any HTTP conditional header.
サーバーは、HTTP条件付きヘッダーをチェックする前に、承認チェックを行う必要があります。
HTTP 1.1 recommends the use of ETags rather than modification dates, for cache control, and there are even stronger reasons to prefer ETags for authoring. Correct use of ETags is even more important in a distributed authoring environment, because ETags are necessary along with locks to avoid the lost-update problem. A client might fail to renew a lock, for example, when the lock times out and the client is accidentally offline or in the middle of a long upload. When a client fails to renew the lock, it's quite possible the resource can still be relocked and the user can go on editing, as long as no changes were made in the meantime. ETags are required for the client to be able to distinguish this case. Otherwise, the client is forced to ask the user whether to overwrite the resource on the server without even being able to tell the user if it has changed. Timestamps do not solve this problem nearly as well as ETags.
HTTP 1.1は、キャッシュコントロールのために変更された日付ではなくETAGSの使用を推奨しており、オーサリングにETAGを好む理由はさらに強い理由があります。分散したオーサリング環境では、ETAGSの正しい使用がさらに重要です。これは、Updateの失われた問題を回避するためにLocksとともにETAGが必要であるためです。たとえば、ロックがタイムアウトし、クライアントが誤ってオフラインまたは長いアップロードの真ん中にある場合、クライアントはロックの更新に失敗する可能性があります。クライアントがロックの更新に失敗した場合、その間に変更が行われない限り、リソースを再ロックし、ユーザーが編集に進むことができる可能性があります。クライアントがこのケースを区別できるようにするには、ETAGが必要です。それ以外の場合、クライアントは、ユーザーが変更されたかどうかを通知することなく、サーバー上のリソースを上書きするかどうかをユーザーに尋ねることを余儀なくされます。タイムスタンプは、この問題をETAGとほぼ同じように解決しません。
Strong ETags are much more useful for authoring use cases than weak ETags (see Section 13.3.3 of [RFC2616]). Semantic equivalence can be a useful concept but that depends on the document type and the application type, and interoperability might require some agreement or standard outside the scope of this specification and HTTP. Note also that weak ETags have certain restrictions in HTTP, e.g., these cannot be used in If-Match headers.
強いETAGは、弱いETAGよりもユースケースを作成するのにはるかに有用です（[RFC2616]のセクション13.3.3を参照）。セマンティックの等価性は有用な概念になる可能性がありますが、ドキュメントタイプとアプリケーションタイプに依存し、相互運用性がこの仕様とHTTPの範囲外で何らかの一致または標準を必要とする場合があります。また、弱いETAGにはHTTPに特定の制限があることに注意してください。たとえば、これらはIFマッチヘッダーでは使用できません。
Note that the meaning of an ETag in a PUT response is not clearly defined either in this document or in RFC 2616 (i.e., whether the ETag means that the resource is octet-for-octet equivalent to the body of the PUT request, or whether the server could have made minor changes in the formatting or content of the document upon storage). This is an HTTP issue, not purely a WebDAV issue.
PUT応答のETAGの意味は、このドキュメントまたはRFC 2616で明確に定義されていないことに注意してください（つまり、ETAGがリソースがプットリクエストの本体に相当するオクテットに相当することを意味するかどうか、またはサーバーは、ストレージ時にドキュメントの書式設定またはコンテンツを軽微な変更した可能性があります）。これはHTTPの問題であり、純粋にWebDavの問題ではありません。
Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or the Last-Modified time) for a resource that has an unchanged body and location. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed.
クライアントはユーザーに促すことを強制されたり、ETAGが変更された場合に変更されたコンテンツを捨てることを強制される可能性があるため、WebDavサーバーは、変更されていないボディと場所を持つリソースのETAG（またはラスト変更の時間）を変更してはなりません。ETAGは、身体の状態またはリソースの内容を表します。プロパティが変更されたかどうかを判断する同様の方法はありません。
HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until the specification for Versioning Extensions to WebDAV introduced a mechanism to include more specific information in the body of an error response (Section 1.6 of [RFC3253]). The error body mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This error body mechanism is covered in Section 16.
HTTPとWebDAVは、WebDAVへのバージョン拡張機能の仕様がエラー応答の本文により具体的な情報を含めるメカニズムを導入するまで、機械型情報のほとんどのエラー応答のボディを使用しませんでした（[RFC3253]のセクション1.6）。エラーボディメカニズムは、ボディを取る可能性のあるエラー応答で使用するのに適していますが、ボディはまだ定義されていません。メカニズムは、ステータスコードが多くのことを意味する場合に特に適切です（たとえば、400の悪いリクエストは、必要なヘッダーが欠落していること、ヘッダーが誤ってフォーマットされていることを意味します）。このエラーボディメカニズムは、セクション16でカバーされています。
Note that the HTTP response headers "Etag" and "Last-Modified" (see [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per resource), and are used by clients for caching. Therefore servers must ensure that executing any operation that affects the URL namespace (such as COPY, MOVE, DELETE, PUT, or MKCOL) does preserve their semantics, in particular: o For any given URL, the "Last-Modified" value MUST increment every time the representation returned upon GET changes (within the limits of timestamp resolution).
HTTP応答ヘッダー「ETAG」および「LASTMODIFIED」（[RFC2616]、セクション14.19および14.29を参照）は、URLごと（リソースごとではない）で定義されており、クライアントがキャッシュに使用していることに注意してください。したがって、サーバーは、URLネームスペースに影響を与える操作（コピー、移動、削除、プット、MKCOLなど）を実行することを確認する必要があります。特に、次のセマンティクスを保持します。GETの変更時に表現が戻ってきたたびに（タイムスタンプの解像度の制限内）。
o For any given URL, an "ETag" value MUST NOT be reused for different representations returned by GET.
o 特定のURLの場合、getによって返されるさまざまな表現に対して「etag」値を再利用してはなりません。
In practice this means that servers
実際には、これはサーバーを意味します
o might have to increment "Last-Modified" timestamps for every resource inside the destination namespace of a namespace operation unless it can do so more selectively, and
o より選択的に行うことができない限り、名前空間操作の宛先ネームスペース内のすべてのリソースの「ラスト変更された」タイムスタンプをインクリメントする必要があるかもしれません。
o similarly, might have to re-assign "ETag" values for these resources (unless the server allocates entity tags in a way so that they are unique across the whole URL namespace managed by the server).
o 同様に、これらのリソースの「ETAG」値を再割り当てする必要がある場合があります（サーバーがエンティティを方法で割り当てて、サーバーが管理するURLネームスペース全体で一意にすることができない限り）。
Note that these considerations also apply to specific use cases, such as using PUT to create a new resource at a URL that has been mapped before, but has been deleted since then.
これらの考慮事項は、Putを使用して以前にマッピングされたが削除されているURLで新しいリソースを作成するなど、特定のユースケースにも適用されることに注意してください。
Finally, WebDAV properties (such as DAV:getetag and DAV: getlastmodified) that inherit their semantics from HTTP headers must behave accordingly.
最後に、HTTPヘッダーからセマンティクスを継承するWebDavプロパティ（DAV：getEtagおよびdav：getLastModifiedなど）は、それに応じて動作する必要があります。
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs. All DAV-compliant resources MUST support the PROPFIND method and the propfind XML element (Section 14.20) along with all XML elements defined for use with that element.
PROPFINDメソッドは、リクエスト-URIによって識別されたリソース、リソースに内部メンバーがない場合、またはリクエスト-URIおよび潜在的にそのメンバーリソースによって識別されるリソースで、リソースが識別されるリソースで定義されたプロパティを取得します。リソースがリソースがコレクションである場合内部メンバーURL。すべてのDAV準拠リソースは、その要素で使用するために定義されたすべてのXML要素とともに、PropfindメソッドとPropfind XML要素（セクション14.20）をサポートする必要があります。
A client MUST submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request. Servers MUST support "0" and "1" depth requests on WebDAV-compliant resources and SHOULD support "infinity" requests. In practice, support for infinite-depth requests MAY be disabled, due to the performance and security concerns associated with this behavior. Servers SHOULD treat a request without a Depth header as if a "Depth: infinity" header was included.
クライアントは、「0」、「1」、または「Infinity」の値を持つ深度ヘッダーを、Propfindリクエストで送信する必要があります。サーバーは、WebDAVに準拠したリソースで「0」および「1」の深さ要求をサポートする必要があり、「Infinity」リクエストをサポートする必要があります。実際には、この動作に関連するパフォーマンスとセキュリティの懸念により、無限の詳細な要求のサポートが無効になる場合があります。サーバーは、「深さ：無限」ヘッダーが含まれているかのように、深度ヘッダーなしでリクエストを扱う必要があります。
A client may submit a 'propfind' XML element in the body of the request method describing what information is being requested. It is possible to:
クライアントは、リクエストメソッドの本文に「Propfind」XML要素を提出することができます。可能です：
o Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by the server),
o 「プロップ」要素内で目的のプロパティを命名することにより、特定のプロパティ値を要求します（ここのプロパティの順序はサーバーによって無視される場合があります）、
o Request property values for those properties defined in this specification (at a minimum) plus dead properties, by using the 'allprop' element (the 'include' element can be used with 'allprop' to instruct the server to also include additional live properties that may not have been returned otherwise),
o この仕様で定義されているプロパティの値（最低では）と死んだプロパティの要素「AllProp」要素（「含まれる」要素は「AllProp」で使用できます。それ以外の場合は返されなかったかもしれません）、
o Request a list of names of all the properties defined on the resource, by using the 'propname' element.
o 「Propname」要素を使用して、リソースに定義されているすべてのプロパティの名前のリストをリクエストします。
A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request.
クライアントは、リクエスト本体を送信しないことを選択できます。空のプロップファインドリクエスト本体は、まるで「AllProp」リクエストであるかのように扱わなければなりません。
Note that 'allprop' does not return values for all live properties. WebDAV servers increasingly have expensively-calculated or lengthy properties (see [RFC3253] and [RFC3744]) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what live properties exist, and request named properties when retrieving values. For a live property defined elsewhere, that definition can specify whether or not that live property would be returned in 'allprop' requests.
「AllProp」はすべてのライブプロパティの値を返さないことに注意してください。WebDAVサーバーは、ますます高価に計算されている、または長いプロパティがあり（[RFC3253]および[RFC3744]を参照）、すべてのプロパティを既に返していません。代わりに、WebDAVクライアントはPropnameリクエストを使用して、ライブプロパティが存在するものを発見し、値を取得するときに名前付きプロパティを要求できます。他の場所で定義されているライブプロパティの場合、その定義は、そのライブプロパティが「AllProp」リクエストで返されるかどうかを指定できます。
All servers MUST support returning a response of content type text/ xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties.
すべてのサーバーは、さまざまなプロパティを取得しようとする試みの結果を記述するMultistatus XML要素を含むコンテンツタイプテキスト/ XMLまたはApplication/ XMLの応答の返却をサポートする必要があります。
If there is an error retrieving a property, then a proper error result MUST be included in the response. A request to retrieve the value of a property that does not exist is an error and MUST be noted with a 'response' XML element that contains a 404 (Not Found) status value.
プロパティを取得するエラーがある場合は、応答に適切なエラー結果を含める必要があります。存在しないプロパティの値を取得するリクエストはエラーであり、404（見つからない）ステータス値を含む「応答」XML要素で注意する必要があります。
Consequently, the 'multistatus' XML element for a collection resource MUST include a 'response' XML element for each member URL of the collection, to whatever depth was requested. It SHOULD NOT include any 'response' elements for resources that are not WebDAV-compliant. Each 'response' element MUST contain an 'href' element that contains the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource are returned as a flat list whose order of entries is not significant. Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses.
その結果、コレクションリソースの「MultiStatus」XML要素には、コレクションの各メンバーURLの「応答」XML要素を、要求された深さに含まれる必要があります。WebDavに準拠していないリソースの「応答」要素を含めるべきではありません。各「応答」要素には、Prop XML要素のプロパティが定義されているリソースのURLを含む「HREF」要素を含める必要があります。コレクションリソース上のプロポフィンドの結果は、エントリの順序が重要ではないフラットリストとして返されます。リソースには、特定の名前のプロパティに対して1つの値が1つしかない可能性があるため、プロパティはPropfind Responseに1回しか表示されないことに注意してください。
Properties may be subject to access control. In the case of 'allprop' and 'propname' requests, if a principal does not have the right to know whether a particular property exists, then the property MAY be silently excluded from the response.
プロパティは、アクセス制御の対象となる場合があります。「AllProp」および「Propname」要求の場合、プリンシパルが特定のプロパティが存在するかどうかを知る権利がない場合、プロパティは回答から静かに除外される可能性があります。
Some PROPFIND results MAY be cached, with care, as there is no cache validation mechanism for most properties. This method is both safe and idempotent (see Section 9.1 of [RFC2616]).
ほとんどのプロパティにキャッシュ検証メカニズムがないため、一部の推定結果は注意してキャッシュされる場合があります。この方法は安全であり、iDempotentの両方です（[RFC2616]のセクション9.1を参照）。
This section, as with similar sections for other methods, provides some guidance on error codes and preconditions or postconditions (defined in Section 16) that might be particularly useful with PROPFIND.
このセクションは、他のメソッドの同様のセクションと同様に、エラーコードと前提条件または事後条件（セクション16で定義）に関するガイダンスを提供します。
403 Forbidden - A server MAY reject PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body.
403禁止 - サーバーは、「Infinity」の深度ヘッダーを備えたコレクションのプロパンドリクエストを拒否する場合があります。この場合、エラー本文内の前提条件コード「Propfind-Finite Depth」でこのエラーを使用する必要があります。
In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
Propfind Responseでは、個々のプロパティに関する情報は、「Propstat」要素内（セクション14.22を参照）内に返されます。それぞれが、その中に表示されるプロパティに関する情報を含む個々の「ステータス」要素を含みます。以下のリストは、「Propstat」内で使用される最も一般的なステータスコードをまとめたものです。ただし、クライアントは、他の2/3/4/5XXシリーズステータスコードを処理する準備をする必要があります。
200 OK - A property exists and/or its value is successfully returned.
200 OK-プロパティが存在し、その値が正常に返されます。
401 Unauthorized - The property cannot be viewed without appropriate authorization.
401許可されていない - 適切な承認なしにプロパティを表示することはできません。
403 Forbidden - The property cannot be viewed regardless of authentication.
403禁止 - 認証に関係なく、プロパティを表示できません。
404 Not Found - The property does not exist.
404見つかりません - プロパティは存在しません。
>>Request
>>リクエスト
PROPFIND /file HTTP/1.1
Host: www.example.com
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:R="http://ns.example.com/boxschema/">
<D:href>http://www.example.com/file</D:href>
<D:propstat>
<D:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Johnson</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to the
DingALing property.
</D:responsedescription>
</D:propstat>
</D:response>
<D:responsedescription> There has been an access violation error.
</D:responsedescription>
</D:multistatus>
In this example, PROPFIND is executed on a non-collection resource http://www.example.com/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case, only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
この例では、Propfindは非収集リソースhttp://www.example.com/fileで実行されます。Propfind XML要素は、値が要求されている4つのプロパティの名前を指定します。この場合、リクエストを発行する元本が3番目と4番目のプロパティを見るのに十分なアクセス権を持っていなかったため、2つのプロパティのみが返されました。
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:">
<propname/>
</propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://www.example.com/container/</href>
<propstat>
<prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<creationdate/>
<displayname/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>http://www.example.com/container/front.html</href>
<propstat>
<prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<creationdate/>
<displayname/>
<getcontentlength/>
<getcontenttype/>
<getetag/>
<getlastmodified/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
In this example, PROPFIND is invoked on the collection resource http://www.example.com/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its descendants should be returned.
この例では、Propfindはコレクションリソースhttp://www.example.com/container/に呼び出されます。深さヘッダーが存在しないため、「無限」のデフォルト値を想定しています。つまり、コレクションのプロパティの名前とそのすべての子孫を返す必要があります。
Consistent with the previous example, resource http://www.example.com/container/ has six properties defined on it: bigbox and author in the "http://ns.example.com/boxschema/" namespace, and creationdate, displayname, resourcetype, and supportedlock in the "DAV:" namespace.
前の例と一致して、Resource http://www.example.com/container/には、「http://ns.example.com/boxschema/」という名前のbigboxと著者の6つのプロパティが定義されています。"dav：" namespaceのDisplayName、ResourceType、およびSupportEdLock。
The resource http://www.example.com/container/index.html, a member of the "container" collection, has nine properties defined on it, bigbox in the "http://ns.example.com/boxschema/" namespace and creationdate, displayname, getcontentlength, getcontenttype, getetag, getlastmodified, resourcetype, and supportedlock in the "DAV:" namespace.
リソースhttp://www.example.com/container/index.htmlは、「コンテナ」コレクションのメンバーである「http://ns.example.com/boxschema/」のBigboxで定義されている9つのプロパティが定義されています。「名前空間とcreationdate、displayName、getContentLength、getContentType、getEtag、getLastModified、ResourceType、およびsupportedLock in "dav：" namespace。
This example also demonstrates the use of XML namespace scoping and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all enclosed elements. Hence, all elements that do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.
この例は、XMLネームスペーススコーピングとデフォルトの名前空間の使用も示しています。「XMLNS」属性にはプレフィックスが含まれていないため、名前空間はデフォルトですべての囲まれた要素に適用されます。したがって、それらが属する名前空間を明示的に明示的に述べていないすべての要素は、「dav： "namespaceのメンバーです。
Note that 'allprop', despite its name, which remains for backward-compatibility, does not return every property, but only dead properties and the live properties defined in this specification.
「AllProp」は、その名前にもかかわらず、後方互換性のために残っているにもかかわらず、すべてのプロパティを返すのではなく、この仕様で定義されているデッドプロパティとライブプロパティのみを返すことに注意してください。
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/container/</D:href>
<D:propstat>
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox><R:BoxType>Box type A</R:BoxType></R:bigbox>
<R:author><R:Name>Hadrian</R:Name></R:author>
<D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
<D:displayname>Example collection</D:displayname>
<D:resourcetype><D:collection/></D:resourcetype>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/container/front.html</D:href>
<D:propstat>
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox><R:BoxType>Box type B</R:BoxType>
</R:bigbox>
<D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate>
<D:displayname>Example HTML resource</D:displayname>
<D:getcontentlength>4525</D:getcontentlength>
<D:getcontenttype>text/html</D:getcontenttype>
<D:getetag>"zzyzx"</D:getetag>
<D:getlastmodified
>Mon, 12 Jan 1998 09:25:56 GMT</D:getlastmodified>
<D:resourcetype/>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
In this example, PROPFIND was invoked on the resource http://www.example.com/container/ with a Depth header of 1, meaning the request applies to the resource and its children, and a propfind XML element containing the allprop XML element, meaning the request should return the name and value of all the dead properties defined on the resources, plus the name and value of all the properties defined in this specification. This example illustrates the use of relative references in the 'href' elements of the response.
この例では、Propfindはリソースhttp://www.example.com/container/ 1の深さヘッダーで呼び出されました。、つまり、リクエストは、リソースで定義されているすべての死んだプロパティの名前と値に加えて、この仕様で定義されているすべてのプロパティの名前と値を返す必要があります。この例は、応答の「HREF」要素での相対的な参照の使用を示しています。
The resource http://www.example.com/container/ has six properties defined on it: 'bigbox' and 'author in the "http://ns.example.com/boxschema/" namespace, DAV:creationdate, DAV: displayname, DAV:resourcetype, and DAV:supportedlock.
リソースhttp://www.example.com/container/には、「http://ns.example.com/boxschema/ "namespace、dav：creationdate、davの「bigbox」と '著者の6つのプロパティが定義されています。：displayName、dav：resourceType、およびdav：supportedlock。
The last four properties are WebDAV-specific, defined in Section 15. Since GET is not supported on this resource, the get* properties (e.g., DAV:getcontentlength) are not defined on this resource. The WebDAV-specific properties assert that "container" was created on December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT (DAV:creationdate), has a name of "Example collection" (DAV: displayname), a collection resource type (DAV:resourcetype), and supports exclusive write and shared write locks (DAV:supportedlock).
最後の4つのプロパティは、セクション15で定義されているWebDAV固有です。GETはこのリソースでサポートされていないため、GET*プロパティ（DAV：GetContentLength）はこのリソースで定義されていません。WebDAV固有のプロパティは、「コンテナ」が1997年12月1日午後5時42分21分に、GMT（DAV：CreationDate）の西8時間のタイムゾーンで「COMPERY COLLECTION」の名前を持っていると主張しています（DAV」：displayName）、コレクションリソースタイプ（DAV：ResourceType）、および排他的な書き込みロック（DAV：supportedLock）をサポートします。
The resource http://www.example.com/container/front.html has nine properties defined on it:
リソースhttp://www.example.com/container/front.htmlには、9つのプロパティが定義されています。
'bigbox' in the "http://ns.example.com/boxschema/" namespace (another instance of the "bigbox" property type), DAV:creationdate, DAV: displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
「http://ns.example.com/boxschema/ "namespace（「bigbox」プロパティタイプの別のインスタンス）、dav：creationdate、dav：displayname、dav：getcontentlength、dav：getcontenttype、dav：GetEtag、DAV：GetLastModified、DAV：ResourceType、およびDAV：SupportEdLock。
The DAV-specific properties assert that "front.html" was created on December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT (DAV:creationdate), has a name of "Example HTML resource" (DAV: displayname), a content length of 4525 bytes (DAV:getcontentlength), a MIME type of "text/html" (DAV:getcontenttype), an entity tag of "zzyzx" (DAV:getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT (DAV:getlastmodified), has an empty resource type, meaning that it is not a collection (DAV:resourcetype), and supports both exclusive write and shared write locks (DAV:supportedlock).
DAV固有のプロパティは、「front.html」が1997年12月1日午後6時27分21分に、GMTの西8時間のタイムゾーン（DAV：CreationDate）に作成されたと主張しています。"（dav：displayName）、コンテンツ長の4525バイト（dav：getContentLength）、「Zzyzx」（dav：geteTag）のエンティティタグである「テキスト/html」（dav：getContentType）のMIMEタイプが最後に変更されました。1998年1月12日月曜日、09：25：56 GMT（dav：getLastModified）は、空のリソースタイプを持っています。つまり、コレクション（DAV：ResourceType）ではなく、排他的な書き込みロックと共有の両方のロック（DAV：supportedlock）。
>>Request
>>リクエスト
PROPFIND /mycol/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:include>
<D:supported-live-property-set/>
<D:supported-report-set/>
</D:include>
</D:propfind>
In this example, PROPFIND is executed on the resource http://www.example.com/mycol/ and its internal member resources. The client requests the values of all live properties defined in this specification, plus all dead properties, plus two more live properties defined in [RFC3253]. The response is not shown.
この例では、Propfindはリソースhttp://www.example.com/mycol/およびその内部メンバーリソースで実行されます。クライアントは、この仕様で定義されているすべてのライブプロパティの値に加えて、すべての死んだプロパティに加えて、[RFC3253]で定義されている2つのライブプロパティを要求します。応答は表示されません。
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.
プロップパッチメソッドは、リクエスト本文で指定された命令を処理し、リクエスト-URIによって識別されたリソースで定義されたプロパティを設定および/または削除します。
All DAV-compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements. Execution of the directives in this method is, of course, subject to access control constraints. DAV-compliant resources SHOULD support the setting of arbitrary dead properties.
すべてのDAVに準拠したリソースは、プロップパッチメソッドをサポートする必要があり、XML要素を設定し、削除するPropertyUpDateを使用して指定された命令を処理する必要があります。この方法での指令の実行は、もちろん、アクセス制御制約の対象となります。DAV準拠のリソースは、任意の死んだプロパティの設定をサポートする必要があります。
The request message body of a PROPPATCH method MUST contain the propertyupdate XML element.
プロップパッチメソッドの要求メッセージ本文には、PropertyUpDate XML要素が含まれている必要があります。
Servers MUST process PROPPATCH instructions in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus, if any error occurs during processing, all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in Sections 14.23 and 14.26.
サーバーは、ドキュメントの順序でプロップパッチ命令を処理する必要があります（順序付けは無関係であるという通常のルールの例外）。指示はすべて実行されるか、実行されない必要があります。したがって、処理中にエラーが発生した場合、実行されたすべての命令は元に戻し、適切なエラー結果が返されなければなりません。命令処理の詳細は、セットの定義とセクション14.23および14.26の指示を削除できます。
If a server attempts to make any of the property changes in a PROPPATCH request (i.e., the request is not rejected for high-level errors before processing the body), the response MUST be a Multi-Status response as described in Section 9.2.1.
サーバーがプロパッチリクエストのプロパティの変更を行おうとする場合（つまり、ボディを処理する前に高レベルのエラーに対してリクエストが拒否されません）、セクション9.2.1で説明されているように応答はマルチステータス応答でなければなりません。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
この方法は等極性ですが、安全ではありません（[RFC2616]のセクション9.1を参照）。この方法への応答をキャッシュしてはなりません。
In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
プロップパッチの応答では、個々のプロパティに関する情報は、「PropStat」要素内（セクション14.22を参照）内に返され、それぞれに表示されるプロパティに関する情報を含む個々の「ステータス」要素が含まれています。以下のリストは、「Propstat」内で使用される最も一般的なステータスコードをまとめたものです。ただし、クライアントは、他の2/3/4/5XXシリーズステータスコードを処理する準備をする必要があります。
200 (OK) - The property set or change succeeded. Note that if this appears for one property, it appears for every property in the response, due to the atomicity of PROPPATCH.
200（OK） - プロパティセットまたは変更が成功しました。これが1つのプロパティに表示される場合、プロップパッチの原子性により、応答内のすべてのプロパティに対して表示されることに注意してください。
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
403（FORBIDDEN） - クライアントは、サーバーが指定しないことを選択した理由で、プロパティのいずれかを変更できません。
403 (Forbidden): The client has attempted to set a protected property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'cannot-modify-protected-property' inside the response body.
403（禁止）：クライアントは、Dav：GetEtagなどの保護されたプロパティを設定しようとしました。このエラーを返す場合、サーバーは応答本体内で「前提条件」コード「Ca n't Cain Ca n't-Modify-Modify-Property」を使用する必要があります。
409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property.
409（競合） - クライアントは、セマンティクスがプロパティに適していない値を提供しました。
424 (Failed Dependency) - The property change could not be made because of another property change that failed.
424（依存の失敗） - 失敗した別のプロパティの変更のために、プロパティの変更を行うことはできませんでした。
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
507（ストレージが不十分） - サーバーには、プロパティを記録するのに十分なスペースがありませんでした。
>>Request
>>リクエスト
PROPPATCH /bar.html HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://ns.example.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:Authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:Authors>
</D:prop>
</D:set>
<D:remove>
<D:prop><Z:Copyright-Owner/></D:prop>
</D:remove>
</D:propertyupdate>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:Z="http://ns.example.com/standards/z39.50/">
<D:response>
<D:href>http://www.example.com/bar.html</D:href>
<D:propstat>
<D:prop><Z:Authors/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
<D:propstat>
<D:prop><Z:Copyright-Owner/></D:prop>
<D:status>HTTP/1.1 409 Conflict</D:status>
</D:propstat>
<D:responsedescription> Copyright Owner cannot be deleted or
altered.</D:responsedescription>
</D:response>
</D:multistatus>
In this example, the client requests the server to set the value of the "Authors" property in the "http://ns.example.com/standards/z39.50/" namespace, and to remove the property "Copyright-Owner" in the same namespace. Since the Copyright-Owner property could not be removed, no property modifications occur. The 424 (Failed Dependency) status code for the Authors property indicates this action would have succeeded if it were not for the conflict with removing the Copyright-Owner property.
この例では、クライアントはサーバーに「http://ns.example.com/standards/z39.50/」の「著者」プロパティの値を設定し、名前空間を削除するように要求し、プロパティを削除します。「同じ名前空間で。著作権所有者のプロパティを削除できないため、プロパティの変更は発生しません。著者のプロパティの424（失敗した依存関係）ステータスコードは、著作権所有者のプロパティの削除と競合がなければ、このアクションが成功したことを示しています。
MKCOL creates a new collection resource at the location specified by the Request-URI. If the Request-URI is already mapped to a resource, then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI an internal member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the request must fail.
MKCOLは、Request-URIによって指定された場所に新しいコレクションリソースを作成します。Request-URIがすでにリソースにマッピングされている場合、MKCOLが失敗する必要があります。MKCOL処理中、サーバーは、リクエスト-URIが「/」でない限り、リクエスト-URIを親コレクションの内部メンバーにする必要があります。そのような祖先が存在しない場合、メソッドが失敗する必要があります。MKCOL操作が新しいコレクションリソースを作成する場合、すべての祖先が既に存在する必要があります。または、メソッドは409（競合）ステータスコードで失敗する必要があります。たとえば、コレクション/a/b/c/d/を作成するリクエストが作成され、/a/b/c/が存在しない場合、リクエストは失敗する必要があります。
When MKCOL is invoked without a request body, the newly created collection SHOULD have no members.
MKCOLがリクエスト本体なしで呼び出された場合、新しく作成されたコレクションにはメンバーがいないはずです。
A MKCOL request message may contain a message body. The precise behavior of a MKCOL request when the body is present is undefined, but limited to creating collections, members of a collection, bodies of members, and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand, it MUST respond with a 415 (Unsupported Media Type) status code. If the server decides to reject the request based on the presence of an entity or the type of an entity, it should use the 415 (Unsupported Media Type) status code.
MKCOLリクエストメッセージにはメッセージ本文が含まれている場合があります。ボディが存在する場合のMKCOL要求の正確な動作は未定義ですが、コレクション、コレクションのメンバー、メンバーのボディ、およびコレクションまたはメンバーのプロパティの作成に限定されます。サーバーがMKCOL要求エンティティタイプをサポートまたは理解していない場合、415（サポートされていないメディアタイプ）ステータスコードで応答する必要があります。サーバーがエンティティの存在またはエンティティのタイプに基づいてリクエストを拒否することを決定した場合、415（サポートされていないメディアタイプ）ステータスコードを使用する必要があります。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
この方法は等極性ですが、安全ではありません（[RFC2616]のセクション9.1を参照）。この方法への応答をキャッシュしてはなりません。
In addition to the general status codes possible, the following status codes have specific applicability to MKCOL:
可能な一般的なステータスコードに加えて、次のステータスコードには、MKCOLに特定の適用可能性があります。
201 (Created) - The collection was created.
201（作成） - コレクションが作成されました。
403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its URL namespace, or 2) the parent collection of the Request-URI exists but cannot accept members.
403（禁止） - これは、2つの条件の少なくとも1つを示します。1）サーバーは、そのURLネームスペースの特定の場所でコレクションを作成することを許可していません。。
405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL.
405（メソッドは許可されていない）-MKCOLは、マップされていないURLでのみ実行できます。
409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409（競合） - 1つ以上の中間コレクションが作成されるまで、リクエスト-URIでコレクションを作成することはできません。サーバーは、これらの中間コレクションを自動的に作成してはなりません。
415 (Unsupported Media Type) - The server does not support the request body type (although bodies are legal on MKCOL requests, since this specification doesn't define any, the server is likely not to support any given body type).
415（サポートされていないメディアタイプ） - サーバーはリクエストボディタイプをサポートしていません（ただし、この仕様は定義されていないため、サーバーは特定のボディタイプをサポートしない可能性が高いため）。
507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージが不十分） - リソースには、この方法の実行後にリソースの状態を記録するのに十分なスペースがありません。
This example creates a collection called /webdisc/xfiles/ on the server www.example.com.
この例では、サーバーwww.example.comに/webdisc/xfiles/というコレクションを作成します。
>>Request
>>リクエスト
MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.example.com
mkcol/webdisc/xfiles/http/1.1ホスト：www.example.com
>>Response
>>応答
HTTP/1.1 201 Created
HTTP/1.1 201が作成しました
The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET, when applied to a collection, may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence, it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection.
GETは「（エンティティの形式で）すべての情報がリクエスト-URIによって識別される」[RFC2616]であると定義されるため、コレクションに適用される場合、GETのセマンティクスは変更されません。コレクションに適用された場合、「index.html」リソースの内容、コレクションの内容の人間が読み取る可能性のあるビュー、または完全に何かを返すことができます。したがって、コレクションの取得の結果は、コレクションのメンバーシップとの相関関係がない可能性があります。
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.
同様に、ヘッドの定義は応答メッセージ本文のないGETであるため、収集リソースに適用すると、ヘッドのセマンティクスは修正されません。
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の動作は、大部分が定義されているため、有意義に変更できません。したがって、ポストのセマンティクスは、コレクションに適用されると修正されていません。
DELETE is defined in [RFC2616], Section 9.7, to "delete the resource identified by the Request-URI". However, WebDAV changes some DELETE handling requirements.
削除は[RFC2616]、セクション9.7で定義されており、「リクエスト-URIによって識別されたリソースを削除します」。ただし、WebDAVは、いくつかの削除処理要件を変更します。
A server processing a successful DELETE request:
サーバーの処理成功した削除要求：
MUST destroy locks rooted on the deleted resource
削除されたリソースに根付いたロックを破壊する必要があります
MUST remove the mapping from the Request-URI to any resource.
リクエスト-URIからマッピングを任意のリソースに削除する必要があります。
Thus, after a successful DELETE operation (and in the absence of other actions), a subsequent GET/HEAD/PROPFIND request to the target Request-URI MUST return 404 (Not Found).
したがって、削除操作が成功した後（および他のアクションがない場合）、ターゲットリクエスト-URIへのその後のget/head/propfindリクエストは404を返す必要があります（見つかりません）。
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity.
コレクションの削除メソッドは、「深さ：無限」ヘッダーが使用されているかのように動作する必要があります。クライアントは、Infinity以外の任意の値のあるコレクションの削除を備えた深度ヘッダーを送信してはなりません。
DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URLs are to be deleted.
削除は、リクエスト-URIで指定されたコレクションと、内部メンバーURLによって識別されたすべてのリソースが削除されることを指示します。
If any resource identified by a member URL cannot be deleted, then all of the member's ancestors MUST NOT be deleted, so as to maintain URL namespace consistency.
メンバーのURLによって識別されたリソースを削除できない場合、URLネームスペースの一貫性を維持するために、すべてのメンバーの祖先を削除する必要はありません。
Any headers included with DELETE MUST be applied in processing every resource to be deleted.
削除に含まれるヘッダーは、削除するすべてのリソースの処理に適用する必要があります。
When the DELETE method has completed processing, it MUST result in a consistent URL namespace.
削除メソッドが処理を完了した場合、一貫したURLネームスペースになる必要があります。
If an error occurs deleting a member resource (a resource other than the resource identified in the Request-URI), then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error code, which should help the client understand which resources caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked.
メンバーリソース（リクエスト-URIで識別されたリソース以外のリソース）を削除するエラーが発生した場合、応答は207（マルチステータス）になります。ここでは、エラーコードを含む内部リソースを削除できないことを示すためにマルチステータスが使用されています。たとえば、マルチステータス本体には、内部リソースがロックされている場合、ステータス423（ロック）の応答を含めることができます。
The server MAY return a 4xx status response, rather than a 207, if the request failed completely.
リクエストが完全に失敗した場合、サーバーは207ではなく4xxステータス応答を返す場合があります。
424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi-Status) response for DELETE. They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally, 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
424（依存関係の失敗）ステータスコードは、削除の207（マルチステータス）応答ではないはずです。クライアントは、クライアントが祖先の子孫のエラーを受け取ったときにリソースの祖先を削除できないことをクライアントが知っているため、安全に除外できます。さらに、207（マルチステータス）で204（コンテンツなし）エラーを返さないでください。この禁止の理由は、204（コンテンツなし）がデフォルトの成功コードであるためです。
>>Request
>>リクエスト
DELETE /container/ HTTP/1.1 Host: www.example.com
削除/コンテナ/http/1.1ホスト：www.example.com
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.example.com/container/resource3</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
In this example, the attempt to delete http://www.example.com/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.example.com/container/ also failed. Thus, the client knows that the attempt to delete http://www.example.com/container/ must have also failed since the parent cannot be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
この例では、http：//www.example.com/container/resource3を削除しようとする試みは、ロックされており、ロックトークンはリクエストで提出されていませんでした。その結果、http：//www.example.com/container/を削除しようとする試みも失敗しました。したがって、クライアントは、http://www.example.com/container/を削除しようとする試みも、子供が削除されない限り、親を削除できないため故障したに違いないことを知っています。深度ヘッダーは含まれていませんが、メソッドがコレクションにあるため、無限の深さが想定されています。
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties.
既存のリソースで実行されたプットは、リソースのGET応答エンティティに取って代わります。リソースで定義されているプロパティは、処理中に再計算される場合がありますが、それ以外の場合は影響を受けません。たとえば、サーバーが要求本体のコンテンツタイプを認識している場合、プロパティとして有益に公開される可能性のある情報を自動的に抽出できる場合があります。
A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
適切にスコープされた親コレクションなしでリソースを作成するプットは、409（競合）で失敗する必要があります。
A PUT request allows a client to indicate what media type an entity body has, and whether it should change if overwritten. Thus, a client SHOULD provide a Content-Type for a new resource if any is known. If the client does not provide a Content-Type for a new resource, the server MAY create a resource with no Content-Type assigned, or it MAY attempt to assign a Content-Type.
プットリクエストにより、クライアントは、エンティティボディにメディアタイプのメディアタイプと、上書きされた場合に変更する必要があるかどうかを示すことができます。したがって、クライアントは、既知の場合、新しいリソースにコンテンツタイプを提供する必要があります。クライアントが新しいリソースにコンテンツタイプを提供しない場合、サーバーはコンテンツタイプの割り当てがないリソースを作成したり、コンテンツタイプの割り当てを試みたりする場合があります。
Note that although a recipient ought generally to treat metadata supplied with an HTTP request as authoritative, in practice there's no guarantee that a server will accept client-supplied metadata (e.g., any request header beginning with "Content-"). Many servers do not allow configuring the Content-Type on a per-resource basis in the first place. Thus, clients can't always rely on the ability to directly influence the content type by including a Content-Type request header.
受信者は一般にHTTPリクエストを権威あるメタデータを処理する必要がありますが、実際には、サーバーがクライアントがサプリしたメタデータを受け入れるという保証はありません（例：「コンテンツ」から始まるリクエストヘッダー）。多くのサーバーでは、最初にリソースごとにコンテンツタイプを構成することはできません。したがって、クライアントは、コンテンツタイプのリクエストヘッダーを含めることにより、コンテンツタイプに直接影響を与える機能に常に依存することはできません。
This specification does not define the behavior of the PUT method for existing collections. A PUT request to an existing collection MAY be treated as an error (405 Method Not Allowed).
この仕様は、既存のコレクションのPUTメソッドの動作を定義しません。既存のコレクションへのリクエストは、エラーとして扱われる場合があります（405メソッドは許可されていません）。
The MKCOL method is defined to create collections.
MKCOLメソッドは、コレクションを作成するために定義されています。
The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource.
コピーメソッドは、宛先ヘッダーのURIによって識別された宛先リソースに、リクエスト-URIによって識別されたソースリソースの複製を作成します。宛先ヘッダーが存在する必要があります。コピー方法の正確な動作は、ソースリソースのタイプに依存します。
All WebDAV-compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server.
すべてのWebDAV準拠のリソースは、コピー方法をサポートする必要があります。ただし、コピー方法のサポートは、リソースをコピーする機能を保証しません。たとえば、個別のプログラムは、同じサーバー上のリソースを制御できます。その結果、同じサーバー上にあるように見える場所にリソースをコピーすることはできない場合があります。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
この方法は等極性ですが、安全ではありません（[RFC2616]のセクション9.1を参照）。この方法への応答をキャッシュしてはなりません。
When the source resource is not a collection, the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible. Since the environment at the destination may be different than at the source due to factors outside the scope of control of the server, such as the absence of resources required for correct operation, it may not be possible to completely duplicate the behavior of the resource at the destination. Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource.
ソースリソースがコレクションではない場合、コピー方法の結果は、宛先に新しいリソースの作成であり、その状態と行動はソースリソースのそれと可能な限り密接に一致します。適切な動作に必要なリソースがないなど、サーバーの制御範囲外の要因により、目的地の環境はソースの環境とは異なる場合があるため、リソースの動作をで完全に複製することはできない場合があります。目的地。その後の宛先リソースの変更は、ソースリソースを変更しません。ソースリソースのその後の変更は、宛先リソースを変更しません。
After a successful COPY invocation, all dead properties on the source resource SHOULD be duplicated on the destination resource. Live properties described in this document SHOULD be duplicated as identically behaving live properties at the destination resource, but not necessarily with the same values. Servers SHOULD NOT convert live properties into dead properties on the destination resource, because clients may then draw incorrect conclusions about the state or functionality of a resource. Note that some live properties are defined such that the absence of the property has a specific meaning (e.g., a flag with one meaning if present, and the opposite if absent), and in these cases, a successful COPY might result in the property being reported as "Not Found" in subsequent requests.
コピーの呼び出しが成功した後、ソースリソース上のすべての死んだプロパティを宛先リソースで複製する必要があります。このドキュメントで説明されているライブプロパティは、宛先リソースで同一に動作するライブプロパティとして複製する必要がありますが、必ずしも同じ値ではそうではありません。サーバーは、クライアントがリソースの状態または機能性に関する誤った結論を導き出す可能性があるため、ライブプロパティを宛先リソースのデッドプロパティに変換するべきではありません。一部のライブプロパティは、プロパティの欠如が特定の意味を持つように定義されていることに注意してください（例えば、存在する場合は1つの意味を持つフラグ、および逆がない場合は反対）、これらの場合、コピーが成功する可能性があることに注意してください。後続の要求で「見つかりません」と報告されています。
When the destination is an unmapped URL, a COPY operation creates a new resource much like a PUT operation does. Live properties that are related to resource creation (such as DAV:creationdate) should have their values set accordingly.
宛先がマップされていないURLである場合、コピー操作は、プット操作と同じように新しいリソースを作成します。リソース作成（DAV：CreationDateなど）に関連するライブプロパティは、それに応じて値を設定する必要があります。
The COPY method on a collection without a Depth header MUST act as if a Depth header with value "infinity" was included. A client may submit a Depth header on a COPY on a collection with a value of "0" or "infinity". Servers MUST support the "0" and "infinity" Depth header behaviors on WebDAV-compliant resources.
深さヘッダーのないコレクションのコピー方法は、値「無限」を持つ深度ヘッダーが含まれているかのように動作する必要があります。クライアントは、「0」または「無限」の値を持つコレクションのコピーに深さヘッダーを送信できます。サーバーは、WebDAVに準拠したリソースで「0」および「Infinity」深度ヘッダー動作をサポートする必要があります。
An infinite-depth COPY instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy. Note that an infinite-depth COPY of /A/ into /A/B/ could lead to infinite recursion if not handled correctly.
無限の詳細なコピーは、リクエスト-URIによって識別されたコレクションリソースが宛先ヘッダーのURIによって識別された場所にコピーされることを指示し、そのすべての内部メンバーリソースは、再帰的にそれに関連する場所にコピーされることを指示します。コレクション階層のすべてのレベルを通じて。/a/into/a/b/の無限の詳細なコピーは、正しく処理されないと無限の再帰につながる可能性があることに注意してください。
A COPY of "Depth: 0" only instructs that the collection and its properties, but not resources identified by its internal member URLs, are to be copied.
「深さ：0」のコピーは、コレクションとそのプロパティのみを指示しますが、内部メンバーURLによって識別されるリソースはコピーされます。
Any headers included with a COPY MUST be applied in processing every resource to be copied with the exception of the Destination header.
コピーに含まれるヘッダーは、宛先ヘッダーを除き、すべてのリソースを処理する際にすべてのリソースを処理する際に適用する必要があります。
The Destination header only specifies the destination URI for the Request-URI. When applied to members of the collection identified by the Request-URI, the value of Destination is to be modified to reflect the current location in the hierarchy. So, if the Request-URI is /a/ with Host header value http://example.com/ and the Destination is http://example.com/b/, then when http://example.com/a/c/d is processed, it must use a Destination of http://example.com/b/c/d.
宛先ヘッダーは、リクエスト-URIの宛先URIのみを指定します。リクエストURIによって識別されたコレクションのメンバーに適用される場合、宛先の価値は、階層内の現在の場所を反映するように変更されます。したがって、ホストヘッダー値http://example.com/を使用している場合、リクエスト-uriが/a/である場合、宛先はhttp://example.com/b/、http：//example.com/a/の場合C/Dは処理され、http：//example.com/b/c/dの宛先を使用する必要があります。
When the COPY method has completed processing, it MUST have created a consistent URL namespace at the destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members that are not descendants of an error-causing collection).
コピーメソッドが処理を完了した場合、宛先に一貫したURLネームスペースを作成した必要があります（名前空間の一貫性の定義については、セクション5.1を参照）。ただし、内部コレクションのコピー中にエラーが発生した場合、サーバーはこのコレクションのメンバーが識別したリソースをコピーしてはなりません（つまり、サーバーはこのサブツリーをスキップする必要があります）。エラーを検出した後、コピー操作は可能な限り多くのコピー操作を完了しようとする必要があります（つまり、サーバーは引き続きエラーを引き起こすコレクションの子孫ではない他のサブツリーとそのメンバーをコピーしようとする必要があります）。
So, for example, if an infinite-depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non-collection resource as part of an infinite-depth copy, the server SHOULD try to finish as much of the original copy operation as possible.
したがって、たとえば、コレクション/a/b/および/a/c/を含むコレクション/a/で無限の詳細なコピー操作が実行され、エラーがコピー/a/b/を実行する場合、試行はまだコピー/a/c/に作られます。同様に、非収集リソースを無限の詳細なコピーの一部としてコピーするエラーが発生した後、サーバーは元のコピー操作をできるだけ多く終了しようとする必要があります。
If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI, then the response MUST be a 207 (Multi-Status), and the URL of the resource causing the failure MUST appear with the specific error.
コピーメソッドを実行する際のエラーがリクエストURIで識別されたリソース以外のリソースで発生した場合、応答は207（マルチステータス）でなければならず、リソースのURLは特定の障害を引き起こします。エラー。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a COPY method. These responses can be safely omitted because the client will know that the progeny of a resource could not be copied when the client receives an error for the parent. Additionally, 201 (Created)/204 (No Content) status codes SHOULD NOT be returned as values in 207 (Multi-Status) responses from COPY methods. They, too, can be safely omitted because they are the default success codes.
424（依存関係の失敗）ステータスコードは、コピーメソッドからの207（マルチステータス）応答で返されないでください。クライアントは、クライアントが親のエラーを受信したときにリソースの子孫をコピーできないことをクライアントが知っているため、これらの応答は安全に省略できます。さらに、201（作成）/204（コンテンツなし）ステータスコードは、コピーメソッドからの207（マルチステータス）応答の値として返されるべきではありません。デフォルトの成功コードであるため、これらも安全に省略できます。
If a COPY request has an Overwrite header with a value of "F", and a resource exists at the Destination URL, the server MUST fail the request.
コピーリクエストに「F」の値を持つオーバーライトヘッダーがあり、宛先URLにリソースが存在する場合、サーバーはリクエストに失敗する必要があります。
When a server executes a COPY request and overwrites a destination resource, the exact behavior MAY depend on many factors, including WebDAV extension capabilities (see particularly [RFC3253]). For example, when an ordinary resource is overwritten, the server could delete the target resource before doing the copy, or could do an in-place overwrite to preserve live properties.
サーバーがコピー要求を実行し、宛先リソースを上書きすると、正確な動作は、WebDAV拡張機能を含む多くの要因に依存する場合があります（特に[RFC3253]を参照）。たとえば、通常のリソースが上書きされた場合、サーバーはコピーを実行する前にターゲットリソースを削除したり、ライブプロパティを保存するためにインプレース上書きを行うことができます。
When a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY. Thus, merging the membership of the source and destination collections together in the destination is not a compliant behavior.
コレクションが上書きされると、コピーリクエストが成功した後の宛先コレクションのメンバーシップは、コピーの直前にソースコレクションと同じメンバーシップでなければなりません。したがって、宛先でソースと目的地のコレクションのメンバーシップをマージすることは、準拠した動作ではありません。
In general, if clients require the state of the destination URL to be wiped out prior to a COPY (e.g., to force live properties to be reset), then the client could send a DELETE to the destination before the COPY request to ensure this reset.
一般に、クライアントがコピーの前に宛先URLの状態を必要とする場合（例えば、ライブプロパティをリセットするように強制するため）、クライアントはコピーリクエストの前に宛先に削除を送信して、このリセットを確認することができます。。
In addition to the general status codes possible, the following status codes have specific applicability to COPY:
可能な一般的なステータスコードに加えて、次のステータスコードには、コピーするための特定の適用性があります。
201 (Created) - The source resource was successfully copied. The COPY operation resulted in the creation of a new resource.
201（作成） - ソースリソースが正常にコピーされました。コピー操作により、新しいリソースが作成されました。
204 (No Content) - The source resource was successfully copied to a preexisting destination resource.
204（コンテンツなし） - ソースリソースは、既存の宛先リソースに正常にコピーされました。
207 (Multi-Status) - Multiple resources were to be affected by the COPY, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. For example, if a destination resource was locked and could not be overwritten, then the destination resource URL appears with the 423 (Locked) status.
207（Multi -Status） - 複数のリソースがコピーの影響を受けることになっていましたが、それらのいくつかのエラーは操作が行われないようにしました。特定のエラーメッセージは、ソースおよび宛先URLの最も適切なものとともに、マルチステータス応答の本体に表示されます。たとえば、宛先リソースがロックされていて上書きできなかった場合、宛先リソースURLは423（ロック）ステータスで表示されます。
403 (Forbidden) - The operation is forbidden. A special case for COPY could be that the source and destination resources are the same resource.
403（禁止） - 操作は禁止されています。コピーの特別なケースは、ソースと宛先のリソースが同じリソースであることです。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409（競合） - 1つ以上の中間コレクションが作成されるまで、目的地でリソースを作成することはできません。サーバーは、これらの中間コレクションを自動的に作成してはなりません。
412 (Precondition Failed) - A precondition header check failed, e.g., the Overwrite header is "F" and the destination URL is already mapped to a resource.
412（前提条件に失敗しました） - 前提条件のヘッダーチェックが失敗しました。たとえば、上書きヘッダーは「F」であり、宛先URLはすでにリソースにマッピングされています。
423 (Locked) - The destination resource, or resource within the destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423（ロック） - 宛先コレクション内の宛先リソースまたはリソースがロックされました。この応答には、「ロックトークンが付着した」前処理要素が含まれている必要があります。
502 (Bad Gateway) - This may occur when the destination is on another server, repository, or URL namespace. Either the source namespace does not support copying to the destination namespace, or the destination namespace refuses to accept the resource. The client may wish to try GET/PUT and PROPFIND/PROPPATCH instead.
502（悪いゲートウェイ） - これは、宛先が別のサーバー、リポジトリ、またはURLネームスペース上にあるときに発生する可能性があります。ソースネームスペースが宛先名空間へのコピーをサポートしていないか、宛先名前スペースがリソースを受け入れることを拒否します。クライアントは、代わりにget/putとpropfind/proppatchを試してみたい場合があります。
507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージが不十分） - 宛先リソースには、この方法の実行後にリソースの状態を記録するのに十分なスペースがありません。
This example shows resource http://www.example.com/~fielding/index.html being copied to the location http://www.example.com/users/f/fielding/index.html. The 204 (No Content) status code indicates that the existing resource at the destination was overwritten.
この例は、リソースhttp://www.example.com/~fielding/index.htmlが場所http://www.example.com/users/f/fielding/index.htmlにコピーされていることを示しています。204（コンテンツなし）ステータスコードは、宛先の既存のリソースが上書きされたことを示しています。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204コンテンツなし
The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 (Precondition Failed) is returned because the destination URL is already mapped to a resource.
次の例は、同じコピー操作が実行されていることを示していますが、上書きヘッダーが「F」に設定されています。宛先URLがすでにリソースにマッピングされているため、412（前提条件が失敗した）の応答が返されます。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/users/f/fielding/index.html
Overwrite: F
>>Response
>>応答
HTTP/1.1 412 Precondition Failed
HTTP/1.1 412前提条件は失敗しました
>>Request
>>リクエスト
COPY /container/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/othercontainer/ Depth: infinity
コピー/コンテナ/http/1.1ホスト：www.example.com宛先：http：//www.example.com/othercontainer/深さ：インフィニティ
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.example.com/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example, most of the resources, along with the collection, were copied successfully. However, the collection R2 failed because the destination R2 is locked. Because there was an error copying R2, none of R2's members were copied. However, no errors were listed for those members due to the error minimization rules.
コレクションのコピーのデフォルトの動作は、「深さ：無限」ヘッダーが提出されたかのように行動することであるため、深さヘッダーは不要です。この例では、ほとんどのリソースはコレクションとともに正常にコピーされました。ただし、宛先R2がロックされているため、コレクションR2は失敗しました。R2をコピーするエラーがあったため、R2のメンバーはどれもコピーされませんでした。ただし、エラーの最小化ルールのため、これらのメンバーのエラーはリストされていません。
The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed in a single operation. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URLs, other than the Request-URI that identifies the source resource, to point to the new destination resource.
非収集リソースの移動操作は、コピー（コピー）に相当する論理的なものであり、その後に一貫性メンテナンス処理が続き、その後にソースが削除され、3つのアクションすべてが単一の操作で実行されます。一貫性メンテナンスステップにより、ソースリソースを識別するリクエスト-URI以外のすべてのURLを更新するなど、新しい宛先リソースを指すように、サーバーが移動によって引き起こされる更新を実行できます。
The Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV-compliant resources MUST support the MOVE method.
宛先ヘッダーはすべての移動方法に存在する必要があり、移動方法のコピー部分のすべてのコピー要件に従う必要があります。すべてのWebDAV準拠のリソースは、移動方法をサポートする必要があります。
Support for the MOVE method does not guarantee the ability to move a resource to a particular destination. For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server.
MOVEメソッドのサポートは、リソースを特定の宛先に移動する能力を保証するものではありません。たとえば、個別のプログラムは、実際に同じサーバー上の異なるリソースセットを制御する場合があります。したがって、同じサーバーに属していると思われる名前空間内でリソースを移動することはできない場合があります。
If a resource exists at the destination, the destination resource will be deleted as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
宛先にリソースが存在する場合、宛先リソースは、上書きヘッダーの制限を条件として、移動操作の副作用として削除されます。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
この方法は等極性ですが、安全ではありません（[RFC2616]のセクション9.1を参照）。この方法への応答をキャッシュしてはなりません。
Live properties described in this document SHOULD be moved along with the resource, such that the resource has identically behaving live properties at the destination resource, but not necessarily with the same values. Note that some live properties are defined such that the absence of the property has a specific meaning (e.g., a flag with one meaning if present, and the opposite if absent), and in these cases, a successful MOVE might result in the property being reported as "Not Found" in subsequent requests. If the live properties will not work the same way at the destination, the server MAY fail the request.
このドキュメントに記載されているライブプロパティは、リソースとともに移動する必要があります。リソースは、宛先リソースでライブプロパティを同じように動作させますが、必ずしも同じ値ではそうではありません。一部のライブプロパティは、プロパティの欠如が特定の意味を持つように定義されていることに注意してください（たとえば、存在する場合は1つの意味を持つフラグ、および反対がない場合は反対）、これらの場合、動きが成功すると、プロパティが存在する可能性があります。後続の要求で「見つかりません」と報告されています。宛先でライブプロパティが同じように機能しない場合、サーバーはリクエストに失敗する可能性があります。
MOVE is frequently used by clients to rename a file without changing its parent collection, so it's not appropriate to reset all live properties that are set at resource creation. For example, the DAV: creationdate property value SHOULD remain the same after a MOVE.
MOVEは、親コレクションを変更せずにファイルの名前を変更するためにクライアントが頻繁に使用するため、リソース作成に設定されたすべてのライブプロパティをリセットすることは適切ではありません。たとえば、DAV：CreationDateプロパティ値は、移動後も同じままでなければなりません。
Dead properties MUST be moved along with the resource.
デッドプロパティは、リソースとともに移動する必要があります。
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the address specified in the Destination header, and all resources identified by its internal member URLs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy.
「深さ：Infinity」の動きは、リクエスト-URIによって識別されたコレクションを宛先ヘッダーで指定されたアドレスに移動することを指示し、その内部メンバーURLによって識別されるすべてのリソースは、それに関連する場所に移動し、再帰的に移動します。コレクション階層のすべてのレベル。
The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity".
コレクションの移動方法は、「深さ：無限」ヘッダーが使用されているかのように動作する必要があります。クライアントは、「Infinity」以外の価値のあるコレクションの動きで深度ヘッダーを送信してはなりません。
Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header. The behavior of the Destination header is the same as given for COPY on collections.
移動に含まれるヘッダーは、宛先ヘッダーを除き、移動するすべてのリソースを処理する際に適用する必要があります。宛先ヘッダーの動作は、コレクションのコピーの場合と同じです。
When the MOVE method has completed processing, it MUST have created a consistent URL namespace at both the source and destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members that are not descendants of an error-causing collection). So, for example, if an infinite-depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite-depth move, the server SHOULD try to finish as much of the original move operation as possible.
移動方法が処理を完了した場合、ソースと宛先の両方で一貫したURLネームスペースを作成した必要があります（名前空間の一貫性の定義については、セクション5.1を参照）。ただし、内部コレクションの移動中にエラーが発生した場合、サーバーは失敗したコレクションのメンバーによって識別されたリソースを移動してはなりません（つまり、サーバーはエラーを引き付けるサブツリーをスキップする必要があります）。これにより、一貫性のない名前空間が作成されるためです。この場合、エラーを検出した後、移動操作は可能な限り多くの元の移動を完了しようとする必要があります（つまり、サーバーは、エラーの子孫ではないメンバーによって識別された他のサブツリーとリソースを移動しようとする必要があります - コレクションの容認）。したがって、たとえば、コレクション/a/b/および/a/c/を含むコレクション/a/で無限の深さの移動が実行され、エラーが移動/a/b/を実行する場合、試みはまだ移動/a/c/を試してみました。同様に、非収集リソースを無限の深さの移動の一部として移動するエラーが発生した後、サーバーは可能な限り多くの元の移動操作を完了しようとする必要があります。
If an error occurs with a resource other than the resource identified in the Request-URI, then the response MUST be a 207 (Multi-Status), and the errored resource's URL MUST appear with the specific error.
Request-URIで識別されたリソース以外のリソースでエラーが発生した場合、応答は207（マルチステータス）でなければならず、エラー化されたリソースのURLが特定のエラーで表示される必要があります。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally, 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
424（依存関係の失敗）ステータスコードは、移動方法からの207（マルチステータス）応答で返されないでください。クライアントは、クライアントが親のエラーを受信したときにリソースの子孫を移動できないことをクライアントが知っているため、これらのエラーを安全に省略できます。さらに、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」である場合、移動を実行する前に、サーバーは宛先リソースの「深さ：Infinity」で削除を実行する必要があります。上書きヘッダーが「F」に設定されている場合、操作は失敗します。
In addition to the general status codes possible, the following status codes have specific applicability to MOVE:
可能な一般的なステータスコードに加えて、次のステータスコードには、移動するための特定の適用性があります。
201 (Created) - The source resource was successfully moved, and a new URL mapping was created at the destination.
201（作成） - ソースリソースが正常に移動され、目的地で新しいURLマッピングが作成されました。
204 (No Content) - The source resource was successfully moved to a URL that was already mapped.
204（コンテンツなし） - ソースリソースは、すでにマッピングされているURLに正常に移動されました。
207 (Multi-Status) - Multiple resources were to be affected by the MOVE, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi-status response. For example, if a source resource was locked and could not be moved, then the source resource URL appears with the 423 (Locked) status.
207（Multi -Status） - 複数のリソースが移動の影響を受けましたが、それらのいくつかのエラーは操作が行われないようにしました。特定のエラーメッセージは、ソースおよび宛先URLの最も適切なものとともに、マルチステータス応答の本体に表示されます。たとえば、ソースリソースがロックされて移動できなかった場合、ソースリソースURLは423（ロックされた）ステータスで表示されます。
403 (Forbidden) - Among many possible reasons for forbidding a MOVE operation, this status code is recommended for use when the source and destination resources are the same.
403（禁止） - 移動操作を禁止する多くの考えられる理由の中で、このステータスコードは、ソースと宛先のリソースが同じ場合に使用することをお勧めします。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. Or, the server was unable to preserve the behavior of the live properties and still move the resource to the destination (see 'preserved-live-properties' postcondition).
409（競合） - 1つ以上の中間コレクションが作成されるまで、目的地でリソースを作成することはできません。サーバーは、これらの中間コレクションを自動的に作成してはなりません。または、サーバーはライブプロパティの動作を保存できず、リソースを宛先に移動することができませんでした（「保存状態の整ったプロパティ」の条件を参照）。
412 (Precondition Failed) - A condition header failed. Specific to MOVE, this could mean that the Overwrite header is "F" and the destination URL is already mapped to a resource.
412（前提条件に失敗した） - 条件ヘッダーが失敗しました。移動するために、これは上書きヘッダーが「F」であり、宛先URLがすでにリソースにマッピングされていることを意味します。
423 (Locked) - The source or the destination resource, the source or destination resource parent, or some resource within the source or destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423（ロック） - ソースまたは宛先リソース、ソースまたは宛先リソースの親、またはソースまたは宛先コレクション内のリソースがロックされました。この応答には、「ロックトークンが付着した」前処理要素が含まれている必要があります。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource. This could also occur when the destination is on another sub-section of the same server namespace.
502（悪いゲートウェイ） - これは、宛先が別のサーバー上にあり、宛先サーバーがリソースの受け入れを拒否したときに発生する可能性があります。これは、宛先が同じサーバー名空間の別のサブセクションにある場合にも発生する可能性があります。
This example shows resource http://www.example.com/~fielding/index.html being moved to the location http://www.example.com/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination URL was already mapped to a resource. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
この例は、リソースhttp://www.example.com/~fielding/index.htmlが場所http://www.example.com/users/f/fielding/index.htmlに移動することを示しています。宛先URLがすでにリソースにマッピングされている場合、宛先リソースの内容は上書きされていました。この場合、宛先リソースには何もなかったため、応答コードは201（作成）です。
>>Request
>>リクエスト
MOVE /~fielding/index.html HTTP/1.1
Host: www.example.com
Destination: http://www.example/users/f/fielding/index.html
>>Response
>>応答
HTTP/1.1 201 Created Location: http://www.example.com/users/f/fielding/index.html
http/1.1 201の作成場所：http：//www.example.com/users/f/fielding/index.html
>>Request
>>リクエスト
MOVE /container/ HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/othercontainer/
Overwrite: F
If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d='DAV:'>
<d:response>
<d:href>http://www.example.com/othercontainer/C2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
<d:error><d:lock-token-submitted/></d:error>
</d:response>
</d:multistatus>
In this example, the client has submitted a number of lock tokens with the request. A lock token will need to be submitted for every resource, both source and destination, anywhere in the scope of the method, that is locked. In this case, the proper lock token was not submitted for the destination http://www.example.com/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error moving /container/C2/, none of /container/C2's members were moved. However, no errors were listed for those members due to the error minimization rules. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
この例では、クライアントはリクエストで多数のロックトークンを提出しました。ロックトークンは、ソースと宛先の両方のリソース、メソッドの範囲内のどこでもロックされているすべてのリソースに提出する必要があります。この場合、適切なロックトークンは宛先http://www.example.com/othercontainer/c2/に提出されませんでした。これは、リソース/コンテナ/C2/を移動できなかったことを意味します。エラー移動/container/c2/があったため、/container/c2のメンバーはいずれも移動しませんでした。ただし、エラーの最小化ルールのため、これらのメンバーのエラーはリストされていません。ユーザーエージェント認証は、基礎となる輸送層で、HTTPプロトコルの範囲外のメカニズムを介して以前に発生しています。
The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested.
次のセクションでは、ロック方法について説明します。これは、アクセスタイプのロックを取り出し、既存のロックを更新するために使用されます。ロックメソッドのこれらのセクションは、ロックメソッドに固有のセマンティクスのみを説明し、要求されているロックのアクセスタイプとは無関係です。
Any resource that supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein.
ロックメソッドをサポートするリソースは、少なくとも、本明細書で定義されているXMLリクエストと応答形式をサポートする必要があります。
This method is neither idempotent nor safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
この方法は、等身でも安全でもありません（[RFC2616]のセクション9.1を参照）。この方法への応答をキャッシュしてはなりません。
A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The resource identified in the Request-URI becomes the root of the lock. LOCK method requests to create a new lock MUST have an XML request body. The server MUST preserve the information provided by the client in the 'owner' element in the LOCK request. The LOCK request MAY have a Timeout header.
既存のリソースへのロックリクエストは、リソースがまだ競合するロックでロックされていない場合、リクエスト-URIによって識別されるリソースにロックを作成します。リクエスト-URIで識別されたリソースは、ロックのルートになります。ロックメソッドリクエスト新しいロックを作成するには、XMLリクエストボディが必要です。サーバーは、ロックリクエストの「所有者」要素にクライアントが提供する情報を保存する必要があります。ロックリクエストにはタイムアウトヘッダーがある場合があります。
When a new lock is created, the LOCK response:
新しいロックが作成されると、ロック応答：
o MUST contain a body with the value of the DAV:lockdiscovery property in a prop XML element. This MUST contain the full information about the lock just granted, while information about other (shared) locks is OPTIONAL.
o Prop XML要素にDAV：Lock -Discoveryプロパティの値を持つ本体を含める必要があります。これには、付与されたロックに関する完全な情報が含まれている必要がありますが、他の（共有）ロックに関する情報はオプションです。
o MUST include the Lock-Token response header with the token associated with the new lock.
o 新しいロックに関連付けられたトークンにロックトークン応答ヘッダーを含める必要があります。
A lock is refreshed by sending a LOCK request to the URL of a resource within the scope of the lock. This request MUST NOT have a body and it MUST specify which lock to refresh by using the 'If' header with a single lock token (only one lock may be refreshed at a time). The request MAY contain a Timeout header, which a server MAY accept to change the duration remaining on the lock to the new value. A server MUST ignore the Depth header on a LOCK refresh.
ロックの範囲内でロック要求をリソースのURLに送信することにより、ロックが更新されます。このリクエストには本文がないため、単一のロックトークンを備えた「if」ヘッダーを使用して更新するロックを指定する必要があります（一度に1つのロックのみが更新される場合があります）。リクエストにはタイムアウトヘッダーが含まれている場合があります。これは、ロックの残りの時間を新しい値に変更するためにサーバーが受け入れる場合があります。サーバーは、ロックリフレッシュで深度ヘッダーを無視する必要があります。
If the resource has other (shared) locks, those locks are unaffected by a lock refresh. Additionally, those locks do not prevent the named lock from being refreshed.
リソースに他の（共有）ロックがある場合、それらのロックはロックリフレッシュの影響を受けません。さらに、これらのロックは、指定されたロックが更新されないようにしません。
The Lock-Token header is not returned in the response for a successful refresh LOCK request, but the LOCK response body MUST contain the new value for the DAV:lockdiscovery property.
ロックトークンヘッダーは、リフレッシュロックリクエストを成功させるために応答で返されませんが、ロック応答本体には、DAV：Lock-Discoveryプロパティの新しい値が含まれている必要があります。
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または無限以外の値は、ロックメソッドの深度ヘッダーで使用してはなりません。ロックメソッドをサポートするすべてのリソースは、深度ヘッダーをサポートする必要があります。
A Depth header of value 0 means to just lock the resource specified by the Request-URI.
値0の深度ヘッダーは、リクエスト-URIによって指定されたリソースをロックすることを意味します。
If the Depth header is set to infinity, then the resource specified in the Request-URI along with all its members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token. Similarly, if an UNLOCK is successfully executed on this token, all associated resources are unlocked. Hence, partial success is not an option for LOCK or UNLOCK. Either the entire hierarchy is locked or no resources are locked.
深度ヘッダーが無限に設定されている場合、すべてのメンバーとともにリクエスト-URIで指定されたリソースは、階層をずっと下ってロックされます。成功した結果は、単一のロックトークンを返す必要があります。同様に、このトークンでロック解除が正常に実行されると、すべての関連リソースがロック解除されます。したがって、部分的な成功は、ロックまたはロックを解除するためのオプションではありません。階層全体がロックされているか、リソースがロックされていません。
If the lock cannot be granted to all resources, the server MUST return a Multi-Status response with a 'response' element for at least one resource that prevented the lock from being granted, along with a suitable status code for that failure (e.g., 403 (Forbidden) or 423 (Locked)). Additionally, if the resource causing the failure was not the resource requested, then the server SHOULD include a 'response' element for the Request-URI as well, with a 'status' element containing 424 Failed Dependency.
すべてのリソースにロックを許可できない場合、サーバーは、ロックが付与されないようにする少なくとも1つのリソースの「応答」要素を使用してマルチステータス応答を返す必要があり、その障害に適したステータスコード（例えば、403（禁止）または423（ロック））。さらに、障害を引き起こすリソースが要求されたリソースではない場合、サーバーには、424の依存関係の故障が含まれる「ステータス」要素を含むリクエスト-URIの「応答」要素も含める必要があります。
If no Depth header is submitted on a LOCK request, then the request MUST act as if a "Depth:infinity" had been submitted.
ロックリクエストで深さヘッダーが送信されない場合、リクエストは「深さ：無限」が提出されたかのように動作する必要があります。
A successful LOCK method MUST result in the creation of an empty resource that is locked (and that is not a collection) when a resource did not previously exist at that URL. Later on, the lock may go away but the empty resource remains. Empty resources MUST then appear in PROPFIND responses including that URL in the response scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length
ロックメソッドを成功させると、リソースが以前にそのURLに存在しなかった場合にロックされた空のリソースが作成されます（コレクションではありません）。その後、ロックは消える可能性がありますが、空のリソースは残ります。空のリソースは、応答範囲のそのURLを含むPropfind Responseに表示する必要があります。サーバーは、204のコンテンツなし応答を使用するか、長さがゼロを示すコンテンツレングスヘッダーで200 OKを使用することにより、空のリソースへのGETリクエストに正常に応答する必要があります
The table below describes the behavior that occurs when a lock request is made on a resource.
以下の表は、リソースにロックリクエストが行われたときに発生する動作について説明しています。
+--------------------------+----------------+-------------------+
| Current State | Shared Lock OK | Exclusive Lock OK |
+--------------------------+----------------+-------------------+
| None | True | True |
| Shared Lock | True | False |
| Exclusive Lock | False | False* |
+--------------------------+----------------+-------------------+
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 =ロックは許可されてはなりません。*=プリンシパルが同じロックを2回要求することは違法です。
The current lock state of a resource is given in the leftmost column, and lock requests are listed in the first row. The intersection of a row and column gives the result of a lock request. For example, if a shared lock is held on a resource, and an exclusive lock is requested, the table entry is "false", indicating that the lock must not be granted.
リソースの現在のロック状態は左端の列に記載されており、ロックリクエストは最初の行にリストされています。行と列の交差点は、ロックリクエストの結果を示します。たとえば、共有ロックがリソースに保持され、排他的ロックが要求された場合、テーブルエントリは「false」であり、ロックを許可してはならないことを示します。
In addition to the general status codes possible, the following status codes have specific applicability to LOCK:
可能な一般的なステータスコードに加えて、次のステータスコードには、ロックするための特定の適用性があります。
200 (OK) - The LOCK request succeeded and the value of the DAV: lockdiscovery property is included in the response body.
200（OK） - ロック要求が成功し、DAVの値：Lock -Discoveryプロパティが応答ボディに含まれています。
201 (Created) - The LOCK request was to an unmapped URL, the request succeeded and resulted in the creation of a new resource, and the value of the DAV:lockdiscovery property is included in the response body.
201（作成） - ロック要求はマップされていないURLに対するものであり、リクエストは成功し、新しいリソースの作成になり、DAV：Lock -Discoveryプロパティの値が応答ボディに含まれています。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409（競合） - 1つ以上の中間コレクションが作成されるまで、目的地でリソースを作成することはできません。サーバーは、これらの中間コレクションを自動的に作成してはなりません。
423 (Locked), potentially with 'no-conflicting-lock' precondition code - There is already a lock on the resource that is not compatible with the requested lock (see lock compatibility table above).
423（ロック）、潜在的に「紛争なしロック」前処理コード - リクエストされたロックと互換性がないリソースにロックが既にあります（上のロック互換性テーブルを参照）。
412 (Precondition Failed), with 'lock-token-matches-request-uri' precondition code - The LOCK request was made with an If header, indicating that the client wishes to refresh the given lock. However, the Request-URI did not fall within the scope of the lock identified by the token. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
412（前提条件が失敗しました）、「ロックトークンマッチ - リクエスト-URI」前処理コード - ロック要求はIFヘッダーで行われ、クライアントが指定されたロックを更新したいことを示しています。ただし、リクエスト-URIは、トークンによって識別されたロックの範囲に該当しませんでした。ロックには、リクエスト-URIが含まれていないスコープがあるか、ロックが消えた可能性があるか、トークンが無効になる可能性があります。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>応答
HTTP/1.1 200 OK
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This example shows the successful creation of an exclusive write lock on resource http://example.com/workspace/webdav/proposal.doc. The resource http://example.org/~ejw/contact.html contains contact information for the creator of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例は、リソースhttp://example.com/workspace/webdav/proposal.docでの排他的な書き込みロックの作成の成功を示しています。リソースhttp://example.org/~ejw/contact.htmlには、ロックの作成者の連絡先情報が含まれています。サーバーには、このリソースにアクティビティベースのタイムアウトポリシーがあり、1週間後（604800秒）後にロックが自動的に削除されます。NONCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていないことに注意してください。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
>>応答
HTTP/1.1 200 OK
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This request would refresh the lock, attempting to reset the timeout to the new value specified in the timeout header. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
このリクエストはロックを更新し、タイムアウトヘッダーで指定された新しい値にタイムアウトをリセットしようとします。クライアントは無限のタイムアウトを求めたが、サーバーはリクエストを無視することを選択したことに注意してください。この例では、NONCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていません。
>>Request
>>リクエスト
LOCK /webdav/ HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Depth: infinity
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D="DAV:">
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:owner>
<D:href>http://example.org/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://example.com/webdav/secret</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
<D:response>
<D:href>http://example.com/webdav/</D:href>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:response>
</D:multistatus>
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.
この例は、コレクションとそのすべての子供に排他的な書き込みロックのリクエストを示しています。このリクエストでは、クライアントは、利用可能な場合は、無限の長さのロックが必要であることを指定しています。リクエストエンティティボディには、ロックを取り出すプリンシパルの連絡先情報が含まれています。この場合、WebページURLが含まれています。
The error is a 403 (Forbidden) response on the resource http://example.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the a 'response' element for the Request-URI itself has been included as required.
エラーは、リソースhttp://example.com/webdav/secretの403（禁止）応答です。このリソースをロックできなかったため、リソースはいずれもロックされていません。また、リクエスト-URI自体の「応答」要素が必要に応じて含まれていることにも注意してください。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、NONCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていません。
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock.
ロック解除メソッドは、ロックトークンリクエストヘッダーのロックトークンによって識別されたロックを削除します。Request-URIは、ロックの範囲内でリソースを識別する必要があります。
Note that use of the Lock-Token header to provide the lock token is not consistent with other state-changing methods, which all require an If header with the lock token. Thus, the If header is not needed to provide the lock token. Naturally, when the If header is present, it has its normal meaning as a conditional header.
ロックトークンを提供するためにロックトークンヘッダーを使用することは、すべての状態変化する方法と一致しないことに注意してください。したがって、ロックトークンを提供するためにヘッダーが必要ありません。当然、ヘッダーが存在する場合、条件付きヘッダーとしての通常の意味があります。
For a successful response to this method, the server MUST delete the lock entirely.
この方法への応答を成功させるには、サーバーはロックを完全に削除する必要があります。
If all resources that have been locked under the submitted lock token cannot be unlocked, then the UNLOCK request MUST fail.
提出されたロックトークンの下でロックされているすべてのリソースをロック解除できない場合、ロック解除リクエストは失敗する必要があります。
A successful response to an UNLOCK method does not mean that the resource is necessarily unlocked. It means that the specific lock corresponding to the specified token no longer exists.
ロック解除方法に対する成功した応答は、リソースが必ずしもロック解除されていることを意味しません。これは、指定されたトークンに対応する特定のロックが存在しなくなることを意味します。
Any DAV-compliant resource that supports the LOCK method MUST support the UNLOCK method.
ロックメソッドをサポートするDAVに準拠したリソースは、ロック解除方法をサポートする必要があります。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
この方法は等極性ですが、安全ではありません（[RFC2616]のセクション9.1を参照）。この方法への応答をキャッシュしてはなりません。
In addition to the general status codes possible, the following status codes have specific applicability to UNLOCK:
可能な一般的なステータスコードに加えて、次のステータスコードには、ロックを解除するための特定の適用性があります。
204 (No Content) - Normal success response (rather than 200 OK, since 200 OK would imply a response body, and an UNLOCK success response does not normally contain a body).
204（コンテンツなし） - 通常の成功応答（200 OKではなく、200 OKは応答本体を意味し、ロック解除成功応答には通常ボディが含まれていません）。
400 (Bad Request) - No lock token was provided.
400（悪いリクエスト） - ロックトークンは提供されていません。
403 (Forbidden) - The currently authenticated principal does not have permission to remove the lock.
403（禁止） - 現在認証されているプリンシパルには、ロックを削除する許可がありません。
409 (Conflict), with 'lock-token-matches-request-uri' precondition - The resource was not locked, or the request was made to a Request-URI that was not within the scope of the lock.
409（競合）、「ロックトークンマッチ - リクエスト-uri」の前提条件 - リソースはロックされていないか、ロックの範囲内ではないリクエスト-URIにリクエストが行われました。
>>Request
>>リクエスト
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: example.com
Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw"
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204コンテンツなし
In this example, the lock identified by the lock token "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://example.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock.
この例では、ロックトークン「URN：UUID：A515CFA4-5DA4-22E1-F5B5-00A0451E6BF7」によって識別されたロックは、リソースhttp://example.com/workspace/webdav/info.docから正常に削除されます。このロックには1つ以上のリソースが含まれている場合、ロックはロックに含まれるすべてのリソースから削除されます。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、NONCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていません。
All DAV headers follow the same basic formatting rules as HTTP headers. This includes rules like line continuation and how to combine (or separate) multiple instances of the same header using commas.
すべてのDAVヘッダーは、HTTPヘッダーと同じ基本フォーマットルールに従います。これには、ラインの継続などのルールが含まれ、コンマを使用して同じヘッダーの複数のインスタンスを組み合わせる（または分離する）方法が含まれます。
WebDAV adds two new conditional headers to the set defined in HTTP: the If and Overwrite headers.
WebDavは、HTTPで定義されているセットに2つの新しい条件付きヘッダーを追加します。IFおよび上書きヘッダー。
DAV = "DAV" ":" #( compliance-class )
compliance-class = ( "1" | "2" | "3" | extend )
extend = Coded-URL | token
; token is defined in RFC 2616, Section 2.2
Coded-URL = "<" absolute-URI ">"
; No linear whitespace (LWS) allowed in Coded-URL
; absolute-URI defined in RFC 3986, Section 4.3
This general-header appearing in the response indicates that the resource supports the DAV schema and protocol as specified. All DAV-compliant resources MUST return the DAV header with compliance-class "1" on all OPTIONS responses. In cases where WebDAV is only supported in part of the server namespace, an OPTIONS request to non-WebDAV resources (including "/") SHOULD NOT advertise WebDAV support.
応答に表示されるこの一般的なヘッダーは、リソースが指定されたDAVスキーマとプロトコルをサポートしていることを示しています。すべてのDAV準拠のリソースは、すべてのオプション応答でコンプライアンスクラス「1」でDAVヘッダーを返す必要があります。WebDAVがサーバー名空間の一部でのみサポートされている場合、WebDav以外のリソース（「/」を含む）へのオプションリクエストは、WebDAVサポートを宣伝してはなりません。
The value is a comma-separated list of all compliance class identifiers that the resource supports. Class identifiers may be Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can appear in any order. Identifiers that are standardized through the IETF RFC process are tokens, but other identifiers SHOULD be Coded-URLs to encourage uniqueness.
値は、リソースがサポートするすべてのコンプライアンスクラス識別子のコンマ分離リストです。クラス識別子は、[RFC2616]で定義されているように、コード化されたURLまたはトークンである場合があります。識別子は任意の順序で表示できます。IETF RFCプロセスを介して標準化された識別子はトークンですが、一意性を促進するために他の識別子はコード化されている必要があります。
A resource must show class 1 compliance if it shows class 2 or 3 compliance. In general, support for one compliance class does not entail support for any other, and in particular, support for compliance class 3 does not require support for compliance class 2. Please refer to Section 18 for more details on compliance classes defined in this specification.
クラス2または3のコンプライアンスが表示される場合、リソースはクラス1のコンプライアンスを表示する必要があります。一般に、1つのコンプライアンスクラスのサポートには、他のコンプライアンスクラスのサポートは必要ありません。特に、コンプライアンスクラス3のサポートには、コンプライアンスクラス2のサポートは必要ありません。この仕様で定義されているコンプライアンスクラスの詳細については、セクション18を参照してください。
Note that many WebDAV servers do not advertise WebDAV support in response to "OPTIONS *".
多くのWebDAVサーバーは、「オプション *」に応じてWebDAVサポートを宣伝していないことに注意してください。
As a request header, this header allows the client to advertise compliance with named features when the server needs that information. Clients SHOULD NOT send this header unless a standards track specification requires it. Any extension that makes use of this as a request header will need to carefully consider caching implications.
リクエストヘッダーとして、このヘッダーは、サーバーがその情報を必要とするときに、クライアントが名前付き機能のコンプライアンスを宣伝することができます。標準トラックの仕様に必要な場合を除き、クライアントはこのヘッダーを送信しないでください。これをリクエストヘッダーとして使用する拡張機能は、キャッシングの意味合いを慎重に検討する必要があります。
Depth = "Depth" ":" ("0" | "1" | "infinity")
The Depth request header is used with methods executed on resources that could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its internal members only ("Depth: 1"), or the resource and all its members ("Depth: infinity").
深度要求ヘッダーは、メソッドがリソース（「深さ：0」）にのみ適用されるかどうかを示すために内部メンバーを潜在的に持つ可能性のあるリソースで実行されたメソッドで使用されます。1 "）、またはリソースとそのすべてのメンバー（「深さ：無限」）。
The Depth header is only supported if a method's definition explicitly provides for such support.
深度ヘッダーは、メソッドの定義がそのようなサポートを明示的に提供する場合にのみサポートされます。
The following rules are the default behavior for any method that supports the Depth header. A method may override these defaults by defining different behavior in its definition.
次のルールは、深度ヘッダーをサポートする任意の方法のデフォルトの動作です。メソッドは、その定義で異なる動作を定義することにより、これらのデフォルトをオーバーライドする場合があります。
Methods that support the Depth header may choose not to support all of the header's values and may define, on a case-by-case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity", and if a Depth header is not present, it will act as if a "Depth: infinity" header had been applied.
深度ヘッダーをサポートする方法は、ヘッダーのすべての値をサポートしないように選択し、深さヘッダーが存在しない場合のメソッドの動作をケースごとに定義する場合があります。たとえば、移動方法は「深さ：無限」のみをサポートし、深さヘッダーが存在しない場合、「深さ：無限」ヘッダーが適用されているかのように機能します。
Clients MUST NOT rely upon methods executing on members of their hierarchies in any particular order or on the execution being atomic unless the particular method explicitly provides such guarantees.
クライアントは、特定のメソッドがそのような保証を明示的に提供しない限り、特定の順序で階層のメンバーを実行したり、原子になったりする方法に依存してはなりません。
Upon execution, a method with a Depth header will perform as much of its assigned task as possible and then return a response specifying what it was able to accomplish and what it failed to do.
実行されると、深さヘッダーを備えたメソッドは、割り当てられたタスクをできるだけ多く実行し、達成できるものと何ができなかったかを指定する応答を返します。
So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not.
したがって、たとえば、階層をコピーしようとすると、一部のメンバーがコピーされ、一部が存在しない場合があります。
By default, the Depth header does not interact with other headers. That is, each header on a request with a Depth header MUST be applied only to the Request-URI if it applies to any resource, unless specific Depth behavior is defined for that header.
デフォルトでは、深度ヘッダーは他のヘッダーと対話しません。つまり、深さヘッダーを使用したリクエストの各ヘッダーは、特定の深さの動作がそのヘッダーに対して定義されていない限り、リソースに適用される場合にのみ、リクエスト-URIに適用する必要があります。
If a source or destination resource within the scope of the Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header.
深度ヘッダーの範囲内のソースまたは宛先リソースが、メソッドの成功を防ぐような方法でロックされている場合、そのリソースのロックトークンは、IFリクエストヘッダーのリクエストとともに提出する必要があります。
The Depth header only specifies the behavior of the method with regards to internal members. If a resource does not have internal members, then the Depth header MUST be ignored.
深度ヘッダーは、内部メンバーに関してメソッドの動作のみを指定します。リソースに内部メンバーがない場合、深度ヘッダーは無視する必要があります。
The Destination request header specifies the URI that identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters.
宛先要求ヘッダーは、2つのURIをパラメーターとして使用するコピーアンドモーブなどのメソッドの宛先リソースを識別するURIを指定します。
Destination = "Destination" ":" Simple-ref
If the Destination value is an absolute-URI (Section 4.3 of [RFC3986]), it may name a different server (or different port or scheme). If the source server cannot attempt a copy to the remote server, it MUST fail the request. Note that copying and moving resources to remote servers is not fully defined in this specification (e.g., specific error conditions).
宛先値が絶対的なURI（[RFC3986]のセクション4.3）である場合、別のサーバー（または異なるポートまたはスキーム）に名前を付けることができます。ソースサーバーがコピーをリモートサーバーに試していない場合、リクエストに失敗する必要があります。リモートサーバーへのリソースのコピーと移動は、この仕様（特定のエラー条件など）で完全に定義されていないことに注意してください。
If the Destination value is too long or otherwise unacceptable, the server SHOULD return 400 (Bad Request), ideally with helpful information in an error body.
宛先値が長すぎるか、容認できない場合、サーバーは400（悪い要求）を返す必要があります。
The If request header is intended to have similar functionality to the If-Match header defined in Section 14.24 of [RFC2616]. However, the If header handles any state token as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification.
IF要求ヘッダーは、[RFC2616]のセクション14.24で定義されているIFマッチヘッダーと同様の機能を持つことを目的としています。ただし、ヘッダーは任意の状態トークンとetagsを処理します。状態トークンの典型的な例はロックトークンであり、ロックトークンは、この仕様で定義されている唯一の状態トークンです。
The If header has two distinct purposes:
ヘッダーには2つの異なる目的があります。
o The first purpose is to make a request conditional by supplying a series of state lists with conditions that match tokens and ETags to a specific resource. If this header is evaluated and all state lists fail, then the request MUST fail with a 412 (Precondition Failed) status. On the other hand, the request can succeed only if one of the described state lists succeeds. The success criteria for state lists and matching functions are defined in Sections 10.4.3 and 10.4.4.
o 最初の目的は、トークンとETAGを特定のリソースに一致させる条件で一連の状態リストを提供することにより、リクエストを条件付きにすることです。このヘッダーが評価され、すべての状態リストが失敗した場合、412（前提条件に失敗した）ステータスでリクエストが失敗する必要があります。一方、記述された状態リストのいずれかが成功した場合にのみ、リクエストが成功することができます。状態リストと一致関数の成功基準は、セクション10.4.3および10.4.4で定義されています。
o Additionally, the mere fact that a state token appears in an If header means that it has been "submitted" with the request. In general, this is used to indicate that the client has knowledge of that state token. The semantics for submitting a state token depend on its type (for lock tokens, please refer to Section 6).
o さらに、状態トークンがIFヘッダーに表示されるという事実は、リクエストで「提出」されたことを意味します。一般に、これはクライアントがその状態トークンの知識を持っていることを示すために使用されます。状態トークンを送信するためのセマンティクスは、そのタイプに依存します（ロックトークンについては、セクション6を参照してください）。
Note that these two purposes need to be treated distinctly: a state token counts as being submitted independently of whether the server actually has evaluated the state list it appears in, and also independently of whether or not the condition it expressed was found to be true.
これらの2つの目的は明確に扱う必要があることに注意してください。状態トークンは、サーバーが実際に表示される状態リストを実際に評価したかどうかとは無関係に提出されているとカウントされます。
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list )
No-tag-list = List Tagged-list = Resource-Tag 1*List
no-tag-list = list tagged-list = resource-tag 1*list
List = "(" 1*Condition ")"
Condition = ["Not"] (State-token | "[" entity-tag "]")
; entity-tag: see Section 3.11 of [RFC2616]
; No LWS allowed between "[", entity-tag and "]"
State-token = Coded-URL
Resource-Tag = "<" Simple-ref ">"
; Simple-ref: see Section 8.3
; No LWS allowed in Resource-Tag
The syntax distinguishes between untagged lists ("No-tag-list") and tagged lists ("Tagged-list"). Untagged lists apply to the resource identified by the Request-URI, while tagged lists apply to the resource identified by the preceding Resource-Tag.
構文は、タグ付きリスト（「ノータグリスト」）とタグ付きリスト（「タグ付きリスト」）を区別します。未積載リストは、リクエスト-URIによって識別されたリソースに適用され、タグ付きリストは前のリソースタグによって識別されたリソースに適用されます。
A Resource-Tag applies to all subsequent Lists, up to the next Resource-Tag.
次のリソースタグまで、リソースタグが後続のすべてのリストに適用されます。
Note that the two list types cannot be mixed within an If header. This is not a functional restriction because the No-tag-list syntax is just a shorthand notation for a Tagged-list production with a Resource-Tag referring to the Request-URI.
2つのリストタイプは、IFヘッダー内で混合できないことに注意してください。これは機能的な制限ではありません。なぜなら、ノータグリストの構文は、Request-URIを参照するリソースタグを備えたタグ付きリストの生成の略歴表記にすぎないためです。
Each List consists of one or more Conditions. Each Condition is defined in terms of an entity-tag or state-token, potentially negated by the prefix "Not".
各リストは、1つ以上の条件で構成されています。各条件は、エンティティタグまたは状態トークンに関して定義され、潜在的にプレフィックス「not」によって否定されます。
Note that the If header syntax does not allow multiple instances of If headers in a single request. However, the HTTP header syntax allows extending single header values across multiple lines, by inserting a line break followed by whitespace (see [RFC2616], Section 4.2).
IF Header構文では、単一のリクエストでヘッダーの複数のインスタンスを許可しないことに注意してください。ただし、HTTPヘッダー構文により、複数の行に単一のヘッダー値を拡張できます。これに続いて、その後の白人が続くラインブレークを挿入します（[RFC2616]、セクション4.2を参照）。
A Condition that consists of a single entity-tag or state-token evaluates to true if the resource matches the described state (where the individual matching functions are defined below in Section 10.4.4). Prefixing it with "Not" reverses the result of the evaluation (thus, the "Not" applies only to the subsequent entity-tag or state-token).
単一のエンティティタグまたは状態のトークンで構成される条件は、リソースが説明された状態と一致する場合に真の評価を評価します（個々の一致関数は、セクション10.4.4で以下に定義されています）。「not」で接頭すると、評価の結果が逆転します（したがって、「not」は後続のエンティティタグまたは州のトークンにのみ適用されます）。
Each List production describes a series of conditions. The whole list evaluates to true if and only if each condition evaluates to true (that is, the list represents a logical conjunction of Conditions).
各リスト生産は、一連の条件について説明します。リスト全体は、各条件がtrueに評価された場合にのみTrueに評価されます（つまり、リストは条件の論理的接続性を表します）。
Each No-tag-list and Tagged-list production may contain one or more Lists. They evaluate to true if and only if any of the contained lists evaluates to true (that is, if there's more than one List, that List sequence represents a logical disjunction of the Lists).
各ノータグリストとタグ付きリストの生成には、1つ以上のリストが含まれる場合があります。含まれているリストのいずれかがTrueに評価された場合にのみTrueを評価します（つまり、複数のリストがある場合、そのリストシーケンスはリストの論理的な分離を表します）。
Finally, the whole If header evaluates to true if and only if at least one of the No-tag-list or Tagged-list productions evaluates to true. If the header evaluates to false, the server MUST reject the request with a 412 (Precondition Failed) status. Otherwise, execution of the request can proceed as if the header wasn't present.
最後に、IFヘッダー全体が、タグリストなしまたはタグ付きリストのプロダクションの少なくとも1つがTrueに評価された場合にのみ、Trueに評価されます。ヘッダーがfalseに評価された場合、サーバーは412（前提条件に失敗した）ステータスでリクエストを拒否する必要があります。それ以外の場合、リクエストの実行は、ヘッダーが存在しないかのように続行できます。
When performing If header processing, the definition of a matching state token or entity tag is as follows:
ヘッダー処理を実行する場合、一致する状態トークンまたはエンティティタグの定義は次のとおりです。
Identifying a resource: The resource is identified by the URI along with the token, in tagged list production, or by the Request-URI in untagged list production.
リソースの識別：リソースは、URIとトークン、タグ付きリストの生産、または未編集リストの生産のリクエストURIによって識別されます。
Matching entity tag: Where the entity tag matches an entity tag associated with the identified resource. Servers MUST use either the weak or the strong comparison function defined in Section 13.3.3 of [RFC2616].
マッチングエンティティタグ：エンティティタグが特定されたリソースに関連付けられたエンティティタグと一致する場合。サーバーは、[RFC2616]のセクション13.3.3で定義されている弱い比較関数または強い比較関数のいずれかを使用する必要があります。
Matching state token: Where there is an exact match between the state token in the If header and any state token on the identified resource. A lock state token is considered to match if the resource is anywhere in the scope of the lock.
一致する状態トークン：IFヘッダーの状態トークンと特定されたリソースの任意の状態トークンの間に正確な一致があります。ロック状態トークンは、リソースがロックの範囲内のどこにでもある場合に一致すると見なされます。
Handling unmapped URLs: For both ETags and state tokens, treat as if the URL identified a resource that exists but does not have the specified state.
マップされていないURLの処理：ETAGSと状態トークンの両方について、URLが存在するが指定された状態を持たないリソースを識別したかのように扱います。
Non-DAV-aware proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the client MUST use the "Cache-Control: no-cache" request header so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies, the "Pragma: no-cache" request header MUST be used for the same reason.
非davに対応するプロキシは、ヘッダーの場合、ヘッダーを尊重しません。なぜなら、彼らはヘッダーを理解していないため、HTTPは無視されていないヘッダーを無視することを要求します。HTTP/1.1プロキシと通信する場合、クライアントは「キャッシュコントロール：ノーキャッシュ」要求ヘッダーを使用して、プロキシがキャッシュからリクエストを不適切に提供しようとするのを防ぐ必要があります。HTTP/1.0プロキシを扱う場合、「プラグマ：ノーキャッシュ」リクエストヘッダーを同じ理由で使用する必要があります。
Because in general clients may not be able to reliably detect non-DAV-aware intermediates, they are advised to always prevent caching using the request directives mentioned above.
一般的には、クライアントは非davに認識されていない中間体を確実に検出できない可能性があるため、上記のリクエストディレクティブを使用して常にキャッシュを防ぐことをお勧めします。
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
["I am an ETag"])
(["I am another ETag"])
The previous header would require that the resource identified in the Request-URI be locked with the specified lock token and be in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag".
前のヘッダーは、リクエスト-URIで識別されたリソースを指定されたロックトークンでロックし、「私はETAG」ETAGによって識別される状態であるか、2番目のETAGによって識別された状態であることを要求します。「。
To put the matter more plainly one can think of the previous If header as expressing the condition below:
この問題をより明確に置くために、以前のヘッダーが以下の条件を表現すると考えることができます。
( is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND matches-etag("I am an ETag") ) OR ( matches-etag("I am another ETag") )
（is-locked-with（urn：uuid：181d4fae-7d8c-11d0-a765-00a0c91e6bf2）およびmatches-etag（ "i a etag"））
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
This If header requires that the resource must not be locked with a lock having the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a lock with the lock token urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
これは、リソースをロックトークンurn：uuid：181d4fae-7d8c-11d0-a765-00a0c91e6bf2を持つロックでリソースをロックしないことを要求し、ロックトークンurn：uuid：uuid：58f202ac-22cf-でロックする必要があります。11D1-B12D-002035B29092。
There may be cases where a client wishes to submit state tokens, but doesn't want the request to fail just because the state token isn't current anymore. One simple way to do this is to include a Condition that is known to always evaluate to true, such as in:
クライアントが州のトークンを提出したい場合がありますが、状態トークンがもう最新ではないという理由だけで、リクエストを失敗させたくない場合があります。これを行う簡単な方法の1つは、以下のように、常に真であることを評価することが知られている条件を含めることです。
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
(Not <DAV:no-lock>)
"DAV:no-lock" is known to never represent a current lock token. Lock tokens are assigned by the server, following the uniqueness requirements described in Section 6.5, therefore cannot use the "DAV:" scheme. Thus, by applying "Not" to a state token that is known not to be current, the Condition always evaluates to true. Consequently, the whole If header will always evaluate to true, and the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 will be submitted in any case.
「Dav：No-Lock」は、現在のロックトークンを表していないことが知られています。ロックトークンは、セクション6.5で説明されている一意性要件に従って、サーバーによって割り当てられます。したがって、「DAV：」スキームを使用できません。したがって、最新ではないことが知られている状態トークンに「NOT」を適用することにより、条件は常に真であると評価します。その結果、ヘッダー全体が常にtrueに評価され、ロックトークンurn：uuid：181D4FAE-7D8C-11D0-A765-00A0C91E6BF2が提出されます。
>>Request
>>リクエスト
COPY /resource1 HTTP/1.1
Host: www.example.com
Destination: /resource2
If: </resource1>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
[W/"A weak ETag"]) (["strong ETag"])
In this example, http://www.example.com/resource1 is being copied to http://www.example.com/resource2. When the method is first applied to http://www.example.com/resource1, resource1 must be in the state specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A weak ETag"]) (["strong ETag"])". That is, either it must be locked with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag".
この例では、http：//www.example.com/resource1がhttp://www.example.com/resource2にコピーされています。メソッドが最初にhttp://www.example.com/resource1に適用された場合、Resource1は「（<urn：uuid：uuid：181d4fae-7d8c-11d0-a765-00a0c91e6bf2>」によって指定された状態にある必要があります。etag "]）（[" strong etag "]）"。つまり、「urn：uuid：181d4fae-7d8c-11d0-a765-00a0c91e6bf22」のロックトークンでロックする必要があり、「弱いエタグ」w/「弱いエンティティタグが必要です」強いetag」。
DELETE /specs/rfc2518.txt HTTP/1.1
Host: www.example.com
If: <http://www.example.com/specs/>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
For this example, the lock token must be compared to the identified resource, which is the 'specs' collection identified by the URL in the tagged list production. If the 'specs' collection is not locked by a lock with the specified lock token, the request MUST fail. Otherwise, this request could succeed, because the If header evaluates to true, and because the lock token for the lock affecting the affected resource has been submitted.
この例では、ロックトークンは、タグ付きリスト制作のURLによって識別される「仕様」コレクションである識別されたリソースと比較する必要があります。「仕様」コレクションが指定されたロックトークンを備えたロックによってロックされていない場合、リクエストは失敗する必要があります。それ以外の場合、このリクエストは成功する可能性があります。なぜなら、ヘッダーがTrueに評価され、影響を受けるリソースに影響を与えるロックのロックトークンが提出されたためです。
Consider a collection "/specs" that does not contain the member "/specs/rfc2518.doc". In this case, the If header
メンバー「/specs/rfc2518.doc」を含まないコレクション「/仕様」を検討してください。この場合、IFヘッダー
If: </specs/rfc2518.doc> (["4217"])
will evaluate to false (the URI isn't mapped, thus the resource identified by the URI doesn't have an entity matching the ETag "4217").
falseに評価されます（URIはマッピングされていないため、URIによって識別されるリソースには、ETAG「4217」と一致するエンティティがありません）。
On the other hand, an If header of
一方、ヘッダー
If: </specs/rfc2518.doc> (Not ["4217"])
will consequently evaluate to true.
したがって、trueに評価します。
Note that, as defined above in Section 10.4.4, the same considerations apply to matching state tokens.
上記のセクション10.4.4で定義されているように、同じ考慮事項が一致する状態トークンにも当てはまることに注意してください。
Lock-Token = "Lock-Token" ":" Coded-URL
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.
ロックトークンリクエストヘッダーは、ロック解除方法で使用され、削除するロックを識別します。ロックトークンリクエストヘッダーのロックトークンは、リクエスト-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.
ロックトークン応答ヘッダーは、ロックメソッドとともに使用され、新しいロックを作成するためのロック要求が成功した結果として作成されたロックトークンを示します。
Overwrite = "Overwrite" ":" ("T" | "F")
The Overwrite request header specifies whether the server should overwrite a resource mapped to the destination URL during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the destination URL does map to a resource. If the overwrite header is not included in a COPY or MOVE request, then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of using an "If-Match: *" header (see [RFC2616]), If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE.
上書き要求ヘッダーは、コピーまたは移動中に宛先URLにマッピングされたリソースをサーバーが上書きするかどうかを指定します。「F」の値は、宛先URLがリソースにマッピングされた場合、サーバーがコピーまたは移動操作を実行してはならないことを示しています。上書きヘッダーがコピーリクエストまたは移動リクエストに含まれていない場合、リソースは、値「t」の上書きヘッダーがあるかのようにリクエストを扱う必要があります。上書きヘッダーは、「if-match： *」ヘッダー（[rfc2616]を参照）を使用する機能を複製しているように見えますが、if-matchはリクエストURIにのみ適用され、コピーまたは移動の宛先には適用されません。
If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code. The server MUST do authorization checks before checking this or any conditional header.
上書きヘッダーの値のためにコピーまたは移動が実行されない場合、412（前提条件に失敗した）ステータスコードでメソッドが失敗する必要があります。サーバーは、これまたは条件付きヘッダーをチェックする前に、承認チェックを行う必要があります。
All DAV-compliant resources MUST support the Overwrite header.
すべてのDAV準拠リソースは、上書きヘッダーをサポートする必要があります。
TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite")
; No LWS allowed within TimeType
DAVTimeOutVal = 1*DIGIT
Clients MAY include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method.
クライアントには、ロックリクエストにタイムアウトリクエストヘッダーが含まれる場合があります。ただし、サーバーは、これらのリクエストを尊重したり、検討する必要もありません。クライアントは、ロックメソッド以外のメソッドを使用してタイムアウトリクエストヘッダーを送信してはなりません。
The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1.
「2番目の」タイムタイプは、サーバーでのロックの付与とロックの自動除去の間に経過する秒数を指定します。TimeType "Second"のタイムアウト値は、2^32-1を超えてはなりません。
See Section 6.6 for a description of lock timeout behavior.
ロックタイムアウト動作の説明については、セクション6.6を参照してください。
The following status codes are added to those defined in HTTP/1.1 [RFC2616].
次のステータスコードは、HTTP/1.1 [RFC2616]で定義されているものに追加されます。
The 207 (Multi-Status) status code provides status for multiple independent operations (see Section 13 for more information).
207（マルチステータス）ステータスコードは、複数の独立操作のステータスを提供します（詳細についてはセクション13を参照）。
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
422（処理不可能なエンティティ）ステータスコードは、サーバーがリクエストエンティティのコンテンツタイプを理解することを意味します（したがって415（サポートされていないメディアタイプ）ステータスコードは不適切です）。）ステータスコードは不適切です）が、含まれている命令を処理できませんでした。たとえば、XMLリクエスト本体によく形成された（つまり、構文的に正しい）が、意味的に誤ったXML命令が含まれている場合、このエラー条件が発生する場合があります。
The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
423（ロックされた）ステータスコードは、メソッドのソースまたは宛先リソースがロックされていることを意味します。この応答には、「ロックトークンが付着した」または「紛争なしロック」などの適切な前提条件または条件後のコードが含まれている必要があります。
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails, then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
424（失敗した依存関係）ステータスコードは、要求されたアクションが別のアクションに依存し、そのアクションが失敗したため、メソッドをリソース上で実行できなかったことを意味します。たとえば、プロップパッチメソッドのコマンドが失敗した場合、少なくとも、残りのコマンドも424で失敗します（依存関係の失敗）。
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
507（ストレージ不足）ステータスコードは、リクエストを正常に完了するために必要な表現を保存できないため、メソッドをリソース上で実行できなかったことを意味します。この状態は一時的な状態と見なされます。このステータスコードを受け取ったリクエストがユーザーアクションの結果である場合、リクエストは、個別のユーザーアクションによって要求されるまで繰り返されてはなりません。
These HTTP codes are not redefined, but their use is somewhat extended by WebDAV methods and requirements. In general, many HTTP status codes can be used in response to any request, not just in cases described in this document. Note also that WebDAV servers are known to use 300-level redirect responses (and early interoperability tests found clients unprepared to see those responses). A 300-level response MUST NOT be used when the server has created a new resource in response to the request.
これらのHTTPコードは再定義されていませんが、それらの使用はWebDAVの方法と要件によって多少拡張されています。一般に、多くのHTTPステータスコードは、このドキュメントで説明されている場合だけでなく、任意の要求に応じて使用できます。また、WebDAVサーバーは300レベルのリダイレクト応答を使用することが知られていることに注意してください（そして、初期の相互運用性テストでは、クライアントがこれらの応答を見る準備ができていないことがわかりました）。サーバーがリクエストに応じて新しいリソースを作成した場合、300レベルの応答を使用しないでください。
Any request can contain a conditional header defined in HTTP (If-Match, If-Modified-Since, etc.) or the "If" or "Overwrite" conditional headers defined in this specification. If the server evaluates a conditional header, and if that condition fails to hold, then this error code MUST be returned. On the other hand, if the client did not include a conditional header in the request, then the server MUST NOT use this status code.
リクエストには、HTTPで定義されている条件付きヘッダー（If-Match、If-Modified-Sinceなど）またはこの仕様で定義された「If」または「上書き」条件付きヘッダーを含めることができます。サーバーが条件付きヘッダーを評価し、その条件が保持されない場合、このエラーコードを返す必要があります。一方、クライアントがリクエストに条件付きヘッダーを含めなかった場合、サーバーはこのステータスコードを使用してはなりません。
This status code is used in HTTP 1.1 only for Request-URIs, not URIs in other locations.
このステータスコードは、他の場所のurisではなく、リクエスト-urisに対してのみHTTP 1.1で使用されます。
A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate. The default Multi-Status response body is a text/xml or application/xml HTTP entity with a 'multistatus' root element. Further elements contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element.
複数のステータスコードが適切な状況で複数のリソースに関する情報をマルチステータス応答が伝えます。デフォルトのマルチステータス応答本体は、「Multistatus」ルート要素を備えたテキスト/XMLまたはApplication/XML HTTPエンティティです。さらに要素には、メソッドの呼び出し中に生成された200、300、400、および500シリーズのステータスコードが含まれています。100シリーズステータスコードは、「応答」XML要素に記録しないでください。
Although '207' is used as the overall response status code, the recipient needs to consult the contents of the multistatus response body for further information about the success or failure of the method execution. The response MAY be used in success, partial success and also in failure situations.
「207」は全体的な応答ステータスコードとして使用されていますが、受信者はメソッド実行の成功または失敗に関する詳細については、MultiStatus Responseボディの内容を参照する必要があります。応答は、成功、部分的な成功、および失敗状況でも使用される場合があります。
The 'multistatus' root element holds zero or more 'response' elements in any order, each with information about an individual resource. Each 'response' element MUST have an 'href' element to identify the resource.
「Multistatus」ルート要素は、ゼロ以上の「応答」要素を任意の順序で保持し、それぞれに個別のリソースに関する情報があります。各「応答」要素には、リソースを識別するために「HREF」要素が必要です。
A Multi-Status response uses one out of two distinct formats for representing the status:
マルチステータス応答は、ステータスを表すために2つの異なる形式のうち1つを使用します。
1. A 'status' element as child of the 'response' element indicates the status of the message execution for the identified resource as a whole (for instance, see Section 9.6.2). Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic rules defined in Section 10 of [RFC2616].
1. 「応答」要素の子としての「ステータス」要素は、特定されたリソース全体のメッセージ実行のステータスを示します（たとえば、セクション9.6.2を参照）。一部のメソッド定義は、特定のステータスコードに関する情報を提供します。クライアントは、応答で確認するために準備する必要があります。ただし、[RFC2616]のセクション10で定義されている一般的なルールを使用して、クライアントは他のステータスコードを処理できる必要があります。
2. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is described in detail in Sections 9.1 and 9.2.
2. PropfindおよびProppatchの場合、形式は「ステータス」ではなく「PropStat」要素を使用して拡張され、リソースの個々のプロパティに関する情報を提供します。この形式は、PropfindおよびProppatchに固有のものであり、セクション9.1および9.2で詳細に説明されています。
HTTP defines the Location header to indicate a preferred URL for the resource that was addressed in the Request-URI (e.g., in response to successful PUT requests or in redirect responses). However, use of this header creates ambiguity when there are URLs in the body of the response, as with Multi-Status. Thus, use of the Location header with the Multi-Status response is intentionally undefined.
HTTPは、リクエスト-URIで対処されたリソースの優先URLを示すための位置ヘッダーを定義します（たとえば、パットリクエストの成功に応じて、またはリダイレクト応答）。ただし、このヘッダーの使用は、マルチスタタスと同様に、応答の本体にURLがある場合に曖昧さを生み出します。したがって、マルチステータス応答を使用したロケーションヘッダーの使用は、意図的に定義されていません。
Redirect responses (300-303, 305, and 307) defined in HTTP 1.1 normally take a Location header to indicate the new URI for the single resource redirected from the Request-URI. Multi-Status responses contain many resource addresses, but the original definition in [RFC2518] did not have any place for the server to provide the new URI for redirected resources. This specification does define a 'location' element for this information (see Section 14.9). Servers MUST use this new element with redirect responses in Multi-Status.
HTTP 1.1で定義されたリダイレクト応答（300-303、305、および307）は、通常、リクエスト-URIからリダイレクトされた単一のリソースの新しいURIを示すためにロケーションヘッダーを取ります。マルチステータス応答には多くのリソースアドレスが含まれていますが、[RFC2518]の元の定義には、サーバーがリダイレクトされたリソースに新しいURIを提供する場所がありませんでした。この仕様では、この情報の「位置」要素を定義します（セクション14.9を参照）。サーバーは、この新しい要素をマルチステータスのリダイレクト応答で使用する必要があります。
Clients encountering redirected resources in Multi-Status MUST NOT rely on the 'location' element being present with a new URI. If the element is not present, the client MAY reissue the request to the individual redirected resource, because the response to that request can be redirected with a Location header containing the new URI.
マルチステータスでリダイレクトされたリソースに遭遇するクライアントは、新しいURIが存在する「場所」要素に依存してはなりません。要素が存在しない場合、クライアントは、新しいURIを含むロケーションヘッダーでそのリクエストへの応答をリダイレクトできるため、クライアントは個々のリダイレクトされたリソースにリクエストを再発行できます。
Sections 9.2.1, 9.1.2, 9.6.1, 9.8.3, and 9.9.2 define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses.
セクション9.2.1、9.1.2、9.6.1、9.8.3、および9.9.2は、マルチステータス応答で使用されるさまざまなステータスコードを定義します。この仕様は、これらの応答に表示される可能性のある他のステータスコードの意味を定義しません。
In this section, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). Note that all of the elements defined here may be extended according to the rules defined in Section 17. All elements defined here are in the "DAV:" namespace.
このセクションでは、各セクションの最終行では、[rec-xml]で定義された形式を使用して、要素タイプ宣言を示します。存在する「値」フィールドは、BNFを使用してXML要素の許容される内容のさらなる制限を指定します（つまり、PCDATA要素の値をさらに制限するため）。ここで定義されているすべての要素は、セクション17で定義されているルールに従って拡張される可能性があることに注意してください。ここで定義されているすべての要素は「DAV：」名前空間にあります。
Name: activelock
名前：ActiveLock
Purpose: Describes a lock on a resource.
目的：リソースのロックについて説明します。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?, lockroot)>
<！要素activelock（lockscope、locktype、depth、owner？、timeout？、locktoken？、lockroot）>
Name: allprop
名前：AllProp
Purpose: Specifies that all names and values of dead properties and the live properties defined by this document existing on the resource are to be returned.
目的：リソースに存在するこのドキュメントで定義されているデッドプロパティのすべての名前と値と、返されることを指定します。
<!ELEMENT allprop EMPTY >
Name: collection
名前：コレクション
Purpose: Identifies the associated resource as a collection. The DAV:resourcetype property of a collection resource MUST contain this element. It is normally empty but extensions may add sub-elements.
目的：関連するリソースをコレクションとして識別します。DAV：ResourceTypeコレクションリソースのプロパティには、この要素が含まれている必要があります。通常は空ですが、拡張機能はサブエレメントを追加する場合があります。
<!ELEMENT collection EMPTY >
Name: depth
名前：深さ
Purpose: Used for representing depth values in XML content (e.g., in lock information).
目的：XMLコンテンツの深さ値を表すために使用されます（例：ロック情報）。
Value: "0" | "1" | "infinity"
<!ELEMENT depth (#PCDATA) >
Name: error
名前：エラー
Purpose: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. In these cases, servers MAY return an XML response body with a document element of 'error', containing child elements identifying particular condition codes.
目的：エラーの応答、特に403 Forbiddenおよび409の競合には、何がうまくいかなかったかを示すために、より多くの情報が必要な場合があります。これらの場合、サーバーは、特定の条件コードを識別する子要素を含む「エラー」のドキュメント要素を持つXML応答本体を返す場合があります。
Description: Contains at least one XML element, and MUST NOT contain text or mixed content. Any element that is a child of the 'error' element is considered to be a precondition or postcondition code. Unrecognized elements MUST be ignored.
説明：少なくとも1つのXML要素が含まれており、テキストまたは混合コンテンツを含めてはなりません。「エラー」要素の子である要素は、前提条件または事後コードと見なされます。認識されていない要素は無視する必要があります。
<!ELEMENT error ANY >
Name: exclusive
名前：排他的
Purpose: Specifies an exclusive lock.
目的：排他的ロックを指定します。
<!ELEMENT exclusive EMPTY >
Name: href
名前：href
Purpose: MUST contain a URI or a relative reference.
目的：URIまたは相対参照を含める必要があります。
Description: There may be limits on the value of 'href' depending on the context of its use. Refer to the specification text where 'href' is used to see what limitations apply in each case.
説明：使用のコンテキストに応じて、「HREF」の価値に制限がある場合があります。「HREF」が使用されて、それぞれの場合にどのような制限が適用されるかを確認する仕様テキストを参照してください。
Value: Simple-ref
値：simple-ref
<!ELEMENT href (#PCDATA)>
Name: include
名前：include
Purpose: Any child element represents the name of a property to be included in the PROPFIND response. All elements inside an 'include' XML element MUST define properties related to the resource, although possible property names are in no way limited to those property names defined in this document or other standards. This element MUST NOT contain text or mixed content.
目的：任意の子要素は、Propfind Responseに含まれるプロパティの名前を表します。「含まれる」XML要素内のすべての要素は、リソースに関連するプロパティを定義する必要がありますが、可能なプロパティ名は、このドキュメントまたはその他の標準で定義されているプロパティ名に決して限定されません。この要素には、テキストまたは混合コンテンツが含まれてはなりません。
<!ELEMENT include ANY >
Name: location
名前：場所
Purpose: HTTP defines the "Location" header (see [RFC2616], Section 14.30) for use with some status codes (such as 201 and the 300 series codes). When these codes are used inside a 'multistatus' element, the 'location' element can be used to provide the accompanying Location header value.
目的：HTTPは、一部のステータスコード（201や300シリーズコードなど）で使用するために「場所」ヘッダー（[RFC2616]、セクション14.30を参照）を定義します。これらのコードが「Multistatus」要素内で使用される場合、「位置」要素を使用して、添付のロケーションヘッダー値を提供できます。
Description: Contains a single href element with the same value that would be used in a Location header.
説明：ロケーションヘッダーで使用される同じ値を持つ単一のHREF要素が含まれています。
<!ELEMENT location (href)>
Name: lockentry
名前：Lockentry
Purpose: Defines the types of locks that can be used with the resource.
目的：リソースで使用できるロックの種類を定義します。
<!ELEMENT lockentry (lockscope, locktype) >
Name: lockinfo
名前：lockinfo
Purpose: The 'lockinfo' XML element is used with a LOCK method to specify the type of lock the client wishes to have created.
目的：「lockinfo」XML要素は、クライアントが作成したいロックのタイプを指定するためにロックメソッドで使用されます。
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
Name: lockroot
名前：Lockroot
Purpose: Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request.
目的：ロックのルートURLが含まれています。これは、ロックリクエストでリソースがアドレス指定されたURLです。
Description: The href element contains the root of the lock. The server SHOULD include this in all DAV:lockdiscovery property values and the response to LOCK requests.
説明：HREF要素には、ロックのルートが含まれています。サーバーは、これをすべてのDAVに含める必要があります：Lock -Discoveryプロパティ値とロックリクエストへの応答。
<!ELEMENT lockroot (href) >
Name: lockscope
名前：Lockscope
Purpose: Specifies whether a lock is an exclusive lock, or a shared lock.
目的：ロックが排他的ロックなのか、共有ロックなのかを指定します。
<!ELEMENT lockscope (exclusive | shared) >
Name: locktoken
名前：LockToken
Purpose: The lock token associated with a lock.
目的：ロックに関連付けられたロックトークン。
Description: The href contains a single lock token URI, which refers to the lock.
説明：HREFには、ロックを指す単一のロックトークンURIが含まれています。
<!ELEMENT locktoken (href) >
Name: locktype
名前：LockType
Purpose: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.
目的：ロックのアクセスタイプを指定します。現在、この仕様では、1つのロックタイプ、つまり書き込みロックのみを定義しています。
<!ELEMENT locktype (write) >
Name: multistatus
名前：Multistatus
Purpose: Contains multiple response messages.
目的：複数の応答メッセージが含まれます。
Description: The 'responsedescription' element at the top level is used to provide a general message describing the overarching nature of the response. If this value is available, an application may use it instead of presenting the individual response descriptions contained within the responses.
説明：上部レベルの「ressiondesscription」要素は、応答の包括的な性質を説明する一般的なメッセージを提供するために使用されます。この値が利用可能な場合、応答内に含まれる個々の応答の説明を提示する代わりに、アプリケーションが使用する場合があります。
<!ELEMENT multistatus (response*, responsedescription?) >
Name: owner
名前：所有者
Purpose: Holds client-supplied information about the creator of a lock.
目的：ロックの作成者に関するクライアントが提供する情報を保持します。
Description: Allows a client to provide information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who created a lock. The value provided MUST be treated as a dead property in terms of XML Information Item preservation. The server MUST NOT alter the value unless the owner value provided by the client is empty. For a certain amount of interoperability between different client implementations, if clients have URI-formatted contact information for the lock creator suitable for user display, then clients SHOULD put those URIs in 'href' child elements of the 'owner' element.
説明：クライアントは、プリンシパル（電話番号や電子メールURIなど）に直接連絡するか、ロックを作成したプリンシパル（ホームページのURLなど）を発見するのに十分な情報を提供できます。提供される値は、XML情報アイテムの保存の観点から、死んだ財産として扱わなければなりません。クライアントが提供する所有者の値が空でない限り、サーバーは値を変更してはなりません。異なるクライアントの実装間の一定量の相互運用性については、クライアントがユーザーディスプレイに適したロック作成者のURI形式の連絡先情報を持っている場合、クライアントはそれらのURIを「所有者」要素の「HREF」子要素に配置する必要があります。
Extensibility: MAY be extended with child elements, mixed content, text content or attributes.
拡張性：子要素、混合コンテンツ、テキストコンテンツ、または属性で拡張される場合があります。
<!ELEMENT owner ANY >
Name: prop
名前：小道具
Purpose: Contains properties related to a resource.
目的：リソースに関連するプロパティが含まれています。
Description: A generic container for properties defined on resources. All elements inside a 'prop' XML element MUST define properties related to the resource, although possible property names are in no way limited to those property names defined in this document or other standards. This element MUST NOT contain text or mixed content.
説明：リソースで定義されたプロパティの一般的なコンテナ。「Prop」XML要素内のすべての要素は、リソースに関連するプロパティを定義する必要がありますが、可能なプロパティ名は、このドキュメントまたはその他の標準で定義されているプロパティ名に決して限定されません。この要素には、テキストまたは混合コンテンツが含まれてはなりません。
<!ELEMENT prop ANY >
Name: propertyupdate
名前：PropertyUpDate
Purpose: Contains a request to alter the properties on a resource.
目的：リソース上のプロパティを変更するリクエストが含まれています。
Description: This XML element is a container for the information required to modify the properties on the resource.
説明：このXML要素は、リソース上のプロパティを変更するために必要な情報のコンテナです。
<!ELEMENT propertyupdate (remove | set)+ >
Name: propfind Purpose: Specifies the properties to be returned from a PROPFIND method. Four special elements are specified for use with 'propfind': 'prop', 'allprop', 'include', and 'propname'. If 'prop' is used inside 'propfind', it MUST NOT contain property values.
名前：Propfind目的：Propfindメソッドから返されるプロパティを指定します。「Propfind」、「Prop」、「AllProp」、「Include」、および「Propname」という4つの特別な要素が指定されています。「Propfind」内で「Prop」が使用されている場合、プロパティ値を含めてはなりません。
<!ELEMENT propfind ( propname | (allprop, include?) | prop ) >
Name: propname
名前：Propname
Purpose: Specifies that only a list of property names on the resource is to be returned.
目的：リソース上のプロパティ名のリストのみが返されることを指定します。
<!ELEMENT propname EMPTY >
Name: propstat
名前：Propstat
Purpose: Groups together a prop and status element that is associated with a particular 'href' element.
目的：特定の「HREF」要素に関連付けられているプロップとステータス要素をグループ化します。
Description: The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies. The optional precondition/ postcondition element and 'responsedescription' text also apply to the properties named in 'prop'.
説明：PropStat XML要素には、1つのProp XML要素と1つのステータスXML要素を含める必要があります。Prop XML要素の内容は、ステータス要素の結果が適用されるプロパティの名前のみをリストする必要があります。オプションの前提条件/条件後要素と「ressuredesscription」テキストは、「Prop」に指定されたプロパティにも適用されます。
<!ELEMENT propstat (prop, status, error?, responsedescription?) >
Name: remove
名前：削除します
Purpose: Lists the properties to be removed from a resource.
目的：リソースから削除するプロパティをリストします。
Description: Remove instructs that the properties specified in prop should be removed. Specifying the removal of a property that does not exist is not an error. All the XML elements in a 'prop' XML element inside of a 'remove' XML element MUST be empty, as only the names of properties to be removed are required.
説明：削除プロップで指定されているプロパティを削除する必要があることを指示します。存在しないプロパティの削除を指定することは、エラーではありません。「削除」XML要素内の「Prop」XML要素内のすべてのXML要素は、削除するプロパティの名前のみが必要であるため、空でなければなりません。
<!ELEMENT remove (prop) >
Name: response
名前：応答
Purpose: Holds a single response describing the effect of a method on resource and/or its properties.
目的：リソースおよび/またはそのプロパティに対するメソッドの効果を説明する単一の応答を保持します。
Description: The 'href' element contains an HTTP URL pointing to a WebDAV resource when used in the 'response' container. A particular 'href' value MUST NOT appear more than once as the child of a 'response' XML element under a 'multistatus' XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by 'href'. There are, however, no requirements regarding ordering based on 'href' values. The optional precondition/postcondition element and 'responsedescription' text can provide additional information about this resource relative to the request or result.
説明：「HREF」要素には、「応答」コンテナで使用された場合、WebDAVリソースを指すHTTP URLが含まれています。特定の「HREF」値は、「MultiStatus」XML要素の下で「応答」XML要素の子として複数回表示してはなりません。この要件は、線形時間への対応のために処理コストを維持するために必要です。基本的に、これは「HREF」ですべての応答をグループ化するために検索しなければならないことを防ぎます。ただし、「HREF」値に基づく注文に関する要件はありません。オプションのPrecondition/Postcondition要素と「RessureDesscription」テキストは、要求または結果に対するこのリソースに関する追加情報を提供できます。
<!ELEMENT response (href, ((href*, status)|(propstat+)),
error?, responsedescription? , location?) >
Name: responsedescription
名前：ressionedescription
Purpose: Contains information about a status response within a Multi-Status.
目的：マルチステータス内のステータス応答に関する情報が含まれています。
Description: Provides information suitable to be presented to a user.
説明：ユーザーに提示するのに適した情報を提供します。
<!ELEMENT responsedescription (#PCDATA) >
Name: set
名前：セット
Purpose: Lists the property values to be set for a resource.
目的：リソースに設定するプロパティ値をリストします。
Description: The 'set' element MUST contain only a 'prop' element. The elements contained by the 'prop' element inside the 'set' element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists, then its value is replaced. Language tagging information appearing in the scope of the 'prop' element (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND.
説明：「セット」要素には、「プロップ」要素のみが含まれている必要があります。「セット」要素内の「プロップ」要素に含まれる要素は、リクエスト-URIによって識別されたリソースに設定されたプロパティの名前と値を指定する必要があります。プロパティが既に存在する場合、その値は置き換えられます。「Prop」要素の範囲（「XML：Lang」属性、存在する場合）の範囲に表示される言語タグ付け情報は、プロパティと一緒に持続的に保存され、その後Propfindを使用して取得できる必要があります。
<!ELEMENT set (prop) >
Name: shared
名前：共有
Purpose: Specifies a shared lock.
目的：共有ロックを指定します。
<!ELEMENT shared EMPTY >
Name: status
名前：ステータス
Purpose: Holds a single HTTP status-line.
目的：単一のHTTPステータスラインを保持します。
Value: status-line (defined in Section 6.1 of [RFC2616])
値：ステータスライン（[RFC2616]のセクション6.1で定義）
<!ELEMENT status (#PCDATA) >
Name: timeout
名前：タイムアウト
Purpose: The number of seconds remaining before a lock expires.
目的：ロックが切れる前に残っている秒数。
Value: TimeType (defined in Section 10.7)
値：タイムタイプ（セクション10.7で定義）
<!ELEMENT timeout (#PCDATA) >
Name: write
名前：書き込み
Purpose: Specifies a write lock.
目的：書き込みロックを指定します。
<!ELEMENT write EMPTY >
For DAV properties, the name of the property is also the same as the name of the XML element that contains its value. In the section below, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element).
DAVプロパティの場合、プロパティの名前は、その値を含むXML要素の名前と同じです。以下のセクションでは、各セクションの最終行では、[rec-xml]で定義された形式を使用して、要素タイプ宣言を示します。存在する「値」フィールドは、BNFを使用してXML要素の許容される内容のさらなる制限を指定します（つまり、PCDATA要素の値をさらに制限するため）。
A protected property is one that cannot be changed with a PROPPATCH request. There may be other requests that would result in a change to a protected property (as when a LOCK request affects the value of DAV:lockdiscovery). Note that a given property could be protected on one type of resource, but not protected on another type of resource.
保護されたプロパティは、プロップパッチリクエストで変更できないプロパティです。保護されたプロパティに変更される他の要求がある場合があります（ロック要求がDAVの値に影響する場合：Lock -Discovery）。特定のプロパティは、あるタイプのリソースで保護できますが、別のタイプのリソースでは保護されていないことに注意してください。
A computed property is one with a value defined in terms of a computation (based on the content and other properties of that resource, or even of some other resource). A computed property is always a protected property.
計算されたプロパティは、計算の観点から定義された値を持つものです（そのリソースのコンテンツやその他のプロパティ、さらには他のリソースに基づいています）。計算されたプロパティは常に保護されたプロパティです。
COPY and MOVE behavior refers to local COPY and MOVE operations.
動作をコピーして移動すると、ローカルコピーと移動操作を指します。
For properties defined based on HTTP GET response headers (DAV:get*), the header value could include LWS as defined in [RFC2616], Section 4.2. Server implementors SHOULD strip LWS from these values before using as WebDAV property values.
HTTP Get Responseヘッダー（DAV：Get*）に基づいて定義されているプロパティの場合、ヘッダー値には[RFC2616]、セクション4.2で定義されているLWSを含めることができます。サーバーの実装者は、WebDAVプロパティ値として使用する前に、これらの値からLWを削除する必要があります。
Name: creationdate
名前：CreationDate
Purpose: Records the time and date the resource was created.
目的：リソースが作成された時刻と日付を記録します。
Value: date-time (defined in [RFC3339], see the ABNF in Section 5.6.)
値：日付時間（[RFC3339]で定義され、セクション5.6のABNFを参照してください。）
Protected: MAY be protected. Some servers allow DAV:creationdate to be changed to reflect the time the document was created if that is more meaningful to the user (rather than the time it was uploaded). Thus, clients SHOULD NOT use this property in synchronization logic (use DAV:getetag instead).
保護：保護される場合があります。一部のサーバーでは、DAV：CreationDateを変更して、それがユーザーにとってより意味のある場合（アップロードされた時間ではなく）、ドキュメントが作成された時間を反映します。したがって、クライアントはこのプロパティを同期ロジックで使用しないでください（代わりにDAV：getEtagを使用してください）。
COPY/MOVE behavior: This property value SHOULD be kept during a MOVE operation, but is normally re-initialized when a resource is created with a COPY. It should not be set in a COPY.
動作のコピー/移動：このプロパティ値は、移動操作中に保持する必要がありますが、通常、リソースがコピーで作成された場合に再初期化されます。コピーに設定しないでください。
Description: The DAV:creationdate property SHOULD be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created. Servers that are incapable of persistently recording the creation date SHOULD instead leave it undefined (i.e. report "Not Found").
説明：DAV：CreationDateプロパティは、すべてのDAV準拠のリソースで定義する必要があります。存在する場合、リソースが作成された瞬間のタイムスタンプが含まれています。作成日を永続的に記録できないサーバーは、代わりに定義されていないままにしておく必要があります（つまり、レポート「見つかりません」）。
<!ELEMENT creationdate (#PCDATA) >
Name: displayname
名前：displayName
Purpose: Provides a name for the resource that is suitable for presentation to a user.
目的：ユーザーへのプレゼンテーションに適したリソースの名前を提供します。
Value: Any text.
値：任意のテキスト。
Protected: SHOULD NOT be protected. Note that servers implementing [RFC2518] might have made this a protected property as this is a new requirement.
保護：保護されるべきではありません。[RFC2518]を実装するサーバーは、これが新しい要件であるため、これを保護されたプロパティにした可能性があることに注意してください。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
動作のコピー/移動：このプロパティ値は、操作をコピーして移動する必要があります。
Description: Contains a description of the resource that is suitable for presentation to a user. This property is defined on the resource, and hence SHOULD have the same value independent of the Request-URI used to retrieve it (thus, computing this property based on the Request-URI is deprecated). While generic clients might display the property value to end users, client UI designers must understand that the method for identifying resources is still the URL. Changes to DAV:displayname do not issue moves or copies to the server, but simply change a piece of meta-data on the individual resource. Two resources can have the same DAV: displayname value even within the same collection.
説明：ユーザーへのプレゼンテーションに適したリソースの説明が含まれています。このプロパティはリソース上で定義されているため、それを取得するために使用されるリクエスト-URIとは独立して同じ値を持つ必要があります（したがって、リクエスト-URIに基づいてこのプロパティを計算することは非推奨です）。ジェネリッククライアントはエンドユーザーにプロパティ値を表示する場合がありますが、クライアントUIデザイナーは、リソースを識別する方法がまだURLであることを理解する必要があります。DAVの変更：DisplayNameは、サーバーへの動きやコピーを発行するのではなく、個々のリソースでメタデータを変更するだけです。2つのリソースには、同じコレクション内でもDisplayName値：DisplayName値があります。
<!ELEMENT displayname (#PCDATA) >
Name: getcontentlanguage
名前：GetContentLanguage
Purpose: Contains the Content-Language header value (from Section 14.12 of [RFC2616]) as it would be returned by a GET without accept headers.
目的：コンテンツ言語ヘッダー値（[RFC2616]のセクション14.12から）が含まれています。
Value: language-tag (language-tag is defined in Section 3.10 of [RFC2616])
値：言語タグ（言語タグは[RFC2616]のセクション3.10で定義されています）
Protected: SHOULD NOT be protected, so that clients can reset the language. Note that servers implementing [RFC2518] might have made this a protected property as this is a new requirement.
保護：クライアントが言語をリセットできるように、保護しないでください。[RFC2518]を実装するサーバーは、これが新しい要件であるため、これを保護されたプロパティにした可能性があることに注意してください。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
動作のコピー/移動：このプロパティ値は、操作をコピーして移動する必要があります。
Description: The DAV:getcontentlanguage property MUST be defined on any DAV-compliant resource that returns the Content-Language header on a GET.
説明：DAV：GetContentLanguageプロパティは、GETでコンテンツランゲージヘッダーを返すDAV準拠のリソースで定義する必要があります。
<!ELEMENT getcontentlanguage (#PCDATA) >
Name: getcontentlength
名前：getContentLength
Purpose: Contains the Content-Length header returned by a GET without accept headers.
目的：Get Accept Headerによって返されるコンテンツ長ヘッダーが含まれています。
Value: See Section 14.13 of [RFC2616].
値：[RFC2616]のセクション14.13を参照してください。
Protected: This property is computed, therefore protected.
保護：このプロパティは計算されるため、保護されています。
Description: The DAV:getcontentlength property MUST be defined on any DAV-compliant resource that returns the Content-Length header in response to a GET.
説明：DAV：GetContentLengthプロパティは、GETに応じてコンテンツレングスヘッダーを返すDAV準拠のリソースで定義する必要があります。
COPY/MOVE behavior: This property value is dependent on the size of the destination resource, not the value of the property on the source resource.
動作のコピー/移動：このプロパティ値は、ソースリソース上のプロパティの値ではなく、宛先リソースのサイズに依存します。
<!ELEMENT getcontentlength (#PCDATA) >
Name: getcontenttype
名前：getContentType
Purpose: Contains the Content-Type header value (from Section 14.17 of [RFC2616]) as it would be returned by a GET without accept headers.
目的：コンテンツタイプのヘッダー値（[RFC2616]のセクション14.17から）が含まれています。
Value: media-type (defined in Section 3.7 of [RFC2616])
値：メディアタイプ（[RFC2616]のセクション3.7で定義）
Protected: Potentially protected if the server prefers to assign content types on its own (see also discussion in Section 9.7.1).
保護：サーバーが独自のコンテンツタイプを割り当てることを好む場合、潜在的に保護されています（セクション9.7.1の説明も参照）。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
動作のコピー/移動：このプロパティ値は、操作をコピーして移動する必要があります。
Description: This property MUST be defined on any DAV-compliant resource that returns the Content-Type header in response to a GET.
説明：このプロパティは、GETに応じてコンテンツタイプのヘッダーを返すDAVに準拠したリソースで定義する必要があります。
<!ELEMENT getcontenttype (#PCDATA) >
Name: getetag
名前：geteTag
Purpose: Contains the ETag header value (from Section 14.19 of [RFC2616]) as it would be returned by a GET without accept headers.
目的：ETAGヘッダー値（[RFC2616]のセクション14.19から）が含まれています。
Value: entity-tag (defined in Section 3.11 of [RFC2616])
値：エンティティタグ（[RFC2616]のセクション3.11で定義）
Protected: MUST be protected because this value is created and controlled by the server.
保護：この値はサーバーによって作成および制御されるため、保護する必要があります。
COPY/MOVE behavior: This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. Also note the considerations in Section 8.8.
動作のコピー/移動：このプロパティ値は、ソースリソース上のプロパティの値ではなく、宛先リソースの最終的な状態に依存します。セクション8.8の考慮事項にも注意してください。
Description: The getetag property MUST be defined on any DAV-compliant resource that returns the Etag header. Refer to Section 3.11 of RFC 2616 for a complete definition of the semantics of an ETag, and to Section 8.6 for a discussion of ETags in WebDAV.
説明：getETAGプロパティは、ETAGヘッダーを返すDAV準拠のリソースで定義する必要があります。ETAGのセマンティクスの完全な定義については、RFC 2616のセクション3.11を参照し、WebDavのETAGの議論についてはセクション8.6を参照してください。
<!ELEMENT getetag (#PCDATA) >
Name: getlastmodified
名前：getLastModified
Purpose: Contains the Last-Modified header value (from Section 14.29 of [RFC2616]) as it would be returned by a GET method without accept headers.
目的：Last修正ヘッダー値（[RFC2616]のセクション14.29から）が含まれています。
Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616])
値：RFC1123-DATE（[RFC2616]のセクション3.3.1で定義）
Protected: SHOULD be protected because some clients may rely on the value for appropriate caching behavior, or on the value of the Last-Modified header to which this property is linked.
保護：一部のクライアントは、適切なキャッシュ動作の価値、またはこのプロパティがリンクされている永続的なヘッダーの価値に依存する可能性があるため、保護する必要があります。
COPY/MOVE behavior: This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this can be preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Note that since [RFC2616] requires clients to use ETags where provided, a server implementing ETags can count on clients using a much better mechanism than modification dates for offline synchronization or cache control. Also note the considerations in Section 8.8.
動作のコピー/移動：このプロパティ値は、宛先リソースの最後の変更日に依存し、ソースリソース上のプロパティの値ではありません。一部のサーバーの実装は、DAV：GetLastModified値のファイルシステム日付変更値を使用しており、HTTPラスト修飾値が変更される場合でも、これは移動中に保存できることに注意してください。[RFC2616]は、クライアントが提供された場合にETAGを使用する必要があるため、ETAGを実装するサーバーは、オフラインの同期またはキャッシュ制御の変更日よりもはるかに優れたメカニズムを使用してクライアントにカウントできることに注意してください。セクション8.8の考慮事項にも注意してください。
Description: The last-modified date on a resource SHOULD only reflect changes in the body (the GET responses) of the resource. A change in a property only SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body. The DAV: getlastmodified property MUST be defined on any DAV-compliant resource that returns the Last-Modified header in response to a GET.
説明：リソース上の最後の修正日は、リソースの身体（GET応答）の変化のみを反映する必要があります。クライアントは、既存のボディを上書きするタイミングを知るためにクライアントがラスト修正日に依存する場合があるため、プロパティの変更のみを変更してはなりません。DAV：getLastModifiedプロパティは、GETに応じてラスト変更されたヘッダーを返すDAVに準拠したリソースで定義する必要があります。
<!ELEMENT getlastmodified (#PCDATA) >
Name: lockdiscovery
名前：Lock -Discovery
Purpose: Describes the active locks on a resource
目的：リソース上のアクティブロックについて説明します
Protected: MUST be protected. Clients change the list of locks through LOCK and UNLOCK, not through PROPPATCH.
保護：保護する必要があります。クライアントは、プロップパッチではなく、ロックとロックを解除することでロックのリストを変更します。
COPY/MOVE behavior: The value of this property depends on the lock state of the destination, not on the locks of the source resource. Recall that locks are not moved in a MOVE operation.
動作のコピー/移動：このプロパティの値は、ソースリソースのロックではなく、宛先のロック状態によって異なります。移動操作でロックが移動されないことを思い出してください。
Description: Returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. Owner information MAY be omitted if it is considered sensitive. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there are one or more locks, an 'activelock' element appears for each lock on the resource. This property is NOT lockable with respect to write locks (Section 7).
説明：誰がロックを持っているのか、彼が持っているロックの種類、タイムアウトのタイプとタイムアウトに残る時間、および関連するロックトークンのリストを返します。所有者の情報は、敏感であると見なされる場合は省略される場合があります。ロックがないが、サーバーがロックをサポートしている場合、プロパティは存在しますが、ゼロの「ActiveLock」要素が含まれます。1つ以上のロックがある場合、リソース上の各ロックに「ActiveLock」要素が表示されます。このプロパティは、書き込みロックに関してロックできません（セクション7）。
<!ELEMENT lockdiscovery (activelock)* >
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Length: xxxx
Content-Type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D='DAV:'>
<D:prop><D:lockdiscovery/></D:prop>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://www.example.com/container/</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
This resource has a single exclusive write lock on it, with an infinite timeout.
このリソースには、無限のタイムアウトを備えた単一の排他的な書き込みロックがあります。
Name: resourcetype
名前：ResourceType
Purpose: Specifies the nature of the resource.
目的：リソースの性質を指定します。
Protected: SHOULD be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), not by PROPPATCH.
保護：保護する必要があります。リソースタイプは、通常、プロップパッチではなく、リソース（mkcol vs put）を作成する操作を通じて決定されます。
COPY/MOVE behavior: Generally a COPY/MOVE of a resource results in the same type of resource at the destination.
動作のコピー/移動：通常、リソースのコピー/移動により、目的地の同じタイプのリソースが得られます。
Description: MUST be defined on all DAV-compliant resources. Each child element identifies a specific type the resource belongs to, such as 'collection', which is the only resource type defined by this specification (see Section 14.3). If the element contains the 'collection' child element plus additional unrecognized elements, it should generally be treated as a collection. If the element contains no recognized child elements, it should be treated as a non-collection resource. The default value is empty. This element MUST NOT contain text or mixed content. Any custom child element is considered to be an identifier for a resource type.
説明：すべてのDAVに準拠したリソースで定義する必要があります。各子要素は、この仕様で定義される唯一のリソースタイプである「コレクション」など、リソースが属する特定のタイプを識別します（セクション14.3を参照）。要素に「コレクション」の子要素と追加の認識されていない要素が含まれている場合、一般にコレクションとして扱う必要があります。要素に認識された子要素が含まれていない場合、非収集リソースとして扱う必要があります。デフォルト値は空です。この要素には、テキストまたは混合コンテンツが含まれてはなりません。カスタムチャイルド要素は、リソースタイプの識別子と見なされます。
Example: (fictional example to show extensibility)
例：（拡張性を示す架空の例）
<x:resourcetype xmlns:x="DAV:">
<x:collection/>
<f:search-results xmlns:f="http://www.example.com/ns"/>
</x:resourcetype>
Name: supportedlock
名前：supportedlock
Purpose: To provide a listing of the lock capabilities supported by the resource.
目的：リソースでサポートされているロック機能のリストを提供する。
Protected: MUST be protected. Servers, not clients, determine what lock mechanisms are supported.
保護：保護する必要があります。クライアントではなくサーバーが、どのロックメカニズムがサポートされているかを決定します。
COPY/MOVE behavior: This property value is dependent on the kind of locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at the destination.
動作のコピー/移動：このプロパティ値は、ソースリソースのプロパティの値ではなく、目的地でサポートされるロックの種類に依存します。目的地にコピーしようとするサーバーは、このプロパティを目的地に設定しようとしないでください。
Description: Returns a listing of the combinations of scope and access types that may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls, so a server is not required to provide information the client is not authorized to see. This property is NOT lockable with respect to write locks (Section 7).
説明：リソースのロックリクエストで指定される可能性のあるスコープとアクセスタイプの組み合わせのリストを返します。実際のコンテンツ自体はアクセス制御によって制御されているため、サーバーはクライアントが確認する権限を与えられていない情報を提供する必要はありません。このプロパティは、書き込みロックに関してロックできません（セクション7）。
<!ELEMENT supportedlock (lockentry)* >
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.example.com
Content-Length: xxxx
Content-Type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop><D:supportedlock/></D:prop>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
As introduced in Section 8.7, extra information on error conditions can be included in the body of many status responses. This section makes requirements on the use of the error body mechanism and introduces a number of precondition and postcondition codes.
セクション8.7で導入されているように、エラー条件に関する追加情報は、多くのステータス応答の本体に含めることができます。このセクションでは、エラーボディメカニズムの使用に関する要件を作成し、多くの前提条件と事後コードを導入します。
A "precondition" of a method describes the state of the server that must be true for that method to be performed. A "postcondition" of a method describes the state of the server that must be true after that method has been completed.
メソッドの「前提条件」は、そのメソッドを実行するために真でなければならないサーバーの状態を説明します。メソッドの「条件」は、そのメソッドが完了した後に真でなければならないサーバーの状態を説明しています。
Each precondition and postcondition has a unique XML element associated with it. In a 207 Multi-Status response, the XML element MUST appear inside an 'error' element in the appropriate 'propstat or 'response' element depending on whether the condition applies to one or more properties or to the resource as a whole. In all other error responses where this specification's 'error' body is used, the precondition/postcondition XML element MUST be returned as the child of a top-level 'error' element in the response body, unless otherwise negotiated by the request, along with an appropriate response status. The most common response status codes are 403 (Forbidden) if the request should not be repeated because it will always fail, and 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. The 'error' element MAY contain child elements with specific error information and MAY be extended with any custom child elements.
各前提条件と事後条件には、それに関連付けられた一意のXML要素があります。207マルチステータス応答では、XML要素は、条件が1つ以上のプロパティまたはリソース全体に適用されるかどうかに応じて、適切な「プロップスタットまたは「応答」要素の「エラー」要素内に表示される必要があります。この仕様の「エラー」本文が使用される他のすべてのエラー応答では、リクエストによって特に交渉されない限り、応答本体のトップレベルの「エラー」要素の子として、前提条件/ポストコンディションXML要素を返す必要があります。適切な応答ステータス。最も一般的な応答ステータスコードは、常に失敗するためにリクエストを繰り返さない場合は403（禁止）、ユーザーが競合を解決してリクエストを再提出できると予想される場合は409（競合）です。「エラー」要素には、特定のエラー情報を持つ子要素が含まれている場合があり、カスタムチャイルド要素で拡張できます。
This mechanism does not take the place of using a correct numeric status code as defined here or in HTTP, because the client must always be able to take a reasonable course of action based only on the numeric code. However, it does remove the need to define new numeric codes. The new machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions, so naturally, any group defining a new condition code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups.
このメカニズムは、ここまたはHTTPで定義されている正しい数値ステータスコードを使用することに代わりはありません。クライアントは、数値コードのみに基づいて常に合理的なアクションコースを取得できる必要があるためです。ただし、新しい数値コードを定義する必要性は削除されます。この目的に使用される新しいマシン読み取り可能なコードは、前提条件と事後条件として分類されるXML要素であるため、当然、新しい条件コードを定義するグループは独自の名前空間を使用できます。いつものように、「DAV：」名前空間は、IETFチャーター付きWebDavワーキンググループが使用するために予約されています。
A server supporting this specification SHOULD use the XML error whenever a precondition or postcondition defined in this document is violated. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank. However, a server MAY instead use a custom condition code and other supporting text, because even when clients do not automatically recognize condition codes, they can be quite useful in interoperability testing and debugging.
この仕様をサポートするサーバーは、このドキュメントで定義されている前提条件または事後条件に違反した場合はいつでもXMLエラーを使用する必要があります。このドキュメントで指定されていないエラー条件の場合、サーバーは単に適切な数値ステータスを選択し、応答ボディを空白のままにすることができます。ただし、サーバーは代わりにカスタム条件コードやその他のサポートテキストを使用する場合があります。クライアントが条件コードを自動的に認識しない場合でも、相互運用性のテストとデバッグに非常に役立つ可能性があるためです。
Example - Response with precondition code
例-Preconditionコードを使用した応答
>>Response
>>応答
HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:lock-token-submitted>
<D:href>/workspace/webdav/</D:href>
</D:lock-token-submitted>
</D:error>
In this example, a client unaware of a depth-infinity lock on the parent collection "/workspace/webdav/" attempted to modify the collection member "/workspace/webdav/proposal.doc".
この例では、クライアントは、親コレクション「/workspace/webdav/「コレクションメンバー」を変更しようとした「/workspace/webdav/proposal.doc」の[/workspace/webdav/"の深さの内容ロックに気付いていません。
Some other useful preconditions and postconditions have been defined in other specifications extending WebDAV, such as [RFC3744] (see particularly Section 7.1.1), [RFC3253], and [RFC3648].
[RFC3744]（特にセクション7.1.1を参照）、[RFC3253]、[RFC3648]など、WebDAVを拡張する他の仕様では、他の有用な前提条件と事後条件が定義されています。
All these elements are in the "DAV:" namespace. If not specified otherwise, the content for each condition's XML element is defined to be empty.
これらの要素はすべて「DAV：」名前空間にあります。特に指定されていない場合、各条件のXML要素のコンテンツは空であると定義されています。
Name: lock-token-matches-request-uri
名前：Lock-Token-Matches-Request-Uri
Use with: 409 Conflict
使用：409競合
Purpose: (precondition) -- A request may include a Lock-Token header to identify a lock for the UNLOCK method. However, if the Request-URI does not fall within the scope of the lock identified by the token, the server SHOULD use this error. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
目的：（前提条件） - リクエストには、ロック解除方法のロックを識別するロックトークンヘッダーが含まれる場合があります。ただし、リクエスト-URIがトークンによって識別されたロックの範囲内に該当しない場合、サーバーはこのエラーを使用する必要があります。ロックには、リクエスト-URIが含まれていないスコープがあるか、ロックが消えた可能性があるか、トークンが無効になる可能性があります。
Name: lock-token-submitted (precondition)
名前：ロックトークンサブミット（前提条件）
Use with: 423 Locked
使用：423ロックされています
Purpose: The request could not succeed because a lock token should have been submitted. This element, if present, MUST contain at least one URL of a locked resource that prevented the request. In cases of MOVE, COPY, and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource made the request fail -- but the server is only responsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all.
目的：ロックトークンが提出されるべきであるため、リクエストは成功できませんでした。この要素は、存在する場合、要求を防ぐロックされたリソースの少なくとも1つのURLを含める必要があります。コレクションロックが関与している場所の移動、コピー、削除の場合、クライアントがどのロックされたリソースがリクエストを失敗させたかを見つけることは困難ですが、サーバーはそのようなロックされたリソースの1つのみを返す責任があります。サーバーは、すべてを知っている場合、リクエストが成功するのを妨げるすべてのロックされたリソースを返す場合があります。
<!ELEMENT lock-token-submitted (href+) >
Name: no-conflicting-lock (precondition)
名前：紛争なし（前提条件）
Use with: Typically 423 Locked
使用：通常423ロックされています
Purpose: A LOCK request failed due the presence of an already existing conflicting lock. Note that a lock can be in conflict although the resource to which the request was directed is only indirectly locked. In this case, the precondition code can be used to inform the client about the resource that is the root of the conflicting lock, avoiding a separate lookup of the "lockdiscovery" property.
目的：既存の矛盾するロックが存在するため、ロック要求が失敗しました。要求が指示されたリソースは間接的にロックされているだけですが、ロックは競合する可能性があることに注意してください。この場合、前提条件コードを使用して、「ロックディスコビリー」プロパティの個別の検索を回避して、競合するロックのルートであるリソースについてクライアントに通知できます。
<!ELEMENT no-conflicting-lock (href)* >
Name: no-external-entities
名前：external-entitiesなし
Use with: 403 Forbidden
使用：403禁止
Purpose: (precondition) -- If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error.
目的：（前提条件） - リクエスト本体に外部エンティティが含まれているためにサーバーがクライアント要求を拒否した場合、サーバーはこのエラーを使用する必要があります。
Name: preserved-live-properties
名前：保存されたlive-properties
Use with: 409 Conflict
使用：409競合
Purpose: (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server only supports some live properties in some parts of the repository, or simply has an internal error.
目的：（ポストコンディション） - サーバーは、それ以外の場合はValid Moveまたはコピーリクエストを受信しましたが、宛先で同じ動作でライブプロパティを維持することはできません。サーバーは、リポジトリの一部の一部のライブプロパティのみをサポートするか、単に内部エラーがある場合があります。
Name: propfind-finite-depth
名前：Propfind-finite-Depth
Use with: 403 Forbidden
使用：403禁止
Purpose: (precondition) -- This server does not allow infinite-depth PROPFIND requests on collections.
目的：（前提条件） - このサーバーでは、コレクションに関する無限のプロップファインドリクエストが許可されていません。
Name: cannot-modify-protected-property
名前：Modify-Modify-Propertyできません
Use with: 403 Forbidden
使用：403禁止
Purpose: (precondition) -- The client attempted to set a protected property in a PROPPATCH (such as DAV:getetag). See also [RFC3253], Section 3.12.
目的：（前提条件） - クライアントは、保護されたプロパティをプロップパッチに設定しようとしました（DAV：getEtagなど）。[RFC3253]、セクション3.12も参照してください。
The XML namespace extension ([REC-XML-NAMES]) is used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the "DAV:" namespace SHOULD NOT be used in the request or response body unless that XML element is explicitly defined in an IETF RFC reviewed by a WebDAV working group.
For WebDAV to be both extensible and backwards-compatible, both clients and servers need to know how to behave when unexpected or unrecognized command extensions are received. For XML processing, this means that clients and servers MUST process received XML documents as if unexpected elements and attributes (and all children of unrecognized elements) were not there. An unexpected element or attribute includes one that may be used in another context but is not expected here. Ignoring such items for purposes of processing can of course be consistent with logging all information or presenting for debugging.
webdavが拡張可能であり、後方互換性の両方であるためには、クライアントとサーバーの両方が、予期しないまたは認識されていないコマンド拡張機能が受信されたときに動作する方法を知る必要があります。XML処理の場合、これは、クライアントとサーバーが受信したXMLドキュメントを処理する必要があることを意味します。予期しない要素または属性には、別のコンテキストで使用される可能性のある要素が含まれますが、ここでは予想されません。処理の目的でそのようなアイテムを無視することは、もちろんすべての情報を記録したり、デバッグのために提示したりすることと一致する可能性があります。
This restriction also applies to the processing, by clients, of DAV property values where unexpected XML elements SHOULD be ignored unless the property's schema declares otherwise.
この制限は、プロパティのスキーマが別の方法で宣言しない限り、予期しないXML要素を無視する必要があるDAVプロパティ値の処理にも適用されます。
This restriction does not apply to setting dead DAV properties on the server where the server MUST record all XML elements.
この制限は、サーバーがすべてのXML要素を記録する必要があるサーバーにDead 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がエンティティボディのコンテンツタイプである場合、たとえば、プットの本体として使用する場合です。
Processing instructions in XML SHOULD be ignored by recipients. Thus, specifications extending WebDAV SHOULD NOT use processing instructions to define normative behavior.
XMLの処理手順は、受信者が無視する必要があります。したがって、WebDAVを拡張する仕様は、規範的な動作を定義するために処理命令を使用してはなりません。
XML DTD fragments are included for all the XML elements defined in this specification. However, correct XML will not be valid according to any DTD due to namespace usage and extension rules. In particular:
XML DTDフラグメントは、この仕様で定義されているすべてのXML要素に含まれています。ただし、名前空間の使用法と拡張ルールのため、正しいXMLはDTDに従って有効ではありません。特に：
o Elements (from this specification) are in the "DAV:" namespace,
o 要素（この仕様から）は「dav：」の名前空間にあります。
o Element ordering is irrelevant unless otherwise stated,
o 特に明記しない限り、要素の順序付けは無関係です、
o Extension attributes MAY be added,
o 拡張属性が追加される場合があります、
o For element type definitions of "ANY", the normative text definition for that element defines what can be in it and what that means.
o 要素タイプの「any」の定義の場合、その要素の規範的なテキスト定義は、その要素に何ができるか、それが何を意味するかを定義します。
o For element type definitions of "#PCDATA", extension elements MUST NOT be added.
o 「#pcdata」の要素タイプ定義の場合、拡張要素を追加してはなりません。
o For other element type definitions, including "EMPTY", extension elements MAY be added.
o 「空」を含む他の要素タイプ定義の場合、拡張要素が追加される場合があります。
Note that this means that elements containing elements cannot be extended to contain text, and vice versa.
これは、要素を含む要素をテキストに含めるように拡張できないことを意味することに注意してください。
With DTD validation relaxed by the rules above, the constraints described by the DTD fragments are normative (see for example Appendix A). A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD.
上記のルールによってDTD検証が緩和されると、DTDフラグメントによって記述された制約は規範的です（たとえば、付録Aを参照）。XMLボディを使用したWebDAVメッセージの受信者は、ハードコーディングまたは動的に宣言されたDTDに従ってXMLドキュメントを検証してはなりません。
Note that this section describes backwards-compatible extensibility rules. There might also be times when an extension is designed not to be backwards-compatible, for example, defining an extension that reuses an XML element defined in this document but omitting one of the child elements required by the DTDs in this specification.
このセクションでは、逆互換の拡張性ルールについて説明していることに注意してください。また、このドキュメントで定義されているXML要素を再利用するが、この仕様でDTDに必要な子要素の1つを省略する拡張機能を定義するなど、拡張機能が後方互換ではないように設計されている場合もあります。
A DAV-compliant resource can advertise several classes of compliance. A client can discover the compliance classes of a resource by executing OPTIONS on the resource and examining the "DAV" header which is returned. Note particularly that resources, rather than servers, are spoken of as being compliant. That is because theoretically some resources on a server could support different feature sets. For example, a server could have a sub-repository where an advanced feature like versioning was supported, even if that feature was not supported on all sub-repositories.
DAVに準拠したリソースは、複数のクラスのコンプライアンスを宣伝できます。クライアントは、リソース上のオプションを実行し、返される「DAV」ヘッダーを調べることにより、リソースのコンプライアンスクラスを発見できます。特に、サーバーではなくリソースが準拠していると話されていることに注意してください。それは、理論的にはサーバー上の一部のリソースがさまざまな機能セットをサポートできるためです。たとえば、サーバーには、すべてのサブレポジトリーでその機能がサポートされていなくても、バージョンのような高度な機能がサポートされているサブレポジトリを持つことができます。
Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV-compliant resources, clients, and proxies MUST be compliant with [RFC2616].
このドキュメントでは、HTTP/1.1プロトコルへの拡張が記述されているため、すべてのすべてのDAVに準拠したリソース、クライアント、およびプロキシは[RFC2616]に準拠する必要があります。
A resource that is class 2 or class 3 compliant must also be class 1 compliant.
クラス2またはクラス3に準拠したリソースも、クラス1に準拠している必要があります。
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document.
クラス1に準拠したリソースは、このドキュメントのすべてのセクションですべての「必須」要件を満たす必要があります。
Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
クラス1に準拠したリソースは、Optionsメソッドへのすべての応答に関するDAVヘッダーの値「1」を少なくとも返す必要があります。
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the DAV:supportedlock property, the DAV: lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class 2 compliant resource SHOULD also support the Timeout request header and the 'owner' XML element.
クラス2準拠のリソースは、すべてのクラス1の要件を満たし、ロックメソッド、DAV：SupportEdLockプロパティ、DAV：Lock-Discoveryプロパティ、タイムアウト応答ヘッダー、ロックトークンリクエストヘッダーをサポートする必要があります。クラス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.
クラス2準拠のリソースは、Optionsメソッドへのすべての応答のDAVヘッダーの値「1」と「2」を少なくとも返す必要があります。
A resource can explicitly advertise its support for the revisions to [RFC2518] made in this document. Class 1 MUST be supported as well. Class 2 MAY be supported. Advertising class 3 support in addition to class 1 and 2 means that the server supports all the requirements in this specification. Advertising class 3 and class 1 support, but not class 2, means that the server supports all the requirements in this specification except possibly those that involve locking support.
リソースは、このドキュメントで作成された[RFC2518]の改訂に対するサポートを明示的に宣伝できます。クラス1もサポートする必要があります。クラス2がサポートされる場合があります。クラス1と2に加えて、クラス3のサポートは、サーバーがこの仕様のすべての要件をサポートすることを意味します。クラス2ではなく、クラス3とクラス1のサポートを広告は、サポートのロックを伴うものを除き、サーバーがこの仕様のすべての要件をサポートすることを意味します。
Example:
例：
DAV: 1, 3
DAV：1、3
In the realm of internationalization, this specification complies with the IETF Character Set Policy [RFC2277]. In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [RFC3629] and UTF-16 [RFC2781] encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header (defined in [RFC3023]), as well as XML charset declarations.
国際化の領域では、この仕様はIETF文字セットポリシー[RFC2277]に準拠しています。この仕様では、プロパティの値のいずれか、または応答エンティティボディで返されるエラーメッセージのいずれかに人間が読めるフィールドを見つけることができます。どちらの場合も、人間の読み取り可能なコンテンツはXMLを使用してエンコードされます。XMLは、文字セットのタグ付けとエンコードの明示的な規定があり、XMLプロセッサがUTF-8 [RFC3629]およびUTF-16を使用して、少なくともエンコードされたXML要素を読み取る必要があります。[RFC2781] ISO 10646多言語面のエンコーディング。この仕様のXML例は、コンテンツタイプのヘッダー（[RFC3023]で定義）のcharsetパラメーターの使用とXML charset宣言を示しています。
XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. The "xml:lang" attribute appears on an XML element to identify the language of its content and attributes. See [REC-XML] for definitions of values and scoping.
XMLは、特定のXML要素の内容の言語を指定するための言語タグ機能も提供します。「XML：Lang」属性はXML要素に表示され、そのコンテンツと属性の言語を識別します。値とスコープの定義については、[rec-xml]を参照してください。
WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" [RFC3023] for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header.
WebDAVアプリケーションは、XML仕様の文字セットのタグ付け、文字セットエンコード、および言語タグ機能をサポートする必要があります。WebDAVアプリケーションの実装者は、XMLトランスポートに使用するMIMEメディアタイプ、およびコンテンツタイプのヘッダーのcharSetパラメーターの使用について、「XMLメディアタイプ」[RFC3023]を読むことを強くお勧めします。
Names used within this specification fall into four categories: names of protocol elements such as methods and headers, names of XML elements, names of properties, and names of conditions. Naming of protocol elements follows the precedent of HTTP, using English names encoded in US-ASCII for methods and headers. Since these protocol elements are not visible to users, and are simply long token identifiers, they do not need to support multiple languages. Similarly, the names of XML elements used in this specification are not visible to the user and hence do not need to support multiple languages.
この仕様内で使用される名前は、メソッドとヘッダーなどのプロトコル要素の名前、XML要素の名前、プロパティの名前、条件の名前の4つのカテゴリに分類されます。プロトコル要素の命名は、HTTPの先例に続き、メソッドとヘッダーのためにUS-ASCIIでエンコードされた英語名を使用します。これらのプロトコル要素はユーザーには見えず、単に長いトークン識別子であるため、複数の言語をサポートする必要はありません。同様に、この仕様で使用されているXML要素の名前はユーザーには表示されないため、複数の言語をサポートする必要はありません。
WebDAV property names are qualified XML names (pairs of XML namespace name and local name). Although some applications (e.g., a generic property viewer) will display property names directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name and namespace to a human-readable field when displaying the property name to a user. It is only in the case where the set of properties is not known ahead of time that an application need display a property name to a user. We recommend that applications provide human-readable property names wherever feasible.
WebDavプロパティ名は、適格なXML名（XMLネームスペース名とローカル名のペア）です。一部のアプリケーション（たとえば、一般的なプロパティビューア）はプロパティ名をユーザーに直接表示しますが、典型的なアプリケーションは固定されたプロパティセットを使用し、プロパティ名と名前空間から人間へのマッピングを提供することが期待されます。ユーザーにプロパティ名を表示するときの読み取り可能なフィールド。プロパティのセットが事前に知られていない場合にのみ、アプリケーションがユーザーにプロパティ名を表示する必要があることが必要です。アプリケーションは、実行可能な場所に人間の読み取り可能なプロパティ名を提供することをお勧めします。
For error reporting, we follow the convention of HTTP/1.1 status codes, including with each status code a short, English description of the code (e.g., 423 (Locked)). While the possibility exists that a poorly crafted user agent would display this message to a user, internationalized applications will ignore this message, and display an appropriate message in the user's language and character set.
エラーレポートの場合、各ステータスコードを含むHTTP/1.1ステータスコードの慣習に従って、コードの短い英語説明（423（ロック）など）に従います。作成されていないユーザーエージェントがこのメッセージをユーザーに表示する可能性は存在しますが、国際化されたアプリケーションはこのメッセージを無視し、ユーザーの言語とキャラクターセットに適切なメッセージを表示します。
Since interoperation of clients and servers does not require locale information, this specification does not specify any mechanism for transmission of this information.
クライアントとサーバーの相互操作はロケール情報を必要としないため、この仕様ではこの情報の送信のメカニズムは指定されていません。
This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware.
このセクションは、WebDAVアプリケーションが注意する必要があるセキュリティの意味に関する詳細な問題について提供されています。
All of the security considerations of HTTP/1.1 (discussed in [RFC2616]) and XML (discussed in [RFC3023]) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.
HTTP/1.1（[RFC2616]で説明）およびXML（[RFC3023]で説明）のセキュリティに関するすべての考慮事項もWebDavに適用されます。さらに、リモートオーサリングに固有のセキュリティリスクは、より強力な認証テクノロジーを必要とし、いくつかの新しいプライバシーの懸念を導入し、サーバーの設計が不十分であるための危険性を高める可能性があります。これらの問題については、以下に詳しく説明しています。
Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication.
オーサリングに重点が置かれているため、WebDAVサーバーは認証テクノロジーを使用して、ネットワークリソースへのアクセスだけでなく、リソースの整合性も保護する必要があります。さらに、ロック機能の導入には、認証をサポートする必要があります。
A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send a Basic authentication challenge in a WWW-Authenticate header unless the connection is secure. An example of a secure connection would be a Transport Layer Security (TLS) connection employing a strong cipher suite and server authentication.
不安定なチャネルでクリアで送信されたパスワードは、パスワードを傍受するためにリソースのアクセシビリティと整合性を保護するための不十分な手段です。HTTP/1.1の基本認証は、パスワードの本質的にクリアなテキスト送信を実行するため、接続が安全でない限り、WebDavクライアントをサーバーに認証するために基本認証を使用してはなりません。さらに、WebDAVサーバーは、接続が安全でない限り、www-authenticateヘッダーに基本的な認証チャレンジを送信してはなりません。安全な接続の例は、強力な暗号スイートとサーバー認証を採用するトランスポートレイヤーセキュリティ（TLS）接続です。
WebDAV applications MUST support the Digest authentication scheme [RFC2617]. Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication that is useful in a wide range of scenarios.
WebDAVアプリケーションは、ダイジェスト認証スキーム[RFC2617]をサポートする必要があります。Digest認証は、通信の両当事者が共有された秘密、パスワードを知っていることを確認するため、明確な消化認証でその秘密を送信することなく、基本認証に固有のセキュリティ問題を回避しながら、広範囲に役立つ認証レベルを提供します。シナリオの範囲。
Denial-of-service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial-of-service attacks on every part of a system's resources.
サービス拒否攻撃は、WebDavサーバーにとって特別な懸念事項です。WebDav Plus HTTPは、システムのリソースのあらゆる部分に対するサービス拒否攻撃を可能にします。
o The underlying storage can be attacked by PUTting extremely large files.
o 基礎となるストレージは、非常に大きなファイルを配置することで攻撃できます。
o Asking for recursive operations on large collections can attack processing time.
o 大規模なコレクションで再帰的な操作を要求すると、処理時間を攻撃できます。
o Making multiple pipelined requests on multiple connections can attack network connections.
o 複数の接続で複数のパイプラインリクエストを作成すると、ネットワーク接続を攻撃できます。
WebDAV servers need to be aware of the possibility of a denial-of-service attack at all levels. The proper response to such an attack MAY be to simply drop the connection. Or, if the server is able to make a response, the server MAY use a 400-level status request such as 400 (Bad Request) and indicate why the request was refused (a 500- level status response would indicate that the problem is with the server, whereas unintentional DoS attacks are something the client is capable of remedying).
WebDAVサーバーは、すべてのレベルでサービス拒否攻撃の可能性を認識する必要があります。このような攻撃に対する適切な応答は、単に接続をドロップすることです。または、サーバーが応答を行うことができる場合、サーバーは400（悪い要求）などの400レベルのステータス要求を使用し、リクエストが拒否された理由を示します（500レベルのステータス応答は、問題があることを示しますサーバーは、意図しないDOS攻撃はクライアントが是正できるものです）。
WebDAV provides, through the PROPFIND method, a mechanism for listing the member resources of a collection. This greatly diminishes the effectiveness of security or privacy techniques that rely only on the difficulty of discovering the names of network resources. Users of WebDAV servers are encouraged to use access control techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.
WebDavは、Propfindメソッドを通じて、コレクションのメンバーリソースをリストするメカニズムを提供します。これにより、ネットワークリソースの名前を発見することの難しさのみに依存するセキュリティまたはプライバシーテクニックの有効性が大幅に低下します。WebDAVサーバーのユーザーは、リソース名の相対的な不明瞭さに依存するのではなく、リソースへの不要なアクセスを防ぐために、アクセス制御手法を使用することをお勧めします。
When submitting a lock request, a user agent may also submit an 'owner' XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a DAV: lockdiscovery property on the resource, and can be used by other collaborators to begin negotiation over access to the resource. However, in many cases, this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the DAV:lockdiscovery property as appropriate. Furthermore, user agents SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
ロックリクエストを送信する場合、ユーザーエージェントは、ロックを取り出した人の連絡先情報を提供する「所有者」XMLフィールドを送信することもできます（ロボットではなく、ロックを取り除いている人の場合）。この連絡先情報は、DAV：Lock -Discoveryプロパティにリソースに保存され、他の協力者がリソースへのアクセスをめぐる交渉を開始することができます。ただし、多くの場合、この連絡先情報は非常にプライベートである可能性があり、広く普及するべきではありません。サーバーは、必要に応じて、DAV：Lock -Discoveryプロパティへの読み取りアクセスを制限する必要があります。さらに、ユーザーエージェントは、連絡先情報が送信されるかどうか、および連絡先情報が送信された場合、どの情報が送信されるかを正確に制御するかどうかを制御する必要があります。
Since property values are typically used to hold information such as the author of a document, there is the possibility that privacy concerns could arise stemming from widespread access to a resource's property data. To reduce the risk of inadvertent release of private information via properties, servers are encouraged to develop access control mechanisms that separate read access to the resource body and read access to the resource's properties. This allows a user to control the dissemination of their property data without overly restricting access to the resource's contents.
プロパティ値は通常、ドキュメントの著者などの情報を保持するために使用されるため、プライバシーの懸念がリソースのプロパティデータへの広範なアクセスに起因する可能性があります。プロパティを介して個人情報の不注意なリリースのリスクを減らすために、サーバーは、リソースボディへの読み取りアクセスを分離し、リソースのプロパティへのアクセスを読み取るアクセス制御メカニズムを開発することをお勧めします。これにより、ユーザーはリソースのコンテンツへのアクセスを過度に制限することなく、プロパティデータの普及を制御できます。
XML supports a facility known as "external entities", defined in Section 4.2.2 of [REC-XML], which instructs an XML processor to retrieve and include additional XML. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non-validating XML, such as the XML used in this specification, including an external XML entity is not required by XML. However, XML does state that an XML processor may, at its discretion, include the external XML entity.
XMLは、[Rec-XML]のセクション4.2.2で定義されている「外部エンティティ」と呼ばれる施設をサポートしており、XMLプロセッサに追加のXMLを取得して含めるよう指示します。外部XMLエンティティを使用して、XMLドキュメントに関連付けられたドキュメントタイプ宣言（DTD）を追加または変更できます。外部XMLエンティティを使用して、XMLドキュメントのコンテンツ内にXMLを含めることもできます。外部XMLエンティティを含むこの仕様で使用されるXMLなど、非検証XMLの場合、XMLでは必要ありません。ただし、XMLは、XMLプロセッサには、その裁量により、外部XMLエンティティが含まれる場合があると述べています。
External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case, significantly modifying its semantics or exposing the XML processor to the security risks discussed in [RFC3023]. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy. If a server chooses not to handle external XML entities, it SHOULD respond to requests containing external entities with the 'no-external-entities' condition code.
外部XMLエンティティには固有の信頼性がなく、あらゆるHTTP GETリクエストに固有のすべての攻撃の対象となります。さらに、外部のXMLエンティティがDTDを変更し、したがって最悪の場合、XMLドキュメントの最終形式に影響を与える可能性があり、最悪の場合、そのセマンティクスを大幅に変更するか、XMLプロセッサを[RFC3023]で説明したセキュリティリスクにさらします。したがって、実装者は、外部XMLエンティティを信頼できないと扱う必要があることに注意する必要があります。サーバーが外部XMLエンティティを処理しないことを選択した場合、「External-Entities」条件コードを持つ外部エンティティを含むリクエストに応答する必要があります。
There is also the scalability risk that would accompany a widely deployed application that made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any server that fields requests for the resource containing the external XML entity.
また、外部XMLエンティティを使用した広く展開されたアプリケーションに伴うスケーラビリティリスクもあります。この状況では、1つの外部XMLエンティティに対してかなりの数のリクエストがあり、外部XMLエンティティを含むリソースのリクエストをフィールドにリクエストするサーバーを過負荷にする可能性があります。
Furthermore, there's also a risk based on the evaluation of "internal entities" as defined in Section 4.2.2 of [REC-XML]. A small, carefully crafted request using nested internal entities may require enormous amounts of memory and/or processing time to process. Server implementers should be aware of this risk and configure their XML parsers so that requests like these can be detected and rejected as early as possible.
さらに、[Rec-XML]のセクション4.2.2で定義されている「内部エンティティ」の評価に基づくリスクもあります。ネストされた内部エンティティを使用した小規模で慎重に作成されたリクエストには、処理するために膨大な量のメモリおよび/または処理時間が必要になる場合があります。サーバーの実装者は、このリスクを認識し、XMLパーサーを構成して、このような要求をできるだけ早く検出および拒否できるようにする必要があります。
This specification encourages the use of "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens (Section 6.5), in order to guarantee their uniqueness across space and time. Version 1 UUIDs (defined in Section 4) MAY contain a "node" field that "consists of an IEEE 802 MAC address, usually the host address. For systems with multiple IEEE addresses, any available one can be used". Since a WebDAV server will issue many locks over its lifetime, the implication is that it may also be publicly exposing its IEEE 802 address.
この仕様では、空間と時間を超えて独自性を保証するために、ロックトークン（セクション6.5）に「普遍的に一意の識別子（UUID）urnネームスペース」（[RFC4122]）の使用を奨励します。バージョン1 UUID（セクション4で定義）には、「IEEE 802 Macアドレス、通常はホストアドレスで構成される「ノード」フィールドが含まれている場合があります。複数のIEEEアドレスを持つシステムの場合、利用可能なものを使用できます」。WebDAVサーバーは寿命にわたって多くのロックを発行するため、IEEE 802アドレスを公開している可能性があるという意味があります。
There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:
IEEE 802アドレスの曝露に関連するいくつかのリスクがあります。IEEE 802アドレスの使用：
o It is possible to track the movement of hardware from subnet to subnet.
o サブネットからサブネットへのハードウェアの動きを追跡することができます。
o It may be possible to identify the manufacturer of the hardware running a WebDAV server.
o WebDavサーバーを実行しているハードウェアのメーカーを識別することが可能かもしれません。
o It may be possible to determine the number of each type of computer running WebDAV.
o WebDavを実行している各タイプのコンピューターの数を決定することが可能かもしれません。
This risk only applies to host-address-based UUID versions. Section 4 of [RFC4122] describes several other mechanisms for generating UUIDs that do not involve the host address and therefore do not suffer from this risk.
このリスクは、ホストアドレスベースのUUIDバージョンにのみ適用されます。[RFC4122]のセクション4では、ホストアドレスを伴わないため、このリスクに悩まされないUUIDを生成するための他のいくつかのメカニズムについて説明します。
HTTP has the ability to host programs that are executed on client machines. These programs can take many forms including Web scripts, executables, plug-in modules, and macros in documents. WebDAV does not change any of the security concerns around these programs, yet often WebDAV is used in contexts where a wide range of users can publish documents on a server. The server might not have a close trust relationship with the author that is publishing the document. Servers that allow clients to publish arbitrary content can usefully implement precautions to check that content published to the server is not harmful to other clients. Servers could do this by techniques such as restricting the types of content that is allowed to be published and running virus and malware detection software on published content. Servers can also mitigate the risk by having appropriate access restriction and authentication of users that are allowed to publish content to the server.
HTTPには、クライアントマシンで実行されるプログラムをホストする機能があります。これらのプログラムは、ドキュメントにWebスクリプト、実行可能ファイル、プラグインモジュール、マクロなど、さまざまなフォームを使用できます。WebDAVは、これらのプログラムに関するセキュリティの懸念事項を変更しませんが、多くの場合、WebDAVは、幅広いユーザーがサーバーにドキュメントを公開できるコンテキストで使用されます。サーバーは、ドキュメントを公開している著者との密接な信頼関係を持たない場合があります。クライアントが任意のコンテンツを公開できるようにするサーバーは、サーバーに公開されたコンテンツが他のクライアントに有害ではないことを確認するために予防策を有用に実装できます。サーバーは、公開されているコンテンツの種類を制限し、公開されたコンテンツでウイルスとマルウェア検出ソフトウェアを実行するなどの手法によってこれを行うことができます。サーバーは、コンテンツをサーバーに公開することが許可されているユーザーの適切なアクセス制限と認証を持つことにより、リスクを軽減することもできます。
This specification defines two URI schemes:
この仕様では、2つのURIスキームが定義されています。
1. the "opaquelocktoken" scheme defined in Appendix C, and
1. 付録Cで定義されている「Opaquelocktoken」スキームと
2. the "DAV" URI scheme, which historically was used in [RFC2518] to disambiguate WebDAV property and XML element names and which continues to be used for that purpose in this specification and others extending WebDAV. Creation of identifiers in the "DAV:" namespace is controlled by the IETF.
2. [RFC2518]で歴史的に使用されていた「DAV」URIスキームは、WebDAVプロパティとXML要素名を明確にし、この仕様やその他のWebDAVを拡張する他の目的で使用され続けています。「dav：」という名前の識別子の作成は、IETFによって制御されます。
Note that defining new URI schemes for XML namespaces is now discouraged. "DAV:" was defined before standard best practices emerged.
XMLネームスペースの新しいURIスキームを定義することは、今では落胆していることに注意してください。「DAV：」は、標準的なベストプラクティスが登場する前に定義されました。
XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names, or element names.
XML NameSpacesは、WebDavプロパティ名とXML要素を微分します。WebDavユーザーまたはアプリケーションは、カスタムプロパティを作成したり、WebDav XML構文を拡張したりするために、新しい名前空間を定義できます。IANAは、そのような名前空間、プロパティ名、または要素名を管理する必要はありません。
The message header fields below should be added to the permanent registry (see [RFC3864]).
以下のメッセージヘッダーフィールドは、永続的なレジストリに追加する必要があります（[RFC3864]を参照）。
Header field name: DAV
ヘッダーフィールド名：Dav
Applicable protocol: http
該当するプロトコル：http
Status: standard Author/Change controller: IETF
ステータス：標準著者/変更コントローラー：IETF
Specification document: this specification (Section 10.1)
仕様文書：この仕様（セクション10.1）
Header field name: Depth
ヘッダーフィールド名：深さ
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.2)
仕様文書：この仕様（セクション10.2）
Header field name: Destination
ヘッダーフィールド名：目的地
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.3)
仕様文書：この仕様（セクション10.3）
Header field name: If
ヘッダーフィールド名：if
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.4)
仕様文書：この仕様（セクション10.4）
Header field name: Lock-Token
ヘッダーフィールド名：ロックトークン
Applicable protocol: http
該当するプロトコル：http
Status: standard Author/Change controller: IETF
ステータス：標準著者/変更コントローラー：IETF
Specification document: this specification (Section 10.5)
仕様文書：この仕様（セクション10.5）
Header field name: Overwrite
ヘッダーフィールド名：上書き
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.6)
仕様文書：この仕様（セクション10.6）
Header field name: Timeout
ヘッダーフィールド名：タイムアウト
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 10.7)
仕様文書：この仕様（セクション10.7）
This specification defines the HTTP status codes
この仕様では、HTTPステータスコードを定義します
o 207 Multi-Status (Section 11.1)
o 207マルチステータス（セクション11.1）
o 422 Unprocessable Entity (Section 11.2),
o 422処理不可能なエンティティ（セクション11.2）、
o 423 Locked (Section 11.3),
o 423ロック（セクション11.3）、
o 424 Failed Dependency (Section 11.4) and
o 424依存の失敗（セクション11.4）および
o 507 Insufficient Storage (Section 11.5),
o 507ストレージ不足（セクション11.5）、
to be updated in the registry at <http://www.iana.org/assignments/http-status-codes>.
レジストリで<http://www.iana.org/assignments/http-status-codes>で更新されます。
Note: the HTTP status code 102 (Processing) has been removed in this specification; its IANA registration should continue to reference RFC 2518.
注：HTTPステータスコード102（処理）は、この仕様で削除されました。そのIANA登録は、引き続きRFC 2518を参照する必要があります。
A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work.
このような仕様は、批判的なレビューを刺すことと、無関心な怠慢からの枯れに繁栄します。著者は、私たちの仕事のあらゆる段階で洞察が非常に価値がある次の人々の貢献に感謝しています。
Contributors to RFC 2518
RFC 2518への貢献者
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.
テリー・アレン、ハラルド・アルベスランド、ジム・アムスデン、ベッキー・アンダーソン、アラン・バビッチ、サンフォード・バー、ディラン・バレル、バーナード・チェスター、ティム・バーナーズ・リー、ダン・コノリー、ジム・カニンガム、ロン・ダニエル、ジュニア、ジム・デイビス、キース・ドーソン、マーク・デイ、ブライアン・ディーン、マーティン・ドゥースト、デビッド・デュランド、リー・ファレル、チャック・フェイ、ウェスリー・フェルター、ロイ・フィールディング、マーク・フィッシャー、アラン・フライアー、ジョージ・フィレンツィーヌ、ジム・ゲッティズ、フィル・ハラム・ベーカー、デニス・ハミルトン、スティーブ・ヘニング、ミード・ヒメルシュタイン、アレックス・ホップマン、アンドレ・ファン・デル・ホーク、ベン・ローリー、ポール・リーチ、オラ・ラシラ、カレン・マッカーサー、スティーブン・マーティン、ラリー・マシン留め、マイケル・ミーリング、キース・ムーア、トーマス・ナルテン、ヘンリック・ニールセン、ケンジ・オタ、ボブ・パーカー、グレン・ピーターソン、ジョン・ラドフ、セーブ・レディ、ヘンリー・サンダース、クリストファー・セウワルド、ジュディス・スリーイン、マイク・スプレッツァー、アイナー・ステフェルード、グレッグ・スタイン、ラルフ・スウィック、ケンジ・タカハシ、リチャード・N・テイラー、ロバート・タウ、ジョン・ターナー、サンカール・ヴァルハグリスワラン、ファビオ・ヴィタリ、グレゴリー・ウッドハウス、ラウレン・ウッド。
Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable; he both helped the formation of the working group and patiently coached the authors along the way. In so many ways he has set high standards that we have toiled to meet. The contributions of Judith Slein were also invaluable; by clarifying the requirements and in patiently reviewing version after version, she both improved this specification and expanded our minds on document management.
このリストの2人は特別な言及に値します。Larry Masinterの貢献は非常に貴重でした。彼は両方ともワーキンググループの形成を助け、途中で著者を辛抱強く指導しました。非常に多くの点で彼は高い基準を設定しているので、私たちは会うために苦労しました。ジュディス・スリーインの貢献も非常に貴重でした。要件を明確にし、バージョン後に辛抱強くレビューすることで、彼女はこの仕様を改善し、ドキュメント管理に関する私たちの心を拡大しました。
We would also like to thank John Turner for developing the XML DTD.
また、XML DTDを開発してくれたJohn Turnerに感謝します。
The authors of RFC 2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter, and D. Jensen. Although their names had to be removed due to IETF author count restrictions, they can take credit for the majority of the design of WebDAV.
RFC 2518の著者は、ヤロンゴーランド、ジムホワイトヘッド、A。ファイジ、スティーブカーター、およびD.ジェンセンでした。IETFの著者数の制限のために名前を削除する必要がありましたが、WebDavの設計の大部分を信用することができます。
Additional Acknowledgements for This Specification
この仕様の追加の謝辞
Significant contributors of text for this specification are listed as contributors in the section below. We must also gratefully acknowledge Geoff Clemm, Joel Soderberg, and Dan Brotsky for hashing out specific text on the list or in meetings. Joe Hildebrand and Cullen Jennings helped close many issues. Barry Lind described an additional security consideration and Cullen Jennings provided text for that consideration. Jason Crawford tracked issue status for this document for a period of years, followed by Elias Sinderson.
この仕様のテキストの重要な貢献者は、以下のセクションに貢献者としてリストされています。また、Geoff Clemm、Joel Soderberg、およびDan Brotskyに、リストまたは会議で特定のテキストをかけてくれたことに感謝しなければなりません。Joe HildebrandとCullen Jenningsは、多くの問題を埋めるのを助けました。Barry Lindは、追加のセキュリティに関する考慮事項を説明し、Cullen Jenningsはその考慮のためにテキストを提供しました。ジェイソン・クロフォードは、この文書の問題ステータスを何年も追跡し、エリアス・シンダーソンがそれに続きました。
Julian Reschke <green/>bytes GmbH Hafenweg 16, 48155 Muenster, Germany EMail: julian.reschke@greenbytes.de
Julian Reschke <Green/> Bytes GmbH Hafenweg 16、48155 Muenster、ドイツメール：julian.reschke@greenbytes.de
Elias Sinderson University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: elias@cse.ucsc.edu
カリフォルニア州エリアスシンダーソン大学サンタクルス1156ハイストリート、サンタクルス、カリフォルニア州95064メール：elias@cse.ucsc.edu
Jim Whitehead University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: ejw@soe.ucsc.edu
ジムホワイトヘッドカリフォルニア大学、サンタクルーズ1156ハイストリート、カリフォルニア州サンタクルス95064メール：ejw@soe.ucsc.edu
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: yarong@microsoft.com
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399メール：yarong@microsoft.com
E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 EMail: ejw@ics.uci.edu
E. J.ホワイトヘッド、Jr。カリフォルニア州情報およびコンピューターサイエンス大学、アーバインアーバイン、CA 92697-3425メール：ejw@ics.uci.edu
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043 EMail: asad@netscape.com S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: srcarter@novell.com
A. Faizi Netscape 685 East Middlefield Road Mountain View、CA 94043メール：asad@netscape.com S. R. Carter Novell 1555 N. Technology Way M/s orm F111 Orem、UT 84097-2399メール：srcarter@novell.com
D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: dcjensen@novell.com
D. Jensen Novell 1555 N. Technology Way M/s Orm F111 Orem、UT 84097-2399メール：dcjensen@novell.com
[REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816/>.
[Rec-Xml] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C.、Maler、E.、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第4版）」、W3C Rec-Xml-20060816、2006年8月、<http://www.w3.org/tr/2006/rec-xml-20060816/>。
[REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/ REC-xml-infoset-20040204/>.
[rec-xml-infoset] Cowan、J。and R. Tobin、「XML Information Set（第2版）」、W3C REC-XML-INFOSET-20040204、2004年2月、<http://www.w3.org/tr/2004/rec-xml-infoset-20040204/>。
[REC-XML-NAMES] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", W3C REC-xml-names-20060816, August 2006, <http:// www.w3.org/TR/2006/REC-xml-names-20060816/>.
[Rec-XML-Names] Bray、T.、Hollander、D.、Layman、A。、およびR. Tobin、「XML 1.0の名前空間（第2版）」、W3C REC-XML-NAMES-20060816、2006年8月、<http：// www.w3.org/tr/2006/rec-xml-names-names-20060816/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339] Klyne、G.、ed。C.ニューマン、「インターネット上の日時：タイムスタンプ」、RFC 3339、2002年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「普遍的にユニークな識別子（UUID）URNネームスペース」、RFC 4122、2005年7月。
[RFC2291] Slein, J., Vitali, F., Whitehead, E., and D. Durand, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web", RFC 2291, February 1998.
[RFC2291] Slein、J.、Vitali、F.、Whitehead、E。、およびD. Durand、「World Wide Webの分散オーサリングおよびバージョンプロトコルの要件」、RFC 2291、1998年2月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。、およびD. Jensen、「分散オーサリングのHTTP拡張 - WebDav」、RFC 2518、1999年2月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781] Hoffman、P。およびF. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253] Clemm、G.、Amsden、J.、Ellison、T.、Kaler、C。、およびJ. Whitehead、「WebDavへのバージョン化拡張機能（Web分散オーサリングとバージョン化）」、RFC 3253、2002年3月。
[RFC3648] Whitehead, J. and J. Reschke, Ed., "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol", RFC 3648, December 2003.
[RFC3648] Whitehead、J。and J. Reschke、ed。、「Web分散オーサリングとバージョン（WebDAV）注文コレクションプロトコル」、RFC 3648、2003年12月。
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.
[RFC3744] Clemm、G.、Reschke、J.、Sedlar、E。、およびJ. Whitehead、「Web分散オーサリングおよびバージョン（WebDAV）アクセス制御プロトコル」、RFC 3744、2004年5月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form <A></A>. The second is to declare an XML element of the form <A/>. The two XML elements are semantically identical.
XMLは、XML要素にコンテンツがないことを示すための2つのメカニズムをサポートしています。1つ目は、フォーム<a> </a>のXML要素を宣言することです。2つ目は、フォーム<a/>のXML要素を宣言することです。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 whitespace, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements.
XMLは、合法であると思われるが実際にはそうではないデータを簡単に送信できる柔軟なデータ形式です。「あなたが受け入れるものに柔軟になり、送信するものに厳格になる」という哲学はまだ適用されますが、不適切に適用してはなりません。XMLは、白人の問題、要素の順序付け、新しい要素の挿入などの問題に非常に柔軟に対処できます。この柔軟性は、特に要素の意味の領域では拡張を必要としません。
There is no kindness in accepting illegal combinations of XML elements. At best, it will cause an unwanted result and at worst it can cause real damage.
XML要素の違法な組み合わせを受け入れることには優しさはありません。せいぜい、それは望ましくない結果を引き起こし、最悪の場合は本当の損傷を引き起こす可能性があります。
The following request body for a PROPFIND method is illegal.
Propfindメソッドの次の要求本体は違法です。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:propname/>
</D:propfind>
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として扱った場合、プロップ名を実行することを意図した帯域幅の限定行を越えて走っているクライアントは、大きな驚きになります。
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.
前の例は、プロップファインド要素に一緒に表示されることを明示的に禁止された2つの要素が含まれていたため、違法でした。ただし、XMLは拡張可能な言語であるため、Propfindで使用するために新しい要素が定義されていると想像できます。以下は、Propfindの要求本体であり、前の例と同様に、期限切れのプロップス要素を理解していないサーバーによって400（悪い要求）で拒否する必要があります。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
<E:expired-props/>
</D:propfind>
To understand why a 400 (Bad Request) is returned, let us look at the request body as the server unfamiliar with expired-props sees it.
400（悪いリクエスト）が返される理由を理解するために、期限切れのプロップに不慣れなサーバーがそれを見ているので、リクエスト本体を見てみましょう。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
</D:propfind>
As the server does not understand the 'expired-props' element, according to the WebDAV-specific XML processing rules specified in Section 17, it must process the request as if the element were not there. Thus, the server sees an empty propfind, which by the definition of the propfind element is illegal.
サーバーは、セクション17で指定されたWebDAV固有のXML処理ルールによれば、「期限切れのプロップ」要素を理解していないため、要素がそこにないかのようにリクエストを処理する必要があります。したがって、サーバーには空の推定が表示されます。これは、Propfind Elementの定義により違法です。
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（悪い要求）になるとは限りません。たとえば、次の要求本体を想像してください。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
<D:propname/>
<E:leave-out>*boss*</E:leave-out>
</D:propfind>
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with 'leave-out', the only result would be that the 'leave-out' element would be ignored and a propname would be executed.
前の例には、架空の要素の休暇が含まれています。その目的は、名前が提出されたパターンと一致するプロパティの返品を防ぐことです。前の例が「残り」に不慣れなサーバーに送信された場合、唯一の結果は「除外」要素が無視され、プロップ名が実行されることです。
WebDAV was designed to be, and has been found to be, backward-compatible with HTTP 1.1. The PUT and DELETE methods are defined in HTTP and thus may be used by HTTP clients as well as WebDAV-aware clients, but the responses to PUT and DELETE have been extended in this specification in ways that only a WebDAV client would be entirely prepared for. Some theoretical concerns were raised about whether those responses would cause interoperability problems with HTTP-only clients, and this section addresses those concerns.
WebDavは、HTTP 1.1と後方互換であるように設計されており、発見されています。PUTおよび削除メソッドはHTTPで定義されているため、HTTPクライアントとWebDAVを認識するクライアントによって使用される場合がありますが、Put and Deleteへの応答は、WebDAVクライアントのみが完全に準備される方法でこの仕様に拡張されています。。これらの応答がHTTPのみのクライアントと相互運用性の問題を引き起こすかどうかについて、いくつかの理論的懸念が提起され、このセクションではこれらの懸念について説明します。
Since any HTTP client ought to handle unrecognized 400-level and 500- level status codes as errors, the following new status codes should not present any issues: 422, 423, and 507 (424 is also a new status code but it appears only in the body of a Multistatus response.) So, for example, if an HTTP client attempted to PUT or DELETE a locked resource, the 423 Locked response ought to result in a generic error presented to the user.
HTTPクライアントは、エラーとして認識されていない400レベルおよび500レベルのステータスコードを処理する必要があるため、次の新しいステータスコードは422、423、および507（424も新しいステータスコードですが、にのみ表示されますが、たとえば、HTTPクライアントがロックされたリソースを配置または削除しようとした場合、423ロックされた応答がユーザーに提示される一般的なエラーになるはずです。
The 207 Multistatus response is interesting because an HTTP client issuing a DELETE request to a collection might interpret a 207 response as a success, even though it does not realize the resource is a collection and cannot understand that the DELETE operation might have been a complete or partial failure. That interpretation isn't entirely justified, because a 200-level response indicates that the server "received, understood, and accepted" the request, not that the request resulted in complete success.
207 MultiStatusの応答は興味深いです。なぜなら、リソースがコレクションであることを認識しておらず、削除操作が完全である可能性があることを理解できない場合でも、コレクションに削除リクエストを発行するHTTPクライアントが207の応答を成功と解釈する可能性があるため、興味深いです。部分的な障害。200レベルの応答は、サーバーがリクエストを「受信、理解し、受け入れた」ことを示しているため、その解釈は完全に正当化されるわけではありません。
One option is that a server could treat a DELETE of a collection as an atomic operation, and use either 204 No Content in case of success, or some appropriate error response (400 or 500 level) for an error. This approach would indeed maximize backward compatibility. However, since interoperability tests and working group discussions have not turned up any instances of HTTP clients issuing a DELETE request against a WebDAV collection, this concern is more theoretical than practical. Thus, servers are likely to be completely successful at interoperating with HTTP clients even if they treat any collection DELETE request as a WebDAV request and send a 207 Multi-Status response.
1つのオプションは、サーバーがコレクションの削除をアトミック操作として扱い、成功した場合に204個のコンテンツを使用するか、エラーのために適切なエラー応答（400レベルまたは500レベル）を使用できることです。このアプローチは、実際に後方互換性を最大化するでしょう。ただし、相互運用性テストとワーキンググループディスカッションは、WebDAVコレクションに対して削除リクエストを発行するHTTPクライアントのインスタンスを表示していないため、この懸念は実用的よりも理論的です。したがって、サーバーは、Collection削除要求をWebDAVリクエストとして扱い、207のマルチステータス応答を送信した場合でも、HTTPクライアントとの相互運用に完全に成功する可能性があります。
In general, server implementations are encouraged to use the detailed responses and other mechanisms defined in this document rather than make changes for theoretical interoperability concerns.
一般に、サーバーの実装は、理論的相互運用性の懸念の変更を加えるのではなく、このドキュメントで定義されている詳細な応答やその他のメカニズムを使用することをお勧めします。
The 'opaquelocktoken' URI scheme was defined in [RFC2518] (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time.
「Opaquelocktoken」URIスキームは、[RFC2518]（およびIANAによって登録されています）で定義され、構文的に正しい、uuidsから生成しやすいURIを作成し、ロックトークンとして使用することを目的としており、すべてのリソースでユニークであることを目的としています。いつも。
An opaquelocktoken URI is constructed by concatenating the 'opaquelocktoken' scheme with a UUID, along with an optional extension. Servers can create new UUIDs for each new lock token. If a server wishes to reuse UUIDs, the server MUST add an extension, and the algorithm generating the extension MUST guarantee that the same extension will never be used twice with the associated UUID.
Opaquelocktoken URIは、「Opaquelocktoken」スキームをUUIDとオプションの拡張機能とともに連結することにより構築されます。サーバーは、新しいロックトークンごとに新しいUUIDを作成できます。サーバーがUUIDを再利用したい場合、サーバーは拡張機能を追加する必要があり、拡張機能を生成するアルゴリズムは、関連するUUIDで同じ拡張機能を2回使用しないことを保証する必要があります。
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
; UUID is defined in Section 3 of [RFC4122]. Note that LWS
; is not allowed between elements of
; this production.
Extension = path ; path is defined in Section 3.3 of [RFC3986]
extension = path;パスは[RFC3986]のセクション3.3で定義されています
The original WebDAV model for locking unmapped URLs created "lock-null resources". This model was over-complicated and some interoperability and implementation problems were discovered. The new WebDAV model for locking unmapped URLs (see Section 7.3) creates "locked empty resources". Lock-null resources are deprecated. This section discusses the original model briefly because clients MUST be able to handle either model.
マップされていないURLをロックするための元のWebDAVモデルは、「ロックヌルリソース」を作成しました。このモデルは複雑であり、相互運用性と実装の問題が発見されました。マップされていないURLをロックするための新しいWebDAVモデル（セクション7.3を参照）は、「ロックされた空のリソース」を作成します。ロックヌルリソースは非推奨です。このセクションでは、クライアントがいずれかのモデルを処理できる必要があるため、元のモデルについて簡単に説明します。
In the original "lock-null resource" model, which is no longer recommended for implementation:
元の「ロックヌルリソース」モデルでは、実装には推奨されなくなりました。
o A lock-null resource sometimes appeared as "Not Found". The server responds with a 404 or 405 to any method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
o ロックヌルのリソースは、「見つからない」と表示されることがありました。サーバーは、put、mkcol、options、propfind、lock、lockを除く任意の方法に404または405で応答します。
o A lock-null resource does however show up as a member of its parent collection.
o ただし、ロックヌルリソースは、その親コレクションのメンバーとして表示されます。
o The server removes the lock-null resource entirely (its URI becomes unmapped) if its lock goes away before it is converted to a regular resource. Recall that locks go away not only when they expire or are unlocked, but are also removed if a resource is renamed or moved, or if any parent collection is renamed or moved.
o サーバーは、通常のリソースに変換される前にロックがなくなると、ロックヌルリソースを完全に削除します（URIはマップされていません）。ロックは、有効期限が切れたりロック解除されている場合だけでなく、リソースの名前が変更または移動された場合、または親コレクションが変更または移動された場合にも削除されることを思い出してください。
o The server converts the lock-null resource into a regular resource if a PUT request to the URL is successful.
o サーバーは、URLへのリクエストが成功した場合、ロックヌルリソースを通常のリソースに変換します。
o The server converts the lock-null resource into a collection if a MKCOL request to the URL is successful (though interoperability experience showed that not all servers followed this requirement).
o サーバーは、URLへのMKCOL要求が成功した場合、ロックヌルリソースをコレクションに変換します（ただし、相互運用性エクスペリエンスは、すべてのサーバーがこの要件に従っているわけではないことを示しました）。
o Property values were defined for DAV:lockdiscovery and DAV: supportedlock properties but not necessarily for other properties like DAV:getcontenttype.
o プロパティ値は、DAV：Lock -DiscoveryおよびDAV：SupportEdLockプロパティで定義されましたが、DAV：GetContentTypeのような他のプロパティでは必ずしもそうではありません。
Clients can easily interoperate both with servers that support the old model "lock-null resources" and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET.
クライアントは、古いモデルの「ロックヌルリソース」をサポートするサーバーと、MKCOLまたはGETではなくマップされていないURLへのロックの後にプットを試みることにより、「ロックされた空のリソース」の推奨モデルと簡単に相互運用できます。
A WebDAV client implemented to this specification might find servers that create lock-null resources (implemented before this specification using [RFC2518]) as well as servers that create locked empty resources. The response to the LOCK request will not indicate what kind of resource was created. There are a few techniques that help the client deal with either type.
この仕様に実装されたWebDAVクライアントは、ロックナルリソースを作成するサーバー（[RFC2518]を使用してこの仕様の前に実装された）と、ロックされた空のリソースを作成するサーバーを見つける場合があります。ロックリクエストへの応答は、どのようなリソースが作成されたかを示しません。クライアントがいずれかのタイプに対処するのに役立ついくつかの手法があります。
If the client wishes to avoid accidentally creating either lock-null or empty locked resources, an "If-Match: *" header can be included with LOCK requests to prevent the server from creating a new resource.
クライアントがロックヌルまたは空のロックされたリソースのいずれかを誤って作成しないようにしたい場合、「if-match： *」ヘッダーをロックリクエストに含めることができ、サーバーが新しいリソースの作成を防ぐことができます。
If a LOCK request creates a resource and the client subsequently wants to overwrite that resource using a COPY or MOVE request, the client should include an "Overwrite: T" header.
ロックリクエストがリソースを作成し、その後、クライアントがコピーまたは移動要求を使用してそのリソースを上書きしたい場合、クライアントには「上書き：t」ヘッダーを含める必要があります。
If a LOCK request creates a resource and the client then decides to get rid of that resource, a DELETE request is supposed to fail on a lock-null resource and UNLOCK should be used instead. But with a locked empty resource, UNLOCK doesn't make the resource disappear. Therefore, the client might have to try both requests and ignore an error in one of the two requests.
ロック要求がリソースを作成し、クライアントがそのリソースを削除することを決定した場合、削除要求はロックヌルリソースで失敗することになっており、代わりにロックを解除する必要があります。しかし、ロックされた空のリソースを使用すると、ロックを解除してもリソースが消えません。したがって、クライアントは両方のリクエストを試して、2つのリクエストのいずれかでエラーを無視する必要がある場合があります。
Many WebDAV clients that have already been implemented have account settings (similar to the way email clients store IMAP account settings). Thus, the WebDAV client would be able to authenticate with its first couple requests to the server, provided it had a way to get the authentication challenge from the server with realm name, nonce, and other challenge information. Note that the results of some requests might vary according to whether or not the client is authenticated -- a PROPFIND might return more visible resources if the client is authenticated, yet not fail if the client is anonymous.
すでに実装されている多くのWebDAVクライアントには、アカウント設定があります（電子メールクライアントがIMAPアカウント設定を保存する方法と同様）。したがって、WebDAVクライアントは、サーバーの名前、NONCE、およびその他のチャレンジ情報を使用してサーバーから認証チャレンジを取得する方法があれば、サーバーへの最初のカップルリクエストで認証することができます。一部のリクエストの結果は、クライアントが認証されているかどうかによって異なる場合があることに注意してください。クライアントが認証されている場合は、より目に見えるリソースを返す可能性がありますが、クライアントが匿名である場合は失敗しない可能性があります。
There are a number of ways the client might be able to trigger the server to provide an authentication challenge. This appendix describes a couple approaches that seem particularly likely to work.
クライアントがサーバーをトリガーして認証チャレンジを提供する方法はいくつかあります。この付録では、特に機能する可能性が高いと思われるいくつかのアプローチについて説明しています。
The first approach is to perform a request that ought to require authentication. However, it's possible that a server might handle any request even without authentication, so to be entirely safe, the client could add a conditional header to ensure that even if the request passes permissions checks, it's not actually handled by the server. An example of following this approach would be to use a PUT request with an "If-Match" header with a made-up ETag value. This approach might fail to result in an authentication challenge if the server does not test authorization before testing conditionals as is required (see Section 8.5), or if the server does not need to test authorization.
最初のアプローチは、認証が必要なリクエストを実行することです。ただし、認証がなくてもサーバーがリクエストを処理する可能性があるため、完全に安全であるために、クライアントは条件付きヘッダーを追加して、要求がアクセス許可チェックに合格しても、実際にはサーバーによって処理されないことを確認できます。このアプローチに従う例は、メイクアップされたETAG値を持つ「if-match」ヘッダーを持つPutリクエストを使用することです。このアプローチは、必要に応じて条件をテストする前にサーバーが承認をテストしない場合（セクション8.5を参照）、またはサーバーが認証をテストする必要がない場合、認証チャレンジに失敗する可能性があります。
Example - forcing auth challenge with write request
例 - 書き込みリクエストを使用したAuth Challengeを強制します
>>Request
>>リクエスト
PUT /forceauth.txt HTTP/1.1
Host: www.example.com
If-Match: "xxx"
Content-Type: text/plain
Content-Length: 0
The second approach is to use an Authorization header (defined in [RFC2617]), which is likely to be rejected by the server but which will then prompt a proper authentication challenge. For example, the client could start with a PROPFIND request containing an Authorization header containing a made-up Basic userid:password string or with actual plausible credentials. This approach relies on the server responding with a "401 Unauthorized" along with a challenge if it receives an Authorization header with an unrecognized username, invalid password, or if it doesn't even handle Basic authentication. This seems likely to work because of the requirements of RFC 2617:
2番目のアプローチは、承認ヘッダー（[RFC2617]で定義されている）を使用することです。これは、サーバーによって拒否される可能性が高いが、適切な認証チャレンジを促します。たとえば、クライアントは、構成された基本ユーザーIDを含む認証ヘッダーを含むPropfindリクエスト（パスワード文字列または実際のもっともらしい資格情報）から始めることができます。このアプローチは、認識されていないユーザー名、無効なパスワード、または基本的な認証さえ処理しない場合、「401の不正」で応答する「401の不正」で応答し、チャレンジに依存しています。これは、RFC 2617の要件のために機能する可能性が高いようです。
"If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource."
「Origin Serverがリクエストで送信された資格情報を受け入れたくない場合、401（不正な）応答を返す必要があります。応答には、リクエストに適用される少なくとも1つの（おそらく新しい）チャレンジを含むwww-authenticateヘッダーフィールドを含める必要があります。リソース。"
There's a slight problem with implementing that recommendation in some cases, because some servers do not even have challenge information for certain resources. Thus, when there's no way to authenticate to a resource or the resource is entirely publicly available over all accepted methods, the server MAY ignore the Authorization header, and the client will presumably try again later.
一部のサーバーには特定のリソースの課題情報さえ持っていないため、場合によってはその推奨事項を実装することにはわずかな問題があります。したがって、リソースに認証する方法がない場合、またはリソースがすべての受け入れられたメソッドで完全に公開されている場合、サーバーは承認ヘッダーを無視する可能性があり、クライアントはおそらく後でもう一度やり直します。
Example - forcing auth challenge with Authorization header
例 - 認証ヘッダーを使用してAUTHチャレンジを強制します
>>Request
>>リクエスト
PROPFIND /docs/ HTTP/1.1
Host: www.example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-type: application/xml; charset="utf-8"
Content-Length: xxxx
[body omitted]
[ボディ省略]
This section lists major changes between this document and RFC 2518, starting with those that are likely to result in implementation changes. Servers will advertise support for all changes in this specification by returning the compliance class "3" in the DAV response header (see Sections 10.1 and 18.3).
このセクションでは、このドキュメントとRFC 2518の間の大きな変更をリストし、実装の変更をもたらす可能性が高いものから始めます。サーバーは、DAV応答ヘッダーのコンプライアンスクラス「3」を返すことにより、この仕様のすべての変更のサポートを宣伝します（セクション10.1および18.3を参照）。
Collections and Namespace Operations
コレクションと名前空間操作
o The semantics of PROPFIND 'allprop' (Section 9.1) have been relaxed so that servers return results including, at a minimum, the live properties defined in this specification, but not necessarily return other live properties. The 'allprop' directive therefore means something more like "return all properties that are supposed to be returned when 'allprop' is requested" -- a set of properties that may include custom properties and properties defined in other specifications if those other specifications so require. Related to this, 'allprop' requests can now be extended with the 'include' syntax to include specific named properties, thereby avoiding additional requests due to changed 'allprop' semantics.
o Propfind 'AllProp'（セクション9.1）のセマンティクスは緩和されているため、サーバーはこの仕様で定義されているライブプロパティを最小限に抑えますが、必ずしも他のライブプロパティを返すわけではありません。したがって、「AllProp」ディレクティブは、「AllProp」が要求されたときに返されるはずのすべてのプロパティを返すすべてのプロパティ」 - 他の仕様が必要な場合に他の仕様で定義されたカスタムプロパティとプロパティを含むプロパティのセットのようなものを意味します。。これに関連して、「AllProp」要求を「含める」構文を使用して拡張して特定の名前のプロパティを含めることができるため、「AllProp」セマンティクスを変更するための追加のリクエストを回避できます。
o Servers are now allowed to reject PROPFIND requests with Depth: Infinity. Clients that used this will need to be able to do a series of Depth:1 requests instead.
o サーバーは、深さ：InfinityでPropfindリクエストを拒否できるようになりました。これを使用したクライアントは、代わりに一連の深さを実行できる必要があります。
o Multi-Status response bodies now can transport the value of HTTP's Location response header in the new 'location' element. Clients may use this to avoid additional roundtrips to the server when there is a 'response' element with a 3xx status (see Section 14.24).
o マルチステータス応答本体は、新しい「位置」要素でHTTPの位置応答ヘッダーの値を輸送できるようになりました。クライアントはこれを使用して、3xxステータスの「応答」要素がある場合にサーバーへの追加のラウンドトリップを回避できます（セクション14.24を参照）。
o The definition of COPY has been relaxed so that it doesn't require servers to first delete the target resources anymore (this was a known incompatibility with [RFC3253]). See Section 9.8.
o コピーの定義は緩和されているため、最初にターゲットリソースを削除するためにサーバーを必要としなくなりました（これは[RFC3253]との既知の非互換性でした）。セクション9.8を参照してください。
Headers and Marshalling
ヘッダーとマーシャリング
o The Destination and If request headers now allow absolute paths in addition to full URIs (see Section 8.3). This may be useful for clients operating through a reverse proxy that does rewrite the Host request header, but not WebDAV-specific headers.
o 宛先とリクエストヘッダーが完全なURIに加えて絶対パスを許可する場合（セクション8.3を参照）。これは、WebDAV固有のヘッダーではなく、ホストリクエストヘッダーを書き換える逆プロキシを介して動作するクライアントに役立つ場合があります。
o This specification adopts the error marshalling extensions and the "precondition/postcondition" terminology defined in [RFC3253] (see Section 16). Related to that, it adds the "error" XML element inside multistatus response bodies (see Section 14.5, however note that it uses a format different from the one recommended in RFC 3253).
o この仕様では、[RFC3253]で定義されている「拡張機能と「前提条件/事後条件」という用語をマーシャリングするエラーが採用されています（セクション16を参照）。それに関連して、Multistatus応答ボディ内に「エラー」XML要素を追加します（セクション14.5を参照してくださいが、RFC 3253で推奨される形式とは異なる形式を使用していることに注意してください）。
o Senders and recipients are now required to support the UTF-16 character encoding in XML message bodies (see Section 19).
o 現在、送信者と受信者は、XMLメッセージ本文でエンコードするUTF-16文字をサポートする必要があります（セクション19を参照）。
o Clients are now required to send the Depth header on PROPFIND requests, although servers are still encouraged to support clients that don't.
o クライアントは現在、Propfindリクエストで深度ヘッダーを送信する必要がありますが、サーバーはまだそうでないクライアントをサポートするように奨励されています。
Locking
ロック
o RFC 2518's concept of "lock-null resources" (LNRs) has been replaced by a simplified approach, the "locked empty resources" (see Section 7.3). There are some aspects of lock-null resources clients cannot rely on anymore, namely, the ability to use them to create a locked collection or the fact that they disappear upon UNLOCK when no PUT or MKCOL request was issued. Note that servers are still allowed to implement LNRs as per RFC 2518.
o RFC 2518の「ロックヌルリソース」（LNRS）の概念は、単純化されたアプローチである「ロックされた空のリソース」に置き換えられました（セクション7.3を参照）。クライアントがもう頼ることができないロックヌルリソースには、ロックされたコレクションを作成するためにそれらを使用する能力、またはPutまたはMKCOLリクエストが発行されたときにロック解除時に消えるという事実には、いくつかの側面があります。RFC 2518に従って、サーバーは引き続きLNRを実装できることに注意してください。
o There is no implicit refresh of locks anymore. Locks are only refreshed upon explicit request (see Section 9.10.2).
o ロックの暗黙の更新はもうありません。ロックは、明示的なリクエストでのみ更新されます（セクション9.10.2を参照）。
o Clarified that the DAV:owner value supplied in the LOCK request must be preserved by the server just like a dead property (Section 14.17). Also added the DAV:lockroot element (Section 14.12), which allows clients to discover the root of lock.
o DAV：ロックリクエストで提供される所有者の価値は、死んだプロパティのようにサーバーによって保存されなければならないことを明らかにしました（セクション14.17）。また、DAV：Lockroot要素（セクション14.12）を追加しました。これにより、クライアントはロックのルートを発見できます。
Collections and Namespace Operations
コレクションと名前空間操作
o Due to interoperability problems, allowable formats for contents of 'href' elements in multistatus responses have been limited (see Section 8.3).
o 相互運用性の問題により、マルチスタッツ応答の「HREF」要素の内容の許容形式は限られています（セクション8.3を参照）。
o Due to lack of implementation, support for the 'propertybehavior' request body for COPY and MOVE has been removed. Instead, requirements for property preservation have been clarified (see Sections 9.8 and 9.9).
o 実装が不足しているため、コピーと移動の「プロパティベハビオール」要求本文のサポートが削除されました。代わりに、資産保存の要件が明確にされています（セクション9.8および9.9を参照）。
Properties
プロパティ
o Strengthened server requirements for storage of property values, in particular persistence of language information (xml:lang), whitespace, and XML namespace information (see Section 4.3).
o プロパティ値のストレージ、特に言語情報（XML：LANG）、Whitespace、およびXML NameSpace情報の持続性のためのサーバー要件の強化（セクション4.3を参照）。
o Clarified requirements on which properties should be writable by the client; in particular, setting "DAV:displayname" should be supported by servers (see Section 15).
o クライアントがどのプロパティを書くべきかについての要件を明確にしました。特に、「DAV：DisplayName」の設定は、サーバーによってサポートされる必要があります（セクション15を参照）。
o Only 'rfc1123-date' productions are legal as values for DAV: getlastmodified (see Section 15.7).
o 「RFC1123-DATE」プロダクションのみが、DAV：GetLastModifiedの価値として合法です（セクション15.7を参照）。
Headers and Marshalling
ヘッダーとマーシャリング
o Servers are now required to do authorization checks before processing conditional headers (see Section 8.5).
o サーバーは、条件付きヘッダーを処理する前に、承認チェックを行う必要があります（セクション8.5を参照）。
Locking
ロック
o Strengthened requirement to check identity of lock creator when accessing locked resources (see Section 6.4). Clients should be aware that lock tokens returned to other principals can only be used to break a lock, if at all.
o ロックされたリソースにアクセスするときにロック作成者のIDを確認するための強化要件（セクション6.4を参照）。クライアントは、ロックトークンが他のプリンシパルに戻っていることを使用して、もしあったとしてもロックを破るためにのみ使用できることに注意する必要があります。
o Section 8.10.4 of [RFC2518] incorrectly required servers to return a 409 status where a 207 status was really appropriate. This has been corrected (Section 9.10).
o [RFC2518]のセクション8.10.4は、207ステータスが本当に適切である409ステータスを返すためにサーバーを誤って要求しました。これは修正されました（セクション9.10）。
The definition of collection state has been fixed so it doesn't vary anymore depending on the Request-URI (see Section 5.2).
コレクション状態の定義は修正されているため、リクエスト-URIによって異なることはもうありません（セクション5.2を参照）。
The DAV:source property introduced in Section 4.6 of [RFC2518] was removed due to lack of implementation experience.
[RFC2518]のセクション4.6で導入されたDAV：ソースプロパティは、実装の経験がないため削除されました。
The DAV header now allows non-IETF extensions through URIs in addition to compliance class tokens. It also can now be used in requests, although this specification does not define any associated semantics for the compliance classes defined in here (see Section 10.1).
DAVヘッダーは、コンプライアンスクラスのトークンに加えて、URIを介して非拡張機能を許可します。この仕様では、ここで定義されているコンプライアンスクラスの関連するセマンティクスを定義するものではありませんが、リクエストでも使用できます（セクション10.1を参照）。
In RFC 2518, the definition of the Depth header (Section 9.2) required that, by default, request headers would be applied to each resource in scope. Based on implementation experience, the default has now been reversed (see Section 10.2).
RFC 2518では、深度ヘッダーの定義（セクション9.2）では、デフォルトでは、リクエストヘッダーが各リソースに範囲内の各リソースに適用される必要がありました。実装エクスペリエンスに基づいて、デフォルトが逆転しました（セクション10.2を参照）。
The definitions of HTTP status code 102 ([RFC2518], Section 10.1) and the Status-URI response header (Section 9.7) have been removed due to lack of implementation.
HTTPステータスコード102（[RFC2518]、セクション10.1）およびステータス-URI応答ヘッダー（セクション9.7）の定義は、実装の欠如により削除されました。
The TimeType format used in the Timeout request header and the "timeout" XML element used to be extensible. Now, only the two formats defined by this specification are allowed (see Section 10.7).
タイムアウトリクエストヘッダーで使用されるタイムタイプ形式と「タイムアウト」XML要素は拡張可能でした。これで、この仕様で定義された2つの形式のみが許可されます（セクション10.7を参照）。
Author's Address
著者の連絡先
Lisa Dusseault (editor) CommerceNet 2064 Edgewood Dr. Palo Alto, CA 94303 US
Lisa Dusseault（編集者）Commercenet 2064 Edgewood Dr. Palo Alto、CA 94303 US
EMail: ldusseault@commerce.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。