Network Working Group L. Dusseault, Ed.
Request for Comments: 4918 CommerceNet
Obsoletes: 2518 June 2007
Category: Standards Track
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
Web分散オーサリングとバージョン管理（WebDAV）のためのHTTP拡張機能
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).
Web分散オーサリングとバージョン管理（WebDAV）リソースプロパティ、リソースのコレクションの作成と管理、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.
ロック：同時に文書に取り組んでから、複数の人を維持する能力。これは、変更が最初の著者として失われている「失われたアップデートの問題」を、防止し、その後、別の、他の作者の変更をマージせずに変更を書き込みます。
Namespace Operations: The ability to instruct the server to copy and move Web resources, operations that change the mapping from URLs to resources.
名前空間の操作：コピーして、Webリソース、リソースへのURLのマッピングを変更する操作を移動するために、サーバーに指示する機能。
Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" [RFC2291].
これらの操作のための要件と根拠は仲間ドキュメント、「ワールド・ワイド・ウェブのための分散オーサリングとバージョン管理プロトコルのための要件」[RFC2291]で説明されています。
This document does not specify the versioning operations suggested by [RFC2291]. That work was done in a separate document, "Versioning Extensions to WebDAV" [RFC3253].
この文書では、[RFC2291]によって提案されたバージョン管理操作を指定していません。その作業は、[RFC3253]「のWebDAVへの拡張機能のバージョン管理」、別の文書で行いました。
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.
一般に、リソース・プロパティ（セクション4）、リソースのコレクション（セクション5）、ロック（第6節）を、具体的にロック（第7章）を記述します。以下のセクションでは、各種のWebDAV抽象化するための詳細な紹介を提供します。
These abstractions are manipulated by the WebDAV-specific HTTP methods (Section 9) and the extra HTTP headers (Section 10) used with WebDAV methods. General considerations for handling HTTP requests and responses in WebDAV are found in Section 8.
これらの抽象化は、WebDAVに特定のHTTPメソッド（セクション9）およびWebDAVの方法で使用余分なHTTPヘッダー（セクション10）によって操作されます。 WebDAVのでHTTPリクエストとレスポンスを処理するための一般的な考慮事項は、セクション8に記載されています。
While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines extra status codes developed for WebDAV methods (Section 11) and describes existing HTTP status codes (Section 12) as used in WebDAV. Since some WebDAV methods may
HTTP / 1.1が提供するステータスコードは、WebDAVメソッドによって発生する最もエラー条件を記述するのに十分であるが、既存のカテゴリにきちんと分類されない多少の誤差があります。この仕様は、WebDAV方法（セクション11）のために開発され、余分なステータスコードを定義し、WebDAVのに使用される既存のHTTPステータスコード（セクション12）を記述する。一部のWebDAVメソッドがありますので
operate over many resources, the Multi-Status response (Section 13) has been introduced to return status information for multiple resources. Finally, this version of WebDAV introduces precondition and postcondition (Section 16) XML elements in error response bodies.
多くのリソースで動作、マルチステータス応答（セクション13）は、複数のリソースのステータス情報を返すために導入されました。最後に、WebDAVのこのバージョンでは、前提条件と事後条件（セクション16）、エラーレスポンスボディのXML要素を導入します。
WebDAV uses XML ([REC-XML]) for property names and some values, and also uses XML to marshal complicated requests and responses. This specification contains DTD and text definitions of all properties (Section 15) and all other XML elements (Section 14) used in marshalling. WebDAV includes a few special rules on extending WebDAV XML marshalling in backwards-compatible ways (Section 17).
WebDAVは、プロパティ名といくつかの値のためにXML（[REC-XML]）を使用し、また複雑な要求と応答をマーシャリングするためにXMLを使用しています。この仕様は、すべてのプロパティ（セクション15）とマーシャリングで使用される他のすべてのXML要素（セクション14）のDTDおよびテキスト定義を含みます。 WebDAVは下位互換性の方法（セクション17）でのWebDAV XMLマーシャリングを延長上にいくつかの特別な規則を含みます。
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プロトコルの拡張セットを記述するため暗黙リニア空白に関する規則を含む、[RFC2616]のセクション2.1に記載されているように、プロトコル要素を記述するために本明細書で使用される拡張BNFは全く同じです。この拡張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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
簡潔にするために：「のCreationDate DAV」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とリソースの関係。リソースが検索可能にネットワークされていないアイテム、ならびにあるものを表すことができるので、リソースは0個、1個、または多数のURIマッピングを持っているため、それが可能です。 「HTTP」スキームURIにリソースをマッピングすることにより、URIを使用してリソースにHTTPプロトコル要求を提出することができます。
Path Segment - Informally, the characters found between slashes ("/") in a URI. Formally, as defined in Section 3.3 of [RFC3986].
パスセグメント - 非公式に、URIにスラッシュ（「/」）との間に見られる文字。正式には、[RFC3986]のセクション3.3で定義された通りです。
Collection - Informally, a resource that also acts as a container of references to child resources. Formally, a resource that contains a set of mappings between path segments and resources and meets the requirements defined in Section 5.
コレクション - 非公式に、また、子リソースへの参照のコンテナとして機能するリソース。正式に、経路セグメントとリソースとの間のマッピングのセットを含むリソースは、セクション5で定義された要件を満たしています。
Internal Member (of a Collection) - Informally, a child resource of a collection. Formally, a resource referenced by a path segment mapping contained in the collection.
（コレクションの）内部メンバー - 非公式に、コレクションの子リソース。正式に、経路セグメントマッピングによって参照されるリソースは、コレクションに含まれています。
Internal Member URL (of a Collection) - A URL of an internal member, consisting of the URL of the collection (including trailing slash) plus the path segment identifying the internal member.
（後続のスラッシュを含む）コレクションのURLからなる内部部材のURLに加え、内部部材を識別する経路セグメント - 内部（コレクション）メンバーURL。
Member (of a Collection) - Informally, a "descendant" of a collection. Formally, an internal member of the collection, or, recursively, a member of an internal member.
（コレクションの）メンバー - 非公式に、コレクションの「子孫」。正式に、内部コレクションのメンバー、あるいは、再帰的に、内部部材の部材。
Member URL (of a Collection) - A URL that is either an internal member URL of the collection itself, or is an internal member URL of a member of that collection.
（コレクションの）メンバーのURL - コレクション自体の内部のメンバーURLのいずれかである、またはそのコレクションのメンバーの内部のメンバーURLですURL。
Property - A name/value pair that contains descriptive information about a resource.
プロパティ - リソースについての記述情報を含む名前/値のペア。
Live Property - A property whose semantics and syntax are enforced by the server. For example, the live property DAV:getcontentlength has its value, the length of the entity returned by a GET request, automatically calculated by the server.
ライブプロパティ - その意味と構文のサーバによって強制されているプロパティ。例えば、ライブプロパティ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.
デッドプロパティ - その意味と構文サーバーによって強制されていない財産。サーバは死んでプロパティの値を記録します。クライアントは死んプロパティの構文とセマンティクスの一貫性を維持する責任があります。
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つのカテゴリがあります。ライブプロパティは、サーバによって強制その構文と意味を持っています。ライブプロパティは、プロパティの値が保護され、サーバーによって維持、およびb）プロパティの値がクライアントによって維持されているa）の例が含まれていますが、サーバーが送信された値に構文チェックを実行します。与えられた生のプロパティのすべてのインスタンスは、そのプロパティ名に関連付けられた定義に準拠しなければなりません。死者プロパティは、クライアントによって施行その構文と意味を持っています。サーバは単にそのままプロパティの値を記録します。
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スコープは、再帰的なので、XML：それはより多くのローカルスコープの属性によって上書きされていない限り、プロパティ名要素を含む任意の要素にlang属性は、プロパティ値に適用されます。プロパティは一の言語における一つの値、（または言語が未定義のままでもよい）を有することに留意されたいです。プロパティは、異なる言語または複数の言語で単一の値で複数の値を持っていません。
A property is always represented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist:
プロパティは常にプロパティ名で構成されるXML要素で表現され、「プロパティ名要素」と呼ばれます。最も簡単な例は存在しないプロパティは異なる空のプロパティです。
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
<R：表題のxmlns：R = "http://www.example.com/ns/"> </ R：タイトル>
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コンテンツの任意の種類であってもよいです。サーバはストレージとデッドプロパティの伝送に（[REC-XML-INFOSET]から用語を使用して）次のXML情報項目を保存しなければなりません。
For the property name Element Information Item itself:
プロパティ名要素情報項目自体の場合：
[namespace name]
[名前空間名]
[local name]
[ローカル名]
[attributes] named "xml:lang" or any such attribute in scope
または範囲のいずれかのような属性：[属性]「LANG XML」と命名
[children] of type element or character
型要素や文字の[子供]
On all Element Information Items in the property value:
プロパティ値のすべての要素情報項目の：
[namespace name]
[名前空間名]
[local name]
[ローカル名]
[attributes]
[属性]
[children] of type element or character
型要素や文字の[子供]
On Attribute Information Items in the property value:
プロパティ値の属性情報には：
[namespace name]
[名前空間名]
[local name]
[ローカル名]
[normalized value]
[正規化された値]
On Character Information Items in the property value:
プロパティ値の文字情報項目の場合：
[character code]
[文字コード]
Since prefixes are used in some XML vocabularies (XPath and XML Schema, for example), servers SHOULD preserve, for any Information Item in the value:
接頭辞は、いくつかのXMLボキャブラリ（例えばXPathとXMLスキーマ、）で使用されているので、サーバーは、値のいずれかの情報項目のために、保存する必要があります。
[prefix]
[プレフィックス]
XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. The above rules would also apply by default to live properties, unless defined otherwise.
XML情報セットは、上記に記載されていない属性は、サーバによって保存することができるが、クライアントはそれらが保存されている当てにしてはいけません。上記の規則は、他に定義されていない限り、プロパティを生きるためにデフォルトで適用されます。
Servers MUST ignore the XML attribute xml:space if present and never use it to change whitespace handling. Whitespace in property values is significant.
現在、決しては空白処理を変更するためにそれを使用する場合スペース：サーバーは、XML属性xmlを無視しなければなりません。プロパティ値の空白は重要です。
Consider a dead property 'author' created by the client as follows:
次のように死んでプロパティクライアントが作成した「著者」を考えてみましょう：
<D:prop xml:lang="en" xmlns:D="DAV:"> <x:author xmlns:x='http://example.com/ns'> <x:name>Jane Doe</x:name> <!-- Jane's contact info --> <x:uri type='email' added='2005-11-26'>mailto:jane.doe@example.com</x:uri> <x:uri type='web' added='2005-11-27'>http://www.example.com</x:uri> <x:notes xmlns:h='http://www.w3.org/1999/xhtml'> Jane has been working way <h:em>too</h:em> long on the long-awaited revision of <![CDATA[<RFC2518>]]>. </x:notes> </x:author> </D:prop>
<D：小道具のXML：LANG = "EN" のxmlns：D = "DAV："> <X：著者のxmlns：X = 'のhttp：//example.com/ns'> <X：名>ジェーン・ドウ</ X ：名> < - ジェーンの連絡先情報 - > <X：！URIタイプ= 'メールは' = '2005-11-26' を追加>のmailto：jane.doe@example.com </ X：URI> <X： URI> <X：リアクションのxmlns：H = 'のhttp：//www.w3.org/ URIタイプ= 'ウェブは、'= '2005-11-27'> http://www.example.com </ Xを追加しました1999 / XHTML '>ジェーンが取り組んできた道<H：em>のあまりに</ H：！em>の長期の待望の改訂版の<[CDATA [<RFC2518>]]>。 </ X：ノート> </ X：著者> </ D：小道具>
When this property is requested, a server might return:
このプロパティが要求されると、サーバーが返す可能性があります：
<D:prop xmlns:D='DAV:'><author xml:lang='en' xmlns:x='http://example.com/ns' xmlns='http://example.com/ns' xmlns:h='http://www.w3.org/1999/xhtml'> <x:name>Jane Doe</x:name> <x:uri added="2005-11-26" type="email" >mailto:jane.doe@example.com</x:uri> <x:uri added="2005-11-27" type="web" >http://www.example.com</x:uri> <x:notes> Jane has been working way <h:em>too</h:em> long on the long-awaited revision of <RFC2518>. </x:notes> </author> </D:prop>
<D：プロペラのxmlns：D = 'DAV：'> <著者のxml：langの=のxmlns 'EN'：X = 'HTTP：//example.com/ns' のxmlns = 'HTTP：//example.com/ns' xmlns：H = 'のhttp：//www.w3.org/1999/xhtml'> <X：名>ジェーン・ドウ</ X：名> <X：URIを追加= "2005-11-26" タイプ= "メール">のmailto：jane.doe@example.com </ X：URI> <X：URIを追加=" 2005-11-27" タイプ= "ウェブ"> http://www.example.com </ X：URI > <X：ノート>ジェーンが作動された方法<H：EM>すぎる</ H：EM>ロング＆LTの待望のリビジョンに、RFC2518＆GT ;. </ X：ノート> </著者> </ D：小道具>
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),
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.
これは名前空間の衝突を防ぎ、管理制御の程度を変化させることを提供するためのURIに基づいてXML名前空間機構は、（[RFC3986]）、名前プロパティに使用されます。
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.
これは、リソースのプロパティの名前空間での衝突を引き起こすよう最後に、単一のリソースに二度同じプロパティを定義することはできません。
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、多対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つ以上の経路セグメントによって識別することができる（例えば、/サーブレット/ WebDAVの/ ...）
Neither HTTP/1.1 nor WebDAV requires that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.
どちらもHTTP / 1.1やWebDAVは、全体のHTTP URL名前空間は一貫していることが必要です - WebDAVの互換リソースは、親コレクションを持っていないかもしれません。しかし、特定のWebDAVメソッドは、名前空間の不整合が生じる結果を生成することは禁止されています。
As is implicit in [RFC2616] and [RFC3986], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
[RFC2616]と[RFC3986]で暗黙的であるとして、回収資源などのリソースは、複数のURIによって識別することができます。たとえば、リソースが複数のHTTP URLで識別することができます。
Collection resources differ from other resources in that they also act as containers. Some HTTP methods apply only to a collection, but some apply to some or all of the resources inside the container defined by the collection. When the scope of a method is not clear, the client can specify what depth to apply. Depth can be either zero levels (only the collection), one level (the collection and directly contained resources), or infinite levels (the collection and all contained resources recursively).
彼らはまた、コンテナとして機能という点でコレクションリソースは他のリソースとは異なります。いくつかのHTTPメソッドはコレクションにのみ適用されますが、いくつかは、コレクションで定義されたコンテナ内のリソースの一部またはすべてに適用されます。この方法の適用範囲が明確でない場合は、クライアントは、適用するかを深さを指定することができます。深さは、ゼロレベル（のみコレクション）、一段階（コレクションと直接含まれるリソース）、または無限レベル（コレクションおよびすべての含まれるリソース再帰的に）することができます。
A collection's state consists of at least a set of mappings between path segments and resources, and a set of properties on the collection itself. In this document, a resource B will be said to be contained in the collection resource A if there is a path segment mapping that maps to B and that is contained in A. A collection MUST contain at most one mapping for a given path segment, i.e., it is illegal to have the same path segment mapped to more than one resource.
コレクションの状態は、少なくともパスセグメントとリソース間のマッピングのセット、コレクション自体のプロパティのセットからなります。この文書では、リソースBは、Bにマッピングし、それはAに含まれているコレクションは、指定されたパスセグメントに対して最大1つのマッピングに含まれなければならない経路セグメントマッピングが存在する場合、コレクションリソースAに含まれると言うことであろうすなわち、複数のリソースにマッピングされた同一の経路セグメントを有することが違法です。
Properties defined on collections behave exactly as do properties on non-collection resources. A collection MAY have additional state such as entity bodies returned by GET.
コレクションに定義されたプロパティは、非コレクションリソースのプロパティがそうであるように正確に動作します。コレクションは、GETで返されるエンティティボディとして追加の状態を持っているかもしれません。
For all WebDAV-compliant resources A and B, identified by URLs "U" and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain exactly one mapping from "blah" to B.
全てのWebDAV準拠リソースAおよびBは、それぞれ、URLの「U」及び「V」によって識別されるような「V」が「U /セグメント」は、Aは、「セグメント」からのマッピングを含むコレクションでなければなりませんに等しいことB.そうに、「http://example.com/bar/blah」URLと、リソースBは、WebDAV準拠しており、場合「http://example.com/bar/」URLと、リソースAは、WebDAVに準拠し、そのリソースがある場合コレクションでなければならず、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結果がマッピングを識別するために、これらの同等のセグメントのいずれかを選択することになるので、マッピングされていない一つのセグメント当たり、マッピングごとにPROPFIND応答要素が存在するであろうことに留意されたいです。
Collection resources MAY have mappings to non-WebDAV-compliant resources in the HTTP URL namespace hierarchy but are not required to do so. For example, if resource X with URL "http://example.com/bar/blah" is not WebDAV compliant and resource A with "URL http://example.com/bar/" identifies a WebDAV collection, then A may or may not have a mapping from "blah" to X.
コレクションのリソースは、HTTP URL名前空間の階層に非のWebDAV準拠のリソースへのマッピングを持っているかもしれませんが、その必要はありません。例えば、URLとリソースX「http://example.com/bar/blah」場合は、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を指して、レスポンスのContent-Locationヘッダを返すべきです。クライアントがhttp://example.com/blah（末尾のスラッシュ）上のメソッドを呼び出した場合の動作は、（スラッシュ末尾）http://example.com/blah/で呼び出されたかのように、例えば、サーバが応答することができます、および値http://example.com/blah/でのContent-Locationヘッダを返すべきです。サーバは、コレクションを参照するURLを生成どこ、サーバーは、末尾にスラッシュを含めるべきです。一般的には、クライアントは、コレクション名の末尾にスラッシュ形式を使用すべきです。クライアントは最後のスラッシュのフォームを使用しない場合、クライアントは、リダイレクト応答を確認するために準備する必要があります。クライアントは、DAVを見つけます：リソースはコレクションであるかどうかを確認するにはURLよりも信頼性の高い性質を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」からOPTIONS応答が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 /リンク」へのGET要求に302のステータスで応答することになるが、例えば、「/ COL /リンクは」、「/ COL /」のメンバーとして表示されない場合があります。したがって、URL「/ COL /リンクは、」確かにマップされます。同様に、動的に生成されたページはこのように、このリソースが「/ COL /」のメンバーとして表示されていない、まだGETリクエストにOK 200で応答可能性がある、「/col/index.html」からURLマッピングを持っているかもしれません。
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をサポートするサーバーです。サーバが「/ COL / A」、したがって、大文字と小文字を区別しないURLを実装することができる「/ COL /」まだのみ「a」または「A」のいずれかが「/ COL」のメンバーをリストする際に報告され、同じリソースを識別する。サーバが同等にセグメントのセットを扱う場合には、サーバは、PROPFIND応答において一貫して選択されたマッピングごとに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つのクライアントが指定したパラメータに亘って変化することを可能に関わる主体の数（排他対が共有される）とアクセスの種類を付与します。この文書では、唯一のアクセスタイプのロックを定義し、書きます。しかし、構文は拡張可能であり、他のアクセスタイプのロックの最終的な仕様を可能にします。
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.
このセクションでは、振る舞いをロックする方法についての簡潔なモデルを提供します。その後のセクションでは、いくつかの概念についてより詳細な情報を提供し、これらのモデルの文に戻って参照します。いずれかの方法をカバーする規範的な文がここに集まっているのに対し、LOCKとメソッドの処理のロックを解除するために、関連する規範的ステートメントは、これらの方法のセクションに記載されています。
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.
そのリソースのURLにLOCK要求が新しいロックを作成するとき2.リソースを直接ロックされます。新しいロックの「ロック・ルート」は、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:
深さ無限ロックLでロックされているコレクション4.は、すべてのメンバー・リソースが間接的にロックされています。そのようなコレクションのメンバーシップの変更は、間接的にロックされたリソースのセットに影響を与えます。
* 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.
* 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.ロック・トークンは、リクエストに「提出」されます。
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ベースの分散オーサリングシステムからの経験が排他ロックは、多くの場合、あまりにも剛性であることが示されたため、共有ロックが含まれています。排他ロックは、特定の編集プロセスを強制するために使用されています、排他ロックを取り出しリソースを読み、編集を実行し、リソースを作成し、ロックを解除します。この編集プロセスは、プログラムがクラッシュした場合や、ロックの作成者がリソースのロックを解除せずに離れたとき、例えば、ロックが常に適切に解放されないという問題がありました。両方のタイムアウト（セクション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つのプリンシパルが同じリソース上の共有書き込みロックを取り出した場合はこのように、5つのロックと5つのロック・トークン、各主体の1が存在します。
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.
サーバは、すべてのユーザーから、または匿名ユーザーからLOCK要求を受け入れるようにするために必要はありません。
Note that having a lock does not confer full privilege to modify the locked resource. Write access and other privileges MUST be enforced through normal privilege or authentication mechanisms, not based on the possible obscurity of lock token values.
ロックを持つことがロックされたリソースを変更するための完全な権限を付与しないことに注意してください。書き込みアクセスおよびその他の権限はロック・トークンの値の可能なあいまいさに基づくのではなく、通常の特権または認証メカニズムを通じて実施されなければなりません。
A lock token is a type of state token that identifies a particular lock. Each lock has exactly one unique lock token generated by the server. Clients MUST NOT attempt to interpret lock tokens in any way.
ロックトークンは、特定のロックを識別する状態トークンのタイプです。各ロックは、サーバによって生成された正確に一つのユニークなロック・トークンを持っています。クライアントは、どのような方法でロック・トークンを解釈するのを試みてはいけません。
Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. Since lock tokens are unique, a client MAY submit a lock token in an If header on a resource other than the one that returned it.
ロックトークンURIは、すべての時間のためにすべてのリソースで一意である必要があります。この一意性制約は、ロックトークンは混乱を恐れることなくリソースとサーバー間で提出することができます。ロックトークンがユニークなので、クライアントはそれを返されたもの以外のリソースであればヘッダにロックトークンを提出することができます。
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.
LOCK操作が新しいロックを作成すると、新しいロック・トークンは、応答のボディにも、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.
サーバは（：lockdiscovery財産例えば、DAVで）ロック・トークンを公に読めることがあります。長寿命のロックは、リソースの所有者（ロックを取得したクライアントがロックをクリーンアップする前にクラッシュしたり切断されている場合があります）によって除去することができるように読めるロックトークンを作製するための1つのユースケースがあります。ユーザーの指導の下でUNLOCKを使用する場合を除き、クライアントが別のクライアントのインスタンスが作成したロック・トークンを使用しないでください。
This specification encourages servers to create Universally Unique Identifiers (UUIDs) for lock tokens, and to use the URI form defined by "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]). However, servers are free to use any URI (e.g., from another scheme) so long as it meets the uniqueness requirements. For example, a valid lock token might be constructed using the "opaquelocktoken" scheme defined in Appendix C.
この仕様は、ロック・トークンのための汎用一意識別子（UUIDを）作成するために、及び「汎用一意識別子（UUID）URN名前空間」（[RFC4122]）によって定義されたURIの形式を使用するようにサーバーを奨励します。ただし、サーバは、それが一意性の要件を満たしているとして（他の方式から、例えば）任意のURIを自由に使用できます。例えば、有効なロック・トークンは、付録Cに定義された「opaquelocktoken」スキームを使用して構築される可能性があります
Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
例： "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.
タイムアウトが満了した場合、ロックを削除する必要があります。この場合、サーバは、UNLOCKメソッドは、そのオーバーライド権限で実行タイムアウトロックのロック・トークンを使用してリソース上のサーバによって実行されたかのように行動しなければなりません。
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.
サーバーロックのサポートはオプションなので、サーバー上のリソースをロックしようとしているクライアントは、サーバがサポートするロック機能を決定するために最善のロックと希望を試す、または発見のいくつかのフォームを行うことができます。これは、ロック機能の発見として知られています。 supportedlockプロパティ：クライアントは、サーバーがDAVを取得してサポートしているロックの種類を判別することができます。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:supportedlock property.
LOCKメソッドをサポートする任意のDAV準拠のリソースは、DAVをサポートしなければならない：supportedlockプロパティを。
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the DAV:lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and MAY even provide the lock tokens.
第2主は最初のプリンシパルが誰であるかを知ることができるようにするために別のプリンシパルロックプリンシパルがアクセスしたいリソースなら、それは便利です。この目的のために、DAV：lockdiscoveryプロパティが用意されています。このプロパティは、すべての未解決のロックを一覧表示し、その種類を説明し、さらにロック・トークンを提供することができます。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:lockdiscovery property.
LOCKメソッドをサポートする任意のDAV準拠のリソースは、DAVをサポートしなければならない：lockdiscoveryプロパティを。
This section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification.
このセクションでは、書き込みロックのタイプに固有の意味を説明しています。書き込みロックは、ロック・タイプの特定のインスタンスであり、そして本明細書に記載さだけロックタイプです。
An exclusive write lock protects a resource: it prevents changes by any principal other than the lock creator and in any case where the lock token is not submitted (e.g., by a client process other than the one holding the lock).
排他的書き込みロックは、リソースを保護する：それはロック作成者以外の任意の他の主によって、ロックトークンが（例えば、ロックを保持しているもの以外のクライアント・プロセスによって）送信されていないどのような場合に変更することを防止します。
Clients MUST submit a lock-token they are authorized to use in any request that modifies a write-locked resource. The list of modifications covered by a write-lock include:
クライアントは、それらが書き込みロックされたリソースを変更するすべての要求に使用することが許可されたロックトークンを提出しなければなりません。書き込みロックでカバー変更のリストが含まれます：
1. A change to any of the following aspects of any write-locked resource:
1.任意の書き込みロックされたリソースの次の局面のいずれかへの変更は：
* any variant,
*任意の変異体、
* any dead property,
*デッドプロパティ、
* any live property that is lockable (a live property is lockable unless otherwise defined.)
*ロック可能である任意のライブプロパティは、（別途定義されない限り、ライブプロパティがロック可能です。）
2. For collections, any modification of an internal member URI. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. More discussion on write locks and collections is found in Section 7.4.
コレクション2.、内部部材URIの任意の修飾。コレクションのURIを考慮する内部部材は、それが添加される場合、改変、削除、または別のリソースを特定することができます。書き込みロックとコレクションの詳細な議論はセクション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.別のリソースに又は全くリソースのいずれかに書き込みロックのルートのマッピングの変更、（例えば、DELETE）。
Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and MKCOL are affected by write locks. All other HTTP/WebDAV methods defined so far -- GET in particular -- function independently of a write lock.
HTTPおよびWebDAV、PUT、POST、PROPPATCH、LOCK、UNLOCK、MOVEで定義された方法のうち、（宛先リソースの）コピー、削除、およびMKCOLは、書き込みロックの影響を受けています。他のすべてのHTTP / WebDAVメソッドが定義され、これまで - 独立書き込みロックの機能 - 特にGET。
The next few sections describe in more specific terms how write locks interact with various operations.
次のいくつかのセクションでは、ロックは様々な操作と対話する書き込み方法、より具体的な用語をで説明します。
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined as lockable are guaranteed not to change while write locked.
書き込みロックのないものは、リソースのプロパティを変更しないかもしれませんが、ライブプロパティの値を変更することは、そのスキーマの要件に、ロックされながらも、まだ可能です。ロック可能として定義されている唯一の死者の特性やライブプロパティは書き込みロックしながら、変化しないことが保証されています。
Although the write locks provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario:
書き込みロックが失われた更新を防止することでいくつかの助けを提供しますが、彼らは更新が失われないことを保証することはできません。以下のシナリオを考えます：
Two clients A and B are interested in editing the resource 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking.
2つのクライアントAとBは、リソース「のindex.html」を編集するに興味を持っています。クライアントAは、HTTPクライアントではなく、WebDAVクライアントであり、従ってロックを実行する方法を知りません。
Client A doesn't lock the document, but does a GET, and begins editing.
クライアントAは、文書をロックしますが、GETを行い、編集を開始しません。
Client B does LOCK, performs a GET and begins editing.
クライアントBは、LOCKは、GETを実行し、編集を開始しますありません。
Client B finishes editing, performs a PUT, then an UNLOCK.
クライアントBは、編集を終了し、次にPUT、UNLOCKを行います。
Client A performs a PUT, overwriting and losing all of B's changes.
クライアントAは、Bのすべての変更を上書きし、失う、PUTを実行します。
There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK.
WebDAVプロトコル自体がこのような状況を防ぐことができない理由はいくつかあります。まず、それがロックを理解していないHTTPクライアントとの互換性がなければならないため、ロックを使用するすべてのクライアントを強制することはできません。第二に、それがために予約およびロックの上にではなく、合併に依存しているそのうちのいくつかはリポジトリの実装、各種のロックをサポートするためのサーバーを必要とすることはできません。最後に、ステートレスであること、それがLOCK / GET / PUT / UNLOCKのような一連の操作を強制することはできません。
WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources.
ロックをサポートするWebDAVサーバは、クライアントが誤ってそれらを変更する前に、リソースをロックするようにクライアントを必要とすることによって、お互いの変更を上書きする可能性を減らすことができます。このようなサーバーでは、効果的にリソースを変更するからHTTP 1.0とHTTP 1.1クライアントを防止するであろう。
WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking.
WebDAVクライアントは、彼らがロックをサポートWebDAVサーバーと対話するたびに（少なくともデフォルトでは）操作のロック/取得/書き込み/ロック解除シーケンスを使用して善良な市民することができます。
HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources.
HTTP 1.1クライアントがリソースを変更する任意の要求であればマッチヘッダーのエンティティタグを使用することにより、他のクライアントの変更を上書き避け、善良な市民ことができます。
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にLOCK要求を送信する機能を提供します。これは、新しいリソース（別の方法は、[RFC2616]のセクション14.26で指定されている場合 - なし - マッチヘッダーを使用することです）の創設に失われた更新の問題を回避するための簡単な方法です。これは、作成者の使用のためにすぐに新しいリソースをロックの副次的な利点があります。
Note that the lost-update problem is not an issue for collections because MKCOL can only be used to create a collection, not to overwrite an existing collection. When trying to lock a collection upon creation, clients can attempt to increase the likelihood of getting the lock by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation, there's no guarantee this will work).
MKCOLが唯一の既存のコレクションを上書きしないように、コレクションを作成するために使用することができるので、失われた更新の問題は、コレクションの問題ではないことに注意してください。作成時にコレクションをロックしようとすると、クライアントは一緒にMKCOLとLOCKリクエストをパイプラインでロックを取得する可能性を高めるために試みることができます（ただし、これは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に成功したロック要求は空の内容でロックされた（非コレクション）リソースの作成をもたらさなければなりません。その後、（正しいロックトークンを使用して）成功したPUT要求は、リソースのためのコンテンツを提供します。したがって、サーバーがデフォルトまたは空の値を使用して、正しい値のため、その後のPUT要求に依存します、LOCK要求はContent-Typeやコンテンツ言語を提供するために、クライアントのための機構がないことに注意してください。
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:
LOCKで作成されたリソースは空ですが、それ以外は通常のリソースとしてあらゆる方法で動作します。これは、同じリソースへのLOCK要求に続いて、空体（およびContent-TypeとContent-言語が指定されていない場合）、とPUT要求によって作成されたリソースと同じような動作をします。このモデルでは、ロックされた空のリソースから次のとおりです。
o Can be read, deleted, moved, and copied, and in all ways behaves as a regular non-collection resource.
oは、読んで、削除、移動、およびコピーされ、すべての方法で、通常の非収集リソースとして動作することができます。
o Appears as a member of its parent collection.
oは親収集のメンバーとして表示されます。
o SHOULD NOT disappear when its lock goes away (clients must therefore be responsible for cleaning up their own mess, as with any other operation or any non-empty resource).
oはそのロックがなくなったとき（クライアントは、したがって、他の操作または任意の非空のリソースと同じように、自分自身の混乱をクリーンアップするための責任である必要があります）消えない（SHOULD NOT）。
o MAY NOT have values for properties like DAV:getcontentlanguage that haven't been specified yet by the client.
クライアントがまだ指定されていませんgetcontentlanguageます。o DAVのようなプロパティの値がない場合があります。
o Can be updated (have content added) with a PUT request.
oはPUTリクエストで（コンテンツが追加されている）に更新することができます。
o MUST NOT be converted into a collection. The server MUST fail a MKCOL request (as it would with a MKCOL request to any existing non-collection resource).
oは、コレクションに変換してはなりません。 （それは、既存の非収集リソースへのMKCOL要求と同じように）サーバはMKCOL要求に失敗しなければなりません。
o MUST have defined values for DAV:lockdiscovery and DAV: supportedlock properties.
lockdiscoveryとDAV：supportedlockプロパティoはDAVの値を定義している必要があります。
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をもたらす）を使用することによって、リソースが作成されたことを示さなければなりません。既存のリソースへのLOCK要求と同様に、lockdiscoveryプロパティ：ボディはまだDAVを含める必要があります。
The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH.
クライアントは、PUT、おそらくPROPPATCHを使用して、すぐにそれをロックした後にロックされた空のリソースを更新することが期待されます。
Alternatively and for backwards compatibility to [RFC2518], servers MAY implement Lock-Null Resources (LNRs) instead (see definition in Appendix D). Clients can easily interoperate both with servers that support the old model LNRs and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET, and by not relying on specific properties of LNRs.
あるいは、そして、[RFC2518]への後方互換性のために、サーバは（付録Dで定義を参照）の代わりに（LNRs）をロックヌルリソースを実施することができます。クライアントは、簡単に古いモデルLNRsのみMKCOLまたはGET、マップされていないURLにLOCKした後でないPUT、およびLNRsの特定の性質に依存しないで試行することにより、「空のリソースをロック」の推奨モデルをサポートするサーバーの両方を相互運用することができます。
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コレクションのうち、内部メンバーを移動し、
o MOVE an internal member into the collection,
Oコレクションに内部メンバーを移動し、
o MOVE to rename an internal member within a collection,
O、コレクション内の内部メンバーの名前を変更するには、Move
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として追加するリソースのURLが発生した場合は、新しいリソースを自動的にロックによって保護されなければなりません。例えば、収集/ A / B /次いで/ A / B / Cは、書き込みロックに追加されるリソース、ロックおよびリソース/ 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を実行します。このシナリオでは、それは主Aの信任状で作用しているので、ロックは、主ではなく、プログラム、及びそのプログラムBに関連付けられているので、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.
これらの衝突を防ぐために、ロック・トークンは、方法が変更される可能性や方法が失敗しなければなりませんすべてのロックされたリソースのための認可校長に提出しなければなりません。それがもしヘッダに表示されたときにロックトークンが送信されます。例えば、リソースがある場合に移動すると、送信元と宛先の両方がロックされ、次いで、2つのロック・トークンは、IFヘッダ、ソース用と送信先の他に提出されなければなりません。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1 Host: www.example.com Destination: http://www.example.com/users/f/fielding/index.html If: <http://www.example.com/users/f/fielding/index.html> (<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
COPY /~fielding/index.html HTTP / 1.1ホスト：www.example.com先：http://www.example.com/users/f/fielding/index.htmlの場合：<のhttp：//www.example。 COM /ユーザ/ F /守備/ 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.
この例では、ソースと宛先の両方がロックされているにもかかわらず、唯一のロックトークンは、（先にロックするためのもの）を提出しなければなりません。ソースリソースがCOPYによって修飾され、書き込みロックによって、したがって影響を受けないためです。この例では、ユーザエージェント認証は以前に、基礎となるトランスポート層では、HTTPプロトコルの範囲外の機構を介して発生しています。
Consider a collection "/locked" with an exclusive, depth-infinity write lock, and an attempt to delete an internal member "/locked/ member":
排他的、深さ無限の書き込みロックを「ロック/」コレクション、および内部部材「/ロック/メンバー」を削除しようとする試みを検討してください。
>>Request
>>リクエスト
DELETE /locked/member HTTP/1.1 Host: example.com
DELETE /ロック/メンバーHTTP / 1.1ホスト：example.com
>>Response
>>回答
HTTP/1.1 423 Locked Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 423ロックのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:lock-token-submitted> <D:href>/locked/</D:href> </D:lock-token-submitted> </D:error>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：エラーのxmlns：D = "DAV："> <D：ロックトークン提出> <D：HREF> /ロック/ </ D ：HREF> </ D：ロックトークン提出> </ D：エラー>
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.
したがって、クライアントはそれを成功させるための要求でロックトークンを提出する必要があります。そのために、もしヘッダ（10.4項を参照）の様々な形態を使用することができます。
"No-Tag-List" format:
「ノー・タグ・リスト」形式：
If: (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
もし：（<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>)
もし：<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>)
もし：<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ヘッダーに表示され、もしヘッダ自体が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.
COPYメソッドの呼び出しは、ソース上のアクティブなすべての書き込みロックを複製してはなりません。先に述べたようしかし、場合深さ無限ロックでロックされているコレクションにコピーコピーリソースは、リソースロックに追加されます。
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.
書き込みロックされたリソースに成功したMOVE要求は、リソースと書き込みロックを移動してはなりません。先の既存のロックがある場合は、サーバーは、先のロック範囲に移動するリソースを追加しなければなりません。 MOVEは、リソースの深さ無限大のロックを持っているコレクションの子を行う場合たとえば、そのリソースはそのコレクションのロックに追加されます。深さ無限ロック付きリソースが同じロックの範囲内で先に移動された場合に加えて、（例えば、ロックによって覆われた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.
クライアントは二回同じ書き込みロック要求を提出してはなりません。クライアントは常にそれが既にロックされているリソースに対する要求を行うためにもしヘッダ内のロック・トークンを含める必要がありますので、それが同じロック要求を再送信されて認識していることに注意してください。
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ヘッダーではなく、本体なしでLOCK要求を提出することができます。ロックに関連付けられているすべてのタイマーがでなければならないことを、最低限の既存のロック（意味は、「リフレッシュ」するために使用されるLOCK要求は、このフォーム - 本文なしでLOCK要求を受けたサーバは、新しいロックを作成してはいけません）リセットします。
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.
クライアントは、彼らのロックリフレッシュ要求を任意の値のタイムアウトヘッダを提出することができます。サーバは、いつものように、クライアントから提出されたタイムアウトヘッダを無視することができ、サーバはそれがLOCKリフレッシュ応答に新しい値をアドバタイズして、ロックを使用する前のタイムアウト時間と異なるタイムアウト時間とロックを更新するかもしれません。
If an error is received in response to a refresh LOCK request, the client MUST NOT assume that the lock was refreshed.
エラーがリフレッシュLOCK要求に応答して受信された場合、クライアントは、ロックが更新されたと仮定してはいけません。
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は、メソッドの出力、ならびに入力をXMLの拡張及び国際利点を提供し、方法からの応答をエンコードするためのWebDAVに使用されます。
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は、要求または応答ボディのために使用されている場合は、Content-Typeのタイプは、アプリケーション/ XMLであるべきです。実装は、リクエストとレスポンスボディ内のテキスト/ XMLおよびアプリケーション/ xmlの両方を受け入れなければなりません。 text / 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（悪いRequest）ステータスコードと問題を説明するオプションのレスポンスボディで、例えば、（彼らは整形式の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の取り扱いに注意します。このセクションのルールは、リソースのURLにマルチステータス応答で「HREF」要素ではなく、先に、ヘッダリソースの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.
Request-URI、又は完全なURIに対して解決されている相対的基準を使用して：送信者は2つの方法の選択肢を有しています。サーバーは、マルチステータス応答内のすべて「のhref」の値が同じ形式を使用していることを保証しなければなりません。
WebDAV only uses one form of relative reference in its extensions, the absolute path.
WebDAVは唯一その拡張における相対的基準の一形態では、絶対パスを使用します。
Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )
シンプル-REF =絶対URI | （パス絶対[ "？" クエリ]）
The absolute-URI, path-absolute and query productions are defined in Sections 4.3, 3.3, and 3.4 of [RFC3986].
絶対URI、パス絶対およびクエリプロダクションはセクション4.3で定義され、3.3、および[RFC3986]の3.4。
Within Simple-ref productions, senders MUST NOT:
シンプル-refの作品の中では、送信者はいけません。
o use dot-segments ("." or ".."), or
O（「」または「..」）ドットセグメントを使用し、又は
o have prefixes that do not match the Request-URI (using the comparison rules defined in Section 3.2.3 of [RFC2616]).
O（[RFC2616]のセクション3.2.3で定義された比較ルールを使用して）のRequest-URIに一致しないプレフィクスを有します。
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:
内部のメンバーURL http://example.com/sample/a%20testと以下のPROPFIND要求を収集http://example.com/sample/を考えてみます。
>>Request:
>>リクエスト：
PROPFIND /sample/ HTTP/1.1 Host: example.com Depth: 1
PROPFIND /サンプル/ 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 '/サンプル/' と '/サンプル/％の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.
サーバが内部「テスト」としてメンバーのリソースを格納することができるにもかかわらず、それは（[RFC3986]のセクション2.1を参照）URI参照内で使用される場合パーセントエンコードされなければならないことに留意されたいです。また、法的な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]を参照）すべての応答にDateヘッダが必要に留意されたいです。
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は、キャッシュ制御のために、ではなくてETag変更日付を使用することを推奨しています、そしてオーサリングのためてETagを好むためにさらに強い理由があります。 ETagが失われた更新の問題を回避するために、ロックと一緒に必要なためて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は（[RFC2616]のセクション13.3.3を参照）弱いてETagよりユースケースをオーサリングするためのはるかに有用です。セマンティック等価は便利な概念であり得るが、それは、ドキュメントタイプとアプリケーションの種類に依存し、相互運用性は、本明細書および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.
（すなわち、ETagのリソースがPUTリクエストのボディへのオクテットのためのオクテット同等であることを意味するかどうか、またはかどうかをPUT応答中のETagの意味が明確に、このドキュメントまたはRFC 2616のいずれかで定義されていないことに注意してくださいサーバーは）貯蔵時に文書の書式や内容の軽微な変更を行った可能性があります。これは、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」とは、「Last-Modifiedの」ことに注意してください（参照[RFC2616]、セクション14.19と14.29）は（ないリソースあたり）URLごとに定義されており、キャッシングのためにクライアントによって使用されています。任意のURLは、「Last-Modifiedの」値はインクリメントしなければならない○：そのためのサーバは、（COPY、MOVE、DELETE、PUT、またはMKCOLなど）URL名前空間に影響を与える操作を実行すると、特に、彼らのセマンティクスを保護ないことを確認する必要があります（タイムスタンプ分解能の限界内で）表現がGET変化に返されるたびに。
o For any given URL, an "ETag" value MUST NOT be reused for different representations returned by GET.
任意のURLに対してoは、「ETagを」値がGETで返さ異なる表現のために再利用してはなりません。
In practice this means that servers
実際には、これはそのサーバを意味します
o might have to increment "Last-Modified" timestamps for every resource inside the destination namespace of a namespace operation unless it can do so more selectively, and
それは、より選択的に行うことができない限り、Oは、名前空間操作の先のネームスペース内のすべてのリソースのための「Last-Modifiedの」タイムスタンプをインクリメントする必要がある場合があります、と
o similarly, might have to re-assign "ETag" values for these resources (unless the server allocates entity tags in a way so that they are unique across the whole URL namespace managed by the server).
（彼らはサーバで管理全体のURL名前空間全体で一意になるように、サーバーが邪魔にエンティティタグを割り当てていない限り）O同様に、これらのリソースのために再割り当て「のETag」値を持っているかもしれません。
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.
これらの考察はまた、以前にマップされたURLに新しいリソースを作成するために、PUTを使用して、それ以来、削除されたように、特定のユースケースに適用されることに注意してください。
Finally, WebDAV properties (such as DAV:getetag and DAV: getlastmodified) that inherit their semantics from HTTP headers must behave accordingly.
最後に、（例えばDAVなど：getetagとDAV：getlastmodified）のWebDAVプロパティHTTPヘッダからその意味を継承応じて動作しなければなりません。
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メソッドは、リソースは、任意の内部部材を有していない場合、Request-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.
クライアントは、PROPFIND要求に「0」、「1」、又は「無限」の値を有する奥行きヘッダを提出しなければなりません。サーバーは、WebDAV準拠の資源の「0」と「1」の深さの要求をサポートしなければならないし、「無限大」要求をサポートする必要があります。実際には、無限の深さの要求のためのサポートが原因この動作に関連したパフォーマンスとセキュリティの懸念に、無効にすることができます。 「：無限の深さ」ヘッダ含まれていたかのようにサーバは深さヘッダーなしで要求を扱うべきです。
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の要求であるかのように空のPROPFIND要求本体は扱わなければなりません。
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要素が含まれているコンテンツタイプtext / 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に準拠していないリソースのための任意の応答 '要素を含めるべきではありません。各「応答」要素は、支柱XML要素のプロパティが定義されているリソースのURLが含まれている「のhref」要素を含まなければなりません。コレクションリソースのPROPFINDの結果は、そのためのエントリの重要ではないフラットリストとして返されます。リソースが指定された名前のプロパティの値を1つのみ有することができるので、プロパティのみPROPFIND応答に一度現れることがあります。
Properties may be subject to access control. In the case of 'allprop' and 'propname' requests, if a principal does not have the right to know whether a particular property exists, then the property MAY be silently excluded from the response.
プロパティは、アクセス制御の対象となることがあります。プリンシパルが特定のプロパティが存在するかどうかを知る権利を持っていない場合は、「allprop」と 'PROPNAMEの要求の場合には、そのプロパティは黙って応答から除外することができます。
Some PROPFIND results MAY be cached, with care, as there is no cache validation mechanism for most properties. This method is both safe and idempotent (see Section 9.1 of [RFC2616]).
ほとんどのプロパティにはキャッシュの検証メカニズムが存在しないように、一部のPROPFINDの結果は、注意して、キャッシュされる場合があります。この方法は、安全かつ冪等もある（[RFC2616]のセクション9.1を参照します）。
This section, as with similar sections for other methods, provides some guidance on error codes and preconditions or postconditions (defined in Section 16) that might be particularly useful with PROPFIND.
このセクションでは、他の方法のための同様のセクションと同様に、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 - サーバーはエラー体内前提条件コード「PROPFIND-有限深」でこのエラーを使用すべき場合には「無限」の深さヘッダーを持つコレクションにPROPFIND要求を拒否することがあります。
In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
PROPFIND応答において、個々のプロパティについての情報は、「propstat」要素（セクション14.22を参照）、それに現れる特性に関する情報を含む個人のステータス '要素を含むそれぞれの内部に戻されます。以下のリストは、「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
PROPFIND /ファイルHTTP / 1.1ホスト：www.example.comコンテンツタイプ：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox/> <R:author/> <R:DingALing/> <R:Random/> </D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：のxmlns小道具：R = "http://ns.example.com/boxschema / "> <R：bigbox /> <R：著者/> <R：DingALing /> <R：ランダム/> </ D：プロップ> </ D：PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response xmlns:R="http://ns.example.com/boxschema/"> <D:href>http://www.example.com/file</D:href> <D:propstat> <D:prop> <R:bigbox> <R:BoxType>Box type A</R:BoxType> </R:bigbox> <R:author> <R:Name>J.J. Johnson</R:Name> </R:author> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> <D:propstat> <D:prop><R:DingALing/><R:Random/></D:prop> <D:status>HTTP/1.1 403 Forbidden</D:status> <D:responsedescription> The user does not have access to the DingALing property. </D:responsedescription> </D:propstat>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：応答のxmlns：R = "http://ns.example.com/boxschema / "> <D：HREF> http://www.example.com/file </ D：HREF> <D：propstat> <D：プロペラ> <R：bigbox> <R：BoxType>ボックスタイプA </ R：BoxType> </ R：bigbox> <R：著者> <R：名> JJジョンソン</ R：名前> </ R：著者> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> <D：propstat> <D：小道具> <R：DingALing /> <R：ランダム/> </ D：プロペラ> <D：禁止状態> HTTP / 1.1 403 </ D：状態> <D：responsedescription>ユーザがDingALingプロパティへのアクセス権を持っていません。 </ D：responsedescription> </ D：propstat>
</D:response> <D:responsedescription> There has been an access violation error. </D:responsedescription> </D:multistatus>
</ D：レスポンス> <D：responsedescription>アクセス違反エラーが発生しました。 </ 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
PROPFIND /コンテナ/ HTTP / 1.1ホスト：www.example.comのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <propfind xmlns="DAV:"> <propname/> </propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <PROPFINDのxmlns = "DAV："> <PROPNAME /> </ PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://www.example.com/container/</href> <propstat> <prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox/> <R:author/> <creationdate/> <displayname/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status>
<？xml version = "1.0" エンコード= "UTF-8"？> <multistatusのxmlns = "DAV："> <レスポンス> <HREF> http://www.example.com/container/ </ HREF> <propstat > <支柱のxmlns：R = "http://ns.example.com/boxschema/"> <R：bigbox /> <R：著者/> <CreationDateプロパティ/> <DisplayNameに/> <resourcetypeの/> <supportedlock /> </小道具> <状態> HTTP / 1.1 200 OK </ステータス>
</propstat> </response> <response> <href>http://www.example.com/container/front.html</href> <propstat> <prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox/> <creationdate/> <displayname/> <getcontentlength/> <getcontenttype/> <getetag/> <getlastmodified/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus>
</ propstat> </レスポンス> <レスポンス> <HREF> http://www.example.com/container/front.html </ HREF> <propstat> <小道具のxmlns：R = "HTTP：//ns.example .COM / boxschema / "> <R：bigbox /> <CreationDateプロパティ/> <DisplayNameに/> <getcontentlength /> <GETCONTENTTYPE /> <getetag /> <getlastmodified /> <resourcetypeの/> <supportedlock /> </小道具> <ステータス> HTTP / 1.1 200 OK </ステータス> </ propstat> </レスポンス> </ 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は、すべてのプロパティの名前が返されるべきである意味、PROPNAMEのXML要素を含むPROPFIND XML要素で、コレクションリソース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.
前の例と一致して、リソースhttp://www.example.com/container/はそれに定義された6つのプロパティがありますbigboxと著者「http://ns.example.com/boxschema/」名前空間で、とのCreationDateを、 DisplayName、resourcetypeの、そしてsupportedlock "DAV：" 名前空間。
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、「コンテナ」コレクションのメンバー、それに定義された9つの性質を持っている、「http://ns.example.com/boxschema/でbigbox 「名前空間とのCreationDate、DisplayNameに、getcontentlength、GETCONTENTTYPE、getetag、getlastmodified、resourcetypeの、そして中supportedlock "DAV：" 名前空間。
This example also demonstrates the use of XML namespace scoping and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all enclosed elements. Hence, all elements that do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.
また、この例では、XML名前空間スコープとデフォルトの名前空間の使用方法を示しています。 「のxmlns」属性は、接頭辞が含まれていないので、名前空間はすべて同封の要素にデフォルトで適用されます。名前空間：このため、明示的にそれらが属する名前空間を述べていないすべての要素は、「DAV」のメンバーです。
Note that 'allprop', despite its name, which remains for backward-compatibility, does not return every property, but only dead properties and the live properties defined in this specification.
「allprop」は、下位互換性のために残され、その名前にもかかわらず、すべてのプロパティを返さないことに注意してください、だけで死んだの特性と、この仕様で定義されたライブのプロパティ。
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1 Host: www.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
PROPFIND /コンテナ/ HTTP / 1.1ホスト：www.example.com奥行：1のContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：= "DAV：" D> <D：allprop /> </ D：PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/container/</D:href> <D:propstat> <D:prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox><R:BoxType>Box type A</R:BoxType></R:bigbox> <R:author><R:Name>Hadrian</R:Name></R:author> <D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate> <D:displayname>Example collection</D:displayname> <D:resourcetype><D:collection/></D:resourcetype> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> /容器/ </ D：HREF> < D：propstat> <D：のxmlns小道具：R = "http://ns.example.com/boxschema/"> <R：bigbox> <R：BoxType>ボックスタイプA </ R：BoxType> </ R： bigbox> <R：著者> <R：名>ハドリアヌス</ R：名前> </ R：著者> <D：CreationDateプロパティ> 1997-12-01T17：42：21から08：00 </ D：CreationDateプロパティ> < D：のDisplayName>実施例コレクション</ D：表示名> <D：resourcetypeの> <D：コレクション/> </ D：resourcetypeの> <D：supportedlock> <D：lockentry> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：たlocktype> <D：書き込み/> </ D：たlocktype> </ D：lockentry> <D：lockentry> <D：LOCKSCOPE> <D：共有/> </ D：LOCKSCOPE > <D：たlocktype> <D：書き込み/> </ D：たlocktype> </ D：lockentry> </ D：supportedlock> </ D：小道具>
<D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/container/front.html</D:href> <D:propstat> <D:prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox><R:BoxType>Box type B</R:BoxType> </R:bigbox> <D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate> <D:displayname>Example HTML resource</D:displayname> <D:getcontentlength>4525</D:getcontentlength> <D:getcontenttype>text/html</D:getcontenttype> <D:getetag>"zzyzx"</D:getetag> <D:getlastmodified >Mon, 12 Jan 1998 09:25:56 GMT</D:getlastmodified> <D:resourcetype/> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> <D：レスポンス> <D：HREF> /container/front.html </ D：HREF> <D：propstat> <D：プロペラのxmlns：R = "http://ns.example.com/boxschema/"> <R：bigbox> <R：BoxType>ボックスタイプB </ R：BoxType> </ R ：bigbox> <D：CreationDateプロパティ> 1997-12-01T18：27：21から08：00 </ D：CreationDateプロパティ> <D：のDisplayName>例HTMLリソース</ D：表示名> <D：getcontentlength> 4525 </ D ：getcontentlength> <D：GETCONTENTTYPE> text / htmlの</ D：GETCONTENTTYPE> <D：getetag> "zzyzx" </ D：getetag> <D：getlastmodified>月、1998年1月12日9時25分56秒GMT </ D ：getlastmodified> <D：resourcetypeの/> <D：supportedlock> <D：lockentry> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：たlocktype> <D：書き込み/> </ D ：種類のLockType> </ D：lockentry> <D：lockentry> <D：LOCKSCOPE> <D：共有/> </ D：LOCKSCOPE> <D：たlocktype> <D：書き込み/> </ D：たlocktype> </ D：lockentry> </ D：supportedlock> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ 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リクエストは、リソースとその子、およびallprop XML要素を含むPROPFIND XML要素に適用される意味、1の深さヘッダーで資源http://www.example.com/container/に呼び出されました、要求を意味する名前とリソースで定義されているすべての死者のプロパティの値は、プラスこの仕様で定義されたすべてのプロパティの名前と値を返す必要があります。この例では、応答の「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.
CreationDate、DAV： 『http://ns.example.com/boxschema/』名前空間、DAVの「bigbox」と「著者：リソースhttp://www.example.com/container/はそれに定義された6つの性質を持っています：表示名、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つのプロパティは、WebDAVの特定、GETは、このリソースではサポートされていないので、第15項で定義されている、*取得の特性（例えば、DAV：getcontentlength）は、このリソースで定義されていません。 WebDAVの固有の性質は、「コンテナ」が8時間西GMT（DAV：のCreationDate）の時間帯で、5時42分21秒PMで、1997年12月1日に作成されたことを主張し、「例コレクション」の名前を持っている（DAV ：表示名）、収集リソースタイプ（DAV：supportedlock）：resourcetypeの）、とは排他的な書き込みと共有書き込みロック（DAVをサポートしています。
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.
CreationDateプロパティ、DAV：表示名、DAV：getcontentlength、DAV：GETCONTENTTYPE、DAV： "http://ns.example.com/boxschema/" 名前空間（ "bigbox" プロパティタイプの別のインスタンス）、DAVの 'bigbox' 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が」8時間西GMTのタイムゾーンで、午前6時27分21秒PMで、1997年12月1日に作成されたことを主張する（DAV：のCreationDate）、「例HTMLリソースの名前を持っています「（DAV：表示名）、4525バイト（DAV：getcontentlength）のコンテンツ長、のMIMEタイプ "text / htmlの"（DAV：GETCONTENTTYPE）のエンティティタグ "zzyzx"（DAV：getetag）、最後に変更されました9時25分56秒GMT（DAV：getlastmodified）で1998年1月12日（月曜日）、上、それはコレクションではないことを意味し、空のリソースタイプがあります（DAV：resourcetypeのは）、および（排他書き込み、共有書き込みロックの両方をサポートしていますDAV：supportedlock）。
>>Request
>>リクエスト
PROPFIND /mycol/ HTTP/1.1 Host: www.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
PROPFIND / mycol / HTTP / 1.1ホスト：www.example.com奥行：1のContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> <D:include> <D:supported-live-property-set/> <D:supported-report-set/> </D:include> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：allprop /> <D：含める> <D：サポート・ライブproperty-サポート・レポート・セット/> </ D：/> <D設定などが> </ 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.
PROPPATCHメソッドは、設定および/またはRequest-URIによって識別されるリソース上で定義されたプロパティを削除する要求本体に指定された命令を処理します。
All DAV-compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements. Execution of the directives in this method is, of course, subject to access control constraints. DAV-compliant resources SHOULD support the setting of arbitrary dead properties.
全てのDAV準拠のリソースは、PROPPATCHメソッドをサポートしなければならないとpropertyupdateを使用して、指定された命令を処理しなければならない、セット、およびXML要素を削除します。この方法のディレクティブの実行は、当然のことながら、制御の制約にアクセスすることがあります。 DAV準拠のリソースは、任意の死者のプロパティの設定をサポートする必要があります。
The request message body of a PROPPATCH method MUST contain the propertyupdate XML element.
PROPPATCHメソッドのリクエストメッセージ本体はpropertyupdate XML要素を含まなければなりません。
Servers MUST process PROPPATCH instructions in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus, if any error occurs during processing, all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in Sections 14.23 and 14.26.
サーバは、文書順序（順序は無関係であることが通常ルールの例外）でPROPPATCHの命令を処理しなければなりません。命令は、どちらかのすべての実行されなければならないか、どれも実行されません。任意の処理中にエラーが発生した場合従って、全て実行された命令を元に戻すと、適切なエラー結果を返さなければなりません。命令処理の詳細は、セットの定義で発見され、セクション14.23と14.26の指示を削除することができます。
If a server attempts to make any of the property changes in a PROPPATCH request (i.e., the request is not rejected for high-level errors before processing the body), the response MUST be a Multi-Status response as described in Section 9.2.1.
サーバはPROPPATCH要求におけるプロパティの変更のいずれかを作るしようとした場合、セクション9.2.1に記載したように、応答はマルチステータス応答する必要があります（すなわち、要求は、本体を処理する前に高レベルのエラーを拒否されていません） 。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
この方法は、（[RFC2616]のセクション9.1を参照）冪等が、安全ではありません。このメソッドへの応答はキャッシュされてはなりません。
In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
PROPPATCH応答において、個々のプロパティについての情報は、「propstat」要素（セクション14.22を参照）、それに現れる特性に関する情報を含む個人のステータス '要素を含むそれぞれの内部に戻されます。以下のリストは、「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） - プロパティセットまたは変更が成功しました。これは一つの特性のために表示された場合、それが原因PROPPATCHの原子に、応答内のすべてのプロパティに表示されていることに注意してください。
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
403（禁止） - クライアントは、サーバが指定しないことを選択した理由のために、プロパティのいずれかを変更することはできません。
403 (Forbidden): The client has attempted to set a protected property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'cannot-modify-protected-property' inside the response body.
403（禁止）：getetag：クライアントは、DAVとして保護されたプロパティを設定しようとしています。このエラーを返す場合、サーバは「-変更しないで保護された財産をすることができます」レスポンス本体の内部前提条件コードを使用すべきです。
409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property.
409（競合） - クライアントは、その意味論性のために適切でない値を提供しました。
424 (Failed Dependency) - The property change could not be made because of another property change that failed.
424（失敗した依存） - プロパティの変更が失敗したため、別のプロパティの変更を行うことができませんでした。
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
507（ストレージ不足） - サーバがプロパティを記録するのに十分なスペースがありませんでした。
>>Request
>>リクエスト
PROPPATCH /bar.html HTTP/1.1 Host: www.example.com Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
PROPPATCH /bar.html HTTP / 1.1ホスト：www.example.comのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:propertyupdate xmlns:D="DAV:" xmlns:Z="http://ns.example.com/standards/z39.50/"> <D:set> <D:prop> <Z:Authors> <Z:Author>Jim Whitehead</Z:Author> <Z:Author>Roy Fielding</Z:Author> </Z:Authors> </D:prop> </D:set> <D:remove> <D:prop><Z:Copyright-Owner/></D:prop> </D:remove> </D:propertyupdate>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：propertyupdateのxmlns：D = "DAV：" のxmlns：Z = "http://ns.example.com/standards/z39.50/ 「> <D：セット> <D：小道具> <Z：著者> <Z：著者>ジム・ホワイトヘッド</ Z：著者> <Z：著者>ロイ・フィールディング</ Z：著者> </ Z：著者> < / D：プロップ> </ D：セット> <D：削除> <D：> <Zプロパ：著作権、所有者/> </ D：プロップ> </ D：削除> </ D：propertyupdate>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:Z="http://ns.example.com/standards/z39.50/"> <D:response> <D:href>http://www.example.com/bar.html</D:href> <D:propstat> <D:prop><Z:Authors/></D:prop> <D:status>HTTP/1.1 424 Failed Dependency</D:status> </D:propstat> <D:propstat> <D:prop><Z:Copyright-Owner/></D:prop> <D:status>HTTP/1.1 409 Conflict</D:status> </D:propstat> <D:responsedescription> Copyright Owner cannot be deleted or altered.</D:responsedescription> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV：" のxmlns：Z = "http://ns.example.com/standards/z39.50/ 「> <D：レスポンス> <D：HREF> http://www.example.com/bar.html </ D：HREF> <D：propstat> <D：プロペラ> <Z：著者/> </ D ：小道具> <D：状態> HTTP / 1.1 424失敗した依存</ D：状態> </ D：propstat> <D：propstat> <D：> <Z小道具：著作権-所有者/> </ D：小道具> <D：ステータス> HTTP / 1.1 409競合</ D：状態> </ D：propstat> <D：responsedescription>著作権所有者は、削除または変更することができない。</ D：responsedescription> </ D：レスポンス> </ 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/」名前空間における「著者」プロパティの値を設定し、プロパティを削除するためにサーバに要求します「同じ名前空間インチ著作権-Ownerプロパティを削除することができなかったので、何のプロパティの変更は行われません。著者のプロパティの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で指定された場所に新しいコレクション・リソースを作成します。要求URIが既にリソースにマッピングされている場合は、MKCOLは失敗しなければなりません。要求URIは「/」でない限り、MKCOL処理中に、サーバーは、要求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名前空間内の指定された場所でコレクションの作成を許可しない、または2）のRequest-URIの親コレクションが存在しますが、メンバーを受け入れることができません。
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（競合） - 一点の以上の中間コレクションが作成されるまでのコレクションがRequest-URIで行うことはできません。サーバーは自動的にそれらの中間のコレクションを作成してはいけません。
415 (Unsupported Media Type) - The server does not support the request body type (although bodies are legal on MKCOL requests, since this specification doesn't define any, the server is likely not to support any given body type).
415（サポートされていないメディアタイプ） - （体はこの仕様がいずれも定義されていないため、サーバーが任意のボディタイプをサポートしていない可能性があり、MKCOL要求の法的ですが）リクエストボディタイプをサポートしていませんサーバー。
507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージ不足） - リソースは、この方法を実行した後、リソースの状態を記録するための十分なスペースがありません。
This example creates a collection called /webdisc/xfiles/ on the server www.example.com.
この例では、サーバーwww.example.com上/ webdisc / XFILES /と呼ばれるコレクションを作成します。
>>Request
>>リクエスト
MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.example.com
MKCOL / webdisc / XFILES / HTTP / 1.1ホスト：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は、[RFC2616]「のRequest-URIによって識別されるどんな情報（エンティティの形で）検索」として定義されているので、GETのセマンティクスは、不変です。 GET、コレクションに適用されたとき、「index.htmlを」リソース、コレクション、または完全に何か他の内容の判読可能なビューの内容を返すことがあります。したがって、コレクションのGETの結果は、コレクションのメンバーシップには相関関係を負いません可能性があります。
Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
HEADの定義は、応答メッセージのボディせずGETであるため、収集リソースに適用した場合、同様に、ヘッドのセマンティクスが変更されません。
Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus, the semantics of POST are unmodified when applied to a collection.
定義によりPOSTによって実行される実際の機能はサーバによって決定され、多くの場合、特定のリソースに依存するので、それは主に未定義であるので、コレクションに適用されるPOSTの挙動が有意変更することができません。コレクションに適用されたときにこのように、POSTのセマンティクスは変更されません。
DELETE is defined in [RFC2616], Section 9.7, to "delete the resource identified by the Request-URI". However, WebDAV changes some DELETE handling requirements.
削除「のRequest-URIによって識別されたリソースを削除」するために、[RFC2616]、セクション9.7で定義されています。しかし、WebDAVは、いくつかのDELETE処理要件が変更されます。
A server processing a successful DELETE request:
成功したDELETE要求を処理するサーバー：
MUST destroy locks rooted on the deleted resource
削除されたリソースに根ざしたロックを破壊しなければなりません
MUST remove the mapping from the Request-URI to any resource.
任意のリソースへのRequest-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).
このように、成功したDELETE操作（および他のアクションがない場合）の後に、ターゲットのRequest-URIへのその後のGET / HEAD / PROPFIND要求が404を返さなければならない（見つかりません）。
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity.
「：無限の深さ」ヘッダそれに使用されたかのように、コレクションに対するDELETEメソッドが行動しなければなりません。クライアントは、任意の値が、無限で、コレクションにDELETEと深さのヘッダーを提出してはなりません。
DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URLs are to be deleted.
DELETEは、Request-URIで指定されたコレクションとその内部のメンバーのURLで識別されるすべてのリソースが削除されることを指示します。
If any resource identified by a member URL cannot be deleted, then all of the member's ancestors MUST NOT be deleted, so as to maintain URL namespace consistency.
メンバーURLによって識別される任意のリソースを削除できない場合は、URL名前空間の一貫性を維持するように、その後、メンバーの祖先のすべては、削除しないでください。
Any headers included with DELETE MUST be applied in processing every resource to be deleted.
DELETEに含まれている任意のヘッダを削除するすべてのリソースの処理に適用されなければなりません。
When the DELETE method has completed processing, it MUST result in a consistent URL namespace.
DELETEメソッドが処理を完了したときは、一貫性のあるURL名前空間をもたらさなければなりません。
If an error occurs deleting a member resource (a resource other than the resource identified in the Request-URI), then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error code, which should help the client understand which resources caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked.
エラーがメンバー・リソース（要求URIで識別されたリソース以外のリソース）を削除発生した場合、応答は207（マルチ状態）とすることができます。マルチステータスは、内部リソースは、クライアントが失敗の原因となったリソースを理解するのに役立つはずですエラーコードを含む、削除することができなかったかを示すために、ここで使用されています。例えば、マルチステータス体は、内部リソースがロックされた場合、ステータス423（ロック）との反応を含むことができます。
The server MAY return a 4xx status response, rather than a 207, if the request failed completely.
要求が完全に失敗した場合、サーバーは、むしろ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（失敗した依存）ステータスコードは、DELETE 207（マルチステータス）応答されるべきではありません。クライアントは、クライアントが祖先の子孫のためにエラーを受信したときに、リソースの祖先は削除できなかったことを知っていますので、彼らは安全に除外することができます。また、204（コンテンツなし）エラーは207（マルチステータス）で返されるべきではありません。この禁止の理由は、204（コンテンツなし）は、デフォルトの成功コードであるということです。
>>Request
>>リクエスト
DELETE /container/ HTTP/1.1 Host: www.example.com
DELETE /コンテナ/ HTTP / 1.1ホスト：www.example.com
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <d:multistatus xmlns:d="DAV:"> <d:response> <d:href>http://www.example.com/container/resource3</d:href> <d:status>HTTP/1.1 423 Locked</d:status> <d:error><d:lock-token-submitted/></d:error> </d:response> </d:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/コンテナ/ resource3 </ D：のhref> <D：状態> HTTP / 1.1 423ロック</ D：状態> <D：エラー> <D：ロック・トークン提出/> </ D：エラー> </ D：応答> </ D：multistatus>
In this example, the attempt to delete http://www.example.com/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.example.com/container/ also failed. Thus, the client knows that the attempt to delete http://www.example.com/container/ must have also failed since the parent cannot be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
それがロックされているため、この例では、http://www.example.com/container/resource3を削除しようとする試みは失敗し、何のロックトークンは、要求を提出しませんでした。その結果、http://www.example.com/container/を削除しようとする試みも失敗しました。したがって、クライアントは、その子も削除されていない限り、親を削除することはできませんので、http://www.example.com/container/を削除しようとする試みも失敗していなければならないことを知っています。深ヘッダが含まれていないにもかかわらず、メソッドがコレクションにあるため、無限の深さを想定しています。
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties.
既存のリソース上で実行さPUTはリソースのGET応答実体を置き換えます。リソースで定義されたプロパティはPUT処理時に再計算することができるが、それ以外の影響を受けません。サーバはリクエストボディのコンテンツタイプを認識した場合、例えば、自動的に有益な特性として公開することができる情報を抽出することができるかもしれません。
A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
適切なスコープの親コレクションせずにリソースの作成につながるPUTは409（競合）で失敗しなければなりません。
A PUT request allows a client to indicate what media type an entity body has, and whether it should change if overwritten. Thus, a client SHOULD provide a Content-Type for a new resource if any is known. If the client does not provide a Content-Type for a new resource, the server MAY create a resource with no Content-Type assigned, or it MAY attempt to assign a Content-Type.
PUTリクエストは、クライアントがエンティティボディが持っているどのようなメディアタイプを示すことができ、かつ上書きあれば、それは変更する必要がありますか。いずれかがわかっている場合はこのように、クライアントは、新しいリソースのためのContent-Typeを提供する必要があります。クライアントは、新しいリソースのためのContent-Typeを提供していない場合は、サーバが割り当てられていないコンテンツタイプのリソースを作成することができ、またはそれは、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リクエストに付属のメタデータを扱うべきであるが、実際にはサーバがクライアントが提供するメタデータ（「のContent」で始まる例えば、任意のリクエストヘッダを）受け入れるという保証はありませんので注意してください。多くのサーバは、最初の場所でリソース単位でのContent-Typeを設定することはできません。したがって、クライアントは常に直接のContent-Typeリクエストヘッダを含めることによって、コンテンツの種類に影響を与える能力に頼ることはできません。
This specification does not define the behavior of the PUT method for existing collections. A PUT request to an existing collection MAY be treated as an error (405 Method Not Allowed).
この仕様は、既存のコレクションのためのPUTメソッドの動作を定義しません。既存のコレクションへのPUT要求はエラーとして処理することができる（405メソッドは許可されていません）。
The MKCOL method is defined to create collections.
MKCOLメソッドは、コレクションを作成するために定義されています。
The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource.
COPYメソッドは、宛先ヘッダにURIによって識別される宛先リソース内のRequest-URIによって識別されたソース・リソースの複製を作成します。宛先ヘッダが存在しなければなりません。 COPYメソッドの正確な動作は、ソースリソースの種類によって異なります。
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準拠のリソースは、COPYメソッドをサポートしなければなりません。しかし、COPYメソッドのサポートは、リソースをコピーする機能を保証するものではありません。例えば、別々のプログラムは、同じサーバー上のリソースを制御することができます。その結果、同じサーバ上にあるように見える場所にリソースをコピーすることはできないかもしれません。
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.
ソースリソースがコレクションでない場合は、COPYメソッドの結果は、状態や行動できるだけ密接にソースリソースのものと一致先の新しいリソースの作成です。先の環境は、正しい動作のために必要なリソースが存在しないようなサーバの制御の範囲外の要因に起因するソースには異なるかもしれないので、完全にリソースの動作を複製することはできないかもしれません先。先リソースへの以降の変更は、ソースのリソースを変更しません。ソースリソースへの以降の変更は先のリソースを変更しません。
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.
成功したCOPY呼び出した後、元のリソース上のすべての死者のプロパティは、先のリソースに複製されるべきです。この文書で説明ライブプロパティは必ずしも必要ではないが、同じ値で、同一の先リソースでのライブの性質を行動として複製されるべきです。クライアントは、リソースの状態や機能について間違った結論を出す可能性があるため、サーバーは、先のリソース上で死んだの特性にライブプロパティを変換すべきではありません。いくつかの生のプロパティは、プロパティが存在しない場合は、特定の意味を有するよう定義されることに留意されたい（例えば、1つの意味存在する場合、反対の不在の場合とフラグ）、及びこれらの場合において、成功したCOPYは、あるプロパティをもたらすかもしれません後続の要求に「見つかりません」と報告しました。
When the destination is an unmapped URL, a COPY operation creates a new resource much like a PUT operation does. Live properties that are related to resource creation (such as DAV:creationdate) should have their values set accordingly.
宛先がマッピングされていないURLがある場合は、コピー操作はPUT操作がないくらいのような新しいリソースを作成します。 （例えばDAVなど：のCreationDate）の作成をリソースに関連しているライブのプロパティは、その値がそれに応じて設定する必要があります。
The COPY method on a collection without a Depth header MUST act as if a Depth header with value "infinity" was included. A client may submit a Depth header on a COPY on a collection with a value of "0" or "infinity". Servers MUST support the "0" and "infinity" Depth header behaviors on WebDAV-compliant resources.
奥行きヘッダ無しコレクション上のコピー方法は、値「無限」の奥行きヘッダが含まれていたかのように行動しなければなりません。クライアントは、「0」または「無限」の値で、コレクションのCOPYの深さヘッダーを提出することができます。サーバーは、WebDAV準拠のリソースに「0」と「無限」の深さヘッダーの動作をサポートしなければなりません。
An infinite-depth COPY instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy. Note that an infinite-depth COPY of /A/ into /A/B/ could lead to infinite recursion if not handled correctly.
無限の深さのCOPYは、Request-URIによって識別されるコレクションリソースが宛先ヘッダにURIによって識別された位置にコピーされることを指示し、そのすべての内部メンバー・リソースは、再帰的、それに対する位置にコピーされますコレクション階層のすべてのレベルを介して。正しく処理されない場合は/無限再帰につながる可能性/ A / Bに/ A /無限の深さCOPYことに注意してください。
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」のCOPYは、コレクションとそのプロパティではなく、その内部のメンバーの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
宛先ヘッダーは唯一のRequest-URIのための先URIを指定します。 Request-URIによって識別されるコレクションのメンバーに適用される場合、先の値は、階層内の現在の位置を反映するように変更されます。だから、リクエストURIが/ホストヘッダー値/ http://example.com/と
Destination is http://example.com/b/, then when http://example.com/a/c/d is processed, it must use a Destination of http://example.com/b/c/d.
宛先がhttp://example.com/b/あるhttp://example.com/a/c/dが処理されるとき、そして、それはhttp://example.com/b/c/dの先を使用する必要があります。 。
When the COPY method has completed processing, it MUST have created a consistent URL namespace at the destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members that are not descendants of an error-causing collection).
COPYメソッドの処理が完了すると、コピー先で一貫した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 / 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.
COPYメソッドを実行中にエラーがRequest-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（失敗した依存）ステータスコードCOPY法から207（マルチステータス）応答で返されるべきではありません。クライアントは、クライアントが親のためのエラーを受信したときに、リソースの子孫をコピーすることができなかったことを知っていますので、これらの応答は、安全に省略することができます。また、201（作成）/ 204（コンテンツなし）ステータスコードは、COPYメソッドから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.
COPY要求は「F」の値を持つ上書きヘッダーを持っており、リソースがリンク先URLに存在する場合、サーバーは要求を失敗しなければなりません。
When a server executes a COPY request and overwrites a destination resource, the exact behavior MAY depend on many factors, including WebDAV extension capabilities (see particularly [RFC3253]). For
サーバは、コピー要求を実行し、宛先リソースを上書きする場合、正確な動作は、WebDAV拡張機能を含む、多くの要因に依存してもよい（特に、[RFC3253]を参照）。ために
example, when an ordinary resource is overwritten, the server could delete the target resource before doing the copy, or could do an in-place overwrite to preserve live properties.
例では、通常のリソースが上書きされている場合、サーバーは、コピーを行う前に、ターゲット・リソースを削除でき、またはライブの特性を維持するために、インプレース上書きを行うことができます。
When a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY. Thus, merging the membership of the source and destination collections together in the destination is not a compliant behavior.
コレクションが上書きされると、成功したCOPY要求後の先のコレクションのメンバーシップがすぐにコピーする前に、ソースのコレクションと同じ会員でなければなりません。このように、先にまとめて送信元と送信先のコレクションのメンバーシップをマージすることは準拠の動作ではありません。
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.
クライアントが（例えば、リセットするライブプロパティを強制的に）前COPYに一掃することが先URLの状態を必要とする場合、一般的には、クライアントは、このリセットを確実にするためにCOPY要求する前に先にDELETEを送ることができます。
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（作成） - ソースリソースは正常にコピーされました。 COPY操作は、新しいリソースの作成になりました。
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（マルチステータス） - 複数のリソースは、COPYによって影響を受けることがあったが、それらのいくつかのエラーが発生してから操作を防止しました。特定のエラーメッセージは、一緒にソースおよび宛先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は、（禁止） - 操作が禁止されています。 COPYのための特別なケースは、送信元と送信先リソースが同じ資源であることが考えられます。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409（競合）は、 - 一つ以上の中間コレクションが作成されるまで、リソースを先に作成することができません。サーバーは自動的にそれらの中間のコレクションを作成してはいけません。
412 (Precondition Failed) - A precondition header check failed, e.g., the Overwrite header is "F" and the destination URL is already mapped to a resource.
412（前提条件が失敗しました） - ヘッダチェックが失敗した前提条件は、例えば、上書きヘッダが「F」で、宛先URLが既にリソースにマッピングされます。
423 (Locked) - The destination resource, or resource within the destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423（ロック） - 先のリソース、または宛先コレクション内のリソースは、ロックされました。この応答は、「ロック・トークン提出」前提条件の要素を含むべきです。
502 (Bad Gateway) - This may occur when the destination is on another server, repository, or URL namespace. Either the source namespace does not support copying to the destination namespace, or the destination namespace refuses to accept the resource. The client may wish to try GET/PUT and PROPFIND/PROPPATCH instead.
502（不正なゲートウェイ） - 宛先が別のサーバ、リポジトリ、またはURL名前空間にあるときに発生することがあります。どちらのソースのネームスペースは、先の名前空間へのコピーをサポートしていない、または宛先のネームスペースは、リソースを受け入れることを拒否します。クライアントは、代わりに/ GETしてみてくださいPUTやPROPFIND / PROPPATCHすることを望むかもしれません。
507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージ不足） - 先のリソースは、この方法を実行した後、リソースの状態を記録するための十分なスペースがありません。
This example shows resource http://www.example.com/~fielding/index.html being copied to the location http://www.example.com/users/f/fielding/index.html. The 204 (No Content) status code indicates that the existing resource at the destination was overwritten.
この例ではhttp://www.example.com/~fielding/index.htmlが位置http://www.example.com/users/f/fielding/index.htmlにコピーされるリソースを示しています。 204（いいえコンテンツ）ステータスコードは、先に既存のリソースが上書きされたことを示しています。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1 Host: www.example.com Destination: http://www.example.com/users/f/fielding/index.html
COPY /~fielding/index.html HTTP / 1.1ホスト：www.example.com先：http://www.example.com/users/f/fielding/index.html
>>Response
>>回答
HTTP/1.1 204 No Content
HTTP / 1.1 204コンテンツなし
The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 (Precondition Failed) is returned because the destination URL is already mapped to a resource.
次の例では、実行される同一のコピー動作を示しているが、「F.」に設定上書きヘッダと先URLが既にリソースにマッピングされるので、412の応答は、（前提条件が失敗）が返されます。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1 Host: www.example.com Destination: http://www.example.com/users/f/fielding/index.html Overwrite: F
COPY /~fielding/index.html HTTP / 1.1ホスト：www.example.com先：http://www.example.com/users/f/fielding/index.html上書き：F
>>Response
>>回答
HTTP/1.1 412 Precondition Failed
HTTP / 1.1 412前提条件が失敗しました。
>>Request
>>リクエスト
COPY /container/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/othercontainer/ Depth: infinity
COPY /コンテナ/ 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
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?>
<？xml version = "1.0" エンコード= "UTF-8"？>
<d:multistatus xmlns:d="DAV:"> <d:response> <d:href>http://www.example.com/othercontainer/R2/</d:href> <d:status>HTTP/1.1 423 Locked</d:status> <d:error><d:lock-token-submitted/></d:error> </d:response> </d:multistatus>
<D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/othercontainer/R2/ </ D：HREF> <D：ステータス> HTTP / 1.1 423はロック</ D：状態> <D：エラー> <D：ロック・トークン提出/> </ D：エラー> </ D：レスポンス> </ 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.
コレクションのCOPYのデフォルトの動作があるかのように行動することであるとして、深さヘッダーは不要である「深さ：無限」ヘッダが送信されました。この例では、資源のほとんどは、コレクションと一緒に、正常にコピーされました。先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つのアクションを単一の操作で実行されるソースの削除続い一貫メンテナンス処理、続いて、コピー（COPY）の論理等価です。一貫性維持ステップは、サーバが新たな宛先リソースを指すように、ソースリソースを識別するリクエストURI以外のすべてのURLを更新するように移動することによって引き起こされる更新を実行することを可能にします。
The Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV-compliant resources MUST support the MOVE method.
宛先ヘッダは、すべてのMOVEメソッドに存在する必要があり、移動方法のCOPY部分の全てのコピー要求に従わなければなりません。すべてのWebDAV準拠のリソースはMOVEメソッドをサポートしなければなりません。
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.
リソースが目的地に存在する場合、宛先リソースは上書きヘッダの制限を受け、MOVE動作の副作用として削除されます。
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は、あるプロパティをもたらすかもしれません後続の要求に「見つかりません」と報告しました。ライブプロパティが目的地に同じように動作しない場合、サーバーは要求を失敗することがあります。
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.
MOVE「深さ：無限」は、リクエストURIによって識別されるコレクションは、宛先ヘッダで指定されたアドレスに移動され、その内部部材のURLによって識別されるすべてのリソースがそれに対して相対位置に移動される、再帰的に通っていることを指示しますコレクション階層のすべてのレベル。
The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity".
コレクションのMOVEメソッドがあるかのように行動しなければならない「深さ：無限」ヘッダーは、それに使用されました。クライアントは、任意の値が、「無限」でコレクションのMOVEの深さヘッダーを提出してはなりません。
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.
MOVEに含まれている任意のヘッダは宛先ヘッダを除いて移動するすべてのリソースを処理する際に適用されなければなりません。コレクションにコピーするために与えられる宛先ヘッダの動作は同じです。
When the MOVE method has completed processing, it MUST have created a consistent URL namespace at both the source and destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members that are not descendants of an error-causing collection). So, for example, if an infinite-depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite-depth move, the server SHOULD try to finish as much of the original move operation as possible.
MOVEメソッドが処理を完了したときは、送信元と送信先（名前空間の一貫性の定義については、セクション5.1を参照）の両方で一貫したURL名前空間を作成しておく必要があります。内部コレクションを移動中にエラーが発生した場合、これは一貫性のない名前空間を作成しますしかし、サーバーは、失敗したコレクション（つまり、サーバーがエラーの原因となるサブツリーをスキップしなければならない）のメンバーによって識別されるすべてのリソースを移動してはなりません。この場合は、エラーを検出した後、移動操作、すなわち（可能な限りオリジナルの動きの限りを終了しようとする必要があり、サーバーは、まだエラーの子孫でない彼らのメンバーによって特定された他のサブツリーとリソースを移動しようとすべきです）コレクションを-causing。だから、例えば、無限の深さの移動がコレクション/ A / B /及び/ A / C /を含むコレクション/ /上で実行された場合、エラーが試みが依然としてあるべきで、移動/ A / B /を発生します移動/ A / C /を試してみました。同様に、無限の深さの動きの一環として、非コレクションリソースを移動するエラーが発生した後、サーバーは、可能な限りオリジナルの移動操作の多くを完了するために試してみてください。
If an error occurs with a resource other than the resource identified in the Request-URI, then the response MUST be a 207 (Multi-Status), and the errored resource's URL MUST appear with the specific error.
エラーが要求URIで識別されるリソース以外のリソースで発生した場合、レスポンスは207（マルチステータス）でなければならない、とエラーが発生したリソースのURLは、特定のエラーが表示されなければなりません。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally, 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
424（失敗した依存）ステータスコードはMOVEメソッドから207（マルチステータス）応答で返されるべきではありません。クライアントは、クライアントが親のためのエラーを受信したときに、リソースの子孫を移動することができなかったことを知っていますので、これらのエラーは安全に省略することができます。また、201は（作成）/ 204（コンテンツなし）応答は、MOVEから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」である場合、前の動きを実行する、サーバは「無限の深さ」とDELETEを実行しなければなりません。上書きヘッダが「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（マルチステータス） - 複数のリソースがMOVEに影響されることがあったが、それらのいくつかのエラーが発生してから操作を防止しました。特定のエラーメッセージは、一緒にソースおよび宛先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（禁止） - 送信元と宛先リソースが同じである場合MOVE動作を禁止するための多くの可能な理由の中でも、このステータスコードを使用するために推奨されます。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. Or, the server was unable to preserve the behavior of the live properties and still move the resource to the destination (see 'preserved-live-properties' postcondition).
409（競合）は、 - 一つ以上の中間コレクションが作成されるまで、リソースを先に作成することができません。サーバーは自動的にそれらの中間のコレクションを作成してはいけません。または、サーバは（ '保存-ライブプロパティの事後条件を参照してください）ライブプロパティの動作を保持することができませんでしたし、まだ先にリソースを移動します。
412 (Precondition Failed) - A condition header failed. Specific to MOVE, this could mean that the Overwrite header is "F" and the destination URL is already mapped to a resource.
412（前提条件が失敗しました） - 条件ヘッダに失敗しました。移動する特定、これは上書きヘッダが「F」で、宛先URLが既にリソースにマッピングされることを意味するかもしれません。
423 (Locked) - The source or the destination resource, the source or destination resource parent, or some resource within the source or destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423（ロック） - 送信元または宛先リソース、ソースまたはデスティネーションリソースの親、またはソースまたは宛先コレクション内の一部のリソースは、ロックされました。この応答は、「ロック・トークン提出」前提条件の要素を含むべきです。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource. This could also occur when the destination is on another sub-section of the same server namespace.
502（不正なゲートウェイ） - 宛先が別のサーバ上にあり、宛先サーバがリソースを受け入れることを拒否した場合に発生する可能性があります。宛先が同じサーバーの名前空間の別のサブセクションにある場合にも発生する可能性があります。
This example shows resource http://www.example.com/~fielding/index.html being moved to the location http://www.example.com/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination URL was already mapped to a resource. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
この例ではhttp://www.example.com/~fielding/index.htmlが位置http://www.example.com/users/f/fielding/index.htmlに移動されるリソースを示しています。先のURLが既にリソースにマッピングされた場合、送信先リソースの内容が上書きされていたであろう。何も先のリソースに存在しなかったので、この場合には、応答コードが201である（作成されます）。
>>Request
>>リクエスト
MOVE /~fielding/index.html HTTP/1.1 Host: www.example.com Destination: http://www.example/users/f/fielding/index.html
MOVE /~fielding/index.html HTTP / 1.1ホスト：www.example.com先ます：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>)
MOVE /コンテナ/ HTTP / 1.1ホスト：www.example.com先：http://www.example.com/othercontainer/上書き：Fの場合：（<URN：UUID：fe184f2e-6eec-41d0-c765-01adc56e6bb4>） （<URN：UUID：e454f3f3-ACDC-452A-56c7-00a5c91e4b77>）
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <d:multistatus xmlns:d='DAV:'> <d:response> <d:href>http://www.example.com/othercontainer/C2/</d:href> <d:status>HTTP/1.1 423 Locked</d:status> <d:error><d:lock-token-submitted/></d:error> </d:response> </d:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = 'DAV：'> <D：レスポンス> <D：HREF> http://www.example.com/ othercontainer / C2 / </ D：のhref> <D：状態> HTTP / 1.1 423ロック</ D：状態> <D：エラー> <D：ロック・トークン提出/> </ D：エラー> </ D ：応答> </ 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 /移動することができなかったことを意味します。 /コンテナ/ C2 /移動エラーが発生したので、/コンテナのいずれも/ C2のメンバーは移動されませんでした。しかし、エラーが誤差最小化ルールのためにそれらのメンバーのためにリストされませんでした。ユーザエージェント認証は以前に、基礎となるトランスポート層では、HTTPプロトコルの範囲外の機構を介して発生しています。
The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested.
次のセクションでは、いずれかのアクセスタイプのロックを取り出すことと、既存のロックをリフレッシュするために使用されるLOCK方法を、説明します。 LOCKメソッドにこれらのセクションは、LOCKメソッドに固有のものであり、要求されたロックのアクセスタイプから独立しているのみ意味を説明します。
Any resource that supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein.
LOCKメソッドをサポートする任意のリソースは、最低でも、本明細書で定義される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.
既存のリソースへのLOCK要求は、すでに競合ロックでロックされていないリソースを提供Request-URIによって識別されるリソースのロックを、作成します。リクエスト-URIで識別されるリソースは、ロックのルートになります。新しいロックを作成するために、LOCKメソッド要求は、XMLリクエストボディを持たなければなりません。サーバーは、LOCK要求で「所有者」の要素には、クライアントによって提供される情報を保存しなければなりません。 LOCK要求がタイムアウトヘッダーを持っているかもしれません。
When a new lock is created, the LOCK response:
新しいロックが作成されると、LOCK応答：
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.
支柱XML要素でlockdiscoveryプロパティ：oはDAVの値で体を含まなければなりません。これは、他の（共有）ロックに関する情報はオプションですが、単に、許可されたロックに関する完全な情報を含まなければなりません。
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にLOCKリクエストを送信することにより更新されます。この要求は、本体を有してはならない、それは単一のロック・トークンと「場合」ヘッダを（唯一のロックは一度にリフレッシュすることができる）を使用してリフレッシュするためにロックを指定しなければなりません。要求は、サーバが新しい値にロック上に残っている時間を変更するために受け入れるかもしれタイムアウトヘッダを含むことができます。サーバーは、LOCKリフレッシュの深ヘッダを無視しなければなりません。
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.
ロック・トークンヘッダが成功したリフレッシュLOCK要求に対する応答で返されませんが、LOCK応答本体はDAVの新しい値が含まれなければならない：lockdiscoveryプロパティを。
The Depth header may be used with the LOCK method. Values other than 0 or infinity MUST NOT be used with the Depth header on a LOCK method. All resources that support the LOCK method MUST support the Depth header.
奥行きヘッダは、LOCKメソッドで使用されてもよいです。 0又は無限以外の値は、LOCKメソッドに奥行きヘッダで使用してはいけません。 LOCKメソッドをサポートするすべてのリソースは、深ヘッダをサポートしなければなりません。
A Depth header of value 0 means to just lock the resource specified by the Request-URI.
値0の奥行きヘッダだけのRequest-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.
奥行きヘッダが無限大に設定されている場合、その後、すべての方法階層下の、そのすべてのメンバーと一緒のRequest-URIで指定されたリソースがロックされます。成功した結果は、単一のロック・トークンを返さなければなりません。 UNLOCKが正常にこのトークンで実行された場合も同様に、関連するすべてのリソースのロックが解除されています。そのため、部分的な成功は、LOCKまたはUNLOCKのためのオプションではありません。どちらの階層全体がロックされているか、何のリソースがロックされていません。
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失敗した依存関係を含む「状態」要素と、同様のRequest-URIのための「応答」要素を含むべきです。
If no Depth header is submitted on a LOCK request, then the request MUST act as if a "Depth:infinity" had been submitted.
提出された：何の深さヘッダーはLOCK要求で提出されていない場合は、「無限の深さ」はあるかのように、その要求は行動しなければなりません。
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に存在しなかったときの成功LOCKメソッドがロックされている空のリソースの作成をもたらさなければなりません（それはコレクションではありません）。その後、ロックが離れて行くかもしれませんが、空のリソースが残っています。空のリソースは、応答の範囲でそのURLを含むPROPFIND応答に現れなければなりません。サーバ204なしコンテンツ応答を使用することによって、またはゼロ長さを示すContent-LengthヘッダでOK 200を使用することによってのいずれかで、空のリソースに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でロックが付与されることがあります。偽=ロックが許可されてはなりません。校長は二度同じロックを要求するため* =それは違法です。
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.
リソースの現在のロック状態は、一番左の列に示され、ロック要求が最初の行に記載されています。行と列の交点は、ロック要求の結果を与えます。共有ロックがリソース上に保持され、かつ排他ロックが要求された場合、例えば、テーブルエントリは、ロックが許可されてはならないことを示し、「偽」です。
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） - LOCK要求が成功し、DAVの値：lockdiscoveryプロパティはレスポンスボディに含まれています。
201 (Created) - The LOCK request was to an unmapped URL, the request succeeded and resulted in the creation of a new resource, and the value of the DAV:lockdiscovery property is included in the response body.
lockdiscoveryプロパティレスポンスボディに含まれている： - 201（作成された）LOCK要求は、要求が成功し、新しいリソースの作成の結果、およびDAVの値は、マップされていないURLにしました。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409（競合）は、 - 一つ以上の中間コレクションが作成されるまで、リソースを先に作成することができません。サーバーは自動的にそれらの中間のコレクションを作成してはいけません。
423 (Locked), potentially with 'no-conflicting-lock' precondition code - There is already a lock on the resource that is not compatible with the requested lock (see lock compatibility table above).
423（ロック）、「無競合ロック」前提条件コードが潜在的に有する - 要求されたロックと互換性がないリソースにロックが既に存在しない（上記ロック互換性の表を参照）。
412 (Precondition Failed), with 'lock-token-matches-request-uri' precondition code - The LOCK request was made with an If header, indicating that the client wishes to refresh the given lock. However, the Request-URI did not fall within the scope of the lock identified by the token. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
412「ロックトークンマッチ要求-URI」前提条件コードと、（前提条件は失敗） - ロック要求が、クライアントが指定されたロックをリフレッシュすることを望むことを示す場合にヘッダを用いて行きました。しかし、Request-URIがトークンによって識別されるロックの範囲内に含まれませんでした。ロックは、Request-URIが含まれていない範囲を有していてもよく、またはロックが消滅している可能性があり、またはトークンが無効である可能性があります。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
LOCK /workspace/webdav/proposal.docのHTTP / 1.1ホスト：example.comタイムアウト：無限、セカンド41億のContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX許可：ダイジェストユーザ名= "EJW"、領域= "ejw@example.com"、ナンス=」... "URI =" /ワークスペース/ webdavの/ proposal.doc "レスポンス=" ... "不透明=" ...」
<?xml version="1.0" encoding="utf-8" ?> <D:lockinfo xmlns:D='DAV:'> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> <D:owner> <D:href>http://example.org/~ejw/contact.html</D:href> </D:owner> </D:lockinfo>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns LOCKINFO：D = 'DAV：'> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：種類のLockType> <D：書き込み/> </ D：たlocktype> <D：所有者> <D：HREF> http://example.org/~ejw/contact.html </ D：HREF> </ D：所有者> </ D：LOCKINFO>
>>Response
>>回答
HTTP/1.1 200 OK Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4> Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 200 OKロックトークン：<壷：UUID：e71d4fae-5dec-22d6-fea5-00a0c91e6be4>のContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:prop xmlns:D="DAV:">
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns小道具：D = "DAV：">
<D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>infinity</D:depth> <D:owner> <D:href>http://example.org/~ejw/contact.html</D:href> </D:owner> <D:timeout>Second-604800</D:timeout> <D:locktoken> <D:href >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href> </D:locktoken> <D:lockroot> <D:href >http://example.com/workspace/webdav/proposal.doc</D:href> </D:lockroot> </D:activelock> </D:lockdiscovery> </D:prop>
<D：lockdiscovery> <D：activelock> <D：たlocktype> <D：書き込み/> </ D：たlocktype> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：深さ>無限</ D：深さ> <D：所有者> <D：HREF> http://example.org/~ejw/contact.html </ D：HREF> </ D：所有者> <D：タイムアウト>第-604800 </ D：タイムアウト> <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：小道具>
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秒）後に削除するロックが発生し、このリソース、上の場所でアクティビティベースのタイムアウトポリシーを持っています。ナンス、応答、及び不透明なフィールドが認可要求ヘッダで算出されていないことに留意されたいです。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
LOCK /workspace/webdav/proposal.docのHTTP / 1.1ホスト：example.comタイムアウト：無限、セカンド41億の場合：（<URN：UUID：e71d4fae-5dec-22d6-fea5-00a0c91e6be4>）認証：ダイジェストユーザ名= "EJW "レルム= "ejw@example.com"、ナンス=" ... "URI =" /ワークスペース/ webdavの/ proposal.doc "レスポンス=" ... "不透明=" ...」
>>Response
>>回答
HTTP/1.1 200 OK Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 200 OKのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:prop xmlns:D="DAV:"> <D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>infinity</D:depth> <D:owner> <D:href>http://example.org/~ejw/contact.html</D:href> </D:owner> <D:timeout>Second-604800</D:timeout> <D:locktoken> <D:href >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href> </D:locktoken> <D:lockroot> <D:href >http://example.com/workspace/webdav/proposal.doc</D:href> </D:lockroot> </D:activelock> </D:lockdiscovery> </D:prop>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns小道具：D = "DAV："> <D：lockdiscovery> <D：activelock> <D：たlocktype> <D：/書き込み> </ D：たlocktype> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：深さ>無限</ D：深さ> <D：所有者> <D：HREF>のhttp：// example.org/~ejw/contact.html </ D：HREF> </ D：所有者> <D：タイムアウト>第-604800 </ D：タイムアウト> <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：小道具>
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.
この要求は、タイムアウトヘッダーで指定された新しい値にタイムアウトをリセットしようとすると、ロックをリフレッシュします。無限のタイムアウトが、サーバーを求めたクライアントが要求を無視することを選択することに注意してください。この例では、一回だけ、応答、及び不透明なフィールドが認可要求ヘッダで算出されていません。
>>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="..."
LOCK / webdavの/ HTTP / 1.1ホスト：example.comタイムアウト：無限、セカンド41億深さ：無限のContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX許可：ダイジェストユーザ名= "EJW"、領域= "ejw@example.com"、ナンス=」... "URI =" /ワークスペース/ webdavの/ proposal.doc "レスポンス=" ... "不透明=" ...」
<?xml version="1.0" encoding="utf-8" ?> <D:lockinfo xmlns:D="DAV:"> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:owner> <D:href>http://example.org/~ejw/contact.html</D:href> </D:owner> </D:lockinfo>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：のxmlns LOCKINFO：D = "DAV："> <D：たlocktype> <D：書き込み/> </ D：たlocktype> <D： LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：所有者> <D：HREF> http://example.org/~ejw/contact.html </ D：HREF> </ D：所有者> </ D：LOCKINFO>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://example.com/webdav/secret</D:href> <D:status>HTTP/1.1 403 Forbidden</D:status> </D:response> <D:response> <D:href>http://example.com/webdav/</D:href> <D:status>HTTP/1.1 424 Failed Dependency</D:status> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://example.com/webdav/秘密</ D：のhref> <D：状態> HTTP / 1.1 403禁止</ D：状態> </ D：レスポンス> <D：応答> <D：のhref> http://example.com/webdav/ < / D：HREF> <D：ステータス> HTTP / 1.1 424は、失敗した依存</ D：状態> </ D：レスポンス> </ D：multistatus>
This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite-length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock -- in this case, a Web page URL.
この例では、コレクションとそのすべての子に排他書き込みロックの要求を示しています。可能な場合は利用可能な場合、この要求では、クライアントは、それが無限の長さのロックを望んでいることを41億秒のそれ以外の場合は、タイムアウトを指定しています。この場合には、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自体のA「応答」要素が含まれていることにも留意されたいです。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、一回だけ、応答、及び不透明なフィールドが認可要求ヘッダで算出されていません。
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock.
UNLOCKメソッドは、ロックトークン要求ヘッダーのロック・トークンによって識別されるロックを除去します。 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.
提出したロック・トークンの下でロックされているすべてのリソースがロックを解除することができない場合は、UNLOCK要求は失敗しなければなりません。
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.
UNLOCKメソッドに成功した応答は、リソースが必ずロックが解除されていることを意味するものではありません。これは、指定されたトークンに対応する特定のロックがもう存在しないことを意味しません。
Any DAV-compliant resource that supports the LOCK method MUST support the UNLOCK method.
LOCKメソッドをサポートする任意のDAV準拠のリソースは、UNLOCKメソッドをサポートしなければなりません。
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は、レスポンスボディ、通常は体が含まれていませんUNLOCK成功応答を意味するからです）。
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.
「ロックトークンマッチ要求-URI」前提と（競合）、409 - リソースがロックされていなかった、または要求は、ロックの範囲内ではありませんでしたのRequest-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="..."
example.comロックトークン：<壷：UUID：a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>認証：ダイジェストユーザ名= "EJW" 領域= "EJW例@ /workspace/webdav/info.docのHTTP / 1.1ホストをUNLOCK .COM "ナンス=" ... "URI =" /ワークスペース/ webdavの/ proposal.doc "レスポンス=" ... "不透明=" ...」
>>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.
この例では、ロック・トークン「壷：UUID：a515cfa4-5da4-22e1-f5b5-00a0451e6bf7」で識別されるロックは成功し、リソースhttp://example.com/workspace/webdav/info.docから削除されます。このロックは、ただ一つのリソース以上のものを含まれている場合、ロックはロックに含まれるすべてのリソースから削除されます。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、一回だけ、応答、及び不透明なフィールドが認可要求ヘッダで算出されていません。
All DAV headers follow the same basic formatting rules as HTTP headers. This includes rules like line continuation and how to combine (or separate) multiple instances of the same header using commas.
すべてのDAVヘッダーは、HTTPヘッダーと同じ基本的な書式のルールに従ってください。これは、行の継続方法と組み合わせること（または別個の）コンマを使用して、同じヘッダーの複数のインスタンスのような規則を含みます。
WebDAV adds two new conditional headers to the set defined in HTTP: the If and Overwrite headers.
WebDAVはHTTPで定義されたセットに二つの新しい条件付きのヘッダーを追加します：Ifとヘッダを上書きします。
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準拠のリソースは、すべてのOPTIONS応答に準拠クラス「1」とDAVヘッダを返さなければなりません。 WebDAVのが唯一のサーバーの名前空間の一部でサポートされた場合には、OPTIONSは（「/」を含む）以外の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プロセスを通して標準化された識別子はトークンであるが、他の識別子は、符号化され、URLをされるべきである一意性を促進します。
A resource must show class 1 compliance if it shows class 2 or 3 compliance. In general, support for one compliance class does not entail support for any other, and in particular, support for compliance class 3 does not require support for compliance class 2. Please refer to Section 18 for more details on compliance classes defined in this specification.
それはクラス2または3コンプライアンスを示している場合、リソースは、クラス1コンプライアンスを示さなければなりません。一般的には、1つのコンプライアンスクラスのサポートは、他のサポートを必要とせず、特に、コンプライアンスクラス3のサポートは、コンプライアンスクラス2のサポートを必要としないこの仕様で定義されたコンプライアンス・クラスの詳細については、セクション18を参照してください。
Note that many WebDAV servers do not advertise WebDAV support in response to "OPTIONS *".
多くのWebDAVサーバは、「OPTIONS *」に対応して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")
深さ= "深さ" "："（ "0" | "1" | "無限大"）
The Depth request header is used with methods executed on resources that could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its internal members only ("Depth: 1"), or the resource and all its members ("Depth: infinity").
のみ（「深リソースとその内部の部材に、：深要求ヘッダは、潜在的方法は、唯一のリソース（「0深さ」）に適用されるかどうかを示すために内部部材を有することができるリソース上で実行される方法で使用されています。 1「）、またはリソースとそのすべてのメンバー（」深さ：無限大 "）。
The Depth header is only supported if a method's definition explicitly provides for such support.
メソッドの定義が明示的にそのようなサポートを提供した場合に深さヘッダーのみがサポートされています。
The following rules are the default behavior for any method that supports the Depth header. A method may override these defaults by defining different behavior in its definition.
以下のルールが深度ヘッダーをサポートする任意のメソッドのデフォルトの動作です。この方法は、その定義に異なる振る舞いを定義することによって、これらのデフォルトをオーバーライドすることができます。
Methods that support the Depth header may choose not to support all of the header's values and may define, on a case-by-case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity", and if a Depth header is not present, it will act as if a "Depth: infinity" header had been applied.
奥行きヘッダをサポートする方法は、ヘッダの値のすべてをサポートしないことを選択することができる深さヘッダーが存在しない場合は、ケースバイケースで、この方法の動作を定義することができます。例えば、MOVEメソッドは、唯一の「深さ：無限大」をサポートしており、深さヘッダーが存在しない場合、それがあるかのように行動するだろう「深さ：無限」ヘッダーが適用されていました。
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.
デフォルトでは、深さヘッダーは他のヘッダと相互作用しません。つまり、奥行きヘッダを持つリクエストの各ヘッダは特定の深さの挙動がそのヘッダーのために定義されていない限り、それは、任意のリソースに適用される場合のみのRequest-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
先= "目的地" "：" シンプル-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（悪いRequest）を返すべきです。
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.
もしリクエストヘッダは[RFC2616]のセクション14.24に定義されている場合、Matchヘッダと同様の機能を有することが意図されています。しかし、ヘッダは、任意の状態のトークンならびにてETagを処理します。状態のトークンの典型的な例は、ロックトークンで、ロックトークンは、本明細書で定義されているだけの状態トークンです。
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（前提条件が失敗した）状態で失敗しなければなりません。一方、要求はこの状態リストの1が成功した場合にのみ成功することができます。状態リストとマッチング機能のための成功基準は、セクション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また、状態トークンがあればヘッダに表示されるという単なる事実は、それが要求して「提出」されていることを意味します。一般的に、これは、クライアントがその状態トークンの知識を持っていることを示すために使用されます。状態トークンを提出するためのセマンティクスは（ロック・トークンのために、第6章を参照してください）、そのタイプによって異なります。
Note that these two purposes need to be treated distinctly: a state token counts as being submitted independently of whether the server actually has evaluated the state list it appears in, and also independently of whether or not the condition it expressed was found to be true.
これら二つの目的が明確に処理する必要があることに注意してください。状態トークンは、サーバーが実際にそれがで表示された状態リストが評価されており、また、独立して、それが発現条件が真であることが判明したかどうかのかどうかとは無関係に提出されたものとしてカウントされます。
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list )
もし=「「もし」：」（1 *無タグリスト| 1 *タグリスト）
No-tag-list = List Tagged-list = Resource-Tag 1*List
無タグリスト=リストタグリスト=リソースタグ1 *リスト
List = "(" 1*Condition ")" Condition = ["Not"] (State-token | "[" entity-tag "]") ; entity-tag: see Section 3.11 of [RFC2616] ; No LWS allowed between "[", entity-tag and "]"
一覧= "（" 1 *条件 "）" 条件= [ "未"]（ステート・トークン| "[" エンティティタグ "]"）;エンティティタグ：[RFC2616]のセクション3.11を参照してください。 「[」、エンティティタグと「]」の間不可LWSありません
State-token = Coded-URL
状態トークン=符号化-URL
Resource-Tag = "<" Simple-ref ">" ; Simple-ref: see Section 8.3 ; No LWS allowed in Resource-Tag
リソースタグ= "<" シンプル-REF ">";シンプル参照：セクション8.3を参照してください。リソースタグで許可されませんLWS
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.
構文は、タグの付いていないリストを区別（「無タグリスト」）とリスト（「タグリスト」）をタグ付け。タグ付けされたリストは、先行するリソースタグで識別されるリソースに適用しながら、タグなしリストは、Request-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ヘッダ内で混合することができないことに留意されたいです。無タグリストの構文は、リソースタグが要求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つ以上の条件で構成されています。各条件は、エンティティタグや状態トークンで定義され、潜在的に接頭辞「なし」によって否定。
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).
もしヘッダー構文は、単一の要求内のヘッダの場合の複数のインスタンスを許可しないことに留意されたいです。しかし、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に評価し、各条件（つまり、リスト条件の論理積を表す）が真と評価された場合にのみ。
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に評価し、含まれているリストのいずれかが真と評価された場合にのみ。
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.
最後に、全体のヘッダがあれば真と評価し、無タグリストまたはタグリストプロダクションの少なくとも一つが真と評価された場合にのみ場合。ヘッダは偽と評価された場合、サーバは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.
リソースの識別：リソースがタグ付けされたリストの生産で、またはタグなしリスト作成中のRequest-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.
一致状態トークン：もしヘッダーの状態トークンと識別されたリソース上の任意の状態のトークンの間の正確な一致があります。ロック状態のトークンは、リソースがロックの範囲内の任意の場所にある場合に一致すると考えられています。
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.
ETagと状態トークンの両方のために、URLが存在するが、指定された状態を持っていないリソースを特定しているかのよう扱う：マップされていない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プロキシと通信する場合、クライアントは「キャッシュなしのCache-Control」を使用しなければなりません。 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".
前のヘッダは、私は別のETag午前」のRequest-URIで識別されたリソースは、指定されたロック・トークンでロックされることを必要とし、「私はのETag」のETagによって、または第二のETagによって同定状態で同定された状態になるであろう」。
To put the matter more plainly one can think of the previous If header as expressing the condition below:
もっとはっきり物を置くには1は、以下の条件を表現するようであれば、前のヘッダと考えることができます：
( is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND matches-etag("I am an ETag") ) OR ( matches-etag("I am another ETag") )
（：UUID：（URN-でロックされ181d4fae-7d8c-11D0-a765-00a0c91e6bf2）ANDマッチ-のETag（ "私はETagをしています"））OR（マッチ-のETag（ "私は別の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.
UUID：181d4fae-7d8c-11D0-a765-00a0c91e6bf2とロック・トークンURNとロックによってロックされなければならない：UUID：58f202ac-22cf-この場合ヘッダは、リソースがロックトークンURNを有するロックでロックされてはならないことを要求します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つの簡単な方法は、のように、常にtrueに評価することが知られている条件を含めることです。
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>) (Not <DAV:no-lock>)
もし：（<URN：UUID：181d4fae-7d8c-11D0-a765-00a0c91e6bf2>）（ない<DAV：ノーロック>）
"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：ノーロックは、」現在のロック・トークンを表すことはないことが知られています。スキーム：ロックトークンは、したがって、「DAV」を使用することはできません、セクション6.5で説明した一意性要件以下、サーバによって割り当てられています。このように、現在ではないことが知られている状態トークンに「なし」適用することで、条件は常にtrueに評価されます。その結果、全体としては、ヘッダは常にtrueに評価され、ロック・トークン骨壷する場合：UUID：181d4fae-7d8c-11D0-a765-00a0c91e6bf2は、どのような場合に提出されます。
>>Request
>>リクエスト
COPY /resource1 HTTP/1.1 Host: www.example.com Destination: /resource2 If: </resource1> (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A weak ETag"]) (["strong ETag"])
COPY /リソース1 HTTP / 1.1ホスト：www.example.com先：/リソース2の場合：</リソース1>（<URN：UUID：181d4fae-7d8c-11D0-a765-00a0c91e6bf2> [ "弱のETag" / W]）（ [ "強い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、リソース1に適用した場合で指定された状態でなければなりません "（<URN：UUID：181d4fae-7d8c-11D0-a765-00a0c91e6bf2> [W /" 弱ETag "]）（[" 強いETagを "]）"。それはどちらか、であるそれは「URN：UUID：181d4fae-7d8c-11D0-a765-00a0c91e6bf2」のロック・トークンでロックされなければならないと弱いエンティティタグW /「弱いのETag」を持っているか、それは「強いエンティティタグを持っている必要があります強いのETag」。
DELETE /specs/rfc2518.txt HTTP/1.1
Host: www.example.com
If: <http://www.example.com/specs/>
(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
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: </specs/rfc2518.doc> (["4217"])
もし：</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"])
もし：</specs/rfc2518.doc>（未[ "4217"]）
will consequently evaluate to true.
その結果、真と評価されます。
Note that, as defined above in Section 10.4.4, the same considerations apply to matching state tokens.
セクション10.4.4に上記で定義したように、同じ考慮事項が一致する状態トークンに適用されることに留意されたいです。
Lock-Token = "Lock-Token" ":" Coded-URL
ロック・トークンは= "ロック・トークン" "：" コード化-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.
ロックトークン要求ヘッダが除去されるロックを識別するために、UNLOCKメソッドで使用されています。ロックトークン要求ヘッダーのロックトークンが部材としてのRequest-URIによって識別されたリソースが含まれているロックを識別しなければなりません。
The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.
ロック・トークンレスポンスヘッダは、新しいロックを作成するために、成功したLOCK要求の結果として作成されたロック・トークンを示すために、LOCKメソッドで使用されています。
Overwrite = "Overwrite" ":" ("T" | "F")
上書き= " "上書き"："（ "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」を有するかのように、リソースは、要求を処理しなければなりません。上書きヘッダは、「もしマッチ：*」を使用しての機能を複製するように見えるが、ヘッダーを（参照[RFC2616]）、マッチした場合のみのRequest-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.
クライアントは、LOCK要求でタイムアウトリクエストヘッダを含むかもしれません。ただし、サーバーは、名誉、あるいはこれらの要求を考慮することが必要とされていません。クライアントは、LOCKメソッド以外の方法でタイムアウトリクエストヘッダを提出してはなりません。
The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1.
「第二」TimeTypeは、サーバでのロックの付与の間に経過する秒数、およびロックの自動削除を指定します。 TimeType「セカンド」のタイムアウト値は2 ^ 32-1を超えてはなりません。
See Section 6.6 for a description of lock timeout behavior.
ロック・タイムアウトの動作については、セクション6.6を参照してください。
The following status codes are added to those defined in HTTP/1.1 [RFC2616].
次のステータスコードは、HTTP / 1.1 [RFC2616]で定義されたものに追加されます。
The 207 (Multi-Status) status code provides status for multiple independent operations (see Section 13 for more information).
207（マルチステータス）ステータスコード（詳細については、セクション13を参照）は、複数の独立した操作のステータスを提供します。
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
422（処理不可能なエンティティ）ステータスコードは、サーバは、要求エンティティ（したがって415（サポートされていないメディアタイプ）ステータスコードは不適切である）のコンテンツタイプを把握手段、及び要求エンティティの構文は、このように（400（不正な要求正しいです）ステータスコードは不適切である）が、含まれる命令を処理できませんでした。例えば、XMLリクエストボディが整形式（すなわち、構文的に正しい）が含まれている場合、このエラー状態が発生する可能性が、意味的に誤った、XML命令。
The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
423（ロック）状態コードは、メソッドのソースまたは宛先リソースがロックされていることを意味します。この応答は、「ロックトークン提出」または「非競合ロック」として、適切な前提条件または事後条件コードを含むべきです。
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails, then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
424（失敗した依存）ステータスコードは、要求されたアクションは別のアクションに依存し、そのアクションが失敗したため、この方法は、リソース上で実行することができなかったことを意味します。 PROPPATCHメソッドでコマンドが失敗した場合たとえば、その後、最低でも、コマンドの残りの部分はまた、424（失敗した依存）で失敗します。
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
507（ストレージ不足）ステータスコードは、サーバーが正常に要求を完了するために必要な表現を保存することができないので、この方法は、リソース上で実行することができなかったことを意味します。この状態は一時的であると考えられています。このステータスコードを受信した要求がユーザーアクションの結果であった場合、それが別のユーザアクションによって要求されるまで、要求が繰り返されてはなりません。
These HTTP codes are not redefined, but their use is somewhat extended by WebDAV methods and requirements. In general, many HTTP status codes can be used in response to any request, not just in cases described in this document. Note also that WebDAV servers are known to use 300-level redirect responses (and early interoperability tests found clients unprepared to see those responses). A 300-level response MUST NOT be used when the server has created a new resource in response to the request.
これらのHTTPコードが再定義されていませんが、その使用はややWebDAVメソッドと要件によって拡張されます。一般的に、多くのHTTPステータスコードは、このドキュメントで説明する例だけではなく、任意の要求に応じて使用することができます。注意また、そのWebDAVサーバは、（これらの回答を見て準備ができていないクライアントを発見し、早期の相互運用性テスト）300レベルの応答をリダイレクトを使用することが知られています。サーバは要求に応じて新しいリソースを作成したときに300レベルの応答を使用してはいけません。
Any request can contain a conditional header defined in HTTP (If-Match, If-Modified-Since, etc.) or the "If" or "Overwrite" conditional headers defined in this specification. If the server evaluates a conditional header, and if that condition fails to hold, then this error code MUST be returned. On the other hand, if the client did not include a conditional header in the request, then the server MUST NOT use this status code.
すべての要求はHTTPで定義された条件ヘッダを含む（もしマッチ、もし修飾-ので、など）または「IF」または本明細書中で定義された条件付きのヘッダーを「上書き」することができます。サーバ条件ヘッダを評価する場合、その条件が成立しなかった場合、このエラーコードが返されなければなりません。クライアントが要求して条件付きのヘッダーを含んでいませんでした一方、サーバはこのステータスコードを使用してはなりません。
This status code is used in HTTP 1.1 only for Request-URIs, not URIs in other locations.
このステータスコードは、要求-URIを、他の場所ではないURIの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」ルート要素とtext / xmlまたはapplication / xmlのHTTPエンティティです。さらなる要素は、メソッドの呼び出し時に発生する200、300、400、及び500シリーズのステータスコードを含みます。 100シリーズのステータスコードは、「応答」のXML要素に記録されるべきではありません。
Although '207' is used as the overall response status code, the recipient needs to consult the contents of the multistatus response body for further information about the success or failure of the method execution. The response MAY be used in success, partial success and also in failure situations.
「207」は、全体的なレスポンスステータスコードとして使用されるが、受信者は、メソッドの実行の成功または失敗の詳細についてはmultistatusレスポンスボディの内容を参照する必要があります。応答が成功、部分的な成功にも失敗の状況で使用されるかもしれません。
The 'multistatus' root element holds zero or more 'response' elements in any order, each with information about an individual resource. Each 'response' element MUST have an 'href' element to identify the resource.
「multistatus」ルート要素は、任意の順序で個々のリソースに関する情報をそれぞれゼロ以上の「応答」の要素を保持しています。各「応答」要素には、リソースを識別するために「の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 A「ステータス」要素は、全体として識別されたリソースのためのメッセージの実行の状態を示す（例えば、セクション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.
PROPFINDとPROPPATCH 2.は、フォーマットは、リソースの個々のプロパティについての情報を提供する代わりに、「ステータス」の「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は、（例えば、成功したPUT要求に応答して、またはリダイレクト応答に）のRequest-URIでアドレス指定されたリソースのための好ましいURLを示すLocationヘッダを定義します。マルチステータスと同様に、応答の本体中のURLがある場合しかし、このヘッダを使用することは、あいまいさを作成します。したがって、マルチステータス応答でLocationヘッダの使用が意図的に未定義です。
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）は、通常のRequest-URIからリダイレクトされた単一のリソースのための新しいURIを示すために、Locationヘッダを取ります。マルチステータス応答は、多くのリソースアドレスが含まれていますが、[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を含むLocationヘッダでリダイレクトすることができるので、クライアントは、個々のリダイレクトされたリソースに要求を再発行することができます。
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（すなわち、さらにPCDATA要素の値を制限する）を使用してXML要素の許容コンテンツにさらなる制限を指定します。 「DAV：」名前空間部17、ここで定義されたすべての要素で定義されたルールに従って延長することができる、ここで定義された要素のすべてがであることに注意してください。
Name: activelock
名前：activelock
Purpose: Describes a lock on a resource.
目的：リソースのロックを記述します。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?, lockroot)>
<！ELEMENTのactivelock（LOCKSCOPE、種類のLockType、深さ、所有者？、？、タイムアウト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 >
<EMPTY allprop！ELEMENT>
Name: collection
名前：コレクション
Purpose: Identifies the associated resource as a collection. The DAV:resourcetype property of a collection resource MUST contain this element. It is normally empty but extensions may add sub-elements.
目的：コレクションとして関連付けられたリソースを識別します。 DAV：コレクション・リソースのresourcetypeのプロパティは、この要素を含まなければなりません。これは、通常は空ですが、拡張子は、サブ要素を追加することができます。
<!ELEMENT collection EMPTY >
<！ELEMENTコレクションEMPTY>
Name: depth
名前：深さ
Purpose: Used for representing depth values in XML content (e.g., in lock information).
目的：（ロック情報で、例えば）XMLコンテンツの奥行き値を表すために使用されます。
Value: "0" | "1" | "infinity"
値： "0" | "1" | 「無限大」
<!ELEMENT depth (#PCDATA) >
<！ELEMENTの深さ（#PCDATA）>
Name: error
名前：エラー
Purpose: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. In these cases, servers MAY return an XML response body with a document element of 'error', containing child elements identifying particular condition codes.
目的：エラー応答、禁断特に403と409紛争は、時々、何が悪かったのかを示すために、より多くの情報が必要。これらのケースでは、サーバは、特定の条件コードを特定する子要素を含む、「エラー」のドキュメント要素とXMLレスポンスボディを返す場合があります。
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 >
<！ELEMENTエラーANY>
Name: exclusive
名前：排他的
Purpose: Specifies an exclusive lock.
目的：排他ロックを指定します。
<!ELEMENT exclusive EMPTY >
<！ELEMENT排他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
値：シンプル-REF
<!ELEMENT href (#PCDATA)>
<！ELEMENTのHREF（#PCDATA）>
Name: include
名前：含めます
Purpose: Any child element represents the name of a property to be included in the PROPFIND response. All elements inside an 'include' XML element MUST define properties related to the resource, although possible property names are in no way limited to those property names defined in this document or other standards. This element MUST NOT contain text or mixed content.
目的：任意の子要素は、PROPFIND応答に含まれるプロパティの名前を表します。可能なプロパティ名がこの文書または他の規格で定義されたプロパティ名に制限されない方法であるが「を含む」XML要素内のすべての要素は、リソースに関連するプロパティを定義しなければなりません。この要素は、テキストまたは混合コンテンツを含めることはできません。
<!ELEMENT include ANY >
<！ELEMENTは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」要素内で使用される場合、「場所」の要素は、添付のLocationヘッダの値を提供するために使用することができます。
Description: Contains a single href element with the same value that would be used in a Location header.
説明：Locationヘッダで使用されるのと同じ値を持つ単一のHREF要素が含まれています。
<!ELEMENT location (href)>
<！ELEMENT場所（HREF）>
Name: lockentry
名前：lockentry
Purpose: Defines the types of locks that can be used with the resource.
目的：リソースで使用できるロックの種類を定義します。
<!ELEMENT lockentry (lockscope, locktype) >
<！ELEMENTのlockentry（LOCKSCOPE、種類のLockType）>
Name: lockinfo
名前：LOCKINFO
Purpose: The 'lockinfo' XML element is used with a LOCK method to specify the type of lock the client wishes to have created.
目的：「LOCKINFO」XML要素は、クライアントが作成しているしたいロックの種類を指定するには、LOCKメソッドで使用されています。
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<！ELEMENTのLOCKINFO（LOCKSCOPE、種類のLockType、所有者？）>
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.
目的：リソースがLOCK要求に対処して、それを通して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の要素は、ロックのルートが含まれています。 lockdiscoveryプロパティ値と要求をロックするには、応答：サーバーは、すべてのDAVでこれを含むべきです。
<!ELEMENT lockroot (href) >
<！ELEMENTののlockroot（HREF）>
Name: lockscope
名前：LOCKSCOPE
Purpose: Specifies whether a lock is an exclusive lock, or a shared lock.
目的：ロックが排他ロック、または共有ロックであるかどうかを指定します。
<!ELEMENT lockscope (exclusive | shared) >
<！ELEMENTのLOCKSCOPE（排他|共有）>
Name: locktoken
名前：locktoken
Purpose: The lock token associated with a lock.
目的：ロックに関連付けられているロック・トークン。
Description: The href contains a single lock token URI, which refers to the lock.
説明：HREFがロックを指す単一のロック・トークンURIを含んでいます。
<!ELEMENT locktoken (href) >
<！ELEMENT locktoken（HREF）>
Name: locktype
名前：種類のLockType
Purpose: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.
目的：ロックのアクセスタイプを指定します。現時点では、この仕様は、唯一のロックタイプ、書き込みロックを定義します。
<!ELEMENT locktype (write) >
<！ELEMENT LockTypeに（書き込み）>
Name: multistatus
名前：multistatus
Purpose: Contains multiple response messages.
目的：複数の応答メッセージが含まれています。
Description: The 'responsedescription' element at the top level is used to provide a general message describing the overarching nature of the response. If this value is available, an application may use it instead of presenting the individual response descriptions contained within the responses.
説明：最上位レベルで「responsedescription」要素は、応答の包括的な性質を記述する一般的なメッセージを提供するために使用されます。この値が利用可能な場合、アプリケーションが応答内に含まれる個々の応答の説明を提示するのではなく、それを使用することができます。
<!ELEMENT multistatus (response*, responsedescription?) >
<！ELEMENT multistatus（レスポンス*、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形式の連絡先情報を持っている場合、クライアントは「所有者」要素の「hrefの」子要素でそれらのURIを置くべきです。
Extensibility: MAY be extended with child elements, mixed content, text content or attributes.
拡張性：子要素、混合コンテンツ、テキストコンテンツまたは属性を延長することができます。
<!ELEMENT owner ANY >
<！ELEMENT所有者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.
説明：リソースに定義されたプロパティのための一般的なコンテナ。可能なプロパティ名がこの文書または他の規格で定義されたプロパティ名に制限されない方法であるが、「小道具」XML要素内のすべての要素は、リソースに関連するプロパティを定義しなければなりません。この要素は、テキストまたは混合コンテンツを含めることはできません。
<!ELEMENT prop ANY >
<！ELEMENT ANYを支えます>
Name: propertyupdate
名前：propertyupdate
Purpose: Contains a request to alter the properties on a resource.
目的：リソースのプロパティを変更するための要求が含まれています。
Description: This XML element is a container for the information required to modify the properties on the resource.
説明：このXML要素は、リソースのプロパティを変更するために必要な情報のコンテナです。
<!ELEMENT propertyupdate (remove | set)+ >
<！ELEMENTのpropertyupdate（削除|セット）+>
Name: propfind
名前：PROPFIND
Purpose: Specifies the properties to be returned from a PROPFIND method. Four special elements are specified for use with 'propfind': 'prop', 'allprop', 'include', and 'propname'. If 'prop' is used inside 'propfind', it MUST NOT contain property values.
目的：PROPFINDメソッドから返されるプロパティを指定します。 、「を含む」「小道具」、「allprop」、および「PROPNAME」：4つの特殊要素を「PROPFIND」で使用するように指定されています。 「小道具が」「PROPFIND」の内部で使用されている場合は、プロパティ値を含めることはできません。
<!ELEMENT propfind ( propname | (allprop, include?) | prop ) >
<！ELEMENTのPROPFIND（PROPNAME |（allprop、含める）|？小道具）>
Name: propname
名前：PROPNAME
Purpose: Specifies that only a list of property names on the resource is to be returned.
目的：リソースのプロパティ名のリストのみが返されることを指定します。
<!ELEMENT propname EMPTY >
<！ELEMENTのPROPNAME EMPTY>
Name: propstat
名前：propstat
Purpose: Groups together a prop and status element that is associated with a particular 'href' element.
目的：一緒にグループ特定「のhref」要素に関連付けられている支柱とステータス要素。
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本の支柱XML要素と1つのステータスXML要素を含まなければなりません。支柱XML要素の内容は、ステータスのみ要素で結果が適用されるプロパティの名前をリストする必要があります。オプションの前提条件/事後条件要素と「responsedescription」テキストも「小道具」に名前付きプロパティに適用されます。
<!ELEMENT propstat (prop, status, error?, responsedescription?) >
<！ELEMENTのpropstat（小道具、ステータス、エラー？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要素の内部「支柱」XML要素内のすべてのXML要素は、空でなければなりません。
<!ELEMENT remove (prop) >
<！ELEMENT削除（プロパ）>
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の価値観に基づいて発注に関していかなる要件は、しかし、ありません。オプションの前提条件/事後条件要素と「responsedescription」テキストは、要求または結果にこのリソースの相対に関する追加情報を提供することができます。
<!ELEMENT response (href, ((href*, status)|(propstat+)), error?, responsedescription? , location?) >
<！ELEMENT応答（HREF、（（HREFの*、ステータス）|？？（propstatの+））、エラー？responsedescription、場所）>
Name: responsedescription
名前：responsedescription
Purpose: Contains information about a status response within a Multi-Status.
目的：マルチステータス内のステータス応答に関する情報が含まれています。
Description: Provides information suitable to be presented to a user.
説明：ユーザーに提示するのに適した情報を提供します。
<!ELEMENT responsedescription (#PCDATA) >
<！ELEMENTのresponsedescription（#PCDATA）>
Name: set
名前：設定
Purpose: Lists the property values to be set for a resource.
目的：リソースに設定するプロパティ値を一覧表示します。
Description: The 'set' element MUST contain only a 'prop' element. The elements contained by the 'prop' element inside the 'set' element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists, then its value is replaced. Language tagging information appearing in the scope of the 'prop' element (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND.
説明：「設定」要素のみ「小道具」要素を含まなければなりません。 「セット」要素の内部「支柱」要素に含まれる要素は、Request-URIによって識別されたリソースで設定されるプロパティの名前と値を指定する必要があります。プロパティが既に存在する場合は、その値が置き換えられます。 「支柱」要素の範囲に現れる情報タグ付け言語（「XML：langの」内の属性は、存在する場合に）永続性と共に記憶されなければならない、とPROPFINDを使用し、続いて検索可能でなければなりません。
<!ELEMENT set (prop) >
<！ELEMENT設定（小道具）>
Name: shared
名前：共有
Purpose: Specifies a shared lock.
目的：共有ロックを指定します。
<!ELEMENT shared EMPTY >
<！ELEMENTはEMPTY共有しました>
Name: status
名前：状況
Purpose: Holds a single HTTP status-line.
目的：単一のHTTPステータスラインを保持します。
Value: status-line (defined in Section 6.1 of [RFC2616])
値：（[RFC2616]のセクション6.1で定義された）ステータスライン
<!ELEMENT status (#PCDATA) >
<！ELEMENTステータス（#PCDATA）>
Name: timeout
名前：タイムアウト
Purpose: The number of seconds remaining before a lock expires.
目的：ロックの有効期限が切れるまでの残りの秒数。
Value: TimeType (defined in Section 10.7)
値：TimeType（10.7節で定義されています）
<!ELEMENT timeout (#PCDATA) >
<！ELEMENTタイムアウト（#PCDATA）>
Name: write
名前：書きます
Purpose: Specifies a write lock.
目的：書き込みロックを指定します。
<!ELEMENT write EMPTY >
<！ELEMENT 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（すなわち、さらにPCDATA要素の値を制限する）を使用してXML要素の許容コンテンツにさらなる制限を指定します。
A protected property is one that cannot be changed with a PROPPATCH request. There may be other requests that would result in a change to a protected property (as when a LOCK request affects the value of DAV:lockdiscovery). Note that a given property could be protected on one type of resource, but not protected on another type of resource.
保護されたプロパティは、PROPPATCH要求を変更することはできませんものです。 （：lockdiscovery LOCK要求はDAVの値に影響する場合など）、保護されたプロパティへの変更につながる他の要求があるかもしれません。指定されたプロパティは、リソースの1種類に保護されたが、リソースの別の種類に保護されていないことができることに注意してください。
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.
COPYとMOVEの動作では、地元のCOPYとMOVE操作を指します。
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レスポンスヘッダに基づいて定義されたプロパティの場合：[RFC2616]、セクション4.2で定義されるように（DAV *得る）、ヘッダ値はLWSを含むことができます。サーバーの実装は、WebDAVプロパティの値として使用する前に、これらの値から、LWSを取り除くべきです。
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はそれが（むしろそれがアップロードされた時刻よりも）、ユーザーにとってより意味がある場合は、文書が作成された時間を反映するように変更します。したがって、クライアントが同期ロジック（：代わりにgetetag使用DAV）でこのプロパティを使用しないでください。
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.
COPY / MOVEの振舞い：このプロパティの値はMOVE操作中に維持されるべきではなく、リソースがCOPYを使用して作成されたとき、通常は再初期化されます。これは、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) >
<！ELEMENTののCreationDate（#PCDATA）>
Name: 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.
COPY / MOVEの振舞い：このプロパティの値は、COPYとMOVE操作で保存されるべき。
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に基づいて、このプロパティを計算することは推奨されていません）リソース上で定義され、それゆえのRequest-URIとは無関係に同じ値がそれを取得するために使用しているべきです。一般的なクライアントは、エンドユーザーにプロパティの値を表示することがありますが、クライアントUIの設計者は、リソースを識別するための方法は依然としてURLであることを理解しなければなりません。 DAVへの変更：DisplayNameには、サーバーに移動またはコピーを発行し、単に個々のリソース上でのメタデータの一部を変更しないでください。でも、同じコレクション内のDisplayName値：2つのリソースは、同じDAVを持つことができます。
<!ELEMENT displayname (#PCDATA) >
<！ELEMENTの表示名（#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.
目的：それは受け入れヘッダなしGETによって返されるように（[RFC2616]のセクション14.12から）のContent-Languageヘッダの値を格納します。
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.
COPY / MOVEの振舞い：このプロパティの値は、COPYとMOVE操作で保存されるべき。
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でのContent-Languageヘッダを返す任意のDAV準拠のリソースに定義されなければなりません。
<!ELEMENT getcontentlanguage (#PCDATA) >
<！ELEMENTのgetcontentlanguage（#PCDATA）>
Name: getcontentlength
名前：getcontentlength
Purpose: Contains the Content-Length header returned by a GET without accept headers.
目的：受け入れるヘッダーなしでGETによって返されたContent-Lengthヘッダが含まれています。
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に応答して、Content-Lengthヘッダを返す任意の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.
COPY / MOVEの振舞い：このプロパティの値は、先のリソースのサイズではなく、ソースリソースのプロパティの値に依存しています。
<!ELEMENT getcontentlength (#PCDATA) >
<！ELEMENTのgetcontentlength（#PCDATA）>
Name: getcontenttype
名前：GETCONTENTTYPE
Purpose: Contains the Content-Type header value (from Section 14.17 of [RFC2616]) as it would be returned by a GET without accept headers.
目的：それは受け入れヘッダなしGETによって返されるように（[RFC2616]のセクション14.17から）Content-Typeヘッダの値を格納します。
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.
COPY / MOVEの振舞い：このプロパティの値は、COPYとMOVE操作で保存されるべき。
Description: This property MUST be defined on any DAV-compliant resource that returns the Content-Type header in response to a GET.
説明：このプロパティはGETに応じて、Content-Typeヘッダを返す任意のDAV準拠のリソースに定義されなければなりません。
<!ELEMENT getcontenttype (#PCDATA) >
<！ELEMENTのGETCONTENTTYPE（#PCDATA）>
Name: getetag
名前：getetag
Purpose: Contains the ETag header value (from Section 14.19 of [RFC2616]) as it would be returned by a GET without accept headers.
目的：それは受け入れヘッダなしGETによって返されるように（[RFC2616]のセクション14.19から）ETagヘッダ値を格納します。
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.
COPY / MOVEの動作：このプロパティの値は先のリソースの最終的な状態ではなく、ソースリソースのプロパティの値に依存しています。また、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準拠のリソース上で定義されなければなりません。 WebDAVのでてETagの議論のためのETagの意味論の完全な定義については、RFC 2616のセクション3.11を参照してください、そして8.6節へ。
<!ELEMENT getetag (#PCDATA) >
<！ELEMENTのgetetag（#PCDATA）>
Name: getlastmodified
名前：getlastmodified
Purpose: Contains the Last-Modified header value (from Section 14.29 of [RFC2616]) as it would be returned by a GET method without accept headers.
目的：それはヘッダを受け入れることなく、GETメソッドによって返されるように（[RFC2616]のセクション14.29から）最終-Modifiedヘッダの値を格納します。
Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616])
値：RFC1123-日付（[RFC2616]のセクション3.3.1に定義されます）
Protected: SHOULD be protected because some clients may rely on the value for appropriate caching behavior, or on the value of the Last-Modified header to which this property is linked.
保護：一部のクライアントは、適切なキャッシュ動作のための値で、またはこのプロパティがリンクされている最終-Modifiedヘッダの値に依存している可能性があるため、保護する必要があります。
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.
COPY / MOVEの振舞い：このプロパティの値は先のリソースの最終更新日時はなく、ソースリソースのプロパティの値に依存しています。 getlastmodified値、これはHTTPのLast-Modified値を変更する必要があります場合でも、MOVEに保存することができますいくつかのサーバの実装は、DAV用のファイルシステムの日付変更された値を使用することに注意してください。 [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に応じて最終-Modifiedヘッダを返す任意のDAV準拠のリソースに定義されなければなりません。
<!ELEMENT getlastmodified (#PCDATA) >
<！ELEMENT getlastmodified（#PCDATA）>
Name: lockdiscovery
名前：lockdiscovery
Purpose: Describes the active locks on a resource
目的：リソース上のアクティブなロックを記述します
Protected: MUST be protected. Clients change the list of locks through LOCK and UNLOCK, not through PROPPATCH.
保護：保護しなければなりません。クライアントはないPROPPATCHを通じて、LOCKとUNLOCKを通じてロックのリストを変更します。
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.
COPY / MOVEの振舞い：このプロパティの値は、先のロック状態ではなく、ソースリソースのロックに依存します。ロックはMOVE操作で移動されていないことを思い出してください。
Description: Returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. Owner information MAY be omitted if it is considered sensitive. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there are one or more locks, an 'activelock' element appears for each lock on the resource. This property is NOT lockable with respect to write locks (Section 7).
説明：彼は、タイムアウトの種類とタイムアウトの残り時間、および関連するロック・トークンを持っているロックの種類、ロックを持っている人のリストを返します。それは敏感であると考えている場合、所有者情報を省略してもよいです。そこにはロックされていないが、サーバーがロックをサポートしている場合、プロパティは存在するが、ゼロ「activelock」要素が含まれています。一つ以上のロックがある場合は、「activelock」要素は、リソース上の各ロックのために表示されます。このプロパティは、ロック（第7節）を書くことに関してロック可能ではありません。
<!ELEMENT lockdiscovery (activelock)* >
<！ELEMENTのlockdiscovery（activelock）*>
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1 Host: www.example.com Content-Length: xxxx Content-Type: application/xml; charset="utf-8"
PROPFIND /コンテナ/ HTTP / 1.1ホスト：www.example.comのContent-Length：XXXXのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" を
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D='DAV:'> <D:prop><D:lockdiscovery/></D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = 'DAVを'> <D：プロペラ> <D：lockdiscovery /> </ D：プロップ> </ D ：PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D='DAV:'> <D:response> <D:href>http://www.example.com/container/</D:href> <D:propstat> <D:prop> <D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>0</D:depth> <D:owner>Jane Smith</D:owner> <D:timeout>Infinite</D:timeout> <D:locktoken> <D:href >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href> </D:locktoken> <D:lockroot> <D:href>http://www.example.com/container/</D:href> </D:lockroot> </D:activelock> </D:lockdiscovery> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = 'DAVを'> <D：レスポンス> <D：HREF> http://www.example.com/容器/ </ D：HREF> <D：propstat> <D：プロペラ> <D：lockdiscovery> <D：activelock> <D：たlocktype> <D：書き込み/> </ D：たlocktype> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：深さ> 0 </ D：深さ> <D：所有者>ジェーン・スミス</ D：所有者> <D：タイムアウト>無限</ D：タイムアウト> < 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：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：ステータス> </ D：propstat> </ D：レスポンス> </ 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.
保護：保護する必要があります。リソースタイプは、一般的にリソース（PUT対MKCOL）を作成する操作を介して、しないPROPPATCHによって決定されます。
COPY/MOVE behavior: Generally a COPY/MOVE of a resource results in the same type of resource at the destination.
COPY / MOVEの動作：先のリソースの同じタイプのリソース結果の一般COPY / MOVE。
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.
COPY / MOVEの振舞い：このプロパティの値がないソースリソースのプロパティの値に、宛先でサポートされるロックの種類に依存しています。先にコピーしようとするサーバーは、先にこのプロパティを設定しようとするべきではありません。
Description: Returns a listing of the combinations of scope and access types that may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls, so a server is not required to provide information the client is not authorized to see. This property is NOT lockable with respect to write locks (Section 7).
説明：リソースのロック要求で指定される範囲やアクセスタイプの組み合わせのリストを返します。実際の内容は、自身がアクセス制御によって制御されているので、サーバはクライアントが見ることが許可されていない情報を提供するために必要とされていないことに注意してください。このプロパティは、ロック（第7節）を書くことに関してロック可能ではありません。
<!ELEMENT supportedlock (lockentry)* >
<！ELEMENTのsupportedlock（lockentry）*>
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1 Host: www.example.com Content-Length: xxxx Content-Type: application/xml; charset="utf-8"
PROPFIND /コンテナ/ HTTP / 1.1ホスト：www.example.comのContent-Length：XXXXのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" を
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop><D:supportedlock/></D:prop> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：D = "DAV："> <D：プロペラ> <D：supportedlock /> </ D：プロップ> </ D ：PROPFIND>
>>Response
>>回答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.example.com/container/</D:href> <D:propstat> <D:prop> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：multistatusのxmlns：D = "DAV："> <D：レスポンス> <D：HREF> http://www.example.com/容器/ </ D：HREF> <D：propstat> <D：プロペラ> <D：supportedlock> <D：lockentry> <D：LOCKSCOPE> <D：排他/> </ D：LOCKSCOPE> <D：種類のLockType> <D：書き込み/> </ D：たlocktype> </ D：lockentry> <D：lockentry> <D：LOCKSCOPE> <D：共有/> </ D：LOCKSCOPE>
<D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<D：たlocktype> <D：書き込み/> </ D：たlocktype> </ D：lockentry> </ D：supportedlock> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> </ D：レスポンス> </ 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要素が適切な「propstatまたは 『条件は、1つ以上のプロパティに又は全体としてのリソースに適用されるかどうかに応じて応答』要素の「エラー」要素内に表示しなければなりません。そうでなければ要求によって交渉されない限り、本明細書の「エラー」体が使用されている他のすべてのエラー応答では、前提条件/事後条件のXML要素は、一緒に、レスポンスボディのトップレベル「のエラー」要素の子として返さなければなりません適切な応答ステータス。ユーザが矛盾を解決し、要求を再送信することができるかもしれないことが予想されている場合、それは常に失敗、および409（競合）しますので、要求が繰り返されてはならない場合は、最も一般的な応答ステータスコードは、（禁止）403です。 「エラー」の要素は、特定のエラー情報を持つ子要素を含んでいてもよいし、任意のカスタム子要素で延長することができます。
This mechanism does not take the place of using a correct numeric status code as defined here or in HTTP, because the client must always be able to take a reasonable course of action based only on the numeric code. However, it does remove the need to define new numeric codes. The new machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions, so naturally, any group defining a new condition code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups.
ここまたはHTTPで定義されているクライアントは常に数字のみのコードに基づいて行動の合理的なコースを取ることができなければならないので、このメカニズムは、正しい数値ステータスコードを使用しての代わりにはなりません。しかし、それは新しい数値コードを定義する必要性を削除しません。この目的のために使用される新しい機械可読コードは、事前条件と事後条件と分類XML要素であるため、当然、新しい条件コードを定義する任意のグループは、独自の名前空間を使用することができます。いつものように、「DAV：」名前空間は、IETF-チャーターのWebDAVワーキンググループで使用するために予約されています。
A server supporting this specification SHOULD use the XML error whenever a precondition or postcondition defined in this document is violated. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank. However, a server MAY instead use a custom condition code and other supporting text, because even when clients do not automatically recognize condition codes, they can be quite useful in interoperability testing and debugging.
この仕様をサポートするサーバは、この文書で定義された前提条件や事後条件に違反したときにXMLエラーを使用すべきです。この文書で指定されていないエラー条件のために、サーバは、単に適切な数値ステータスを選択し、レスポンスボディを空白のままにするかもしれません。クライアントが自動的に条件コードを認識しない場合でも、彼らは相互運用性のテストとデバッグに威力を発揮することができしかし、サーバーではなく、カスタム条件コードおよびその他のサポートテキストを使用するかもしれません。
Example - Response with precondition code
例 - 前提条件コードとレスポンス
>>Response
>>回答
HTTP/1.1 423 Locked Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 423ロックのContent-Type：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:lock-token-submitted> <D:href>/workspace/webdav/</D:href> </D:lock-token-submitted> </D:error>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：エラーのxmlns：D = "DAV："> <D：ロックトークン提出> <D：HREF> /ワークスペース/ WebDAVの/ < / D：HREF> </ D：ロックトークン提出> </ D：エラー>
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".
この例では、親コレクション「/ワークスペース/ webdavの/」上の深さ無限錠を知らないクライアントは、コレクションのメンバー「/workspace/webdav/proposal.doc」を変更しようとしました。
Some other useful preconditions and postconditions have been defined in other specifications extending WebDAV, such as [RFC3744] (see particularly Section 7.1.1), [RFC3253], and [RFC3648].
いくつかの他の有用な前提条件および事後条件は、[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
名前：ロック・トークンマッチ-の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.
目的：（前提条件） - 要求がUNLOCKメソッドのロックを識別するためのロックトークンヘッダを含むことができます。要求URIがトークンで識別されるロックの範囲内に入らない場合は、サーバーはこのエラーを使用すべきです。ロックは、Request-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つのそのようなロックされたリソースを返すための唯一の責任がある - クライアントがリソースを要求が失敗作っロックされているかを発見するためにMOVE、COPY、およびコレクションのロックが関与しているところDELETEの場合には、それが困難な場合があります。サーバは、それはそれらすべてを知っている場合、後続の要求を防止し、すべてのロックされたリソースを返すことがあります。
<!ELEMENT lock-token-submitted (href+) >
<！ELEMENTロック・トークン提出（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.
目的：既存の競合ロックの存在により失敗したLOCK要求。要求が向けられたリソースは、間接的にのみロックされているものの、ロックが競合することができることに留意されたいです。この場合、前提条件コードが「lockdiscovery」プロパティの別々のルックアップを避け、競合ロックのルートであるリソースについてクライアントに通知するために使用することができます。
<!ELEMENT no-conflicting-lock (href)* >
<！ELEMENT無矛盾ロック（HREF）*>
Name: no-external-entities
名前：ノー外部エンティティ
Use with: 403 Forbidden
使用します。403は禁止
Purpose: (precondition) -- If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error.
目的：（前提条件） - リクエストボディは、外部エンティティが含まれているため、サーバーがクライアントの要求を拒否した場合、サーバはこのエラーを使用すべきです。
Name: preserved-live-properties
名前：保存 - ライブプロパティ
Use with: 409 Conflict
409紛争：で使用します
Purpose: (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server only supports some live properties in some parts of the repository, or simply has an internal error.
目的：（事後条件） - サーバーは、そうでない場合は、有効な移動またはコピー要求を受けたが、先の同じ動作でライブ特性を維持することはできません。これは、サーバーが唯一のリポジトリの一部では、いくつかのライブプロパティをサポート、または単に内部エラーが発生している可能性があります。
Name: propfind-finite-depth
名前：PROPFIND-有限深さ
Use with: 403 Forbidden
使用します。403は禁止
Purpose: (precondition) -- This server does not allow infinite-depth PROPFIND requests on collections.
目的：（前提条件） - このサーバーは、コレクション上無限の深さのPROPFIND要求を許可していません。
Name: cannot-modify-protected-property
名前：ことができ、変更しないで保護された財産
Use with: 403 Forbidden
使用します。403は禁止
Purpose: (precondition) -- The client attempted to set a protected property in a PROPPATCH (such as DAV:getetag). See also [RFC3253], Section 3.12.
目的：（前提条件） - クライアントが（たとえば、DAVなど：getetag）PROPPATCHで保護されたプロパティを設定しようとしました。また、[RFC3253]、セクション3.12を参照してください。
The XML namespace extension ([REC-XML-NAMES]) is used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the "DAV:" namespace SHOULD NOT be used in the request or response body unless that XML element is explicitly defined in an IETF RFC reviewed by a WebDAV working group.
XML名前空間の拡張（[REC-XML-NAMES]）は、他の要素名と衝突の恐れなしに追加される新しいXML要素を可能にするために、本明細書で使用されます。 WebDAV要求と応答ボディは、メッセージ受信者のXML要素によって無視することができる任意のXML要素によって拡張することができるが、「DAV：」というXML要素が明示的に定義されない限り、名前空間が、要求または応答の本体で使用すべきではありませんIETF RFCでWebDAVワーキンググループで検討。
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要素を記録しなければなりませんサーバー上で死んで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.
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.
「#PCDATA」の要素タイプの定義についてはO、拡張要素を追加してはいけません。
o For other element type definitions, including "EMPTY", extension elements MAY be added.
「EMPTY」を含む他の要素タイプの定義については、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によって必要な子要素のいずれかを省略拡張子を定義する、拡張は、例えば、後方互換性がないように設計されて時間があるかもしれません。
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準拠のリソースは、このドキュメントのすべてのセクションにあるすべての「MUST」の要件を満たす必要があります。
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つの要件を満たし、LOCK方法、DAVサポートしなければならない：supportedlockプロパティ、DAV：lockdiscoveryプロパティ、タイムアウトレスポンスヘッダとロック・トークンのリクエストヘッダを。クラス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つの準拠のリソースは、値「1」と「2」OPTIONSメソッドへのすべての応答にDAVヘッダに、最低でも、返さなければなりません。
A resource can explicitly advertise its support for the revisions to [RFC2518] made in this document. Class 1 MUST be supported as well. Class 2 MAY be supported. Advertising class 3 support in addition to class 1 and 2 means that the server supports all the requirements in this specification. Advertising class 3 and class 1 support, but not class 2, means that the server supports all the requirements in this specification except possibly those that involve locking support.
リソースは、明示的にこの文書で作られた[RFC2518]の改定のための支援を宣伝することができます。クラス1は、同様にサポートしなければなりません。クラス2をサポートすることができます。クラス1および2に加えて、広告クラス3のサポートは、サーバーがこの仕様のすべての要件をサポートすることを意味します。広告クラス3およびクラス1つのサポートではなく、クラス2は、サーバがサポートをロック伴うことおそらくものを除き、本明細書中のすべての要件をサポートすることを意味します。
Example:
例：
DAV: 1, 3
DAV：1、3
In the realm of internationalization, this specification complies with the IETF Character Set Policy [RFC2277]. In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [RFC3629] and UTF-16 [RFC2781] encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header (defined in [RFC3023]), as well as XML charset declarations.
国際化の分野では、この仕様は、IETF文字セットポリシー[RFC2277]に準拠しています。本明細書では、人間が読み取り可能なフィールドは、プロパティの値に、または応答実体本体に返されたエラーメッセージのいずれかで見ることができます。両方の場合において、人間が読み取り可能なコンテンツは、文字セットのタグ付けおよび符号化のための明示的な規定を持つXMLを用いて符号化され、UTF-8 [RFC3629]とUTF-16を使用して、XMLプロセッサが最小で、エンコードされたXML要素を読み取ることを要求します[RFC2781] ISO 10646多平面のエンコード。本明細書におけるXMLの例は、（[RFC3023]で定義された）Content-Typeヘッダのcharsetパラメータの使用、ならびにXML文字セット宣言を実証します。
XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. The "xml:lang" attribute appears on an XML element to identify the language of its content and attributes. See [REC-XML] for definitions of values and scoping.
XMLは、特定のXML要素のコンテンツの言語を指定するための言語タグ付け機能を提供します。 「XML：LANG」属性は、その内容と属性の言語を識別するために、XML要素に表示されます。値とスコープの定義については、[REC-XML]を参照してください。
WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" [RFC3023] for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header.
WebDAVのアプリケーションでは、文字セットのタグ付け、文字セットエンコーディング、およびXML仕様の言語タグ付け機能をサポートしなければなりません。 WebDAVのアプリケーションの実装者が強くMIMEメディアタイプがXMLの輸送に使用する上、およびContent-Typeヘッダの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.
本明細書内で使用される名前は、4つのカテゴリに分類されます。そのような方法およびヘッダー、XML要素の名前、プロパティの名前、および状態の名前などのプロトコル要素の名前。プロトコル要素のネーミングは、メソッドとヘッダのUS-ASCIIでエンコードされた英語の名前を使用して、HTTPの先例に従います。これらのプロトコル要素は、ユーザーには表示されません、単に長いトークン識別子であるので、それらは複数の言語をサポートする必要はありません。同様に、本明細書で使用される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.
エラー報告のために、我々は、各ステータスコードコードの短い、英語の記述（例えば、423（ロック））を含むHTTP / 1.1ステータスコードの慣例に従います。可能性が不十分に細工されたユーザエージェントがユーザーにこのメッセージを表示することを存在するが、国際化されたアプリケーションは、このメッセージを無視し、ユーザーの言語と文字セットで適切なメッセージを表示します。
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]をサポートしなければなりません。ダイジェスト認証は、通信の両当事者が明確にその秘密を送信することなく、共有秘密、パスワードを知っていることを確認しているので広いに有用である認証レベルを提供しながら、ダイジェスト認証は、基本認証に固有のセキュリティ上の問題を回避しますシナリオの範囲。
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のプラスHTTPは、システムのリソースのすべての部分にDoS攻撃を可能にします。
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に格納されます。リソースのlockdiscoveryプロパティ、およびリソースへのアクセスを介して交渉を開始するために他の共同作業で使用することができます。しかし、多くの場合、この連絡先情報は非常にプライベートなことができ、かつ広く普及すべきではありません。適切なlockdiscoveryプロパティ：サーバーはDAVへの読み取りアクセスを制限する必要があります。さらに、ユーザエージェントは、連絡先情報が全く送信され、および連絡先情報が送信された場合、正確にどのような情報をコントロールが送信されるかどうかを制御を提供する必要があります。
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を取得し、追加のXMLを含むようにXMLプロセッサに指示する[REC-XML]のセクション4.2.2で定義された「外部エンティティ」として知られる機能をサポートします。外部の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を修正し、したがって有意そのセマンティクスを変更するか、[RFC3023]で説明したセキュリティリスクにXMLプロセッサを露出させる、最悪の場合には、XML文書の最終形態に影響するまた、可能です。そのため、実装者は外部のXMLエンティティは信用できないとして扱われるべきであることを認識する必要があります。サーバは外部のXMLエンティティを処理しないことを選択した場合、それは無外部エンティティの条件コードと外部エンティティを含む要求に応答する必要があります。
There is also the scalability risk that would accompany a widely deployed application that made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any server that fields requests for the resource containing the external XML entity.
外部のXMLエンティティを利用した、広く配備されたアプリケーションを伴うだろうスケーラビリティのリスクもあります。このような状況では、潜在的に外部の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]）の使用を奨励しています。 （セクション4で定義された）バージョン1つのUUIDが「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:
この仕様は、二つのURIスキームを定義しています。
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.歴史のWebDAVプロパティとXML要素名を明確にするために[RFC2518]で使用し続けている「DAV」URIスキームは、その本明細書において目的とWebDAVを拡張他人に使用されます。内の識別子の作成「DAV：」名前空間はIETFによって制御されます。
Note that defining new URI schemes for XML namespaces is now discouraged. "DAV:" was defined before standard best practices emerged.
XML名前空間のための新しいURIスキームを定義することになりました推奨されていることに注意してください。 「DAV：」は、標準的なベストプラクティスが出現する前に定義されました。
XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names, or element names.
XML名前空間は、WebDAVプロパティ名とXML要素を明確。任意のWebDAVユーザーやアプリケーションがカスタムプロパティを作成またはWebDAV XML構文を拡張するために新しい名前空間を定義することができます。 IANAは、このような名前空間、プロパティ名、または要素名を管理する必要はありません。
The message header fields below should be added to the permanent registry (see [RFC3864]).
以下永久レジストリに追加されるべきメッセージのヘッダフィールド（[RFC3864]を参照）。
Header field name: DAV
ヘッダフィールド名：DAV
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 10.1)
仕様書：この仕様書（10.1節）
Header field name: Depth
ヘッダフィールド名：深さ
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 10.2)
仕様書：この仕様書（10.2節）
Header field name: Destination
ヘッダフィールド名：デスティネーション
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 10.3)
仕様書：この仕様書（10.3節）
Header field name: If
ヘッダフィールド名：もし
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 10.4)
仕様書：この仕様書（第10.4節）
Header field name: Lock-Token
ヘッダフィールド名：ロックトークン
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 10.5)
仕様書：この仕様書（10.5節）
Header field name: Overwrite
ヘッダフィールド名：上書き
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 10.6)
仕様書：この仕様書（10.6節）
Header field name: Timeout
ヘッダフィールド名：タイムアウト
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 10.7)
仕様書：この仕様書（10.7節）
This specification defines the HTTP status codes
この仕様は、HTTPステータスコードを定義します
o 207 Multi-Status (Section 11.1)
207マルチステータスO（11.1節）
o 422 Unprocessable Entity (Section 11.2),
422処理不可能なエンティティ（セクション11.2）O、
o 423 Locked (Section 11.3),
O 423ロック（11.3）、
o 424 Failed Dependency (Section 11.4) and
424失敗した依存（11.4節）とO
o 507 Insufficient Storage (Section 11.5),
507ストレージ不足（11.5節）O、
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.
テリー・アレン、ハラルドAlvestrand、ジムAmsden、ベッキー・アンダーソン、アランBabich、サンフォードバール、ディランBarrell、バーナードチェスター、ティム・バーナーズ=リー、ダン・コノリー、ジム・カニンガム、ロンダニエル・ジュニア、ジム・デイビス、キース・ドーソン、マーク・デイ、ブライアン・デーン、マーティンDuerst、デビッド・デュラン、リー・ファレル、チャック・フェイ、ウェズリーFelter、ロイ・フィールディング、マーク・フィッシャー、アラン・フライアー、ジョージ・フィレンツェ、ジム・ゲティーズ、フィルハラム - ベイカー、デニス・ハミルトン、スティーブ・ヘニング、ミードHimelstein、アレックスHopmann、アンドレ・ファン・デル・ホーク、ベン・ローリー、ポールリーチ、オーラ・ラシラ、カレン・マッカーサー、スティーブ・マーティン、ラリーMasinter、マイケル・メオーリング、キースムーア、トーマスNartes、ヘンリック・ニールセン、健二太田、ボブ・パーカー、グレン・ピーターソン、ジョン・ラドフ、Saveenレディ、ヘンリー・サンダース、クリストファーSeiwald、ジュディスは、マイク・スプレイッツァー、はEinar Stefferud、グレッグ・スタイン、ラルフ・スウィック、高橋健司、リチャード・N.・テイラー、ロバート・トー、ジョン・ターナー、SankarのVirdhagriswaran、ファビオ・ビタリ、グレゴリー・ウッドハウス、およびローレン・ウッドを襲いました。
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.
このリストの二つは特筆に値します。ラリーMasinterの貢献は非常に貴重でした。彼の両方がワーキンググループの形成を助け、辛抱強く道に沿って著者を指導しました。非常に多くの方法で彼は我々が満たすために苦労している高い基準を設定しています。ジュディスSleinの貢献も非常に貴重でした。要件を明確化することにより、辛抱強くバージョン後のバージョンを検討中で、彼女の両方がこの仕様を改善し、文書管理上の私たちの心を拡大しました。
We would also like to thank John Turner for developing the XML DTD.
また、XMLのDTDを開発するためのジョン・ターナーに感謝したいと思います。
The authors of RFC 2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter, and D. Jensen. Although their names had to be removed due to IETF author count restrictions, they can take credit for the majority of the design of WebDAV.
RFC 2518の作者はヤロンGoland、ジム・ホワイトヘッド、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.
この仕様のためのテキストの重要な貢献者は、以下のセクションでの貢献者として記載されています。また、感謝し、リスト上やミーティングで特定のテキストをハッシュするためにジェフClemm、ジョエルセーデルベリ、およびダンBrotskyを確認する必要があります。ジョー・ヒルデブラントとカレン・ジェニングスは、多くの問題を閉じて助けました。バリー・リンドは、追加のセキュリティ考慮を説明し、カレン・ジェニングスは、その検討のためのテキストを提供しました。ジェイソン・クロフォードは、エリアスSinderson続く年の期間、このドキュメントの発行状況を追跡しました。
Julian Reschke <green/>bytes GmbH Hafenweg 16, 48155 Muenster, Germany EMail: julian.reschke@greenbytes.de
ジュリアンReschke <グリーン/>バイト社Hafenweg 16、48155ミュンスター、ドイツEメール：julian.reschke@greenbytes.de
Elias Sinderson University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: elias@cse.ucsc.edu
カリフォルニアのエリアスSinderson大学サンタクルーズ校1156ハイストリート、サンタクルス、CA 95064 Eメール：elias@cse.ucsc.edu
Jim Whitehead University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: ejw@soe.ucsc.edu
カリフォルニア州のジム・ホワイトヘッド大学サンタクルーズ校1156ハイストリート、サンタクルス、CA 95064 Eメール：ejw@soe.ucsc.edu
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: yarong@microsoft.com
Y. Y. Golandマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399 Eメール：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.ホワイトヘッド、情報およびカリフォルニアのコンピュータサイエンス大学・ジュニア部門、アーヴァイン、CA 92697-3425 Eメール：ejw@ics.uci.edu
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043 EMail: asad@netscape.com
A.フェッチネットスケープ685東ミドルロード、マウンテンビュー、CA 94043 Eメール：asad@netscape.com
S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: srcarter@novell.com
S. R.カーターノベル1555 N.技術ウェイM / S ORM F111オレム、UT 84097から2399 Eメール：srcarter@novell.com
D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: dcjensen@novell.com
D.ジェンセンノベル1555 N.技術ウェイM / S ORM F111オレム、UT 84097から2399 Eメール：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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、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]コーワン、J.とR.トビン、 "XML情報セット（第二版）"、W3C REC-XML-インフォセット-20040204、2004年2月、<http://www.w3.org/TR / 2004 / REC-XML-インフォセット-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]ブレイ、T.、オランダ、D.、素人、A.、およびR.トビン、 "XML 1.0での名前空間（第二版）"、W3C REC-XML-名-20060816、2006年8月、 <のhttp：// www.w3.org/TR/2006/REC-xml-names-20060816/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "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.、エド。そして、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]バーナーズ - リー、T.、フィールディング、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]リーチ、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.、ビタリ、F.、ホワイトヘッド、E.、およびD.デュラン、 "ワールド・ワイド・ウェブのための分散オーサリングとバージョン管理プロトコルのための要件"、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.、ホワイトヘッド、E.、フェッチ、A.、カーター、S.、およびD.ジェンセン、 "分散オーサリングのHTTP拡張 - WEBDAV"、RFC 2518、1999年2月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781]ホフマン、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]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253] Clemm、G.、Amsden、J.、エリソン、T.、Kaler、C.、およびJ.ホワイトヘッド "の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]ホワイトヘッド、J.とJ. Reschke、エド。、RFC 3648、2003年12月 "Web分散オーサリングとバージョン管理（WebDAV）は、コレクションのプロトコルを順序"。
[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.ホワイトヘッド、 "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.、ノッティンガム、M.、およびJ.モーグル、BCP 90、RFC 3864、2004年9月 "メッセージヘッダフィールドの登録手順"。
Appendix A. Notes on Processing XML Elements
処理XML要素の付録A.ノート
A.1. Notes on Empty XML Elements
A.1。空のXML要素についての注意
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つのメカニズムをサポートしています。最初は、フォーム<A> </A>のXML要素を宣言することです。第二は、フォーム<A/>のXML要素を宣言することです。 2つのXML要素は、意味的に同じです。
A.2. Notes on Illegal XML Processing
A.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要素の違法な組み合わせを受け入れるには優しさがありません。せいぜい、それが不要な結果が発生し、最悪の場合、それは本当の損傷を引き起こす可能性があります。
A.3. Example - XML Syntax Error
A.3。例 - XML構文エラー
The following request body for a PROPFIND method is illegal.
PROPFINDメソッドの次のリクエストボディは違法です。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> <D:propname/> </D:propfind>
<？xml version = "1.0" エンコード= "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（悪いRequest）で応答しなければなりません。
Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop.
サーバは「親切」になりたかった、真の要素としてallprop要素を選択し、それに対応することを決めた、しかし、想像してみてください。サーバがallpropとしてコマンドを扱う場合PROPNAMEを実行することを目的と帯域幅が制限されたライン上で実行しているクライアントは、大きな驚きのためにあるだろう。
Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
サーバは寛大だったし、この要求に応答することを決定した場合はさらに、その結果は、いくつかのサーバがallpropディレクティブを実行し、他の人がPROPNAMEディレクティブを実行すると、サーバからサーバにランダムに変化します。これは、それを増やすのではなく、相互運用性を低減します。
A.4. Example - Unexpected XML Element
A.4。例 - 予期しないXML要素
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
それが明示的PROPFIND要素に一緒に表示され禁止された2つの要素を含んでいるため、前の例では違法でした。しかし、XMLは拡張可能な言語なので、一つはPROPFINDで使用するために定義された新しい要素を想像することができます。以下は、前の例のように、期限切れの-小道具要素を理解していないサーバが400（悪いRequest）で拒絶されなければならない、PROPFINDのリクエストボディがあります。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E="http://www.example.com/standards/props/"> <E:expired-props/> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：Dは= "DAV：" のxmlns：E = "http://www.example.com/standards/props/"> <E：期限切れの-小道具/> </ D：PROPFIND>
To understand why a 400 (Bad Request) is returned, let us look at the request body as the server unfamiliar with expired-props sees it.
400（不正なリクエスト）が返された理由を理解するには、有効期限が切れ、小道具に精通していないサーバは、それを見て、私たちがリクエストボディを見てみましょう。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E="http://www.example.com/standards/props/"> </D:propfind>
<？xml version = "1.0" エンコード= "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要素の定義によって違法である空のPROPFINDを見ます。
Please note that had the extension been additive, it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
拡張子が添加されていたことに注意してください、それは必ずしも400（悪いRequest）をもたらしたではないでしょう。たとえば、PROPFINDについては、以下のリクエストボディを想像してみてください。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E="http://www.example.com/standards/props/"> <D:propname/> <E:leave-out>*boss*</E:leave-out> </D:propfind>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：PROPFINDのxmlns：Dは= "DAV：" のxmlns：E = "http://www.example.com/standards/props/"> <D：PROPNAME /> <E：残しアウト> *ボス* </ E：残しアウト> </ 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.
前の例では、架空の要素休暇アウトが含まれています。その目的は、名前提出パターンに一致するすべてのプロパティの戻りを防ぐためです。前の例は、「去るアウト」に慣れていないサーバーに送信された場合は、結果だけは「去るアウト」要素は無視されるだろうとPROPNAMEが実行されることになります。
Appendix B. Notes on HTTP Client Compatibility
HTTPクライアントとの互換性については、付録B.注意事項
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との後方互換性であることが見出されています。メソッドはHTTPで定義されているので、HTTPクライアントなどのWebDAV対応のクライアントで使用することができるが、PUTとDELETEのための応答が唯一のWebDAVクライアントが完全ために準備されるだろうな方法でこの仕様で拡張されたPUTとDELETE 。いくつかの理論的な懸念は、これらの応答は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.
424はまた、新しいステータスコードである（422、423、および507それだけで表示されます任意のHTTPクライアントはエラーとして認識されていない400レベルと500-レベルのステータスコードを処理するべきであるので、以下の新しいステータスコードは、すべての問題を提示してはなりませんMultistatusレスポンスのボディ。）HTTPクライアントがロックされたリソースをPUTまたはDELETEしようとしたのであれば、例えば、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.
コレクションにDELETEリクエストを発行するHTTPクライアントが成功として207応答を解釈するかもしれないので、207 Multistatus応答が収集され、DELETE操作が完了またはだったかもしれないということを理解することはできません、それは資源を実現していなくても、面白いです部分的な障害。その解釈は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つのオプションは、サーバーがアトミック操作として、コレクションのDELETEを処理し、エラーのために204成功の場合はコンテンツなし、またはいくつかの適切なエラー応答（400または500レベル）のいずれかを使用することができることです。このアプローチは確かに下位互換性を最大にします。相互運用性テストとワーキンググループの議論はWebDAVコレクションに対するDELETEリクエストを発行するHTTPクライアントのインスタンスを上げていないので、この懸念は実用よりも理論的です。したがって、サーバーは、任意のコレクションは、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.
一般的には、サーバの実装は、この文書で定義された詳細な回答や他のメカニズムを使用するのではなく、理論的相互運用性の懸念のための変更を行うことが奨励されています。
Appendix C. The 'opaquelocktoken' Scheme and URIs
付録C.ザ・「opaquelocktoken」スキームとのURI
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スキームは、ロック・トークンとして使用するとのすべてのリソース間で一意であることを意図し、のUUIDのうち構文的に正しいと簡単に生成するURIを作成するために[RFC2518]（およびIANAによって登録された）で定義されましたすべての時間。
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は、任意の拡張子と共に、UUIDと「opaquelocktoken」スキームを連結することによって構築されます。サーバはそれぞれの新しいロック・トークンのための新しいUUIDを作成することができます。サーバーは、UUIDを再利用したい場合は、サーバーは、拡張子を追加しなければならない、と拡張子を生成するアルゴリズムは、同じ拡張子が関連付けられたUUIDで二回使用されることはありませんことを保証しなければなりません。
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; UUID is defined in Section 3 of [RFC4122]. Note that LWS ; is not allowed between elements of ; this production.
OpaqueLockToken-URI = "opaquelocktoken：" UUID [拡張]。 UUIDは、[RFC4122]のセクション3で定義されています。なお、LWS。の要素の間に許可されていません。この生産。
Extension = path ; path is defined in Section 3.3 of [RFC3986]
拡張=パス。パスは、[RFC3986]のセクション3.3で定義され
Appendix D. Lock-null Resources
付録D.ロックヌルリソース
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、UNLOCK以外の任意の方法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.
URLにPUTリクエストが成功した場合、Oサーバは、定期的なリソースへのロックヌルリソースを変換します。
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).
（相互運用性の経験がないすべてのサーバーがこの要件に従っていることを示したが）URLへのMKCOL要求が成功した場合、サーバはコレクションにロックヌルリソースを変換し、O。
o Property values were defined for DAV:lockdiscovery and DAV: supportedlock properties but not necessarily for other properties like DAV:getcontenttype.
Oプロパティ値がDAVのために定義した：lockdiscoveryおよびDAV：supportedlock特性必ずしもではないがDAVのような他の特性のために：GETCONTENTTYPE。
Clients can easily interoperate both with servers that support the old model "lock-null resources" and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET.
クライアントは、簡単に古い機種「ロックヌルリソース」との推奨モデルをサポートするサーバーにMKCOLまたはGETではない、だけでマップされていないURLにLOCK後にPUTしようとすることで、「空のリソースをロック」の両方に相互運用することができます。
D.1. Guidance for Clients Using LOCK to Create Resources
D.1。リソースを作成するためにロックを使用したクライアントのためのガイダンス
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]を使用して、この仕様の前に実装されている）だけでなく、ロックされた空のリソースを作成するサーバーを作成するサーバを見つけるかもしれません。 LOCK要求に対する応答が作成されたリソースの種類を示すものではありません。どちらのタイプで、クライアントとの契約を助けるいくつかのテクニックがあります。
If the client wishes to avoid accidentally creating either lock-null or empty locked resources, an "If-Match: *" header can be included with LOCK requests to prevent the server from creating a new resource.
クライアントが誤ってロック-nullまたは空のロックされたいずれかのリソースを作成しないように希望する場合は、「場合 - マッチ：*」ヘッダーは、新しいリソースを作成からサーバーを防ぐために、LOCK要求に含めることができます。
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.
ヘッダ：LOCK要求がリソースを作成し、クライアントがその後にコピーまたは移動要求を使用して、そのリソースを上書きしたい場合、クライアントは「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.
LOCK要求がリソースを作成し、クライアントがそのリソースを取り除くことを決定した場合、DELETE要求はロックヌルリソースで失敗することになっているとUNLOCKは代わりに使用する必要があります。しかし、ロックされた空のリソースと、UNLOCKは、リソースが消えることはありません。そのため、クライアントは両方の要求をしようとすると、2つの要求のいずれかでエラーを無視する必要がある場合があります。
Appendix E. Guidance for Clients Desiring to Authenticate
認証を希望するクライアントのための付録E.ガイダンス
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クライアントがサーバーへの最初のカップルのリクエストで認証することができるだろう、それはレルム名、ナンス、およびその他の挑戦の情報をサーバーから認証チャレンジを取得する方法を持っていた提供。 PROPFINDは、クライアントが認証された場合、より多くの目に見えるリソースを返し、まだクライアントが匿名である場合には失敗しないことがあります - いくつかの要求の結果は、クライアントが認証されているかどうかに応じて異なる場合がありますので注意してください。
There are a number of ways the client might be able to trigger the server to provide an authentication challenge. This appendix describes a couple approaches that seem particularly likely to work.
クライアントが認証チャレンジを提供するために、サーバーをトリガすることができるかもしれないいくつかの方法があります。この付録では、動作するように特にそう思われるカップルのアプローチを説明します。
The first approach is to perform a request that ought to require authentication. However, it's possible that a server might handle any request even without authentication, so to be entirely safe, the client could add a conditional header to ensure that even if the request passes permissions checks, it's not actually handled by the server. An example of following this approach would be to use a PUT request with an "If-Match" header with a made-up ETag value. This approach might fail to result in an authentication challenge if the server does not test authorization before testing conditionals as is required (see Section 8.5), or if the server does not need to test authorization.
最初のアプローチは、認証を必要とするべきである要求を実行することです。しかし、それはそう完全に安全であると、クライアントが要求が権限チェックに合格した場合でも、それは実際にサーバによって処理されないということを保証するために、条件付きヘッダーを追加することができ、サーバーでも認証なしですべての要求を処理するかもしれないことが可能です。このアプローチを以下の例は、作られたアップETag値と「IFマッチ」ヘッダとPUT要求を使用することであろう。サーバが認証をテストする必要がない場合、このアプローチは、サーバーが（セクション8.5を参照）が必要とされるような条件文をテストする前に承認をテストしていない場合は、認証チャレンジをもたらすことができない、または可能性があります。
Example - forcing auth challenge with write request
例 - 書き込み要求で強制認証挑戦
>>Request
>>リクエスト
PUT /forceauth.txt HTTP/1.1 Host: www.example.com If-Match: "xxx" Content-Type: text/plain Content-Length: 0
PUT /forceauth.txt HTTP / 1.1ホスト：www.example.com-一致した場合： "XXX" のContent-Type：text / plainのコンテンツ長：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]で定義される）Authorizationヘッダを使用することです。パスワード文字列または実際のもっともらしい資格情報を持つ：たとえば、クライアントが作らアップの基本的なユーザーIDを含むAuthorizationヘッダーを含むPROPFIND要求を開始することができます。このアプローチは、それが認識されていないユーザ名、無効なパスワード、あるいはそれも基本認証を処理しない場合にAuthorizationヘッダを受信した場合の課題と一緒に「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."
オリジンサーバがリクエストと共に送られた資格証明書を受け入れることを望まない場合」、それは401（不正な）応答を返すべきである。応答は、要求に適用される少なくとも一つの（おそらく新しい）の挑戦を含むWWW-Authenticateヘッダフィールドを含まなければなりません資源。"
There's a slight problem with implementing that recommendation in some cases, because some servers do not even have challenge information for certain resources. Thus, when there's no way to authenticate to a resource or the resource is entirely publicly available over all accepted methods, the server MAY ignore the Authorization header, and the client will presumably try again later.
一部のサーバーでも、特定のリソースのためのチャレンジ情報を持っていないので、いくつかのケースではその勧告を実装すると若干の問題が、あります。リソースまたはリソースに対して認証する方法は、すべての受け入れの方法に比べて、完全に一般に公開が無いだときこのように、サーバはAuthorizationヘッダを無視することができ、クライアントはおそらく後で再試行します。
Example - forcing auth challenge with Authorization header
例 - Authorizationヘッダと強制認証チャレンジ
>>Request
>>リクエスト
PROPFIND /docs/ HTTP/1.1 Host: www.example.com Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Content-type: application/xml; charset="utf-8" Content-Length: xxxx
PROPFIND /ドキュメント/ HTTP / 1.1ホスト：www.example.com認証：基本QWxhZGRpbjpvcGVuIHNlc2FtZQ ==コンテンツタイプ：アプリケーション/ xmlの; charset = "UTF-8" をコンテンツの長さ：XXXX
[body omitted]
【本体は省略します]
Appendix F. Summary of Changes from
からの変更点の付録F.概要
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との間に大きな変化を示しています。サーバは（セクション10.1と18.3を参照）DAVレスポンスヘッダに準拠クラス「3」を返すことによって、本明細書におけるすべての変更をサポートすることを通知します。
F.1. Changes for Both Client and Server Implementations
F.1。クライアントとサーバの両方を実装するための変更点
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.
サーバーは、最低でも、含めて結果を返すようにPROPFIND「allprop」（9.1節）の意味論が緩和されているO、ライブプロパティは、この仕様で定義され、必ずしも必要ではないが、他のライブのプロパティを返します。それらの他の仕様はとても必要な場合は、他の仕様で定義されたカスタムプロパティとプロパティが含まれるプロパティのセットを - 「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サーバは、現在の深さのPROPFIND要求を拒否することが許可されています。これは深さの一連の操作を行うことができるようにする必要があります使用するクライアント：代わりに1を要求。
o Multi-Status response bodies now can transport the value of HTTP's Location response header in the new 'location' element. Clients may use this to avoid additional roundtrips to the server when there is a 'response' element with a 3xx status (see Section 14.24).
Oマルチステータスのレスポンスボディは今、新しい「場所」要素に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.
それは最初もはやターゲットリソースを削除するには、サーバを必要としないように、COPYの定義が緩和された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.
要求ヘッダーは、現在完全なURIに加えて絶対パスを許可する場合、O宛先（セクション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レスポンスボディ（ただし、それはRFC 3253で推奨たものとは異なるフォーマットを使用することに注意して、14.5節を参照）内の「エラー」XML要素を追加します。
o Senders and recipients are now required to support the UTF-16 character encoding in XML message bodies (see Section 19).
O送信者と受信者は現在、XMLメッセージの本文（セクション19を参照）でUTF-16文字エンコーディングをサポートするために必要とされます。
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.
「ロックヌルリソース」（LNRs）のO RFC 2518のコンセプトは単純化されたアプローチによって置き換えられている、「空のリソースをロックされた」（7.3節を参照してください）。もう頼ることはできませんロックヌルリソースクライアントのいくつかの側面がありますが、つまり、ロックされたコレクションまたは全くPUTやMKCOL要求が発行されなかったとき、彼らがUNLOCK時に消えているという事実を作成するためにそれらを使用する機能。サーバがまだRFC 2518に従ってLNRsを実装するために許可されていることに注意してください。
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.
LOCK要求で供給され、所有者の値だけで死んで財産（セクション14.17）のように、サーバによって保存されている必要があります。o DAVがいることを明らかにしました。 lockroot要素（セクション14.12）、クライアントはロックのルートを発見することができます。また、DAVを追加しました。
F.2. Changes for Server Implementations
F.2。サーバー実装の変更点
Collections and Namespace Operations
コレクションと名前空間操作
o Due to interoperability problems, allowable formats for contents of 'href' elements in multistatus responses have been limited (see Section 8.3).
Oにより相互運用性の問題のために、multistatus応答で「HREF」要素の内容の許容フォーマットは（8.3節を参照）を限定されていました。
o Due to lack of implementation, support for the 'propertybehavior' request body for COPY and MOVE has been removed. Instead, requirements for property preservation have been clarified (see Sections 9.8 and 9.9).
Oにより、実装の不足のために、COPYとMOVEのための「propertybehavior」リクエストボディのためのサポートが削除されました。代わりに、プロパティの保存の要件は（セクション9.8および9.9を参照）明らかにされています。
Properties
プロパティ
o Strengthened server requirements for storage of property values, in particular persistence of language information (xml:lang), whitespace, and XML namespace information (see Section 4.3).
O特定の言語情報の永続性（XML：LANG）で、プロパティ値を格納するためのサーバ要件を強化、空白、およびXML名前空間情報（4.3節を参照してください）。
o Clarified requirements on which properties should be writable by the client; in particular, setting "DAV:displayname" should be supported by servers (see Section 15).
Oプロパティは、クライアントによって書き込み可能であるべきで要件を明確化。具体的には、設定を「DAV：表示名を」サーバー（セクション15を参照）によってサポートされる必要があります。
o Only 'rfc1123-date' productions are legal as values for DAV: getlastmodified (see Section 15.7).
（項15.7を参照してください）getlastmodified：Oのみ「RFC1123-日付」プロダクションは、DAVの値として有効です。
Headers and Marshalling
ヘッダーとマーシャリング
o Servers are now required to do authorization checks before processing conditional headers (see Section 8.5).
Oサーバは、現在（セクション8.5を参照）条件付きのヘッダーを処理する前に認証チェックを行うために必要とされています。
Locking
ロッキング
o Strengthened requirement to check identity of lock creator when accessing locked resources (see Section 6.4). Clients should be aware that lock tokens returned to other principals can only be used to break a lock, if at all.
O強化要件がロックされたリソースにアクセスするロック作成者の身元を確認すること（セクション6.4を参照してください）。クライアントは、まったく場合にのみ、ロックを解除するために使用することができ、ロックトークンは、他のプリンシパルに戻ったことに注意する必要があります。
o Section 8.10.4 of [RFC2518] incorrectly required servers to return a 409 status where a 207 status was really appropriate. This has been corrected (Section 9.10).
O [RFC2518]のセクション8.10.4が誤っ207個の状態が本当に適切であった409のステータスを返すようにサーバを必要としました。これは、（セクション9.10）を修正しました。
F.3. Other Changes
F.3。その他の変更
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.
DAV：[RFC2518]のセクション4.6で導入されたソースプロパティが原因実装経験の不足のため削除されました。
The DAV header now allows non-IETF extensions through URIs in addition to compliance class tokens. It also can now be used in requests, although this specification does not define any associated semantics for the compliance classes defined in here (see Section 10.1).
DAVヘッダーは、現在コンプライアンスクラストークンに加えて、URIを介して非IETFの拡張を可能にします。この仕様は、ここで定義されたコンプライアンス・クラスのための任意の関連するセマンティクスを定義していないが、それはまた、現在、リクエストで使用することができます（10.1節を参照してください）。
In RFC 2518, the definition of the Depth header (Section 9.2) required that, by default, request headers would be applied to each resource in scope. Based on implementation experience, the default has now been reversed (see Section 10.2).
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要素で使用TimeTypeフォーマット。さて、この仕様で定義された2つのだけの形式は（10.7節を参照）が許可されています。
Author's Address
著者のアドレス
Lisa Dusseault (editor) CommerceNet 2064 Edgewood Dr. Palo Alto, CA 94303 US
リサDusseault（エディタ）CommerceNet 2064エッジウッド博士はカリフォルニア州パロアルト94303米国
EMail: ldusseault@commerce.net
メールアドレス：ldusseault@commerce.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。