[要約] RFC 2518は、WEBDAV（分散型著者付きHTTP拡張）のためのHTTP拡張に関する仕様です。このRFCの目的は、HTTPプロトコルを使用してウェブ上でのコンテンツの作成、編集、管理を可能にするための機能を提供することです。
Network Working Group Y. Goland
Request for Comments: 2518 Microsoft
Category: Standards Track E. Whitehead
UC Irvine
A. Faizi
Netscape
S. Carter
Novell
D. Jensen
Novell
February 1999
HTTP Extensions for Distributed Authoring -- WEBDAV
分散オーサリング用のHTTP拡張機能-WebDav
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
Abstract
概要
This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance).
このドキュメントは、リソースプロパティの管理、リソースコレクションの作成と管理、名前空間操作、およびリソースロック（衝突回避）のために、HTTP/1.1に補助するメソッド、ヘッダー、およびコンテンツタイプのセットを指定します。
Table of Contents
目次
ABSTRACT............................................................1
1 INTRODUCTION .....................................................5
2 NOTATIONAL CONVENTIONS ...........................................7
3 TERMINOLOGY ......................................................7
4 DATA MODEL FOR RESOURCE PROPERTIES ...............................8
4.1 The Resource Property Model ...................................8
4.2 Existing Metadata Proposals ...................................8
4.3 Properties and HTTP Headers ...................................9
4.4 Property Values ...............................................9
4.5 Property Names ...............................................10
4.6 Media Independent Links ......................................10
5 COLLECTIONS OF WEB RESOURCES ....................................11
5.1 HTTP URL Namespace Model .....................................11
5.2 Collection Resources .........................................11
5.3 Creation and Retrieval of Collection Resources ...............12
5.4 Source Resources and Output Resources ........................13
6 LOCKING .........................................................14
6.1 Exclusive Vs. Shared Locks ...................................14
6.2 Required Support .............................................16
6.3 Lock Tokens ..................................................16
6.4 opaquelocktoken Lock Token URI Scheme ........................16
6.4.1 Node Field Generation Without the IEEE 802 Address ........17
6.5 Lock Capability Discovery ....................................19
6.6 Active Lock Discovery ........................................19
6.7 Usage Considerations .........................................19
7 WRITE LOCK ......................................................20
7.1 Methods Restricted by Write Locks ............................20
7.2 Write Locks and Lock Tokens ..................................20
7.3 Write Locks and Properties ...................................20
7.4 Write Locks and Null Resources ...............................21
7.5 Write Locks and Collections ..................................21
7.6 Write Locks and the If Request Header ........................22
7.6.1 Example - Write Lock ......................................22
7.7 Write Locks and COPY/MOVE ....................................23
7.8 Refreshing Write Locks .......................................23
8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
8.1 PROPFIND .....................................................24
8.1.1 Example - Retrieving Named Properties .....................25
8.1.2 Example - Using allprop to Retrieve All Properties ........26
8.1.3 Example - Using propname to Retrieve all Property Names ...29
8.2 PROPPATCH ....................................................31
8.2.1 Status Codes for use with 207 (Multi-Status) ..............31
8.2.2 Example - PROPPATCH .......................................32
8.3 MKCOL Method .................................................33
8.3.1 Request ...................................................33
8.3.2 Status Codes ..............................................33
8.3.3 Example - MKCOL ...........................................34
8.4 GET, HEAD for Collections ....................................34
8.5 POST for Collections .........................................35
8.6 DELETE .......................................................35
8.6.1 DELETE for Non-Collection Resources .......................35
8.6.2 DELETE for Collections ....................................36
8.7 PUT ..........................................................36
8.7.1 PUT for Non-Collection Resources ..........................36
8.7.2 PUT for Collections .......................................37
8.8 COPY Method ..................................................37
8.8.1 COPY for HTTP/1.1 resources ...............................37
8.8.2 COPY for Properties .......................................38
8.8.3 COPY for Collections ......................................38
8.8.4 COPY and the Overwrite Header .............................39
8.8.5 Status Codes ..............................................39
8.8.6 Example - COPY with Overwrite .............................40
8.8.7 Example - COPY with No Overwrite ..........................40
8.8.8 Example - COPY of a Collection ............................41
8.9 MOVE Method ..................................................42
8.9.1 MOVE for Properties .......................................42
8.9.2 MOVE for Collections ......................................42
8.9.3 MOVE and the Overwrite Header .............................43
8.9.4 Status Codes ..............................................43
8.9.5 Example - MOVE of a Non-Collection ........................44
8.9.6 Example - MOVE of a Collection ............................44
8.10 LOCK Method ..................................................45
8.10.1 Operation .................................................46
8.10.2 The Effect of Locks on Properties and Collections .........46
8.10.3 Locking Replicated Resources ..............................46
8.10.4 Depth and Locking .........................................46
8.10.5 Interaction with other Methods ............................47
8.10.6 Lock Compatibility Table ..................................47
8.10.7 Status Codes ..............................................48
8.10.8 Example - Simple Lock Request .............................48
8.10.9 Example - Refreshing a Write Lock .........................49
8.10.10 Example - Multi-Resource Lock Request ....................50
8.11 UNLOCK Method ................................................51
8.11.1 Example - UNLOCK ..........................................52
9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
9.1 DAV Header ...................................................52
9.2 Depth Header .................................................52
9.3 Destination Header ...........................................54
9.4 If Header ....................................................54
9.4.1 No-tag-list Production ....................................55
9.4.2 Tagged-list Production ....................................55
9.4.3 not Production ............................................56
9.4.4 Matching Function .........................................56
9.4.5 If Header and Non-DAV Compliant Proxies ...................57
9.5 Lock-Token Header ............................................57
9.6 Overwrite Header .............................................57
9.7 Status-URI Response Header ...................................57
9.8 Timeout Request Header .......................................58
10 STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
10.1 102 Processing ...............................................59
10.2 207 Multi-Status .............................................59
10.3 422 Unprocessable Entity .....................................60
10.4 423 Locked ...................................................60
10.5 424 Failed Dependency ........................................60
10.6 507 Insufficient Storage .....................................60
11 MULTI-STATUS RESPONSE .........................................60
12 XML ELEMENT DEFINITIONS .......................................61
12.1 activelock XML Element .......................................61
12.1.1 depth XML Element .........................................61
12.1.2 locktoken XML Element .....................................61
12.1.3 timeout XML Element .......................................61
12.2 collection XML Element .......................................62
12.3 href XML Element .............................................62
12.4 link XML Element .............................................62
12.4.1 dst XML Element ...........................................62
12.4.2 src XML Element ...........................................62
12.5 lockentry XML Element ........................................63
12.6 lockinfo XML Element .........................................63
12.7 lockscope XML Element ........................................63
12.7.1 exclusive XML Element .....................................63
12.7.2 shared XML Element ........................................63
12.8 locktype XML Element .........................................64
12.8.1 write XML Element .........................................64
12.9 multistatus XML Element ......................................64
12.9.1 response XML Element ......................................64
12.9.2 responsedescription XML Element ...........................65
12.10 owner XML Element ...........................................65
12.11 prop XML element ............................................66
12.12 propertybehavior XML element ................................66
12.12.1 keepalive XML element ....................................66
12.12.2 omit XML element .........................................67
12.13 propertyupdate XML element ..................................67
12.13.1 remove XML element .......................................67
12.13.2 set XML element ..........................................67
12.14 propfind XML Element ........................................68
12.14.1 allprop XML Element ......................................68
12.14.2 propname XML Element .....................................68
13 DAV PROPERTIES ................................................68
13.1 creationdate Property ........................................69
13.2 displayname Property .........................................69
13.3 getcontentlanguage Property ..................................69
13.4 getcontentlength Property ....................................69
13.5 getcontenttype Property ......................................70
13.6 getetag Property .............................................70
13.7 getlastmodified Property .....................................70
13.8 lockdiscovery Property .......................................71
13.8.1 Example - Retrieving the lockdiscovery Property ...........71
13.9 resourcetype Property ........................................72
13.10 source Property .............................................72
13.10.1 Example - A source Property ..............................72
13.11 supportedlock Property ......................................73
13.11.1 Example - Retrieving the supportedlock Property ..........73
14 INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
15 DAV COMPLIANCE CLASSES ........................................75
15.1 Class 1 ......................................................75
15.2 Class 2 ......................................................75
16 INTERNATIONALIZATION CONSIDERATIONS ...........................76
17 SECURITY CONSIDERATIONS .......................................77
17.1 Authentication of Clients ....................................77
17.2 Denial of Service ............................................78
17.3 Security through Obscurity ...................................78
17.4 Privacy Issues Connected to Locks ............................78
17.5 Privacy Issues Connected to Properties .......................79
17.6 Reduction of Security due to Source Link .....................79
17.7 Implications of XML External Entities ........................79
17.8 Risks Connected with Lock Tokens .............................80
18 IANA CONSIDERATIONS ...........................................80
19 INTELLECTUAL PROPERTY .........................................81
20 ACKNOWLEDGEMENTS ..............................................82
21 REFERENCES ....................................................82
21.1 Normative References .........................................82
21.2 Informational References .....................................83
22 AUTHORS' ADDRESSES ............................................84
23 APPENDICES ....................................................86
23.1 Appendix 1 - WebDAV Document Type Definition .................86
23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
23.3 Appendix 3 - Notes on Processing XML Elements ................89
23.3.1 Notes on Empty XML Elements ...............................89
23.3.2 Notes on Illegal XML Processing ...........................89
23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
23.4.1 Introduction ..............................................92
23.4.2 Meaning of Qualified Names ................................92
24 FULL COPYRIGHT STATEMENT ......................................94
1 Introduction
1はじめに
This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for:
このドキュメントでは、クライアントがリモートWebコンテンツオーサリング操作を実行できるようにするHTTP/1.1プロトコルの拡張機能について説明します。この拡張機能は、次の操作を提供するメソッド、ヘッダー、リクエストエンティティボディフォーマット、および応答エンティティボディフォーマットのコヒーレントセットを提供します。
Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc. Also, the ability to link pages of any media type to related pages.
プロパティ：著者、作成日などの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.
ロック：複数の人がドキュメントで同時に作業するのを防ぐ能力。これにより、最初の1人の著者が別の著者の変更を統合せずに変更を書き込むときに変更が失われる「失われた更新問題」が防止されます。
Namespace Operations: The ability to instruct the server to copy and move Web resources.
名前空間操作：サーバーにWebリソースをコピーして移動するよう指示する機能。
Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" [RFC2291].
これらの操作の要件と根拠は、コンパニオンドキュメント「World Wide Webの分散オーサリングおよびバージョンプロトコルの要件」[RFC2291]に記載されています。
The sections below provide a detailed introduction to resource properties (section 4), collections of resources (section 5), and locking operations (section 6). These sections introduce the abstractions manipulated by the WebDAV-specific HTTP methods described in section 8, "HTTP Methods for Distributed Authoring".
以下のセクションでは、リソースプロパティ（セクション4）、リソースのコレクション（セクション5）、およびロック操作（セクション6）の詳細な紹介を示します。これらのセクションでは、セクション8「分散オーサリングのHTTPメソッド」で説明されているWebDAV固有のHTTPメソッドによって操作される抽象化を紹介します。
In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter information either in an Extensible Markup Language (XML) [REC-XML] request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility; and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support. As a rule of thumb, parameters are encoded in XML entity bodies when they have unbounded length, or when they may be shown to a human user and hence require encoding in an ISO 10646 character set. Otherwise, parameters are encoded within HTTP headers. Section 9 describes the new HTTP headers used with WebDAV methods.
HTTP/1.1では、メソッドパラメーター情報はHTTPヘッダーでのみエンコードされました。HTTP/1.1とは異なり、WebDAVはメソッドパラメーター情報を拡張可能なマークアップ言語（XML）[REC-XML]リクエストエンティティボディ、またはHTTPヘッダーのいずれかでエンコードします。メソッドパラメーターをエンコードするためにXMLを使用することは、既存の構造に追加のXML要素を追加し、拡張性を提供する機能によって動機付けられました。また、ISO 10646文字セットで情報をエンコードするXMLの機能により、国際化のサポートを提供します。経験則として、パラメーターは、固定されていない長さがある場合、またはそれらが人間のユーザーに表示される可能性がある場合、ISO 10646文字セットでエンコードする必要がある場合、XMLエンティティボディでエンコードされます。それ以外の場合、パラメーターはHTTPヘッダー内でエンコードされます。セクション9では、WebDAVメソッドで使用される新しいHTTPヘッダーについて説明します。
In addition to encoding method parameters, XML is used in WebDAV to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input.
メソッドパラメーターをエンコードすることに加えて、XMLはWebDAVで使用され、メソッドからの応答をエンコードし、メソッド出力のXMLの拡張性と国際化の利点と入力を提供します。
XML elements used in this specification are defined in section 12.
この仕様で使用されるXML要素は、セクション12で定義されています。
The XML namespace extension (Appendix 4) is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names.
XMLネームスペース拡張機能（付録4）は、他の要素名と衝突することを恐れずに新しいXML要素を追加できるようにするために、この仕様でも使用されています。
While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. New status codes developed for the WebDAV methods are defined in section 10. Since some WebDAV methods may operate over many
HTTP/1.1によって提供されるステータスコードは、WebDAVメソッドで発生するほとんどのエラー条件を記述するのに十分ですが、既存のカテゴリにきちんと該当しないエラーがいくつかあります。WebDAVメソッド用に開発された新しいステータスコードは、セクション10で定義されています。一部のWebDAVメソッドは多くの場合に動作する可能性があるため
resources, the Multi-Status response has been introduced to return status information for multiple resources. The Multi-Status response is described in section 11.
リソース、複数のリソースのステータス情報を返すためにマルチステータス応答が導入されました。マルチステータス応答はセクション11で説明されています。
WebDAV employs the property mechanism to store information about the current state of the resource. For example, when a lock is taken out on a resource, a lock information property describes the current state of the lock. Section 13 defines the properties used within the WebDAV specification.
WebDavは、プロパティメカニズムを採用して、リソースの現在の状態に関する情報を保存します。たとえば、ロックがリソースで取り出されると、ロック情報プロパティはロックの現在の状態を説明します。セクション13では、WebDAV仕様内で使用されるプロパティを定義しています。
Finishing off the specification are sections on what it means to be compliant with this specification (section 15), on internationalization support (section 16), and on security (section 17).
仕様の仕上げは、この仕様（セクション15）、国際化のサポート（セクション16）、およびセキュリティ（セクション17）に準拠することの意味に関するセクションです。
2 Notational Conventions
2表記規則
Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol elements is exactly the same as described in section 2.1 of [RFC2068]. Since this augmented BNF uses the basic production rules provided in section 2.2 of [RFC2068], these rules apply to this document as well.
このドキュメントはHTTP/1.1プロトコルの一連の拡張機能を記述しているため、ここで使用されるプロトコル要素を説明するために使用される拡張BNFは、[RFC2068]のセクション2.1で説明されているとまったく同じです。この拡張されたBNFは、[RFC2068]のセクション2.2で提供されている基本的な生産ルールを使用しているため、これらの規則もこのドキュメントにも適用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード「必須」、「必要」、「必須」、「必要」、「しなければ」、「そうしない」、「ははは」、「ははは」、「推奨」、「5月」、「オプション」は、RFC 2119 [RFC2119]に記載されているように解釈されます。
3 Terminology
3用語
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in [RFC2396].
URI/URL-それぞれ均一なリソース識別子と均一なリソースロケーター。これらの用語（およびそれらの区別）は[RFC2396]で定義されています。
Collection - A resource that contains a set of URIs, termed member URIs, which identify member resources and meets the requirements in section 5 of this specification.
コレクション - メンバーのURIと呼ばれるURISのセットを含むリソースは、メンバーリソースを識別し、この仕様のセクション5の要件を満たしています。
Member URI - A URI which is a member of the set of URIs contained by a collection.
メンバーURI-コレクションに含まれるURISのセットのメンバーであるURI。
Internal Member URI - A Member URI that is immediately relative to the URI of the collection (the definition of immediately relative is given in section 5.2).
内部メンバーURI-コレクションのURIに対してすぐに比較的メンバーURI（すぐに相対的な定義はセクション5.2に記載されています）。
Property - A name/value pair that contains descriptive information about a resource.
プロパティ - リソースに関する記述情報を含む名前/値ペア。
Live Property - A property whose semantics and syntax are enforced by the server. For example, the live "getcontentlength" property has its value, the length of the entity returned by a GET request, automatically calculated by the server.
ライブプロパティ - サーバーによってセマンティクスと構文が実施されるプロパティ。たとえば、ライブ「GetContentLength」プロパティにはその価値があり、サーバーによって自動的に計算されたGETリクエストによって返されるエンティティの長さがあります。
Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property.
Deadプロパティ - サーバーによってセマンティクスと構文が施行されていないプロパティ。サーバーは、死んだプロパティの値のみを記録します。クライアントは、死んだプロパティの構文とセマンティクスの一貫性を維持する責任があります。
Null Resource - A resource which responds with a 404 (Not Found) to any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK. A NULL resource MUST NOT appear as a member of its parent collection.
nullリソース - put、mkcol、options and lockを除き、http/1.1またはdavメソッドに404（見つかりません）で応答するリソース。ヌルリソースは、その親コレクションのメンバーとして表示されてはなりません。
4 Data Model for Resource Properties
リソースプロパティの4データモデル
Properties are pieces of data that describe the state of a resource. Properties are data about data.
プロパティは、リソースの状態を記述するデータの部分です。プロパティはデータに関するデータです。
Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents.
プロパティは、リソースの効率的な発見と管理を提供するために、分散オーサリング環境で使用されます。たとえば、「サブジェクト」プロパティは、被験者によるすべてのリソースのインデックス作成を可能にする場合があり、「著者」プロパティは、著者がどの文書を書いたかを発見することを可能にする場合があります。
The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics.
DAVプロパティモデルは、名前/値のペアで構成されています。プロパティの名前は、プロパティの構文とセマンティクスを識別し、その構文とセマンティクスを参照するアドレスを提供します。
There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is read-only, maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.
プロパティには2つのカテゴリがあります。「ライブ」と「死んでいる」。ライブプロパティには、サーバーによって実施された構文とセマンティクスがあります。ライブプロパティには、a）プロパティの値がサーバーによって維持され、b）プロパティの値がクライアントによって維持されますが、サーバーは提出された値を構文チェックする場合が含まれます。特定のライブプロパティのすべてのインスタンスは、そのプロパティ名に関連付けられた定義に準拠する必要があります。死んだプロパティには、クライアントが実施する構文とセマンティクスがあります。サーバーは、単にプロパティのVerbatimの値を記録するだけです。
Properties have long played an essential role in the maintenance of large document repositories, and many current proposals contain some notion of a property, or discuss web metadata more generally. These include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several proposals on representing relationships within HTML. Work on PICS-NG
プロパティは、大規模なドキュメントリポジトリのメンテナンスにおいて長い間重要な役割を果たしてきました。多くの現在の提案には、プロパティの概念が含まれているか、より一般的にWebメタデータを議論しています。これらには、写真[Rec-Pics]、Pics-NG、XML、Webコレクション、およびHTML内の関係を表すいくつかの提案が含まれます。Pics-ngの作業
and Web Collections has been subsumed by the Resource Description Framework (RDF) metadata activity of the World Wide Web Consortium. RDF consists of a network-based data model and an XML representation of that model.
また、Webコレクションは、World Wide Webコンソーシアムのリソース説明フレームワーク（RDF）メタデータアクティビティに包まれています。RDFは、ネットワークベースのデータモデルとそのモデルのXML表現で構成されています。
Some proposals come from a digital library perspective. These include the Dublin Core [RFC2413] metadata set and the Warwick Framework [WF], a container architecture for different metadata schemas. The literature includes many examples of metadata, including MARC [USMARC], a bibliographic metadata format, and a technical report bibliographic format employed by the Dienst system [RFC1807]. Additionally, the proceedings from the first IEEE Metadata conference describe many community-specific metadata sets.
いくつかの提案は、デジタルライブラリの観点から来ています。これらには、ダブリンコア[RFC2413]メタデータセットと、さまざまなメタデータスキーマのコンテナアーキテクチャであるワーウィックフレームワーク[WF]が含まれます。文献には、Marc [USMARC]、書誌メタデータ形式、およびDIENSTシステム[RFC1807]で採用されている技術レポート書誌形式など、メタデータの多くの例が含まれています。さらに、最初のIEEEメタデータ会議の議事録では、多くのコミュニティ固有のメタデータセットについて説明しています。
Participants of the 1996 Metadata II Workshop in Warwick, UK [WF], noted that "new metadata sets will develop as the networked infrastructure matures" and "different communities will propose, design, and be responsible for different types of metadata." These observations can be corroborated by noting that many community-specific sets of metadata already exist, and there is significant motivation for the development of new forms of metadata as many communities increasingly make their data available in digital form, requiring a metadata format to assist data location and cataloging.
英国ワーウィックの1996年メタデータIIワークショップ[WF]の参加者は、「ネットワークインフラストラクチャが成熟するにつれて新しいメタデータセットが発展する」と「さまざまなコミュニティがさまざまな種類のメタデータを提案、設計、責任を負う」と述べました。これらの観察結果は、多くのコミュニティ固有のメタデータがすでに存在していることに注意することで裏付けられる可能性があり、多くのコミュニティがデジタル形式でデータを利用できるようになっているため、メタデータの新しい形式の開発に大きな動機があり、データを支援するためにメタデータ形式を必要とします。場所とカタログ。
Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus a mechanism is needed which allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.
HTTPメッセージヘッダーには、限られた意味で、プロパティがすでに存在しています。ただし、分散オーサリング環境では、リソースの状態を記述するために比較的多数のプロパティが必要であり、HTTPヘッダーを介してそれらをすべて設定/返信することは非効率的です。したがって、プリンシパルが関心のある一連のプロパティを識別し、それらのプロパティのみを設定または取得できるようにするメカニズムが必要です。
The value of a property when expressed in XML MUST be well formed.
XMLで表現された場合のプロパティの値は、適切に形成する必要があります。
XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self-describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages,
XMLは、豊富なスキーマ定義をサポートする柔軟で自己記述的な構造化されたデータ形式であり、複数の文字セットをサポートしているため、選択されています。XMLの自己記述的性質により、新しい要素を追加することにより、プロパティの値を拡張できます。古いクライアントは、元のスキーマで指定されたデータをまだ持っており、理解できない要素を無視するため、拡張機能に遭遇したときに壊れません。複数の文字セットに対するXMLのサポートにより、ユーザーに馴染みのあるキャラクターセットで、人間の読み取り可能なプロパティをエンコードして読み取ることができます。XMLの複数の人間言語に対するサポート、
using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages.
「XML：Lang」属性を使用すると、同じ文字セットが複数の人間言語で採用されているケースを処理します。
A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property.
プロパティ名は、プロパティの構文とセマンティクスに関する情報を提供するスキーマに関連付けられた普遍的に一意の識別子です。
Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition.
プロパティの名前は普遍的に一意であるため、クライアントは、問題のリソースでそのプロパティが「ライブ」である限り、複数のリソース、同じ、および異なるサーバーにわたる特定のプロパティの一貫した動作に依存できます。生きている財産はその定義に忠実です。
The XML namespace mechanism, which is based on URIs [RFC2396], is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control.
uris [RFC2396]に基づいたXMLネームスペースメカニズムは、名前空間衝突を防ぎ、さまざまな程度の管理制御を提供するため、プロパティの名前に使用されます。
The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced which will address issues relating to hierarchical properties.
プロパティネームスペースはフラットです。つまり、プロパティの階層は明示的に認識されていません。したがって、プロパティAとプロパティA/Bがリソースに存在する場合、2つのプロパティ間の関係の認識はありません。最終的には、階層特性に関連する問題に対処する別の仕様が生成されることが予想されます。
Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace.
最後に、単一のリソースで同じプロパティを2回定義することはできません。これにより、リソースのプロパティネームスペースに衝突が発生するためです。
Although HTML resources support links to other resources, the Web needs more general support for links between resources of any media type (media types are also known as MIME types, or content types). WebDAV provides such links. A WebDAV link is a special type of property value, formally defined in section 12.4, that allows typed connections to be established between resources of any media type. The property value consists of source and destination Uniform Resource Identifiers (URIs); the property name identifies the link type.
HTMLリソースは他のリソースへのリンクをサポートしていますが、Webは、あらゆるメディアタイプのリソース間のリンクに対してより一般的なサポートを必要とします（メディアタイプはMIMEタイプまたはコンテンツタイプとしても知られています）。WebDavはそのようなリンクを提供します。WebDavリンクは、セクション12.4で正式に定義されている特別なタイプのプロパティ値であり、任意のメディアタイプのリソース間で入力された接続を確立できるようにします。プロパティ値は、ソースおよび宛先のユニフォームリソース識別子（URI）で構成されています。プロパティ名はリンクタイプを識別します。
5 Collections of Web Resources
Webリソースの5つのコレクション
This section provides a description of a new type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace.
このセクションでは、新しいタイプのWebリソース、コレクションの説明を提供し、HTTP URLネームスペースとの相互作用について説明します。収集リソースの目的は、サーバーの名前空間内でコレクションのようなオブジェクト（ファイルシステムディレクトリなど）をモデル化することです。
All DAV compliant resources MUST support the HTTP URL namespace model specified herein.
すべてのDAVに準拠したリソースは、ここで指定されているHTTP URL名空間モデルをサポートする必要があります。
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.
HTTP URLネームスペースは、階層が「/」文字で区切られている階層名空間です。
An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member. The root, or top-level collection of the namespace under consideration is exempt from the previous rule.
HTTP URLネームスペースは、次の条件を満たしている場合に一貫していると言われています。HTTP階層のすべてのURLには、そのURLが内部メンバーとして含まれるコレクションが存在します。検討中の名前空間のルートまたはトップレベルのコレクションは、前のルールから免除されます。
Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL namespace be consistent. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.
HTTP/1.1もWebDAVも、HTTP URLネームスペース全体が一貫している必要はありません。ただし、特定のWebDAVメソッドは、名前空間の矛盾を引き起こす結果を生成することを禁止されています。
Although implicit in [RFC2068] and [RFC2396], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
[RFC2068]および[RFC2396]には暗黙的ですが、収集リソースを含むすべてのリソースは、複数のURIによって識別される場合があります。たとえば、複数のHTTP URLによってリソースを識別できます。
A collection is a resource whose state consists of at least a list of internal member URIs and a set of properties, but which may have additional state such as entity bodies returned by GET. An internal member URI MUST be immediately relative to a base URI of the collection. That is, the internal member URI is equal to a containing collection's URI plus an additional segment for non-collection resources, or additional segment plus trailing slash "/" for collection resources, where segment is defined in section 3.3 of [RFC2396].
コレクションは、少なくとも内部メンバーのURIのリストと一連のプロパティで構成されるリソースですが、GETによって返されるエンティティボディなどの追加の状態がある場合があります。内部メンバーのURIは、コレクションのベースURIに対してすぐに比較している必要があります。つまり、内部メンバーのURIは、コンテンディングコレクションのURIと非収集リソースの追加セグメント、または追加セグメントと収集リソースのトレーリングスラッシュ "/"に等しく、セグメントは[RFC2396]のセクション3.3で定義されています。
Any given internal member URI MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URI in a collection. Properties defined on collections behave exactly as do properties on non-collection resources.
指定された内部メンバーのURIは、コレクションに1回のみ属している必要があります。つまり、コレクションに同じURIの複数のインスタンスがあることは違法です。コレクションで定義されているプロパティは、非収集リソースのプロパティとまったく同じように動作します。
For all WebDAV compliant resources A and B, identified by URIs U and V, for which U is immediately relative to V, B MUST be a collection that has U as an internal member URI. So, if the resource with URL http://foo.com/bar/blah is WebDAV compliant and if the resource with URL http://foo.com/bar/ is WebDAV compliant then the resource with URL http://foo.com/bar/ must be a collection and must contain URL http://foo.com/bar/blah as an internal member.
URIS UとVによって識別されたすべてのWebDAV準拠のリソースAおよびBについて、UはすぐにVに比べて、Bは内部メンバーURIとしてUを持つコレクションでなければなりません。したがって、url http://foo.com/bar/blahを備えたリソースがWebdavに準拠している場合、url http://foo.com/bar/のリソースがwebdavに準拠している場合、url http：// fooのリソース.com/bar/はコレクションである必要があり、内部メンバーとしてurl http://foo.com/bar/blahが含まれている必要があります。
Collection resources MAY list the URLs of non-WebDAV compliant children in the HTTP URL namespace hierarchy as internal members but are not required to do so. For example, if the resource with URL http://foo.com/bar/blah is not WebDAV compliant and the URL http://foo.com/bar/ identifies a collection then URL http://foo.com/bar/blah may or may not be an internal member of the collection with URL http://foo.com/bar/.
収集リソースは、HTTP URL名空間階層に内部メンバーとして非webdav準拠の子供のURLをリストする場合がありますが、そうする必要はありません。たとえば、url http://foo.com/bar/blahのリソースがWebdavに準拠していない場合、url http://foo.com/bar/コレクションを識別し、url http://foo.com/bar/blahは、url http://foo.com/bar/を使用したコレクションの内部メンバーである場合とそうでない場合があります。
If a WebDAV compliant resource has no WebDAV compliant children in the HTTP URL namespace hierarchy then the WebDAV compliant resource is not required to be a collection.
WebDAV準拠のリソースにHTTP URL名前空間階層にWebDav準拠の子供がいない場合、WebDav準拠のリソースはコレクションである必要はありません。
There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names.
コレクションがその名前で後続のスラッシュなしで言及されると、後続のスラッシュが自動的に追加されるという常立条約があります。このため、リソースは、コレクションを指すために、「/」という点でURIを受け入れる場合があります。この場合、「/」で終わるURIを指す応答のコンテンツロケーションヘッダーを返す必要があります。たとえば、クライアントがhttp://foo.bar/blah（トレーリングスラッシュなし）でメソッドを呼び出す場合、リソースhttp://foo.bar/blah/（トレーリングスラッシュ）は、操作が呼び出されたかのように応答する場合がありますそれは、http：//foo.bar/blah/を含むコンテンツロケーションヘッダーを返す必要があります。一般に、クライアントはコレクション名の「/」形式を使用する必要があります。
A resource MAY be a collection but not be WebDAV compliant. That is, the resource may comply with all the rules set out in this specification regarding how a collection is to behave without necessarily supporting all methods that a WebDAV compliant resource is required to support. In such a case the resource may return the DAV:resourcetype property with the value DAV:collection but MUST NOT return a DAV header containing the value "1" on an OPTIONS response.
リソースはコレクションかもしれませんが、webdavに準拠していません。つまり、リソースは、WebDAV準拠のリソースがサポートする必要があるすべての方法を必ずしもサポートせずに、コレクションがどのように動作するかについてのこの仕様に記載されているすべてのルールに準拠する場合があります。そのような場合、リソースは、Value DAV：Collectionを持つDAV：ResourceTypeプロパティを返すことができますが、オプション応答に値「1」を含むDAVヘッダーを返してはなりません。
This document specifies the MKCOL method to create new collection resources, rather than using the existing HTTP/1.1 PUT or POST method, for the following reasons:
このドキュメントは、既存のHTTP/1.1 PUTまたはPOSTメソッドを使用するのではなく、新しいコレクションリソースを作成するMKCOLメソッドを指定しています。
In HTTP/1.1, the PUT method is defined to store the request body at the location specified by the Request-URI. While a description format for a collection can readily be constructed for use with PUT, the implications of sending such a description to the server are undesirable. For example, if a description of a collection that omitted some existing resources were PUT to a server, this might be interpreted as a command to remove those members. This would extend PUT to perform DELETE functionality, which is undesirable since it changes the semantics of PUT, and makes it difficult to control DELETE functionality with an access control scheme based on methods.
HTTP/1.1では、PUTメソッドが定義されており、リクエストウリで指定された場所にリクエスト本体を保存します。コレクションの説明形式は、PUTで使用するために容易に構築できますが、そのような説明をサーバーに送信することの意味は望ましくありません。たとえば、既存のリソースを省略したコレクションの説明がサーバーに配置された場合、これはそれらのメンバーを削除するコマンドとして解釈される可能性があります。これにより、削除機能を実行するために拡張されます。これは、Putのセマンティクスを変更し、メソッドに基づいてアクセス制御スキームで機能を制御することを困難にします。
While the POST method is sufficiently open-ended that a "create a collection" POST command could be constructed, this is undesirable because it would be difficult to separate access control for collection creation from other uses of POST.
POSTメソッドは「コレクションの作成」POSTコマンドを構築できるほど十分にオープンエンドですが、これは、コレクション作成のためのアクセス制御を他のポストの使用から分離することが困難であるため、望ましくありません。
The exact definition of the behavior of GET and PUT on collections is defined later in this document.
CETとコレクションの動作の正確な定義は、このドキュメントの後半で定義されています。
For many resources, the entity returned by a GET method exactly matches the persistent state of the resource, for example, a GIF file stored on a disk. For this simple case, the URI at which a resource is accessed is identical to the URI at which the source (the persistent state) of the resource is accessed. This is also the case for HTML source files that are not processed by the server prior to transmission.
多くのリソースの場合、GETメソッドによって返されるエンティティは、リソースの永続的な状態、たとえばディスクに保存されたGIFファイルと正確に一致します。この単純なケースでは、リソースにアクセスされるURIは、リソースのソース（永続的状態）にアクセスされるURIと同一です。これは、送信前にサーバーによって処理されないHTMLソースファイルにも当てはまります。
However, the server can sometimes process HTML resources before they are transmitted as a return entity body. For example, a server-side-include directive within an HTML file might instruct a server to replace the directive with another value, such as the current date. In this case, what is returned by GET (HTML plus date) differs from the persistent state of the resource (HTML plus directive). Typically there is no way to access the HTML resource containing the unprocessed directive.
ただし、サーバーは、リターンエンティティボディとして送信される前に、HTMLリソースを処理することがあります。たとえば、HTMLファイル内のサーバーサイドインクルードディレクティブは、サーバーに指令を現在の日付などの別の値に置き換えるように指示する場合があります。この場合、GET（HTML Plus日付）によって返されるものは、リソースの永続的な状態（HTML Plusディレクティブ）とは異なります。通常、未処理のディレクティブを含むHTMLリソースにアクセスする方法はありません。
Sometimes the entity returned by GET is the output of a data-producing process that is described by one or more source resources (that may not even have a location in the URI namespace). A single data-producing process may dynamically generate the state of a potentially large number of output resources. An example of this is a CGI script that describes a "finger" gateway process that maps part of the namespace of a server into finger requests, such as http://www.foo.bar.org/finger_gateway/user@host.
GETによって返されるエンティティは、1つ以上のソースリソース（URIネームスペースに場所がない場合もあります）によって説明されるデータ生産プロセスの出力です。単一のデータ生産プロセスは、潜在的に多数の出力リソースの状態を動的に生成する場合があります。この例は、サーバーの名前空間の一部をhttp://www.foo.bar.org/finger_gateway/user@hostなど、サーバーの名前空間の一部を指の要求にマッピングする「指」ゲートウェイプロセスを説明するCGIスクリプトです。
In the absence of distributed authoring capabilities, it is acceptable to have no mapping of source resource(s) to the URI namespace. In fact, preventing access to the source resource(s) has desirable security benefits. However, if remote editing of the source resource(s) is desired, the source resource(s) should be given a location in the URI namespace. This source location should not be one of the locations at which the generated output is retrievable, since in general it is impossible for the server to differentiate requests for source resources from requests for process output resources. There is often a many-to-many relationship between source resources and output resources.
分散オーサリング機能がない場合、URIネームスペースへのソースリソースのマッピングがないことは受け入れられます。実際、ソースリソースへのアクセスを防ぐことは、望ましいセキュリティ利益です。ただし、ソースリソースのリモート編集が必要な場合は、ソースリソースにURIネームスペースの場所を提供する必要があります。このソースの場所は、生成された出力が取得可能な場所の1つではありません。一般的に、サーバーがプロセス出力リソースの要求からソースリソースのリクエストを区別することは不可能であるためです。多くの場合、ソースリソースと出力リソースの間には多くの関係があります。
On WebDAV compliant servers the URI of the source resource(s) may be stored in a link on the output resource with type DAV:source (see section 13.10 for a description of the source link property). Storing the source URIs in links on the output resources places the burden of discovering the source on the authoring client. Note that the value of a source link is not guaranteed to point to the correct source. Source links may break or incorrect values may be entered. Also note that not all servers will allow the client to set the source link value. For example a server which generates source links on the fly for its CGI files will most likely not allow a client to set the source link value.
WebDAV準拠サーバーでは、ソースリソースのURIは、Type DAV：ソースの出力リソースのリンクに保存できます（ソースリンクプロパティの説明については、セクション13.10を参照）。出力リソースのリンクにソースURIを保存すると、オーサリングクライアントのソースを発見する負担がかかります。ソースリンクの値は、正しいソースを指すように保証されていないことに注意してください。ソースリンクが壊れたり、誤った値を入力したりすることがあります。また、すべてのサーバーがクライアントがソースリンク値を設定できるわけではないことに注意してください。たとえば、CGIファイルのソースリンクを飛行中に生成するサーバーは、クライアントがソースリンク値を設定できない可能性が高いです。
6 Locking
6ロック
The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem.
リソースをロックする機能は、そのリソースへのアクセスをシリアル化するメカニズムを提供します。オーサリングクライアントは、ロックを使用して、別のプリンシパルが編集中にリソースを変更しないという合理的な保証を提供できます。このようにして、クライアントは「紛失した更新」の問題を防ぐことができます。
This specification allows locks to vary over two client-specified parameters, the number of principals involved (exclusive vs. shared) and the type of access to be granted. This document defines locking for only one access type, write. However, the syntax is extensible, and permits the eventual specification of locking for other access types.
この仕様により、ロックは、2つのクライアント指定パラメーター、関与するプリンシパルの数（排他的対共有）、および許可されるアクセスの種類を異なります。このドキュメントでは、1つのアクセスタイプのみのロックを定義します。ただし、構文は拡張可能であり、他のアクセスタイプのロックの最終的な仕様を可能にします。
The most basic form of lock is an exclusive lock. This is a lock where the access right in question is only granted to a single principal. The need for this arbitration results from a desire to avoid having to merge results.
ロックの最も基本的な形式は、排他的なロックです。これは、問題の正しいアクセスが単一のプリンシパルにのみ付与されるロックです。この仲裁の必要性は、結果をマージしないようにしたいという欲求に起因します。
However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal with appropriate access can get the lock.
ただし、ロックの目標は、他の人がアクセス権を行使することを排除するのではなく、校長がアクセス権を行使するつもりであることを示すメカニズムを提供することである場合があります。このケースには共有ロックが提供されます。共有ロックにより、複数のプリンシパルがロックを受信できるようになります。したがって、適切なアクセスを備えたプリンシパルは、ロックを取得できます。
With shared locks there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set.
共有ロックには、リソースに影響を与える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 owner leaves without unlocking a resource. While both timeouts and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.
Web分散オーサリングシステムからの経験により、排他的なロックが硬すぎることが多すぎることが示されているため、共有ロックが含まれています。特定の編集プロセスを実施するために排他的ロックが使用されます。独占ロックを取り出し、リソースの読み取り、編集を実行し、リソースを書き、ロックを解放します。この編集プロセスには、プログラムがクラッシュしたとき、またはロックの所有者がリソースのロックを解除せずに離れるときなど、ロックが常に適切にリリースされるとは限らないという問題があります。タイムアウトと管理アクションの両方を使用して、問題のあるロックを削除することができますが、どちらのメカニズムも必要に応じて利用できない場合があります。タイムアウトが長い場合があるか、管理者が利用できない場合があります。
A WebDAV compliant server is not required to support locking in any form. If the server does support locking it may choose to support any combination of exclusive and shared locks for any access types.
WebDAV準拠のサーバーは、いかなる形式でもロックをサポートする必要はありません。サーバーがロックをサポートしている場合、アクセスタイプの排他的ロックと共有ロックの任意の組み合わせをサポートすることを選択できます。
The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks while others only provide support for exclusive write locks while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.
この柔軟性の理由は、ロックポリシーがさまざまなストレージリポジトリで採用されているリソース管理およびバージョンシステムのまさに中心に衝突するためです。これらのリポジトリでは、どのようなロックが利用可能になるかを制御する必要があります。たとえば、一部のリポジトリは共有の書き込みロックのみをサポートしますが、他のリポジトリは排他的な書き込みロックのみをサポートしますが、他のリポジトリはロックをまったく使用しません。各システムは特定のロック機能の除外に値するほど十分に異なるため、この仕様はWebDAV内の交渉の唯一の軸としてロックを残します。
A lock token is a type of state token, represented as a URI, which identifies a particular lock. A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body, and can also be found through lock discovery on a resource.
ロックトークンは、特定のロックを識別するURIとして表される状態トークンの一種です。ロックトークンは、応答本体のロックディスコービリプロパティのすべての成功したロック操作によって返されます。また、リソースのロックディスカバリーを通じても見つけることができます。
Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion.
ロックトークンURIは、常にすべてのリソースでユニークでなければなりません。この独自性の制約により、混乱を恐れることなく、ロックトークンをリソースとサーバー間で提出できます。
This specification provides a lock token URI scheme called opaquelocktoken that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements.
この仕様は、一意性要件を満たすOpaquelockTokenと呼ばれるロックトークンURIスキームを提供します。ただし、リソースは、URIスキームが一意性要件を満たしている限り、自由に返すことができます。
Having a lock token provides no special access rights. Anyone can find out anyone else's lock token by performing lock discovery. Locks MUST be enforced based upon whatever authentication mechanism is used by the server, not based on the secrecy of the token values.
ロックトークンを持つことは、特別なアクセス権を提供しません。誰でも、ロックディスカバリーを実行することで他の人のロックトークンを見つけることができます。ロックは、トークン値の秘密ではなく、サーバーが使用する認証メカニズムに基づいて実施する必要があります。
The opaquelocktoken URI scheme is designed to be unique across all resources for all time. Due to this uniqueness quality, a client may submit an opaque lock token in an If header on a resource other than the one that returned it.
Opaquelocktoken URIスキームは、常にすべてのリソースでユニークになるように設計されています。この一意性品質のため、クライアントは、それを返したリソース以外のリソースのヘッダーにIFヘッダーに不透明なロックトークンを送信することができます。
All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource.
すべてのリソースは、Opaquelocktokenスキームを認識する必要があり、少なくとも、ロックトークンがリソースの傑出したロックを参照していないことを認識します。
In order to guarantee uniqueness across all resources for all time the opaquelocktoken requires the use of the Universal Unique Identifier (UUID) mechanism, as described in [ISO-11578].
すべてのリソースにわたってすべてのリソースにわたって一意性を保証するために、Opaquelocktokenは、[ISO-11578]に記載されているように、ユニバーサルユニークな識別子（UUID）メカニズムの使用を必要とします。
Opaquelocktoken generators, however, have a choice of how they create these tokens. They can either generate a new UUID for every lock token they create or they can create a single UUID and then add extension characters. If the second method is selected then the program generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID.
ただし、Opaquelocktokenジェネレーターは、これらのトークンを作成する方法を選択できます。彼らは、作成するすべてのロックトークンの新しいUUIDを生成するか、単一のUUIDを作成してから拡張文字を追加することができます。2番目のメソッドが選択されている場合、拡張機能を生成するプログラムは、同じ拡張子が関連するUUIDで2回使用されないことを保証する必要があります。
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID, as defined in [ISO-11578]. Note that white space (LWS) is not allowed between elements of this production.
opaquelocktoken-uri = "opaquelocktoken：" uuid [endix];UUID生産は、[ISO-11578]で定義されているように、UUIDの文字列表現です。この生産の要素間では、空白（LWS）は許可されていないことに注意してください。
Extension = path ; path is defined in section 3.2.1 of RFC 2068 [RFC2068]
extension = path;パスは、RFC 2068 [RFC2068]のセクション3.2.1で定義されています
UUIDs, as defined in [ISO-11578], contain a "node" field that contains one of the IEEE 802 addresses for the server machine. As noted in section 17.8, there are several security risks associated with exposing a machine's IEEE 802 address. This section provides an alternate mechanism for generating the "node" field of a UUID which does not employ an IEEE 802 address. WebDAV servers MAY use this algorithm for creating the node field when generating UUIDs. The text in this section is originally from an Internet-Draft by Paul Leach and Rich Salz, who are noted here to properly attribute their work.
[ISO-11578]で定義されているUUIDSには、サーバーマシンのIEEE 802アドレスの1つが含まれる「ノード」フィールドが含まれています。セクション17.8で述べたように、マシンのIEEE 802アドレスの公開に関連するいくつかのセキュリティリスクがあります。このセクションでは、IEEE 802アドレスを使用していないUUIDの「ノード」フィールドを生成するための代替メカニズムを提供します。WebDAVサーバーは、UUIDを生成するときにノードフィールドを作成するためにこのアルゴリズムを使用する場合があります。このセクションのテキストは、もともとポール・リーチとリッチ・サルツによるインターネットドラフトからのものです。彼は、彼らの作品を適切に帰するためにここで注目されています。
The ideal solution is to obtain a 47 bit cryptographic quality random number, and use it as the low 47 bits of the node ID, with the most significant bit of the first octet of the node ID set to 1. This bit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards; hence, there can never be a conflict between UUIDs generated by machines with and without network cards.
理想的な解決策は、47ビット暗号化品質の乱数を取得し、ノードIDの低い47ビットとして使用することです。ノードIDの最初のオクテットの最も重要なビットは1に設定されています。ネットワークカードから取得したIEEE 802アドレスでは決して設定されないマルチキャストビット。したがって、ネットワークカードの有無にかかわらず、マシンによって生成されたUUID間に競合することはありません。
If a system does not have a primitive to generate cryptographic quality random numbers, then in most systems there are usually a fairly large number of sources of randomness available from which one can be generated. Such sources are system specific, but often include:
システムに暗号化品質の乱数を生成するための原始的なものがない場合、ほとんどのシステムでは、通常、利用可能なランダム性のかなり多くのソースがあり、そこから生成できます。このようなソースはシステム固有ですが、多くの場合：
- the percent of memory in use - the size of main memory in bytes - the amount of free main memory in bytes - the size of the paging or swap file in bytes - free bytes of paging or swap file - the total size of user virtual address space in bytes - the total available user address space bytes - the size of boot disk drive in bytes - the free disk space on boot drive in bytes - the current time - the amount of time since the system booted - the individual sizes of files in various system directories - the creation, last read, and modification times of files in various system directories - the utilization factors of various system resources (heap, etc.) - current mouse cursor position - current caret position - current number of running processes, threads - handles or IDs of the desktop window and the active window - the value of stack pointer of the caller - the process and thread ID of caller - various processor architecture specific performance counters (instructions executed, cache misses, TLB misses)
- 使用中のメモリの割合 - バイト内のメインメモリのサイズ - バイト内のフリーメインメモリの量 - バイトのページングまたはスワップファイルのサイズ - ページングまたはスワップファイルの無料バイト - ユーザー仮想アドレスの合計サイズバイトのスペース - 利用可能なユーザーアドレスの合計スペースバイト - ブートディスクドライブのサイズバイト - ブートドライブのフリーディスクスペース - 現在の時間 - システムが起動してからの時間 - 個々のサイズのファイルの個々のサイズさまざまなシステムディレクトリ - さまざまなシステムディレクトリのファイルの作成、最後の読み取り、および変更時間 - さまざまなシステムリソース（ヒープなど）の利用率 - 現在のマウスカーソル位置 - 現在の世話 - 現在の実行プロセスの現在の数、スレッド - デスクトップウィンドウとアクティブウィンドウのハンドルまたはID-発信者のスタックポインターの値 - 発信者のプロセスとスレッドID-さまざまなプロセッサーアーキテクチャ固有のパフォーマンスカウンター（命令実行された命令、キャッシュMIS SES、TLBミス）
(Note that it is precisely the above kinds of sources of randomness that are used to seed cryptographic quality random number generators on systems without special hardware for their construction.)
（建設用の特別なハードウェアのないシステムに暗号化品質のランダム数ジェネレーターをシードするために使用されるのは、まさに上記のランダム性のソースであることに注意してください。）
In addition, items such as the computer's name and the name of the operating system, while not strictly speaking random, will help differentiate the results from those obtained by other systems.
さらに、コンピューターの名前やオペレーティングシステムの名前などのアイテムは、厳密に言えばランダムではありませんが、他のシステムで得られた結果との結果を区別するのに役立ちます。
The exact algorithm to generate a node ID using these data is system specific, because both the data available and the functions to obtain them are often very system specific. However, assuming that one can concatenate all the values from the randomness sources into a buffer, and that a cryptographic hash function such as MD5 is available, then any 6 bytes of the MD5 hash of the buffer, with the multicast bit (the high bit of the first byte) set will be an appropriately random node ID.
これらのデータを使用してノードIDを生成する正確なアルゴリズムはシステム固有です。これは、利用可能なデータとそれらを取得する関数の両方が非常にシステム固有のものであるためです。ただし、ランダム性ソースからすべての値をバッファーに連結できると仮定すると、MD5などの暗号化ハッシュ関数が利用可能であると仮定すると、バッファーのMD5ハッシュの6バイト、マルチキャストビット（ハイビット）最初のバイト）セットは、適切にランダムノードIDです。
Other hash functions, such as SHA-1, can also be used. The only requirement is that the result be suitably random _ in the sense that the outputs from a set uniformly distributed inputs are themselves uniformly distributed, and that a single bit change in the input can be expected to cause half of the output bits to change.
SHA-1などの他のハッシュ関数も使用できます。唯一の要件は、結果が均一に分散された入力からの出力自体が均一に分散され、入力の単一のビット変更が出力ビットの半分を変更すると予想されるという意味で、適切にランダム_であることです。
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. Lock capability discovery differs from discovery of supported access control types, since there may be access control types without corresponding lock types. A client can determine what lock types the server supports by retrieving the supportedlock property.
サーバーロックサポートはオプションであるため、サーバー上のリソースをロックしようとするクライアントは、ロックを試して最善を希望するか、何らかの形のディスカバリーを実行してサーバーがサポートするロック機能を決定できます。これは、ロック機能ディスカバリーとして知られています。ロック機能の発見は、対応するロックタイプのないアクセス制御タイプがある可能性があるため、サポートされているアクセス制御タイプの発見とは異なります。クライアントは、SupportEdLockプロパティを取得することにより、サーバーがサポートするロックタイプを決定できます。
Any DAV compliant resource that supports the LOCK method MUST support the supportedlock property.
ロックメソッドをサポートするDAVに準拠したリソースは、supportedlockプロパティをサポートする必要があります。
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and where available, provides their lock token.
別のプリンシパルがアクセスを希望するリソースをロックする場合、2番目のプリンシパルが最初のプリンシパルが誰であるかを見つけることができることが役立ちます。この目的のために、Lock -Discoveryプロパティが提供されます。このプロパティは、すべての未解決のロックをリストし、そのタイプを説明し、利用可能な場合はロックトークンを提供します。
Any DAV compliant resource that supports the LOCK method MUST support the lockdiscovery property.
ロックメソッドをサポートするDAVに準拠したリソースは、Lock -Discoveryプロパティをサポートする必要があります。
Although the locking mechanisms specified here provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario:
ここで指定されているロックメカニズムは、失われた更新の防止に何らかの助けを提供しますが、更新が決して失われないことを保証することはできません。次のシナリオを検討してください。
Two clients A and B are interested in editing the resource ' index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking. Client A doesn't lock the document, but does a GET and begins editing. Client B does LOCK, performs a GET and begins editing. Client B finishes editing, performs a PUT, then an UNLOCK. Client A performs a PUT, overwriting and losing all of B's changes.
2人のクライアントAとBは、リソース「index.html」の編集に関心があります。クライアントAは、WebDAVクライアントではなくHTTPクライアントであるため、ロックを実行する方法がわかりません。クライアントAはドキュメントをロックしませんが、GETと編集を開始します。クライアントBはロックし、GETを実行し、編集を開始します。クライアントBは編集を終了し、プットを実行し、ロックを解除します。クライアントAは、Bの変更のすべてを実行し、上書きし、失うことを実行します。
There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK.
WebDAVプロトコル自体がこの状況を防ぐことができない理由はいくつかあります。まず、ロックを理解していないHTTPクライアントと互換性がなければならないため、すべてのクライアントにロックを使用するように強制することはできません。第二に、リポジトリの実装の多様性のためにサーバーにロックをサポートする必要はありません。その一部は、ロックではなく予約とマージに依存しています。最後に、ステートレスであるため、Lock / Get / Put /ロック解除などの一連の操作を実施することはできません。
WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requiring clients to lock resources before modifying them. Such servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying resources.
ロックをサポートするWebDAVサーバーは、クライアントがリソースを変更する前にリソースをロックすることを要求することにより、クライアントが誤って互いの変更を上書きする可能性を減らすことができます。このようなサーバーは、HTTP 1.0およびHTTP 1.1クライアントがリソースを変更することを効果的に防止します。
WebDAV clients can be good citizens by using a lock / retrieve / write /unlock sequence of operations (at least by default) whenever they interact with a WebDAV server that supports locking.
WebDAVクライアントは、ロックをサポートするWebDAVサーバーと対話するたびに、ロック /取得 /書き込み /ロック解除の操作を使用することにより、操作の一連を使用することにより、優秀な市民になることができます。
HTTP 1.1 clients can be good citizens, avoiding overwriting other clients' changes, by using entity tags in If-Match headers with any requests that would modify resources.
HTTP 1.1クライアントは、リソースを変更するリクエストでIFマッチヘッダーのエンティティタグを使用することにより、他のクライアントの変更を上書きすることを避けて、優秀な市民になる可能性があります。
Information managers may attempt to prevent overwrites by implementing client-side procedures requiring locking before modifying WebDAV resources.
情報マネージャーは、WebDAVリソースを変更する前にロックを必要とするクライアント側の手順を実装することにより、上書きを防ぐことができます。
7 Write Lock
7書き込みロック
This section describes the semantics specific to the write lock type. The write lock is a specific instance of a lock type, and is the only lock type described in this specification.
このセクションでは、書き込みロックタイプに固有のセマンティクスについて説明します。書き込みロックは、ロックタイプの特定のインスタンスであり、この仕様で説明されている唯一のロックタイプです。
A write lock MUST prevent a principal without the lock from successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, or MKCOL on the locked resource. All other current methods, GET in particular, function independently of the lock.
書き込みロックは、ロックがロックされたリソース上でプット、ポスト、プロップパッチ、ロック、ロック解除、移動、削除、またはMKCOLを正常に実行することなくプリンシパルを防ぐ必要があります。特に、他のすべての現在の方法は、ロックとは無関係に機能します。
Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.
ただし、新しい方法が作成されると、書き込みロックとの対話方法を指定する必要があることに注意してください。
A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal.
排他的または共有された書き込みロックのリクエストを成功させるには、リクエストプリンシパルに関連付けられた一意のロックトークンの生成につながる必要があります。したがって、5人のプリンシパルが同じリソースに共有された書き込みロックを持っている場合、各プリンシパルに1つのロックトークンがあります。
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas.
書き込みロックのない人は、リソース上のプロパティを変更しない場合がありますが、スキーマの要件により、ロックされていても、ライブプロパティの値が変更される可能性があります。
Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked.
ロックを尊重するために定義されたデッドプロパティとライブプロパティのみが、書き込み中に変更されないように保証されます。
It is possible to assert a write lock on a null resource in order to lock the name.
名前をロックするために、ヌルリソースに書き込みロックをアサートすることができます。
A write locked null resource, referred to as a lock-null resource, MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and UNLOCK. A lock-null resource MUST appear as a member of its parent collection. Additionally the lock-null resource MUST have defined on it all mandatory DAV properties. Most of these properties, such as all the get* properties, will have no value as a lock-null resource does not support the GET method. Lock-Null resources MUST have defined values for lockdiscovery and supportedlock properties.
ロックヌルリソースと呼ばれる書き込みロックされたNULLリソースは、Put、Mkcol、Options、Propfind、Lockを除き、http/1.1またはdavメソッドに404（見つかりません）または405（方法では許可されていない）で応答する必要があります、ロックを解除します。ロックヌルリソースは、その親コレクションのメンバーとして表示する必要があります。さらに、ロックヌルリソースは、すべての必須DAVプロパティを定義している必要があります。すべてのget*プロパティなど、これらのプロパティのほとんどは、lock-nullリソースがGETメソッドをサポートしていないため、価値がありません。Lock-Nullリソースには、Lock-DiscoveryおよびSupportEdLockプロパティの値を定義している必要があります。
Until a method such as PUT or MKCOL is successfully executed on the lock-null resource the resource MUST stay in the lock-null state. However, once a PUT or MKCOL is successfully executed on a lock-null resource the resource ceases to be in the lock-null state.
PutやMKCOLなどのメソッドがロックヌルリソースで正常に実行されるまで、リソースはロックヌル状態にとどまる必要があります。ただし、プットまたはMKCOLがロックヌルリソースで正常に実行されると、リソースはロックヌル状態になりなくなります。
If the resource is unlocked, for any reason, without a PUT, MKCOL, or similar method having been successfully executed upon it then the resource MUST return to the null state.
リソースのロックが解除されている場合、何らかの理由で、Put、MKCOL、または同様の方法が正常に実行された場合、リソースはNULL状態に戻る必要があります。
A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection.
「深さ：0」または「深さ：無限」ロック要求によって作成されたコレクションの書き込みロックは、非ロック所有者によるコレクションのメンバーURIの追加または削除を防ぎます。結果として、プリンシパルがPUTまたはPOSTリクエストを発行してURIの下で新しいリソースを作成し、HTTP名空間の一貫性を維持するために書き込みロックコレクションの内部メンバーである必要があります。Writeロックコレクションの既存の内部メンバーURIであるURIは、プリンシパルにコレクションに書き込みロックがない場合、この要求が失敗する必要があります。
However, if a write lock request is issued to a collection containing member URIs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code.
ただし、Write Lockリクエストが、Writeロックと競合する方法で現在ロックされているリソースを識別するメンバーURIを含むコレクションに発行された場合、423（ロックされた）ステータスコードでリクエストが失敗する必要があります。
If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that
ロック所有者がロックコレクションの内部メンバーURIとしてリソースのURIを追加している場合、新しいリソースをロックに自動的に追加する必要があります。これが唯一のメカニズムです
allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock.
リソースを書き込みロックに追加できます。したがって、たとえば、コレクション/a/b/が書き込みロックされ、リソース/cが/a/b/cに移動されると、リソース/a/b/cが書き込みロックに追加されます。
If a user agent is not required to have knowledge about a lock when requesting an operation on a locked resource, the following scenario might occur. Program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by Program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization.
ロックされたリソースで操作を要求するときにユーザーエージェントがロックに関する知識を持たない場合、次のシナリオが発生する可能性があります。ユーザーAが実行するプログラムAは、リソースの書き込みロックを取り出します。また、ユーザーAが実行するプログラムBは、プログラムAによって撮影されたロックの知識はありませんが、ロックされたリソースにプットを実行します。このシナリオでは、ロックはプログラムではなくプリンシパルに関連付けられているため、プリンシップBはプリンシパルAの資格情報で作用しているため、Putを実行することが許可されているため、Putは成功します。ただし、プログラムBがロックについて知られていた場合、リソースを上書きしていなかったため、代わりにユーザーへの競合を説明するダイアログボックスを提示することを好みます。このシナリオのため、同じ許可を持つ他のプログラムによって撮影されたロックを誤って無視しないように、さまざまなプログラムを防ぐためにメカニズムが必要です。
In order to prevent these collisions a lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with or the method MUST fail. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted, one for the source and the other for the destination.
これらの衝突を防ぐために、メソッドが相互作用するか、メソッドが失敗する必要があるすべてのロックされたリソースのIFヘッダーの認定元本によってロックトークンを提出する必要があります。たとえば、リソースを移動し、ソースと宛先の両方がロックされている場合、2つのロックトークンを提出する必要があります。1つはソース用、もう1つは宛先用です。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
If: <http://www.ics.uci.edu/users/f/fielding/index.html>
(<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204コンテンツなし
In this example, even though both the source and destination are locked, only one lock token must be submitted, for the lock on the destination. This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.
この例では、ソースと宛先の両方がロックされていても、宛先のロックについては、1つのロックトークンのみを提出する必要があります。これは、ソースリソースがコピーによって変更されておらず、したがって書き込みロックの影響を受けないためです。この例では、ユーザーエージェント認証は、基礎となる輸送層内のHTTPプロトコルの範囲外のメカニズムを介して以前に発生しました。
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with "Depth: infinity", then the resource will be added to the lock.
コピーメソッドの呼び出しは、ソース上でアクティブな書き込みロックを複製してはなりません。ただし、前述のように、コピーがリソースを「深さ：無限」でロックされたコレクションにコピーした場合、リソースがロックに追加されます。
A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, the resource is subject to being added to an existing lock at the destination, as specified in section 7.5. For example, if the MOVE makes the resource a child of a collection that is locked with "Depth: infinity", then the resource will be added to that collection's lock. Additionally, if a resource locked with "Depth: infinity" is moved to a destination that is within the scope of the same lock (e.g., within the namespace tree covered by the lock), the moved resource will again be a added to the lock. In both these examples, as specified in section 7.6, an If header must be submitted containing a lock token for both the source and destination.
書き込みロックされたリソースでの成功した移動要求は、リソースで書き込みロックを移動してはなりません。ただし、セクション7.5で指定されているように、リソースは宛先の既存のロックに追加される場合があります。たとえば、この動きにより、リソースが「深さ：Infinity」でロックされたコレクションの子になった場合、リソースはそのコレクションのロックに追加されます。さらに、「深さ：Infinity」でロックされたリソースが同じロックの範囲内にある宛先に移動した場合（たとえば、ロックで覆われた名前空間ツリー内）、移動されたリソースは再びロックに追加されます。セクション7.6で指定されているように、これらの両方の例では、ソースと宛先の両方にロックトークンを含むヘッダーを提出する必要があります。
A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked.
クライアントは、同じ書き込みロック要求を2回送信してはなりません。クライアントは、すでにロックされているリソースを要求するためにIFヘッダーにロックトークンを含める必要があるため、同じロックリクエストを再送信していることを常に認識していることに注意してください。
However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set.
ただし、クライアントは、ifヘッダーを使用してボディがないロックメソッドを送信することができます。この形式のロックは、ロックを「更新」するためにのみ使用する必要があります。少なくとも、ロックに関連付けられたタイマーを再設定する必要があることを意味します。
A server may return a Timeout header with a lock refresh that is different than the Timeout header returned when the lock was originally requested. Additionally clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client.
サーバーは、ロックが元々要求されたときに返されたタイムアウトヘッダーとは異なるロックリフレッシュでタイムアウトヘッダーを返す場合があります。さらに、クライアントは、ロックリフレッシュリクエストで任意の価値のタイムアウトヘッダーを送信できます。サーバーは、いつものように、クライアントが提出したタイムアウトヘッダーを無視する場合があります。
If an error is received in response to a refresh LOCK request the client SHOULD assume that the lock was not refreshed.
更新ロックのリクエストに応じてエラーが受信された場合、クライアントはロックが更新されていないと想定する必要があります。
8 HTTP Methods for Distributed Authoring
分散オーサリング用の8 HTTPメソッド
The following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with [REC-XML]. All XML used in either requests or responses MUST be, at minimum, well formed. If a server receives
次の新しいHTTPメソッドは、XMLを要求および応答形式として使用します。すべてのDAVに準拠したクライアントとリソースは、[rec-xml]に準拠したXMLパーサーを使用する必要があります。リクエストまたは応答のいずれかで使用されるすべてのXMLは、少なくとも十分に形成されている必要があります。サーバーが受信された場合
ill-formed XML in a request it MUST reject the entire request with a 400 (Bad Request). If a client receives ill-formed XML in a response then it MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
不正なXMLリクエストでは、400（悪いリクエスト）でリクエスト全体を拒否する必要があります。クライアントが応答で不整合されたXMLを受信した場合、実行されたメソッドの結果について何も仮定してはならず、サーバーを誤動作として扱う必要があります。
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URIs. All DAV compliant resources MUST support the PROPFIND method and the propfind XML element (section 12.14) along with all XML elements defined for use with that element.
PROPFINDメソッドは、リクエストURIによって識別されたリソース、リソースに内部メンバーがない場合、またはリクエスト-RIおよび潜在的にそのメンバーリソースによって識別されるリソースで、リソースが識別されるリソースで定義されたプロパティを取得します。リソースがリソースがコレクションである場合内部メンバーURIS。すべてのDAVに準拠したリソースは、その要素で使用するために定義されたすべてのXML要素とともに、PropfindメソッドとPropfind XML要素（セクション12.14）をサポートする必要があります。
A client may submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND on a collection resource with internal member URIs. DAV compliant servers MUST support the "0", "1" and "infinity" behaviors. By default, the PROPFIND method without a Depth header MUST act as if a "Depth: infinity" header was included.
クライアントは、「0」、「1」、または「Infinity」の値を持つ深度ヘッダーを、内部メンバーのURIを含むコレクションリソースに課された「無限」を送信できます。DAVに準拠したサーバーは、「0」、「1」、および「無限」の動作をサポートする必要があります。デフォルトでは、深度ヘッダーのないPropfindメソッドは、「深さ：無限」ヘッダーが含まれているかのように動作する必要があります。
A client may submit a propfind XML element in the body of the request method describing what information is being requested. It is possible to request particular property values, all property values, or a list of the names of the resource's properties. A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as a request for the names and values of all properties.
クライアントは、要求されている情報を説明するリクエストメソッドの本文でPropfind XML要素を提出することができます。特定のプロパティ値、すべてのプロパティ値、またはリソースのプロパティの名前のリストを要求することができます。クライアントは、リクエスト本体を提出しないことを選択できます。空の推定要求本体は、すべてのプロパティの名前と値の要求として扱わなければなりません。
All servers MUST support returning a response of content type text/xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties.
すべてのサーバーは、さまざまなプロパティを取得しようとする試みの結果を説明するMultistatus XML要素を含むコンテンツタイプテキスト/XMLまたはApplication/XMLの応答の返却をサポートする必要があります。
If there is an error retrieving a property then a proper error result MUST be included in the response. A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a multistatus XML element, with a response XML element which contains a 404 (Not Found) status value.
プロパティを取得するエラーがある場合、応答に適切なエラー結果を含める必要があります。存在しないプロパティの値を取得するリクエストはエラーであり、応答がマルチスタッサスXML要素を使用している場合、404（見つからない）ステータス値を含む応答XML要素を使用する場合に注意する必要があります。
Consequently, the multistatus XML element for a collection resource with member URIs MUST include a response XML element for each member URI of the collection, to whatever depth was requested. Each response XML element MUST contain an href XML element that gives the URI of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URIs are returned as a flat list whose order of entries is not significant.
その結果、メンバーのURISを使用したコレクションリソースのMultiStatus XML要素には、コレクションの各メンバーURIの応答XML要素を、要求された深さをどのようにしても含める必要があります。各応答XML要素には、Prop XML要素のプロパティが定義されているリソースのURIを与えるHREF XML要素を含める必要があります。内部メンバーのurisを含む収集リソースのプロパンドの結果は、エントリの順序が重要ではないフラットリストとして返されます。
In the case of allprop and propname, if a principal does not have the right to know whether a particular property exists then the property should be silently excluded from the response.
AllPropとPropnameの場合、プリンシパルが特定のプロパティが存在するかどうかを知る権利がない場合、プロパティは回答から静かに除外されるべきです。
The results of this method SHOULD NOT be cached.
この方法の結果をキャッシュしてはなりません。
>>Request
>>リクエスト
PROPFIND /file HTTP/1.1
Host: www.foo.bar
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foo.bar/file</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Johnson</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to
the DingALing property.
</D:responsedescription>
</D:propstat>
</D:response>
<D:responsedescription> There has been an access violation error.
</D:responsedescription>
</D:multistatus>
In this example, PROPFIND is executed on a non-collection resource http://www.foo.bar/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
この例では、Propfindは非収集リソースhttp://www.foo.bar/fileで実行されます。Propfind XML要素は、値が要求されている4つのプロパティの名前を指定します。この場合、リクエストを発行する元本が3番目と4番目のプロパティを見るのに十分なアクセス権を持っていなかったため、2つのプロパティのみが返されました。
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foo.bar/container/</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>Hadrian</R:Name>
</R:author>
<D:creationdate>
1997-12-01T17:42:21-08:00
</D:creationdate>
<D:displayname>
Example collection
</D:displayname>
<D:resourcetype><D:collection/></D:resourcetype>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.foo.bar/container/front.html</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox>
<R:BoxType>Box type B</R:BoxType>
</R:bigbox>
<D:creationdate>
1997-12-01T18:27:21-08:00
</D:creationdate>
<D:displayname>
Example HTML resource
</D:displayname>
<D:getcontentlength>
4525
</D:getcontentlength>
<D:getcontenttype>
text/html
</D:getcontenttype>
<D:getetag>
zzyzx
</D:getetag>
<D:getlastmodified>
Monday, 12-Jan-98 09:25:56 GMT
</D:getlastmodified>
<D:resourcetype/>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
In this example, PROPFIND was invoked on the resource http://www.foo.bar/container/ with a Depth header of 1, meaning the request applies to the resource and its children, and a propfind XML element containing the allprop XML element, meaning the request should return the name and value of all properties defined on each resource.
この例では、Propfindはリソースhttp://www.foo.bar/container/ 1の深さヘッダーを持つ、リクエストがリソースとその子供に適用され、AllProp XML要素を含むPropfind XML要素に呼び出されました。、つまり、リクエストは、各リソースで定義されているすべてのプロパティの名前と値を返す必要があります。
The resource http://www.foo.bar/container/ has six properties defined on it:
リソースhttp://www.foo.bar/container/には、6つのプロパティが定義されています。
http://www.foo.bar/boxschema/bigbox, http://www.foo.bar/boxschema/author, DAV:creationdate, DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
http://www.foo.bar/boxschema/bigbox、http://www.foo.bar/boxschema/author、dav：creationdate、dav：displayname、dav：resourceType、and dav：supportedlock。
The last four properties are WebDAV-specific, defined in section 13. Since GET is not supported on this resource, the get* properties (e.g., getcontentlength) are not defined on this resource. The DAV-specific properties assert that "container" was created on December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT (creationdate), has a name of "Example collection" (displayname), a collection resource type (resourcetype), and supports exclusive write and shared write locks (supportedlock).
最後の4つのプロパティは、セクション13で定義されているWebDAV固有です。GETはこのリソースでサポートされていないため、GET*プロパティ（GetContentLengthなど）はこのリソースで定義されていません。DAV固有のプロパティは、「コンテナ」が1997年12月1日午後5時42分21分に、GMT（CreationDate）の西8時間のタイムゾーンに作成されたと主張しています。コレクションリソースタイプ（ResourceType）、および排他的な書き込みおよび共有書き込みロック（SupportEdLock）をサポートします。
The resource http://www.foo.bar/container/front.html has nine properties defined on it:
リソースhttp://www.foo.bar/container/front.htmlには、9つのプロパティが定義されています。
http://www.foo.bar/boxschema/bigbox (another instance of the "bigbox" property type), DAV:creationdate, DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
http://www.foo.bar/boxschema/bigbox（「bigbox」プロパティタイプの別のインスタンス）、dav：creationdate、dav：displayname、dav：getcontentlength、dav：getContentType、getetag、dav：getLastModified、dav：ResourceType、およびDAV：SupportEdLock。
The DAV-specific properties assert that "front.html" was created on December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT (creationdate), has a name of "Example HTML resource" (displayname), a content length of 4525 bytes (getcontentlength), a MIME type of "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT (getlastmodified), has an empty resource type, meaning that it is not a collection (resourcetype), and supports both exclusive write and shared write locks (supportedlock).
DAV固有のプロパティは、「Front.html」が1997年12月1日午後6時27分21分に、GMTの西8時間のタイムゾーン（CreationDate）に作成されたと主張しています。displayName）、コンテンツ長4525バイト（getContentLength）、「text/html」（getContentType）のMIMEタイプ、「Zzyzx」（getEtag）のエンティティタグは、1998年1月12日月曜日09で最後に変更されました。：25：56 GMT（getLastModified）、空のリソースタイプがあります。つまり、コレクション（ResourceType）ではなく、排他的な書き込みロックと共有の両方の書き込みロック（supportedLock）の両方をサポートします。
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:">
<propname/>
</propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://www.foo.bar/container/</href>
<propstat>
<prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/>
<R:author/>
<creationdate/>
<displayname/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>http://www.foo.bar/container/front.html</href>
<propstat>
<prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/>
<creationdate/>
<displayname/>
<getcontentlength/>
<getcontenttype/>
<getetag/>
<getlastmodified/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
In this example, PROPFIND is invoked on the collection resource http://www.foo.bar/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its progeny should be returned.
この例では、Propfindはコレクションリソースhttp://www.foo.bar/container/に呼び出されます。深さヘッダーが存在しないため、「無限」のデフォルト値を想定しています。つまり、コレクション上のプロパティの名前を意味し、そのすべての子孫を返す必要があります。
Consistent with the previous example, resource http://www.foo.bar/container/ has six properties defined on it, http://www.foo.bar/boxschema/bigbox, http://www.foo.bar/boxschema/author, DAV:creationdate, DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
前の例と一致して、リソースhttp://www.foo.bar/container/には、http://www.foo.bar/boxschema/bigbox、http://www.foo.bar//Boxschema/著者、DAV：CreationDate、DAV：DisplayName、DAV：ResourceType、およびDAV：SupportEdLock。
The resource http://www.foo.bar/container/index.html, a member of the "container" collection, has nine properties defined on it, http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
リソースhttp://www.foo.bar/container/index.htmlは、「コンテナ」コレクションのメンバーであり、9つのプロパティが定義されています。CreationDate、DAV：DisplayName、DAV：GetContentLength、DAV：GetContentType、DAV：GetETAG、DAV：GetLastModified、DAV：ResourceType、およびDAV：SupportEdLock。
This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain an explicit "shorthand name" (prefix) letter, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace schema.
この例は、XMLネームスペーススコープとデフォルトの名前空間の使用も示しています。「xmlns」属性には明示的な「shorthand name」（prefix）文字が含まれていないため、名前空間はデフォルトですべての囲まれた要素に適用されます。したがって、それらが属する名前空間を明示的に明示的に述べていないすべての要素は、「DAV：」名前空間スキーマのメンバーです。
The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI.
プロップパッチメソッドは、要求本体で指定された指示を処理し、リクエスト-URIによって識別されたリソースで定義されたプロパティを設定および/または削除します。
All DAV compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements of the DAV schema. Execution of the directives in this method is, of course, subject to access control constraints. DAV compliant resources SHOULD support the setting of arbitrary dead properties.
すべてのDAVに準拠したリソースは、Proppatchメソッドをサポートする必要があり、DAVスキーマのXML要素を設定し、削除するプロパティの要素を使用して指定された命令を処理する必要があります。この方法での指令の実行は、もちろん、アクセス制御制約の対象となります。DAVに準拠したリソースは、任意の死んだプロパティの設定をサポートする必要があります。
The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. Instruction processing MUST occur in the order instructions are received (i.e., from top to bottom). Instructions MUST either all be executed or none executed. Thus if any error occurs during processing all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in section 12.13.
プロップパッチメソッドの要求メッセージ本文には、PropertyUpDate XML要素が含まれている必要があります。命令処理は、注文指示を受け取る必要があります（つまり、上から下まで）。指示はすべて実行されるか、実行されない必要があります。したがって、処理中にエラーが発生した場合、実行されたすべての命令は元に戻し、適切なエラー結果が返される必要があります。命令処理の詳細は、セット12.13のセットの定義と削除指示にあります。
The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response.
以下は、この方法の207（マルチステータス）応答で使用されると予想される応答コードの例です。ただし、明示的に禁止されていない限り、207（マルチステータス）応答で2/3/4/5XXシリーズ応答コードを使用できることに注意してください。
200 (OK) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate.
200（OK） - コマンドが成功しました。セットと除去の混合物が体内にある可能性があるため、201（作成）は不適切と思われます。
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
403（FORBIDDEN） - クライアントは、サーバーが指定しないことを選択した理由で、プロパティのいずれかを変更できません。
409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property. This includes trying to set read-only properties.
409（競合） - クライアントは、セマンティクスがプロパティに適していない値を提供しました。これには、読み取り専用プロパティを設定しようとすることが含まれます。
423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it.
423（ロック） - 指定されたリソースがロックされており、クライアントはロック所有者ではないか、ロックタイプでロックトークンを提出する必要があり、クライアントはそれを提出しませんでした。
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
507（ストレージが不十分） - サーバーには、プロパティを記録するのに十分なスペースがありませんでした。
>>Request
>>リクエスト
PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:authors>
</D:prop>
</D:set>
<D:remove>
<D:prop><Z:Copyright-Owner/></D:prop>
</D:remove>
</D:propertyupdate>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50">
<D:response>
<D:href>http://www.foo.com/bar.html</D:href>
<D:propstat>
<D:prop><Z:Authors/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
<D:propstat>
<D:prop><Z:Copyright-Owner/></D:prop>
<D:status>HTTP/1.1 409 Conflict</D:status>
</D:propstat>
<D:responsedescription> Copyright Owner can not be deleted or
altered.</D:responsedescription>
</D:response>
</D:multistatus>
In this example, the client requests the server to set the value of the http://www.w3.com/standards/z39.50/Authors property, and to remove the property http://www.w3.com/standards/z39.50/Copyright-Owner. Since the Copyright-Owner property could not be removed, no property modifications occur. The 424 (Failed Dependency) status code for the Authors property indicates this action would have succeeded if it were not for the conflict with removing the Copyright-Owner property.
この例では、クライアントはサーバーにhttp://www.w3.com/standards/z39.50/authorsプロパティの値を設定し、プロパティhttp://www.w3.com/standardsを削除するよう要求します。/Z39.50/Copyright-Owner。著作権所有者のプロパティを削除できないため、プロパティの変更は発生しません。著者プロパティの424（依存の失敗）ステータスコードは、著作権所有者のプロパティを削除することと競合しなければ、このアクションが成功したことを示しています。
The MKCOL method is used to create a new collection. All DAV compliant resources MUST support the MKCOL method.
MKCOLメソッドは、新しいコレクションを作成するために使用されます。すべてのDAVに準拠したリソースは、MKCOLメソッドをサポートする必要があります。
MKCOL creates a new collection resource at the location specified by the Request-URI. If the resource identified by the Request-URI is non-null then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI a member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ exists, the request must fail.
MKCOLは、Request-URIによって指定された場所に新しいコレクションリソースを作成します。Request-URIによって識別されたリソースが非ヌルの場合、MKCOLは失敗する必要があります。MKCOL処理中、サーバーは、リクエスト-URIが「/」でない限り、Request-URIを親コレクションのメンバーにする必要があります。そのような祖先が存在しない場合、メソッドが失敗する必要があります。MKCOL操作が新しいコレクションリソースを作成する場合、すべての祖先が既に存在する必要があります。または、メソッドは409（競合）ステータスコードで失敗する必要があります。たとえば、コレクション/a/b/c/d/を作成するリクエストが作成され、/a/b/nor/a/b/c/が存在しない場合、リクエストは失敗する必要があります。
When MKCOL is invoked without a request body, the newly created collection SHOULD have no members.
MKCOLがリクエスト本体なしで呼び出された場合、新しく作成されたコレクションにはメンバーがいないはずです。
A MKCOL request message may contain a message body. The behavior of a MKCOL request when the body is present is limited to creating collections, members of a collection, bodies of members and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand it MUST respond with a 415 (Unsupported Media Type) status code. The exact behavior of MKCOL for various request media types is undefined in this document, and will be specified in separate documents.
MKCOLリクエストメッセージにはメッセージ本文が含まれている場合があります。ボディが存在する場合のMKCOL要求の動作は、コレクション、コレクションのメンバー、メンバーのボディ、コレクションまたはメンバーのプロパティの作成に限定されています。サーバーがMKCOLリクエストエンティティタイプを受信した場合、415（サポートされていないメディアタイプ）ステータスコードで応答する必要があります。さまざまなリクエストメディアタイプのMKCOLの正確な動作は、このドキュメントで定義されていないため、個別のドキュメントで指定されます。
Responses from a MKCOL request MUST NOT be cached as MKCOL has non-idempotent semantics.
MKCOLには非公開セマンティクスがあるため、MKCOL要求からの応答はキャッシュされてはなりません。
201 (Created) - The collection or structured resource was created in its entirety.
201（作成） - コレクションまたは構造化されたリソースは完全に作成されました。
403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its namespace, or 2) the parent collection of the Request-URI exists but cannot accept members.
403（禁止） - これは、2つの条件の少なくとも1つを示します。1）サーバーは、名前空間の特定の場所でコレクションを作成することはできません。
405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource.
405（方法は許可されていない）-MKCOLは、削除/存在しないリソースでのみ実行できます。
409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created.
409（競合） - 1つ以上の中間コレクションが作成されるまで、リクエスト-URIでコレクションを作成することはできません。
415 (Unsupported Media Type)- The server does not support the request type of the body.
415（サポートされていないメディアタイプ） - サーバーは、ボディの要求タイプをサポートしていません。
507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージが不十分） - リソースには、このメソッドの実行後にリソースの状態を記録するのに十分なスペースがありません。
This example creates a collection called /webdisc/xfiles/ on the server www.server.org.
この例では、サーバーwww.server.orgに/webdisc/xfiles/というコレクションを作成します。
>>Request
>>リクエスト
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org
>>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" [RFC2068]. GET when applied to a collection may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection.
GETは「（エンティティの形式で）すべての情報を取得する」[Request-URIによって識別される] [RFC2068]として定義されるため、コレクションに適用される場合、GETのセマンティクスは変更されません。コレクションに適用されたときに取得すると、「index.html」リソースの内容、コレクションの内容の人間の読み取り可能なビュー、または他の何かを完全に返すことができます。したがって、コレクションの取得の結果は、コレクションのメンバーシップとの相関関係がない可能性があります。
Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
同様に、ヘッドの定義は応答メッセージ本文のないGETであるため、収集リソースに適用されると、ヘッドのセマンティクスが修正されません。
Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus the semantics of POST are unmodified when applied to a collection.
定義上、POSTによって実行される実際の関数はサーバーによって決定され、多くの場合特定のリソースに依存するため、コレクションに適用された場合のPOSTの動作は、大部分が定義されていないため、有意義に変更できません。したがって、コレクションに適用されると、ポストのセマンティクスが修正されていません。
8.6.1 DELETE for Non-Collection Resources
8.6.1 非収集リソースを削除します
If the DELETE method is issued to a non-collection resource whose URIs are an internal member of one or more collections, then during DELETE processing a server MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member.
削除メソッドが1つ以上のコレクションの内部メンバーであるURIが非収集リソースに発行された場合、削除の処理中にサーバーは、それを含むコレクションから識別されたリソースのURIを削除する必要があります。メンバー。
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity.
コレクションの削除メソッドは、「深さ：無限」ヘッダーが使用されているかのように動作する必要があります。クライアントは、Infinity以外の任意の値のあるコレクションの削除を備えた深度ヘッダーを送信してはなりません。
DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URIs are to be deleted.
Deleteは、リクエスト-URIで指定されたコレクションと、内部メンバーのURIによって識別されたすべてのリソースが削除されることを指示します。
If any resource identified by a member URI cannot be deleted then all of the member's ancestors MUST NOT be deleted, so as to maintain namespace consistency.
メンバーURIによって識別されたリソースを削除できない場合、名前空間の一貫性を維持するために、メンバーのすべての祖先を削除する必要はありません。
Any headers included with DELETE MUST be applied in processing every resource to be deleted.
削除に含まれるヘッダーは、削除するすべてのリソースの処理に適用する必要があります。
When the DELETE method has completed processing it MUST result in a consistent namespace.
削除メソッドが処理を完了した場合、一貫した名前空間になる必要があります。
If an error occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status). 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status). They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
Request-URIで識別されたリソース以外のリソースでエラーが発生した場合、応答は207（マルチステータス）でなければなりません。424（依存関係の失敗）エラーは207（マルチステータス）にあるべきではありません。クライアントは、クライアントが先祖の子孫のエラーを受け取ったときにリソースの先祖を削除できないことをクライアントが知っているため、安全に除外することができます。さらに、207（マルチステータス）で204（コンテンツなし）エラーを返してはいけません。この禁止の理由は、204（コンテンツなし）がデフォルトの成功コードであるためです。
>>Request
>>リクエスト
DELETE /container/ HTTP/1.1
Host: www.foo.bar
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.foo.bar/container/resource3</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
</d:response>
</d:multistatus>
In this example the attempt to delete http://www.foo.bar/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.foo.bar/container/ also failed. Thus the client knows that the attempt to delete http://www.foo.bar/container/ must have also failed since the parent can not be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
この例では、http：//www.foo.bar/container/resource3を削除しようとする試みは、ロックされているために失敗し、ロックトークンはリクエストで提出されませんでした。その結果、http：//www.foo.bar/container/を削除しようとする試みも失敗しました。したがって、クライアントは、http://www.foo.bar/container/を削除しようとする試みも、子供が削除されない限り、親を削除できないため失敗したに違いないことを知っています。深度ヘッダーは含まれていませんが、メソッドがコレクションにあるため、無限の深さが想定されています。
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties.
既存のリソースで実行されたプットは、リソースのGET応答エンティティに取って代わります。リソースで定義されているプロパティは、処理中に再計算される可能性がありますが、それ以外の場合は影響を受けません。たとえば、サーバーが要求本体のコンテンツタイプを認識している場合、プロパティとして有益に公開される可能性のある情報を自動的に抽出できる場合があります。
A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
適切にスコープされた親の収集なしでリソースを作成するプットは、409（競合）で失敗する必要があります。
As defined in the HTTP/1.1 specification [RFC2068], the "PUT method requests that the enclosed entity be stored under the supplied Request-URI." Since submission of an entity representing a collection would implicitly encode creation and deletion of resources, this specification intentionally does not define a transmission format for creating a collection using PUT. Instead, the MKCOL method is defined to create collections.
HTTP/1.1仕様[RFC2068]で定義されているように、「PUTメソッドは、囲まれたエンティティが提供されたリクエストURIの下に保存されることを要求します」。コレクションを表すエンティティの提出は、リソースの作成と削除を暗黙的にエンコードするため、この仕様はPUTを使用してコレクションを作成するための伝送形式を意図的に定義しません。代わりに、MKCOLメソッドはコレクションを作成するために定義されています。
When the PUT operation creates a new non-collection resource all ancestors MUST already exist. If all ancestors do not exist, the method MUST fail with a 409 (Conflict) status code. For example, if resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, then the request must fail.
Put Operationが新しい非収集リソースを作成すると、すべての先祖がすでに存在する必要があります。すべての祖先が存在しない場合、メソッドは409（競合）ステータスコードで失敗する必要があります。たとえば、Resource /a/b/c/d.htmlが作成され、/a/b/c/が存在しない場合、リクエストは失敗する必要があります。
The COPY method creates a duplicate of the source resource, identified by the Request-URI, in the destination resource, identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource.
コピーメソッドは、宛先ヘッダーのURIによって識別される宛先リソースで、リクエスト-URIによって識別されるソースリソースの複製を作成します。宛先ヘッダーが存在する必要があります。コピー方法の正確な動作は、ソースリソースのタイプに依存します。
All WebDAV compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server.
すべてのWebDAV準拠のリソースは、コピー方法をサポートする必要があります。ただし、コピー方法のサポートは、リソースをコピーする機能を保証しません。たとえば、個別のプログラムは、同じサーバー上のリソースを制御できます。その結果、同じサーバー上にあるように見える場所にリソースをコピーすることはできない場合があります。
When the source resource is not a collection the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible. After a successful COPY invocation, all properties on the source resource MUST be duplicated on the destination resource, subject to modifying headers and XML elements, following the definition for copying properties. Since the environment at the destination may be different than at the source due to factors outside the scope of control of the server, such as the absence of resources required for correct operation, it may not be possible to completely duplicate the behavior of the resource at the destination. Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource.
ソースリソースがコレクションではない場合、コピー方法の結果は、宛先に新しいリソースの作成であり、その状態と行動はソースリソースのそれと可能な限り密接に一致します。コピーの呼び出しが成功した後、ソースリソース上のすべてのプロパティを、プロパティのコピーの定義に従って、ヘッダーとXML要素の変更を条件として、宛先リソースで複製する必要があります。適切な動作に必要なリソースがないなど、サーバーの制御範囲外の要因により、目的地の環境はソースの環境とは異なる場合があるため、リソースの動作をで完全に複製することはできない場合があります。目的地。宛先リソースのその後の変更は、ソースリソースを変更しません。その後のソースリソースの変更は、宛先リソースを変更しません。
The following section defines how properties on a resource are handled during a COPY operation.
次のセクションでは、コピー操作中にリソース上のプロパティが処理される方法を定義します。
Live properties SHOULD be duplicated as identically behaving live properties at the destination resource. If a property cannot be copied live, then its value MUST be duplicated, octet-for-octet, in an identically named, dead property on the destination resource subject to the effects of the propertybehavior XML element.
ライブプロパティは、宛先リソースで同一に動作するライブプロパティとして複製する必要があります。プロパティをライブでコピーできない場合、その値は、プロパティベハビオールXML要素の効果に従って、宛先リソース上の同一の名前の死んだプロパティで、Octet-for-octetを複製する必要があります。
The propertybehavior XML element can specify that properties are copied on best effort, that all live properties must be successfully copied or the method must fail, or that a specified list of live properties must be successfully copied or the method must fail. The propertybehavior XML element is defined in section 12.12.
PropertyBehavior XML要素は、プロパティが最善の努力でコピーされること、すべてのライブプロパティを正常にコピーする必要があるか、メソッドが失敗する必要があること、またはライブプロパティの指定されたリストを正常にコピーする必要があるか、メソッドが失敗する必要があることを指定できます。PropertyBehavior XML要素は、セクション12.12で定義されています。
The COPY method on a collection without a Depth header MUST act as if a Depth header with value "infinity" was included. A client may submit a Depth header on a COPY on a collection with a value of "0" or "infinity". DAV compliant servers MUST support the "0" and "infinity" Depth header behaviors.
深さヘッダーのないコレクションのコピー方法は、値「無限」を持つ深度ヘッダーが含まれているかのように動作する必要があります。クライアントは、「0」または「Infinity」の値を持つコレクションのコピーに深さヘッダーを送信できます。DAVに準拠したサーバーは、「0」および「Infinity」深度ヘッダーの動作をサポートする必要があります。
A COPY of depth infinity instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy.
Depth Infinityのコピーは、リクエスト-URIによって識別された収集リソースが宛先ヘッダーのURIによって識別された場所にコピーされることを指示し、そのすべての内部メンバーリソースは、再帰的にそれに関連する場所にコピーされることを指示します。コレクション階層のすべてのレベルを通じて。
A COPY of "Depth: 0" only instructs that the collection and its properties but not resources identified by its internal member URIs, are to be copied.
「深さ：0」のコピーは、コレクションとそのプロパティのみを指示しますが、内部メンバーのURIによって識別されるリソースはコピーされることを指示します。
Any headers included with a COPY MUST be applied in processing every resource to be copied with the exception of the Destination header.
コピーに含まれるヘッダーは、宛先ヘッダーを除き、コピーするためにすべてのリソースを処理する際に適用する必要があります。
The Destination header only specifies the destination URI for the Request-URI. When applied to members of the collection identified by the Request-URI the value of Destination is to be modified to reflect the current location in the hierarchy. So, if the Request- URI is /a/ with Host header value http://fun.com/ and the Destination is http://fun.com/b/ then when http://fun.com/a/c/d is processed it must use a Destination of http://fun.com/b/c/d.
宛先ヘッダーは、Request-URIの宛先URIのみを指定します。リクエスト-Riによって識別されたコレクションのメンバーに適用される場合、宛先の価値は、階層内の現在の場所を反映するように変更されます。したがって、リクエストがホストヘッダー値http://fun.com/を持つリクエストが/a/a/a/a/dettessはhttp://fun.com/b/である場合、http://fun.com/a/c/dが処理されますhttp://fun.com/b/c/dの宛先を使用する必要があります。
When the COPY method has completed processing it MUST have created a consistent namespace at the destination (see section 5.1 for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non-collection resource as part of an infinite depth copy, the server SHOULD try to finish as much of the original copy operation as possible.
コピーメソッドが処理を完了した場合、宛先に一貫した名前空間を作成したはずです（名前空間の一貫性の定義については、セクション5.1を参照）。ただし、内部コレクションのコピー中にエラーが発生した場合、サーバーはこのコレクションのメンバーによって識別されたリソースをコピーしてはなりません（つまり、サーバーはこのサブツリーをスキップする必要があります）。これにより、一貫性のない名前空間が作成されるためです。エラーを検出した後、コピー操作は、元のコピー操作をできるだけ多く終了しようとする必要があります（つまり、サーバーは、エラーを引き起こすコレクションの子孫ではない他のサブツリーとそのメンバーをコピーしようとする必要があります）。したがって、たとえば、コレクション/a/b/および/a/c/を含むコレクション/a/で無限の深度コピー操作が実行され、エラーがコピー/a/b/を実行する場合、試行はまだコピー/a/c/に作られました。同様に、非収集リソースを無限の深度コピーの一部としてコピーするエラーが発生した後、サーバーは元のコピー操作をできるだけ多くのコピー操作を完了しようとする必要があります。
If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status).
コピーメソッドを実行する際のエラーが、リクエスト-URIで識別されたリソース以外のリソースで発生する場合、応答は207（マルチステータス）でなければなりません。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a COPY method. These responses can be safely omitted because the client will know that the progeny of a resource could not be copied when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) status codes SHOULD NOT be returned as values in 207 (Multi-Status) responses from COPY methods. They, too, can be safely omitted because they are the default success codes.
424（依存関係の失敗）ステータスコードは、コピーメソッドからの207（マルチステータス）応答で返されないでください。クライアントが親のエラーを受信したときにクライアントがコピーできないことをクライアントが知っているため、これらの応答は安全に省略できます。さらに、コピー方法からの207（マルチステータス）応答の値として、201（作成）/204（コンテンツなし）ステータスコードを返すべきではありません。それらもデフォルトの成功コードであるため、安全に省略できます。
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail.
宛先にリソースが存在し、上書きヘッダーが「t」である場合、コピーを実行する前に、サーバーは宛先リソースに「深さ：無限」で削除を実行する必要があります。上書きヘッダーが「F」に設定されている場合、操作は失敗します。
201 (Created) - The source resource was successfully copied. The copy operation resulted in the creation of a new resource.
201（作成） - ソースリソースが正常にコピーされました。コピー操作により、新しいリソースが作成されました。
204 (No Content) - The source resource was successfully copied to a pre-existing destination resource.
204（コンテンツなし） - ソースリソースは、既存の宛先リソースに正常にコピーされました。
403 (Forbidden) _ The source and destination URIs are the same.
403（禁止）_ソースと目的地のurisは同じです。
409 (Conflict) _ A resource cannot be created at the destination until one or more intermediate collections have been created.
409（競合）_ 1つ以上の中間コレクションが作成されるまで、宛先にリソースを作成することはできません。
412 (Precondition Failed) - The server was unable to maintain the liveness of the properties listed in the propertybehavior XML element or the Overwrite header is "F" and the state of the destination resource is non-null.
412（前提条件に失敗した） - サーバーは、プロパティベハビオールXML要素にリストされているプロパティの快適さを維持することができませんでした。または上書きヘッダーは「F」であり、宛先リソースの状態は非ヌルです。
423 (Locked) - The destination resource was locked.
423（ロック） - 宛先リソースがロックされました。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource.
502（悪いゲートウェイ） - これは、宛先が別のサーバー上にあり、宛先サーバーがリソースの受け入れを拒否したときに発生する可能性があります。
507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
507（ストレージが不十分） - 宛先リソースには、この方法の実行後にリソースの状態を記録するのに十分なスペースがありません。
This example shows resource http://www.ics.uci.edu/~fielding/index.html being copied to the location http://www.ics.uci.edu/users/f/fielding/index.html. The 204 (No Content) status code indicates the existing resource at the destination was overwritten.
この例は、リソースhttp://www.ics.uci.edu/~fielding/index.htmlを示しています。204（コンテンツなし）ステータスコードは、宛先の既存のリソースが上書きされたことを示しています。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204コンテンツなし
The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 (Precondition Failed) is returned because the destination resource has a non-null state.
次の例は、同じコピー操作が実行されていることを示していますが、上書きヘッダーが「F」に設定されています。宛先リソースに非ヌル状態があるため、412（前提条件が失敗した）の応答が返されます。
>>Request
>>リクエスト
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
Overwrite: F
>>Response
>>応答
HTTP/1.1 412 Precondition Failed
HTTP/1.1 412前提条件は失敗しました
>>Request
>>リクエスト
COPY /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d="DAV:">
<d:keepalive>*</d:keepalive>
</d:propertybehavior>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.foo.bar/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 412 Precondition Failed</d:status>
</d:response>
</d:multistatus>
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example most of the resources, along with the collection, were copied successfully. However the collection R2 failed, most likely due to a problem with maintaining the liveness of properties (this is specified by the propertybehavior XML element). Because there was an error copying R2, none of R2's members were copied. However no errors were listed for those members due to the error minimization rules given in section 8.8.3.
コレクションのコピーのデフォルトの動作は、「深さ：無限」ヘッダーが提出されたかのように行動することであるため、深度ヘッダーは不要です。この例では、ほとんどのリソースとコレクションが正常にコピーされました。ただし、Collection R2は失敗しましたが、おそらくプロパティの活性を維持する問題が原因です（これは、プロパティベハビオールXML要素によって指定されています）。R2をコピーするエラーがあったため、R2のメンバーはどれもコピーされませんでした。ただし、セクション8.8.3に記載されているエラー最小化ルールのため、これらのメンバーのエラーはリストされていません。
The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URIs other than the Request-URI which identify the source resource, to point to the new destination resource. Consequently, the Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All DAV compliant resources MUST support the MOVE method. However, support for the MOVE method does not guarantee the ability to move a resource to a particular destination.
非収集リソースの移動操作は、コピー（コピー）に相当する論理的なものであり、その後に一貫性メンテナンス処理が続き、その後に3つのアクションがすべて原子的に実行されるソースの削除が続きます。一貫性メンテナンスステップにより、サーバーは、ソースリソースを識別するリクエスト-URI以外のすべてのURIを更新して、新しい宛先リソースを指すなど、移動によって引き起こされる更新を実行できます。したがって、宛先ヘッダーはすべての移動方法に存在する必要があり、移動方法のコピー部分のすべてのコピー要件に従う必要があります。すべてのDAVに準拠したリソースは、移動方法をサポートする必要があります。ただし、MOVEメソッドのサポートは、リソースを特定の目的地に移動する能力を保証するものではありません。
For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server.
たとえば、個別のプログラムは、同じサーバー上の異なるリソースセットを実際に制御する場合があります。したがって、同じサーバーに属していると思われる名前空間内でリソースを移動することはできない場合があります。
If a resource exists at the destination, the destination resource will be DELETEd as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
宛先にリソースが存在する場合、宛先リソースは、上書きヘッダーの制限を条件として、移動操作の副作用として削除されます。
The behavior of properties on a MOVE, including the effects of the propertybehavior XML element, MUST be the same as specified in section 8.8.2.
プロパティベハビオールXML要素の効果を含む移動に対するプロパティの動作は、セクション8.8.2で指定されたものと同じでなければなりません。
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the URI specified in the Destination header, and all resources identified by its internal member URIs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy.
「深さ：Infinity」の動きは、リクエスト-URIによって識別されたコレクションを宛先ヘッダーで指定されたURIに移動することを指示し、その内部メンバーによって識別されたすべてのリソースは、それに関連する場所に移動し、再帰的に移動します。コレクション階層のすべてのレベル。
The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity".
コレクションの移動方法は、「深さ：無限」ヘッダーが使用されているかのように動作する必要があります。クライアントは、「Infinity」以外の価値のあるコレクションの動きで深度ヘッダーを送信してはなりません。
Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header.
移動に含まれるヘッダーは、宛先ヘッダーを除き、移動するすべてのリソースの処理に適用する必要があります。
The behavior of the Destination header is the same as given for COPY on collections.
宛先ヘッダーの動作は、コレクションのコピーの場合と同じです。
When the MOVE method has completed processing it MUST have created a consistent namespace at both the source and destination (see section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite depth move, the server SHOULD try to finish as much of the original move operation as possible.
移動方法が処理を完了した場合、ソースと宛先の両方で一貫した名前空間を作成したはずです（名前空間の一貫性の定義については、セクション5.1を参照）。ただし、内部コレクションの移動中にエラーが発生した場合、サーバーは失敗したコレクションのメンバーによって識別されたリソースを移動してはなりません（つまり、サーバーはエラーを引き付けるサブツリーをスキップする必要があります）。これにより、一貫性のない名前空間が作成されるためです。この場合、エラーを検出した後、移動操作は可能な限り多くの元の移動を完了しようとする必要があります（つまり、サーバーは、他のサブツリーとメンバーによって特定されたリソースを移動しようとする必要があります。エラーを引き起こすコレクション）。したがって、たとえば、コレクション/a/b/および/a/c/を含むコレクション/a/で無限の深さの移動が実行され、エラーが移動/a/b/を実行する場合、試行はまだ行われるべきです移動/a/c/を試してみてください。同様に、非収集リソースを無限の深さの移動の一部として移動するエラーが発生した後、サーバーは元の移動操作をできるだけ多く終了しようとする必要があります。
If an error occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status).
Request-URIで識別されたリソース以外のリソースでエラーが発生した場合、応答は207（マルチステータス）でなければなりません。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
424（失敗した依存関係）ステータスコードは、移動方法からの207（マルチステータス）応答で返されないでください。クライアントは、クライアントが親のエラーを受信したときにリソースの子孫を移動できないことをクライアントが知るため、これらのエラーを安全に省略できます。さらに、201（作成）/204（コンテンツなし）応答は、動きから207（マルチステータス）応答の値として返されるべきではありません。これらの応答は、デフォルトの成功コードであるため、安全に省略できます。
If a resource exists at the destination and the Overwrite header is "T" then prior to performing the move the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail.
宛先にリソースが存在し、上書きヘッダーが「T」である場合、移動を実行する前に、サーバーは宛先リソースの「深さ：無限」で削除を実行する必要があります。上書きヘッダーが「F」に設定されている場合、操作は失敗します。
201 (Created) - The source resource was successfully moved, and a new resource was created at the destination.
201（作成） - ソースリソースが正常に移動され、目的地で新しいリソースが作成されました。
204 (No Content) - The source resource was successfully moved to a pre-existing destination resource.
204（コンテンツなし） - ソースリソースは、既存の宛先リソースに正常に移動されました。
403 (Forbidden) _ The source and destination URIs are the same.
403（禁止）_ソースと目的地のurisは同じです。
409 (Conflict) _ A resource cannot be created at the destination until one or more intermediate collections have been created.
409（競合）_ 1つ以上の中間コレクションが作成されるまで、宛先にリソースを作成することはできません。
412 (Precondition Failed) - The server was unable to maintain the liveness of the properties listed in the propertybehavior XML element or the Overwrite header is "F" and the state of the destination resource is non-null.
412（前提条件に失敗した） - サーバーは、プロパティベハビオールXML要素にリストされているプロパティの快適さを維持することができませんでした。または上書きヘッダーは「F」であり、宛先リソースの状態は非ヌルです。
423 (Locked) - The source or the destination resource was locked.
423（ロック） - ソースまたは宛先リソースがロックされました。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource.
502（悪いゲートウェイ） - これは、宛先が別のサーバー上にあり、宛先サーバーがリソースの受け入れを拒否したときに発生する可能性があります。
This example shows resource http://www.ics.uci.edu/~fielding/index.html being moved to the location http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination resource had been non-null. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
この例は、リソースhttp://www.ics.uci.edu/~fielding/index.htmlが場所http://www.ics.users/users/f/fielding/index.htmlに移動していることを示しています。宛先リソースの内容は、宛先リソースが非ヌルだった場合、上書きされていたでしょう。この場合、宛先リソースには何もなかったため、応答コードは201（作成）です。
>>Request
>>リクエスト
MOVE /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
>>Response
>>応答
HTTP/1.1 201 Created
Location: http://www.ics.uci.edu/users/f/fielding/index.html
>>Request
>>リクエスト
MOVE /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Overwrite: F
If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d='DAV:'>
<d:keepalive>*</d:keepalive>
</d:propertybehavior>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d='DAV:'>
<d:response>
<d:href>http://www.foo.bar/othercontainer/C2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
</d:response>
</d:multistatus>
In this example the client has submitted a number of lock tokens with the request. A lock token will need to be submitted for every resource, both source and destination, anywhere in the scope of the method, that is locked. In this case the proper lock token was not submitted for the destination http://www.foo.bar/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error copying /container/C2/, none of /container/C2's members were copied. However no errors were listed for those members due to the error minimization rules given in section 8.8.3. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
この例では、クライアントはリクエストで多くのロックトークンを提出しました。ロックトークンは、ロックされているメソッドの範囲内のどこでも、ソースと宛先の両方のリソースごとに提出する必要があります。この場合、適切なロックトークンは、宛先http://www.foo.bar/othercontainer/c2/に提出されませんでした。これは、リソース/コンテナ/C2/を移動できなかったことを意味します。エラーコピー/コンテナ/C2/があったため、/container/c2のメンバーはコピーされませんでした。ただし、セクション8.8.3に記載されているエラー最小化ルールのため、これらのメンバーのエラーはリストされていません。ユーザーエージェント認証は、基礎となる輸送層で、HTTPプロトコルの範囲外のメカニズムを介して以前に発生しています。
The following sections describe the LOCK method, which is used to take out a lock of any access type. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested.
次のセクションでは、アクセスタイプのロックを取り出すために使用されるロック方法について説明します。ロックメソッドのこれらのセクションは、ロックメソッドに固有のセマンティクスのみを説明し、要求されているロックのアクセスタイプとは無関係です。
Any resource which supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein.
ロックメソッドをサポートするリソースは、少なくとも、本明細書で定義されているXML要求と応答形式をサポートする必要があります。
A LOCK method invocation creates the lock specified by the lockinfo XML element on the Request-URI. Lock method requests SHOULD have a XML request body which contains an owner XML element for this lock request, unless this is a refresh request. The LOCK request may have a Timeout header.
ロックメソッドの呼び出しは、リクエスト-URI上のLockinfo XML要素によって指定されたロックを作成します。ロックメソッドリクエストには、更新リクエストでない限り、このロックリクエストの所有者XML要素を含むXMLリクエストボディが必要です。ロックリクエストにはタイムアウトヘッダーがある場合があります。
Clients MUST assume that locks may arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if "extraordinary" circumstances do not occur. For example, an administrator may remove a lock at any time or the system may crash in such a way that it loses the record of the lock's existence. The response MUST contain the value of the lockdiscovery property in a prop XML element.
クライアントは、タイムアウトヘッダーで与えられた値に関係なく、いつでもロックが任意に消える可能性があると想定する必要があります。タイムアウトヘッダーは、「異常な」状況が発生しない場合にのみサーバーの動作を示します。たとえば、管理者はいつでもロックを削除するか、システムがロックの存在の記録を失うようにクラッシュする場合があります。応答には、プロップXML要素にロックディスコベリプロパティの値が含まれている必要があります。
In order to indicate the lock token associated with a newly created lock, a Lock-Token response header MUST be included in the response for every successful LOCK request for a new lock. Note that the Lock-Token header would not be returned in the response for a successful refresh LOCK request because a new lock was not created.
新しく作成されたロックに関連付けられたロックトークンを示すには、新しいロックの成功したロック要求ごとに、ロックトークン応答ヘッダーを応答に含める必要があります。新しいロックが作成されなかったため、リフレッシュロック要求を成功させるために、ロックトークンヘッダーは応答で返されないことに注意してください。
The scope of a lock is the entire state of the resource, including its body and associated properties. As a result, a lock on a resource MUST also lock the resource's properties.
ロックの範囲は、その身体と関連する特性を含むリソースの全体の状態です。その結果、リソースのロックもリソースのプロパティをロックする必要があります。
For collections, a lock also affects the ability to add or remove members. The nature of the effect depends upon the type of access control involved.
コレクションの場合、ロックはメンバーを追加または削除する機能にも影響します。効果の性質は、関連するアクセス制御のタイプに依存します。
A resource may be made available through more than one URI. However locks apply to resources, not URIs. Therefore a LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable.
複数のURIを通じてリソースを利用できるようにすることができます。ただし、ロックはurisではなくリソースに適用されます。したがって、リソースのロックリクエストは、リソースがアドレス指定できるすべてのURIによって尊重できない場合、成功してはなりません。
The Depth header may be used with the LOCK method. Values other than 0 or infinity MUST NOT be used with the Depth header on a LOCK method. All resources that support the LOCK method MUST support the Depth header.
深度ヘッダーは、ロックメソッドで使用できます。0以外の値または無限以外の値は、ロックメソッドの深度ヘッダーで使用してはなりません。ロックメソッドをサポートするすべてのリソースは、深度ヘッダーをサポートする必要があります。
A Depth header of value 0 means to just lock the resource specified by the Request-URI.
値0の深度ヘッダーは、リクエスト-URIによって指定されたリソースをロックすることを意味します。
If the Depth header is set to infinity then the resource specified in the Request-URI along with all its internal members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token which represents all the resources that have been locked. If an UNLOCK is successfully executed on this token, all associated resources are unlocked. If the lock cannot be granted to all resources, a 409 (Conflict) status code MUST be returned with a response entity body containing a multistatus XML element describing which resource(s) prevented the lock from being granted. Hence, partial success is not an option. Either the entire hierarchy is locked or no resources are locked.
深さヘッダーが無限に設定されている場合、すべての内部メンバーとともにリクエスト-URIで指定されたリソースは、階層をずっと下ってロックされます。成功した結果は、ロックされたすべてのリソースを表す単一のロックトークンを返す必要があります。このトークンでロック解除が正常に実行されると、すべての関連リソースがロック解除されます。すべてのリソースにロックを付与できない場合、ロックが付与されないようにするリソースを説明するマルチスタッサスXML要素を含む応答エンティティボディで409（競合）ステータスコードを返す必要があります。したがって、部分的な成功は選択肢ではありません。階層全体がロックされているか、リソースがロックされていません。
If no Depth header is submitted on a LOCK request then the request MUST act as if a "Depth:infinity" had been submitted.
ロックリクエストで深さヘッダーが送信されない場合、リクエストは「深さ：無限」が提出されたかのように動作する必要があります。
The interaction of a LOCK with various methods is dependent upon the lock type. However, independent of lock type, a successful DELETE of a resource MUST cause all of its locks to be removed.
ロックとさまざまな方法との相互作用は、ロックタイプに依存します。ただし、ロックタイプとは無関係に、リソースの削除が成功すると、すべてのロックを削除する必要があります。
The table below describes the behavior that occurs when a lock request is made on a resource.
以下の表は、リソースにロックリクエストが行われたときに発生する動作を説明しています。
Current lock state/ | Shared Lock | Exclusive
Lock request | | Lock
=====================+=================+==============
None | True | True
---------------------+-----------------+--------------
Shared Lock | True | False
---------------------+-----------------+--------------
Exclusive Lock | False | False*
------------------------------------------------------
Legend: True = lock may be granted. False = lock MUST NOT be granted. *=It is illegal for a principal to request the same lock twice.
凡例：true =ロックが付与される場合があります。false =ロックは許可されてはなりません。*=プリンシパルが同じロックを2回要求することは違法です。
The current lock state of a resource is given in the leftmost column, and lock requests are listed in the first row. The intersection of a row and column gives the result of a lock request. For example, if a shared lock is held on a resource, and an exclusive lock is requested, the table entry is "false", indicating the lock must not be granted.
リソースの現在のロック状態は左端の列に記載されており、ロックリクエストは最初の行にリストされています。行と列の交差点は、ロック要求の結果を示します。たとえば、共有ロックがリソースに保持され、排他的ロックが要求されている場合、テーブルエントリは「偽」であり、ロックを許可してはならないことを示します。
200 (OK) - The lock request succeeded and the value of the lockdiscovery property is included in the body.
200（OK） - ロックリクエストが成功し、ロックディスコービリプロパティの値がボディに含まれています。
412 (Precondition Failed) - The included lock token was not enforceable on this resource or the server could not satisfy the request in the lockinfo XML element.
412（前提条件に失敗した） - 付属のロックトークンは、このリソースで強制力がなかったか、サーバーがLockinfo XML要素の要求を満たすことができなかった。
423 (Locked) - The resource is locked, so the method has been rejected.
423（ロック） - リソースがロックされているため、この方法は拒否されました。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>応答
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>Infinity</D:depth>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This example shows the successful creation of an exclusive write lock on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The resource http://www.ics.uci.edu/~ejw/contact.html contains contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例は、リソースhttp://webdav.sb.aol.com/workspace/webdav/proposal.docの排他的な書き込みロックの作成の成功を示しています。リソースhttp://www.ics.uci.edu/~ejw/contact.htmlには、ロックの所有者の連絡先情報が含まれています。サーバーには、このリソースにアクティビティベースのタイムアウトポリシーがあり、1週間後（604800秒）後にロックが自動的に削除されます。NONCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていないことに注意してください。
>>Request
>>リクエスト
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
>>応答
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>Infinity</D:depth>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This request would refresh the lock, resetting any time outs. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
このリクエストはロックを更新し、いつでもリセットされます。クライアントは無限のタイムアウトを求めたが、サーバーはリクエストを無視することを選択したことに注意してください。この例では、NonCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていません。
>>Request
>>リクエスト
LOCK /webdav/ HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D="DAV:">
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
<D:response>
<D:href>http://webdav.sb.aol.com/webdav/</D:href>
<D:propstat>
<D:prop><D:lockdiscovery/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
</D:response>
</D:multistatus>
This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock, in this case a web page URL.
この例は、コレクションとそのすべての子供に排他的な書き込みロックのリクエストを示しています。このリクエストでは、クライアントは、利用可能な場合は無限の長さロックを望むことを指定しています。リクエストエンティティボディには、ロックを取り出すプリンシパルの連絡先情報、この場合はWebページURLが含まれています。
The error is a 403 (Forbidden) response on the resource http://webdav.sb.aol.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the lockdiscovery property for the Request-URI has been included as required. In this example the lockdiscovery property is empty which means that there are no outstanding locks on the resource.
エラーは、リソースhttp://webdav.sb.aol.com/webdav/secretの403（禁止）応答です。このリソースをロックできなかったため、リソースはいずれもロックされていません。また、リクエスト-URIのロック装備プロパティが必要に応じて含まれていることに注意してください。この例では、Lock -Discoveryプロパティは空です。つまり、リソースに顕著なロックがありません。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、NonCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていません。
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail.
ロック解除メソッドは、リクエスト-URIからのロックトークンリクエストヘッダーのロックトークンによって識別されたロックを削除し、ロックに含まれる他のすべてのリソースを削除します。提出されたロックトークンの下でロックされているすべてのリソースをロック解除できない場合、ロック解除リクエストは失敗する必要があります。
Any DAV compliant resource which supports the LOCK method MUST support the UNLOCK method.
ロックメソッドをサポートするDAV準拠のリソースは、ロック解除方法をサポートする必要があります。
>>Request
>>リクエスト
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204コンテンツなし
In this example, the lock identified by the lock token "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body.
この例では、ロックトークン「OpaquelockToken：A515CFA4-5DA4-22E1-F5B5-00A0451E6BF7」によって識別されたロックは、リソースhttp://webdav.sb.aol.com/workspace/webdav/info.docから正常に削除されます。このロックには1つ以上のリソースが含まれている場合、ロックはロックに含まれるすべてのリソースから削除されます。応答エンティティボディがないため、204（コンテンツなし）ステータスコードは200（OK）ではなく使用されます。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、NonCE、応答、および不透明フィールドは、承認要求ヘッダーで計算されていません。
9 HTTP Headers for Distributed Authoring
分散オーサリング用の9 HTTPヘッダー
DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
This header indicates that the resource supports the DAV schema and protocol as specified. All DAV compliant resources MUST return the DAV header on all OPTIONS responses.
このヘッダーは、リソースが指定されたDAVスキーマとプロトコルをサポートしていることを示しています。すべてのDAVに準拠したリソースは、すべてのオプション応答でDAVヘッダーを返す必要があります。
The value is a list of all compliance classes that the resource supports. Note that above a comma has already been added to the 2. This is because a resource can not be level 2 compliant unless it is also level 1 compliant. Please refer to section 15 for more details. In general, however, support for one compliance class does not entail support for any other.
値は、リソースがサポートするすべてのコンプライアンスクラスのリストです。上記のコンマはすでに2に追加されていることに注意してください。これは、レベル1に準拠していない限り、リソースをレベル2に準拠させることはできないためです。詳細については、セクション15を参照してください。ただし、一般に、あるコンプライアンスクラスのサポートは、他のコンプライアンスクラスのサポートを伴いません。
Depth = "Depth" ":" ("0" | "1" | "infinity")
The Depth header is used with methods executed on resources which could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its immediate children, ("Depth: 1"), or the resource and all its progeny ("Depth: infinity").
深さヘッダーは、リソースでのみ内部メンバーを持つ可能性のあるリソースで実行されたメソッドで使用されます。メソッドがリソース（「深さ：0」）、リソース、およびその直接の子供にのみ適用されるかどうかを示すことができます（ "深さ：1"）、またはリソースとそのすべての子孫（「深さ：無限」）。
The Depth header is only supported if a method's definition explicitly provides for such support.
深度ヘッダーは、メソッドの定義がそのようなサポートを明示的に提供する場合にのみサポートされます。
The following rules are the default behavior for any method that supports the Depth header. A method may override these defaults by defining different behavior in its definition.
次のルールは、深度ヘッダーをサポートする任意の方法のデフォルトの動作です。メソッドは、その定義で異なる動作を定義することにより、これらのデフォルトをオーバーライドする場合があります。
Methods which support the Depth header may choose not to support all of the header's values and may define, on a case by case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity" and if a Depth header is not present will act as if a "Depth: infinity" header had been applied.
深度ヘッダーをサポートする方法は、ヘッダーのすべての値をサポートしないように選択し、ケースバイケースで、深度ヘッダーが存在しない場合のメソッドの動作を定義する場合があります。たとえば、移動方法は「深さ：無限」のみをサポートし、深さヘッダーが存在しない場合は、「深さ：無限」ヘッダーが適用されているかのように機能します。
Clients MUST NOT rely upon methods executing on members of their hierarchies in any particular order or on the execution being atomic unless the particular method explicitly provides such guarantees.
クライアントは、特定の方法が明示的にそのような保証を提供しない限り、特定の順序で階層のメンバーを実行したり、原子になったりする方法に依存してはなりません。
Upon execution, a method with a Depth header will perform as much of its assigned task as possible and then return a response specifying what it was able to accomplish and what it failed to do.
実行されると、深度ヘッダーを備えたメソッドは、割り当てられたタスクをできるだけ多く実行し、達成できるものと失敗したことを指定する応答を返します。
So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not.
したがって、たとえば、階層をコピーしようとすると、一部のメンバーがコピーされ、一部が存在しない場合があります。
Any headers on a method that has a defined interaction with the Depth header MUST be applied to all resources in the scope of the method except where alternative behavior is explicitly defined. For example, an If-Match header will have its value applied against every resource in the method's scope and will cause the method to fail if the header fails to match.
深さヘッダーとの対話が定義されたメソッドのヘッダーは、代替動作が明示的に定義されている場合を除き、メソッドの範囲内のすべてのリソースに適用する必要があります。たとえば、IFマッチヘッダーは、メソッドの範囲内のすべてのリソースに対して値を適用し、ヘッダーが一致しない場合にメソッドが失敗します。
If a resource, source or destination, within the scope of the method with a Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header.
深度ヘッダーを備えたメソッドの範囲内で、リソース、ソース、または宛先がメソッドの成功を防ぐような方法でロックされている場合、そのリソースのロックトークンは、ifのリクエストとともに提出する必要があります。ヘッダーをリクエストします。
The Depth header only specifies the behavior of the method with regards to internal children. If a resource does not have internal children then the Depth header MUST be ignored.
深度ヘッダーは、内部の子供に関しての方法の動作のみを指定します。リソースに内部の子供がいない場合、深度ヘッダーは無視する必要があります。
Please note, however, that it is always an error to submit a value for the Depth header that is not allowed by the method's definition. Thus submitting a "Depth: 1" on a COPY, even if the resource does not have internal members, will result in a 400 (Bad Request). The method should fail not because the resource doesn't have internal members, but because of the illegal value in the header.
ただし、メソッドの定義で許可されていない深度ヘッダーの値を送信することは常にエラーであることに注意してください。したがって、リソースに内部メンバーがない場合でも、コピーに「深さ：1」を送信すると、400（悪い要求）が得られます。メソッドは、リソースに内部メンバーがないためではなく、ヘッダーの違法価値のために失敗するはずです。
Destination = "Destination" ":" absoluteURI
宛先= "宛先" "：" Absoluteuri
The Destination header specifies the URI which identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters. Note that the absoluteURI production is defined in [RFC2396].
宛先ヘッダーは、2つのURIをパラメーターとして使用するコピーアンドモーブなどのメソッドの宛先リソースを識別するURIを指定します。絶対尿産生は[RFC2396]で定義されていることに注意してください。
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List
Tagged-list = Resource 1*List
Resource = Coded-URL
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
State-token = Coded-URL
Coded-URL = "<" absoluteURI ">"
The If header is intended to have similar functionality to the If-Match header defined in section 14.25 of [RFC2068]. However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification.
IFヘッダーは、[RFC2068]のセクション14.25で定義されているIFマッチヘッダーと同様の機能を持つことを目的としています。ただし、ヘッダーは、状態トークンと呼ばれる状態情報を表すURIで使用することを目的としています。状態トークンの典型的な例はロックトークンであり、ロックトークンはこの仕様で定義されている唯一の状態トークンです。
All DAV compliant resources MUST honor the If header.
すべてのDAVに準拠したリソースは、IFヘッダーを称えなければなりません。
The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). If one of the described state lists matches the state of the resource then the request may succeed.
ヘッダーの目的は、一連の状態リストを説明することです。ヘッダーが適用されるリソースの状態が指定された状態リストのいずれかと一致しない場合、要求は412で失敗する必要があります（前提条件は失敗しました）。説明されている状態のいずれかがリソースの状態と一致する場合、要求は成功する可能性があります。
Note that the absoluteURI production is defined in [RFC2396].
絶対尿産生は[RFC2396]で定義されていることに注意してください。
The No-tag-list production describes a series of state tokens and ETags. If multiple No-tag-list productions are used then one only needs to match the state of the resource for the method to be allowed to continue.
ノータグリストの生産では、一連の状態トークンとエタグについて説明しています。複数のノータグリスト制作を使用する場合、メソッドを継続するためにリソースの状態を一致させる必要があります。
If a method, due to the presence of a Depth or Destination header, is applied to multiple resources then the No-tag-list production MUST be applied to each resource the method is applied to.
深度または宛先ヘッダーの存在により、複数のリソースに適用される方法がある場合、メソッドが適用される各リソースにノータグリストの生産を適用する必要があります。
If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another
ETag"])
The previous header would require that any resources within the scope of the method must either be locked with the specified lock token and in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag". To put the matter more plainly one can think of the previous If header as being in the form (or (and <locktoken:a-write-lock-token> ["I am an ETag"]) (and ["I am another ETag"])).
前のヘッダーは、メソッドの範囲内のリソースを指定されたロックトークンでロックし、「私はetag a a a a a a a」etagによって識別される状態で、または2番目のetagによって識別される状態のいずれかを要求します。etag "。この問題をより明確に言うと、以前のヘッダーがフォームにあると考えることができます（または（および<locktoken：a-write-lock-token> ["i a a etag"]）（ "私は別のetag "]））。
The tagged-list production scopes a list production. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any.
タグ付きリストの生産は、リストの生成をスコープします。つまり、リソース仕様に続くリストが指定されたリソースにのみ適用されることを指定します。リソース生産の範囲は、リソース生産直後のリスト生産から始まり、次のリソース生産があれば終了します。
When the If header is applied to a particular resource, the Tagged-list productions MUST be searched to determine if any of the listed resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section.
ヘッダーが特定のリソースに適用される場合、タグ付きリストのプロダクションを検索して、リストされているリソースのいずれかが現在の方法のオペランドリソースと一致するかどうかを判断する必要があります。リソースプロダクションのいずれも現在のリソースと一致しない場合、ヘッダーは無視する必要があります。リソースプロダクションの1つが検討中のリソースの名前と一致する場合、リソース生産後のリストプロダクションは、前のセクションで指定された方法でリソースに適用する必要があります。
The same URI MUST NOT appear more than once in a resource production in an If header.
同じURIが、IFヘッダーのリソース生産に複数回表示してはなりません。
COPY /resource1 HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/resource2
If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>
[W/"A weak ETag"]) (["strong ETag"])
<http://www.bar.bar/random>(["another strong ETag"])
In this example http://www.foo.bar/resource1 is being copied to http://www.foo.bar/resource2. When the method is first applied to http://www.foo.bar/resource1, resource1 must be in the state specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"]) (["strong ETag"])", that is, it either must be locked with a lock token of "locktoken:a-write-lock-token" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag".
この例では、http：//www.foo.bar/resource1がhttp://www.foo.bar/resource2にコピーされています。メソッドが最初にhttp://www.foo.bar/resource1に適用される場合、Resource1は「<locktoken：a-write-lock-token> [w/"a weak etag"）によって指定された状態にある必要があります。（["strong etag"]） "、つまり、「locktoken：a-write-lock-token」のロックトークンでロックする必要があり、「弱いetag」w/" w/"wid weak ent wake eminit強力なエンティティタグ「強いETAG」を持っています。
That is the only success condition since the resource http://www.bar.bar/random never has the method applied to it (the only other resource listed in the If header) and http://www.foo.bar/resource2 is not listed in the If header.
リソースhttp://www.bar.bar/randomがそれに適用されることはないので、それは唯一の成功条件です（ifヘッダーにリストされている他のリソースのみ）、http://www.foo.bar/resource2IFヘッダーにはリストされていません。
Every state token or ETag is either current, and hence describes the state of a resource, or is not current, and does not describe the state of a resource. The boolean operation of matching a state token or ETag to the current state of a resource thus resolves to a true or false value. The not production is used to reverse that value. The scope of the not production is the state-token or entity-tag immediately following it.
すべての州のトークンまたはETAGは最新であるため、リソースの状態を説明するか、最新ではなく、リソースの状態を説明していません。状態トークンまたはETAGをリソースの現在の状態に一致させるというブール操作は、真または偽の値に解決します。生産されていないことは、その価値を逆転させるために使用されます。NOTの生産の範囲は、その直後のState-TokenまたはEntity-Tagです。
If: (Not <locktoken:write1> <locktoken:write2>)
When submitted with a request, this If header requires that all operand resources must not be locked with locktoken:write1 and must be locked with locktoken:write2.
リクエストで送信すると、ヘッダーがすべてのオペランドリソースをlocktoken：write1でロックしてはならないことを要求し、locktoken：write2でロックする必要があります。
When performing If header processing, the definition of a matching state token or entity tag is as follows.
ヘッダー処理を実行する場合、一致する状態トークンまたはエンティティタグの定義は次のとおりです。
Matching entity tag: Where the entity tag matches an entity tag associated with that resource.
マッチングエンティティタグ：エンティティタグがそのリソースに関連付けられたエンティティタグと一致する場合。
Matching state token: Where there is an exact match between the state token in the If header and any state token on the resource.
一致する状態トークン：IFヘッダーの状態トークンとリソースの任意の状態トークンの間に正確な一致があります。
Non-DAV compliant proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the "Cache-Control: no-cache" request header MUST be used so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" request header MUST be used for the same reason.
非DAV準拠のプロキシは、IFヘッダーを理解していないため、ヘッダーを尊重しません。HTTPは、理解されていないヘッダーを無視する必要があります。HTTP/1.1プロキシと通信する場合、プロキシがキャッシュからリクエストを不適切にサービスを提供しようとするのを防ぐために、「キャッシュコントロール：ノーキャッシュ」要求ヘッダーを使用する必要があります。HTTP/1.0を処理する場合、「プラグマ：ノーキャッシュ」リクエストヘッダーを同じ理由で使用する必要があります。
Lock-Token = "Lock-Token" ":" Coded-URL
Lock-Token = "Lock-Token" "：" Coded-url
The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed. The lock token in the Lock-Token request header MUST identify a lock that contains the resource identified by Request-URI as a member.
ロックトークンリクエストヘッダーは、ロック解除方法で使用され、削除するロックを識別します。ロックトークンリクエストヘッダーのロックトークンは、リクエスト-URIによってメンバーとして識別されたリソースを含むロックを識別する必要があります。
The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.
ロックトークン応答ヘッダーは、ロックメソッドとともに使用され、新しいロックを作成するためのロック要求が成功した結果として作成されたロックトークンを示します。
Overwrite = "Overwrite" ":" ("T" | "F")
The Overwrite header specifies whether the server should overwrite the state of a non-null destination resource during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the state of the destination resource is non-null. If the overwrite header is not included in a COPY or MOVE request then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of the If-Match: * header of HTTP/1.1, If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE.
上書きヘッダーは、コピーまたは移動中にサーバーが非ヌルの宛先リソースの状態を上書きするかどうかを指定します。「F」の値は、宛先リソースの状態が非ヌルである場合、サーバーがコピーまたは移動操作を実行してはならないことを示しています。上書きヘッダーがコピーまたは移動リクエストに含まれていない場合、リソースは、値「t」の上書きヘッダーがあるかのようにリクエストを扱う必要があります。上書きヘッダーは、IF-Match： * HTTP/1.1のヘッダーの機能を複製しているように見えますが、If-MatchはリクエストURIにのみ適用され、コピーまたは移動の宛先には適用されません。
If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code.
上書きヘッダーの値のためにコピーまたは移動が実行されない場合、メソッドは412（前提条件に失敗した）ステータスコードで失敗する必要があります。
All DAV compliant resources MUST support the Overwrite header.
すべてのDAVに準拠したリソースは、上書きヘッダーをサポートする必要があります。
The Status-URI response header may be used with the 102 (Processing) status code to inform the client as to the status of a method.
ステータス-URI応答ヘッダーは、102（処理）ステータスコードで使用して、メソッドのステータスについてクライアントに通知できます。
Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
is defined in 6.1.1 of [RFC2068]
The URIs listed in the header are source resources which have been affected by the outstanding method. The status code indicates the resolution of the method on the identified resource. So, for example, if a MOVE method on a collection is outstanding and a 102 (Processing) response with a Status-URI response header is returned, the included URIs will indicate resources that have had move attempted on them and what the result was.
ヘッダーにリストされているURIは、未解決の方法の影響を受けたソースリソースです。ステータスコードは、識別されたリソース上のメソッドの解決を示します。したがって、たとえば、コレクションの移動方法が未解決であり、ステータス-RI応答ヘッダーを使用した102（処理）応答が返された場合、付属のURIは、動きを試みたリソースと結果が何であるかを示します。
TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
DAVTimeOutVal = 1*digit
Other = "Extend" field-value ; See section 4.2 of [RFC2068]
Clients may include Timeout headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method.
クライアントには、ロックリクエストにタイムアウトヘッダーが含まれる場合があります。ただし、サーバーは、これらのリクエストを尊重したり、検討する必要もありません。クライアントは、ロックメソッド以外のメソッドを備えたタイムアウトリクエストヘッダーを送信してはなりません。
A Timeout request header MUST contain at least one TimeType and may contain multiple TimeType entries. The purpose of listing multiple TimeType entries is to indicate multiple different values and value types that are acceptable to the client. The client lists the TimeType entries in order of preference.
タイムアウトリクエストヘッダーには、少なくとも1つのタイムタイプが含まれている必要があり、複数のタイムタイプエントリが含まれる場合があります。複数のタイムタイプエントリをリストする目的は、クライアントが受け入れられる複数の異なる値と値タイプを示すことです。クライアントは、タイムタイプのエントリを好みの順にリストします。
Timeout response values MUST use a Second value, Infinite, or a TimeType the client has indicated familiarity with. The server may assume a client is familiar with any TimeType submitted in a Timeout header.
タイムアウト応答値は、クライアントが親しみを示している2番目の値、無限、またはタイムタイプを使用する必要があります。サーバーは、クライアントがタイムアウトヘッダーで提出されたタイムタイプに精通していると想定する場合があります。
The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1.
「2番目の」タイムタイプは、サーバーでのロックの付与とロックの自動削除との間に経過する秒数を指定します。TimeType "Second"のタイムアウト値は、2^32-1を超えてはなりません。
The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received.
タイムアウトカウンターは、ロックの所有者が、サポートされていないメソッド、または失敗したメソッドを含むロックのメンバーにメソッドを送信するときはいつでも再起動する必要があります。ただし、更新ロックメソッドが正常に受信された場合、ロックを更新する必要があります。
If the timeout expires then the lock may be lost. Specifically, if the server wishes to harvest the lock upon time-out, the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with
タイムアウトの有効期限が切れると、ロックが失われる可能性があります。具体的には、サーバーがタイムアウト時にロックを収穫することを希望する場合、サーバーは、タイムアウトロックのロックトークンを使用してリソース上のサーバーによってロック解除メソッドが実行され、実行されたかのように動作する必要があります。
its override authority. Thus logs should be updated with the disposition of the lock, notifications should be sent, etc., just as they would be for an UNLOCK request.
そのオーバーライドの権限。したがって、ロックの処分でログを更新する必要があります。ロック解除リクエストの場合と同様に、通知を送信する必要があります。
Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going off-line.
サーバーは、クライアントが実行しようとするアクティビティのタイプを示すため、クライアントが提出した値に細心の注意を払うことをお勧めします。たとえば、ブラウザで実行されているアプレットはリソースをロックする必要がある場合がありますが、アプレットが実行されている環境の不安定性のため、アプレットは警告なしにオフにすることができます。その結果、アプレットは比較的小さなタイムアウト値を要求する可能性が高いため、アプレットが死んだ場合、ロックをすばやく収集できるようになります。ただし、ドキュメント管理システムは、ユーザーがオフラインに進むことを計画している可能性があるため、非常に長いタイムアウトを要求する可能性があります。
A client MUST NOT assume that just because the time-out has expired the lock has been lost.
クライアントは、タイムアウトが期限切れになったからといって、ロックが失われたと仮定してはなりません。
10 Status Code Extensions to HTTP/1.1
10ステータスコード拡張機能HTTP/1.1
The following status codes are added to those defined in HTTP/1.1 [RFC2068].
次のステータスコードは、HTTP/1.1 [RFC2068]で定義されているものに追加されます。
The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed.
102（処理）ステータスコードは、サーバーが完全な要求を受け入れたがまだ完了していないことをクライアントに通知するために使用される暫定応答です。このステータスコードは、リクエストが完了するまでにかなりの時間がかかるという合理的な期待がある場合にのみ送信する必要があります。ガイダンスとして、メソッドが20秒以上かかっている場合（合理的ですが、任意の値）、サーバーは102（処理）応答を返す必要があります。リクエストが完了した後、サーバーは最終的な応答を送信する必要があります。
Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.
方法は、特に深度ヘッダーをサポートする方法、特に処理に長時間時間がかかる可能性があります。そのような場合、クライアントは応答を待っている間に接続をタイムアウトすることができます。これを防ぐために、サーバーは102（処理）ステータスコードを返して、サーバーがまだメソッドを処理していることをクライアントに示すことができます。
The 207 (Multi-Status) status code provides status for multiple independent operations (see section 11 for more information).
207（マルチステータス）ステータスコードは、複数の独立操作のステータスを提供します（詳細についてはセクション11を参照）。
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.
422（処理不可能なエンティティ）ステータスコードは、サーバーがリクエストエンティティのコンテンツタイプを理解することを意味します（したがって415（サポートされていないメディアタイプ）ステータスコードは不適切です）。）ステータスコードは不適切です）が、含まれている命令を処理できませんでした。たとえば、XML要求本体によく形成された（つまり、構文的に正しい）が、意味的に誤ったXML命令が含まれている場合、このエラー条件が発生する場合があります。
The 423 (Locked) status code means the source or destination resource of a method is locked.
423（ロックされた）ステータスコードは、メソッドのソースまたは宛先リソースがロックされていることを意味します。
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).
424（失敗した依存関係）ステータスコードは、要求されたアクションが別のアクションに依存し、そのアクションが失敗したため、メソッドをリソースで実行できなかったことを意味します。たとえば、プロップパッチメソッドのコマンドが失敗した場合、少なくとも424（依存関係の失敗）でコマンドの残りも失敗します。
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request which received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
507（不十分なストレージ）ステータスコードは、リクエストを正常に完了するために必要な表現を保存できないため、メソッドをリソースで実行できなかったことを意味します。この状態は一時的な状態と見なされます。このステータスコードを受信したリクエストがユーザーアクションの結果である場合、リクエストは、個別のユーザーアクションによって要求されるまで繰り返されてはなりません。
11 Multi-Status Response
11マルチステータス応答
The default 207 (Multi-Status) response body is a text/xml or application/xml HTTP entity that contains a single XML element called multistatus, which contains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a response XML element.
デフォルト207（マルチステータス）応答本体は、MultiStatusと呼ばれる単一のXML要素を含むテキスト/XMLまたはApplication/XML HTTPエンティティです。メソッドの呼び出し中に生成されたステータスコード。100シリーズステータスコードは、応答XML要素に記録しないでください。
12 XML Element Definitions
12 XML要素定義
In the section below, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element).
以下のセクションでは、各セクションの最終行では、[rec-xml]で定義された形式を使用して、要素タイプ宣言を示します。存在する「値」フィールドは、BNFを使用してXML要素の許容コンテンツのさらなる制限を指定します（つまり、PCDATA要素の値をさらに制限するため）。
Name: activelock Namespace: DAV: Purpose: Describes a lock on a resource.
名前：ActiveLock NameSpace：DAV：目的：リソースのロックについて説明します。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?) >
<！要素activelock（lockscope、locktype、depth、owner？、timeout？、locktoken？）>
Name: depth
Namespace: DAV:
Purpose: The value of the Depth header.
Value: "0" | "1" | "infinity"
<!ELEMENT depth (#PCDATA) >
Name: locktoken Namespace: DAV: Purpose: The lock token associated with a lock. Description: The href contains one or more opaque lock token URIs which all refer to the same lock (i.e., the OpaqueLockToken-URI production in section 6.4).
名前：ロックトークン名空間：DAV：目的：ロックに関連付けられたロックトークン。説明：HREFには、すべて同じロックを指す1つまたは複数の不透明なロックトークンURIが含まれています（つまり、セクション6.4のオパロックトークン-RIの生成）。
<!ELEMENT locktoken (href+) >
Name: timeout
Namespace: DAV:
Purpose: The timeout associated with a lock
Value: TimeType ;Defined in section 9.8
<!ELEMENT timeout (#PCDATA) >
Name: collection Namespace: DAV: Purpose: Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST have this value.
名前：コレクション名空間：DAV：目的：関連するリソースをコレクションとして識別します。コレクションリソースのResourceTypeプロパティには、この値が必要です。
<!ELEMENT collection EMPTY >
Name: href
Namespace: DAV:
Purpose: Identifies the content of the element as a URI.
Value: URI ; See section 3.2.1 of [RFC2068]
<!ELEMENT href (#PCDATA)>
Name: link Namespace: DAV: Purpose: Identifies the property as a link and contains the source and destination of that link. Description: The link XML element is used to provide the sources and destinations of a link. The name of the property containing the link XML element provides the type of the link. Link is a multi-valued element, so multiple links may be used together to indicate multiple links with the same type. The values in the href XML elements inside the src and dst XML elements of the link XML element MUST NOT be rejected if they point to resources which do not exist.
名前：リンク名空間：DAV：目的：プロパティをリンクとして識別し、そのリンクのソースと宛先を含みます。説明：リンクXML要素は、リンクのソースと目的地を提供するために使用されます。リンクXML要素を含むプロパティの名前は、リンクのタイプを提供します。リンクは多値の要素であるため、複数のリンクを一緒に使用して、同じタイプの複数のリンクを示すことができます。Link XML要素のSRCおよびDST XML要素内のHREF XML要素の値は、存在しないリソースを指している場合、拒否してはなりません。
<!ELEMENT link (src+, dst+) >
Name: dst Namespace: DAV: Purpose: Indicates the destination of a link Value: URI
名前：dst namespace：dav：目的：リンク値の宛先を示します：uri
<!ELEMENT dst (#PCDATA) >
Name: src Namespace: DAV: Purpose: Indicates the source of a link.
名前：SRC名空間：DAV：目的：リンクのソースを示します。
Value: URI
値：uri
<!ELEMENT src (#PCDATA) >
Name: lockentry Namespace: DAV: Purpose: Defines the types of locks that can be used with the resource.
名前：Lockentry NameSpace：DAV：目的：リソースで使用できるロックの種類を定義します。
<!ELEMENT lockentry (lockscope, locktype) >
Name: lockinfo Namespace: DAV: Purpose: The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created.
名前：lockinfo namespace：dav：目的：lockinfo xml要素は、クライアントが作成したいロックのタイプを指定するためにロック方法で使用されます。
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
Name: lockscope Namespace: DAV: Purpose: Specifies whether a lock is an exclusive lock, or a shared lock.
名前：LocksCope NameSpace：DAV：目的：ロックが排他的ロックか共有ロックかを指定します。
<!ELEMENT lockscope (exclusive | shared) >
Name: exclusive Namespace: DAV: Purpose: Specifies an exclusive lock
名前：排他的な名前空間：DAV：目的：排他的ロックを指定します
<!ELEMENT exclusive EMPTY >
Name: shared Namespace: DAV: Purpose: Specifies a shared lock
名前：共有名空間：DAV：目的：共有ロックを指定します
<!ELEMENT shared EMPTY >
Name: locktype Namespace: DAV: Purpose: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.
名前：locktype namespace：dav：目的：ロックのアクセスタイプを指定します。現在、この仕様では、1つのロックタイプである書き込みロックのみを定義しています。
<!ELEMENT locktype (write) >
Name: write Namespace: DAV: Purpose: Specifies a write lock.
名前：書き込み名前空間：DAV：目的：書き込みロックを指定します。
<!ELEMENT write EMPTY >
Name: multistatus Namespace: DAV: Purpose: Contains multiple response messages. Description: The responsedescription at the top level is used to provide a general message describing the overarching nature of the response. If this value is available an application may use it instead of presenting the individual response descriptions contained within the responses.
名前：MultiStatus NameSpace：DAV：目的：複数の応答メッセージが含まれています。説明：上位レベルでのressonsedesscriptionを使用して、応答の包括的な性質を説明する一般的なメッセージを提供します。この値が利用可能な場合、アプリケーションは、応答内に含まれる個々の応答の説明を提示する代わりに使用する場合があります。
<!ELEMENT multistatus (response+, responsedescription?) >
Name: response Namespace: DAV: Purpose: Holds a single response describing the effect of a method on resource and/or its properties. Description: A particular href MUST NOT appear more than once as the child of a response XML element under a multistatus XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by href. There are, however, no requirements regarding ordering based on href values.
名前：応答名スペース：DAV：目的：リソースおよび/またはそのプロパティに対するメソッドの効果を説明する単一の応答を保持します。説明：特定のHREFは、Multistatus XML要素の下で応答XML要素の子として複数回表示してはなりません。この要件は、線形時間への応答の処理コストを維持するために必要です。基本的に、これにより、HREFによるすべての応答をグループ化するために検索する必要があります。ただし、HREF値に基づく注文に関する要件はありません。
<!ELEMENT response (href, ((href*, status)|(propstat+)),
responsedescription?) >
Name: propstat Namespace: DAV: Purpose: Groups together a prop and status element that is associated with a particular href element. Description: The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies.
名前：PropStat NameSpace：DAV：目的：特定のHREF要素に関連付けられているプロップとステータス要素をグループ化します。説明：PropStat XML要素には、1つのProp XML要素と1つのステータスXML要素を含める必要があります。Prop XML要素の内容は、ステータス要素の結果が適用されるプロパティの名前のみをリストする必要があります。
<!ELEMENT propstat (prop, status, responsedescription?) >
Name: status
Namespace: DAV:
Purpose: Holds a single HTTP status-line
Value: status-line ;status-line defined in [RFC2068]
<!ELEMENT status (#PCDATA) >
Name: responsedescription Namespace: DAV: Purpose: Contains a message that can be displayed to the user explaining the nature of the response. Description: This XML element provides information suitable to be presented to a user.
名前：ressedesscription namespace：dav：目的：応答の性質を説明するユーザーに表示できるメッセージが含まれています。説明：このXML要素は、ユーザーに提示されるのに適した情報を提供します。
<!ELEMENT responsedescription (#PCDATA) >
Name: owner Namespace: DAV: Purpose: Provides information about the principal taking out a lock. Description: The owner XML element provides information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who owns a lock.
名前：所有者の名前空間：DAV：目的：校長がロックを取り出したことに関する情報を提供します。説明：所有者XML要素は、プリンシパル（電話番号や電子メールURIなど）に直接連絡するか、ロックを所有しているプリンシパル（ホームページのURLなど）を発見するのに十分な情報を提供します。
<!ELEMENT owner ANY>
Name: prop Namespace: DAV: Purpose: Contains properties related to a resource. Description: The prop XML element is a generic container for properties defined on resources. All elements inside a prop XML element MUST define properties related to the resource. No other elements may be used inside of a prop element.
名前：Prop NameSpace：DAV：目的：リソースに関連するプロパティが含まれています。説明：Prop XML要素は、リソースで定義されているプロパティの汎用コンテナです。Prop XML要素内のすべての要素は、リソースに関連するプロパティを定義する必要があります。プロップ要素の中に他の要素を使用することはできません。
<!ELEMENT prop ANY>
Name: propertybehavior Namespace: DAV: Purpose: Specifies how properties are handled during a COPY or MOVE. Description: The propertybehavior XML element specifies how properties are handled during a COPY or MOVE. If this XML element is not included in the request body then the server is expected to act as defined by the default property handling behavior of the associated method. All WebDAV compliant resources MUST support the propertybehavior XML element.
名前：PropertyBehaviorネームスペース：DAV：目的：コピーまたは移動中のプロパティの処理方法を指定します。説明：PropertyBehavior XML要素は、コピーまたは移動中のプロパティの処理方法を指定します。このXML要素がリクエスト本文に含まれていない場合、サーバーは、関連する方法のデフォルトのプロパティ処理動作によって定義されたとおりに機能すると予想されます。すべてのWebDAV準拠のリソースは、PropertyBehavior XML要素をサポートする必要があります。
<!ELEMENT propertybehavior (omit | keepalive) >
Name: keepalive Namespace: DAV: Purpose: Specifies requirements for the copying/moving of live properties. Description: If a list of URIs is included as the value of keepalive then the named properties MUST be "live" after they are copied (moved) to the destination resource of a COPY (or MOVE). If the value "*" is given for the keepalive XML element, this designates that all live properties on the source resource MUST be live on the destination. If the requirements specified by the keepalive element can not be honored then the method MUST fail with a 412 (Precondition Failed). All DAV compliant resources MUST support the keepalive XML element for use with the COPY and MOVE methods. Value: "*" ; #PCDATA value can only be "*"
名前：KeepAlive NameSpace：DAV：目的：ライブプロパティのコピー/移動の要件を指定します。説明：URIのリストがKeepAliveの値として含まれている場合、コピー（または移動）の宛先リソースにコピー（移動）された後、指定されたプロパティを「ライブ」する必要があります。keepAlive XML要素に値「*」が与えられている場合、これはソースリソース上のすべてのライブプロパティが宛先でライブでなければならないことを指定します。KeepAlive要素によって指定された要件を尊重できない場合、メソッドは412で失敗する必要があります（前提条件が失敗しました）。すべてのDAVに準拠したリソースは、コピーおよび移動方法で使用するためにKeepAlive XML要素をサポートする必要があります。価値： "*" ;#PCDATA値は「*」のみであることができます
<!ELEMENT keepalive (#PCDATA | href+) >
Name: omit Namespace: DAV: Purpose: The omit XML element instructs the server that it should use best effort to copy properties but a failure to copy a property MUST NOT cause the method to fail. Description: The default behavior for a COPY or MOVE is to copy/move all properties or fail the method. In certain circumstances, such as when a server copies a resource over another protocol such as FTP, it may not be possible to copy/move the properties associated with the resource. Thus any attempt to copy/move over FTP would always have to fail because properties could not be moved over, even as dead properties. All DAV compliant resources MUST support the omit XML element on COPY/MOVE methods.
名前：名前空間を省略：DAV：目的：OMIT XML要素は、プロパティをコピーするために最良の努力を使用する必要があることをサーバーに指示しますが、プロパティのコピーに失敗してもメソッドが失敗してはなりません。説明：コピーまたは移動のデフォルトの動作は、すべてのプロパティをコピー/移動するか、メソッドを失敗させることです。サーバーがFTPなどの別のプロトコルを介してリソースをコピーする場合など、特定の状況では、リソースに関連付けられたプロパティをコピー/移動することはできない場合があります。したがって、FTPをコピー/移動しようとすると、プロパティを移動できなかったため、死んだプロパティとしても移動できなかったため、常に失敗する必要があります。すべてのDAVに準拠したリソースは、コピー/移動メソッドのOMIT XML要素をサポートする必要があります。
<!ELEMENT omit EMPTY >
Name: propertyupdate Namespace: DAV: Purpose: Contains a request to alter the properties on a resource. Description: This XML element is a container for the information required to modify the properties on the resource. This XML element is multi-valued.
名前：PropertyUpDate名空間：DAV：目的：リソースのプロパティを変更するリクエストが含まれています。説明：このXML要素は、リソース上のプロパティを変更するために必要な情報のコンテナです。このXML要素は多値です。
<!ELEMENT propertyupdate (remove | set)+ >
Name: remove Namespace: DAV: Purpose: Lists the DAV properties to be removed from a resource. Description: Remove instructs that the properties specified in prop should be removed. Specifying the removal of a property that does not exist is not an error. All the XML elements in a prop XML element inside of a remove XML element MUST be empty, as only the names of properties to be removed are required.
名前：名前空間を削除：DAV：目的：リソースから削除するDAVプロパティをリストします。説明：削除プロップで指定されたプロパティを削除する必要があることを指示します。存在しないプロパティの削除を指定することは、エラーではありません。削除するプロパティの名前のみが必要なため、削除XML要素内のプロップXML要素内のすべてのXML要素は空でなければなりません。
<!ELEMENT remove (prop) >
Name: set Namespace: DAV: Purpose: Lists the DAV property values to be set for a resource.
名前：名前空間を設定：DAV：目的：リソースに設定するDAVプロパティ値をリストします。
Description: The set XML element MUST contain only a prop XML element. The elements contained by the prop XML element inside the set XML element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists then its value is replaced. Language tagging information in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND.
説明：SET XML要素には、Prop XML要素のみを含める必要があります。SET XML要素内のProp XML要素に含まれる要素は、Request-URIによって識別されたリソースに設定されたプロパティの名前と値を指定する必要があります。プロパティが既に存在する場合、その値は置き換えられます。プロパティの値（「XML：Lang」属性、存在する場合）の言語タグ付け情報は、プロパティと一緒に持続的に保存され、その後Propfindを使用して取得可能でなければなりません。
<!ELEMENT set (prop) >
Name: propfind Namespace: DAV: Purpose: Specifies the properties to be returned from a PROPFIND method. Two special elements are specified for use with propfind, allprop and propname. If prop is used inside propfind it MUST only contain property names, not values.
名前：Propfind namespace：dav：目的：Propfindメソッドから返されるプロパティを指定します。Propfind、AllProp、およびPropnameで使用するために2つの特別な要素が指定されています。Propfind内でPROPが使用される場合、値は値ではなく、プロパティ名のみを含める必要があります。
<!ELEMENT propfind (allprop | propname | prop) >
Name: allprop Namespace: DAV: Purpose: The allprop XML element specifies that all property names and values on the resource are to be returned.
名前：AllProp NameSpace：DAV：目的：AllProp XML要素は、リソース上のすべてのプロパティ名と値が返されることを指定します。
<!ELEMENT allprop EMPTY >
Name: propname Namespace: DAV: Purpose: The propname XML element specifies that only a list of property names on the resource is to be returned.
名前：propname namespace：dav：目的：propname xml要素は、リソース上のプロパティ名のリストのみが返されることを指定します。
<!ELEMENT propname EMPTY >
13 DAV Properties
13 DAVプロパティ
For DAV properties, the name of the property is also the same as the name of the XML element that contains its value. In the section below, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element).
DAVプロパティの場合、プロパティの名前は、その値を含むXML要素の名前と同じです。以下のセクションでは、各セクションの最終行では、[rec-xml]で定義された形式を使用して、要素タイプ宣言を示します。存在する「値」フィールドは、BNFを使用してXML要素の許容コンテンツのさらなる制限を指定します（つまり、PCDATA要素の値をさらに制限するため）。
Name: creationdate Namespace: DAV: Purpose: Records the time and date the resource was created. Value: date-time ; See Appendix 2 Description: The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created (i.e., the moment it had non-null state).
名前：creationdate namespace：dav：目的：リソースが作成された時刻と日付を記録します。値：日付時間;付録2を参照してください。説明：CreationDateプロパティは、すべてのDAV準拠のリソースで定義する必要があります。存在する場合、リソースが作成された瞬間のタイムスタンプが含まれています（つまり、非誤状態があった瞬間）。
<!ELEMENT creationdate (#PCDATA) >
Name: displayname Namespace: DAV: Purpose: Provides a name for the resource that is suitable for presentation to a user. Description: The displayname property should be defined on all DAV compliant resources. If present, the property contains a description of the resource that is suitable for presentation to a user.
名前：DisplayName NameSpace：DAV：目的：ユーザーへのプレゼンテーションに適したリソースの名前を提供します。説明：DisplayNameプロパティは、すべてのDAV準拠リソースで定義する必要があります。存在する場合、プロパティには、ユーザーへのプレゼンテーションに適したリソースの説明が含まれています。
<!ELEMENT displayname (#PCDATA) >
Name: getcontentlanguage Namespace: DAV: Purpose: Contains the Content-Language header returned by a GET without accept headers Description: The getcontentlanguage property MUST be defined on any DAV compliant resource that returns the Content-Language header on a GET. Value: language-tag ;language-tag is defined in section 14.13 of [RFC2068]
名前：GetContentLanguage NameSpace：DAV：目的：GET Accept Headersによって返されるコンテンツランガージヘッダーが含まれています。値：言語タグ;言語タグは[RFC2068]のセクション14.13で定義されています
<!ELEMENT getcontentlanguage (#PCDATA) >
Name: getcontentlength Namespace: DAV: Purpose: Contains the Content-Length header returned by a GET without accept headers. Description: The getcontentlength property MUST be defined on any DAV compliant resource that returns the Content-Length header in response to a GET.
名前：GetContentLength NameSpace：DAV：目的：Accept HeaderなしでGETによって返されるコンテンツ長ヘッダーが含まれます。説明：GetContentLengthプロパティは、GETに応じてコンテンツレングスヘッダーを返すDAV準拠のリソースで定義する必要があります。
Value: content-length ; see section 14.14 of [RFC2068]
値：コンテンツレングス;[RFC2068]のセクション14.14を参照してください
<!ELEMENT getcontentlength (#PCDATA) >
Name: getcontenttype Namespace: DAV: Purpose: Contains the Content-Type header returned by a GET without accept headers. Description: This getcontenttype property MUST be defined on any DAV compliant resource that returns the Content-Type header in response to a GET. Value: media-type ; defined in section 3.7 of [RFC2068]
名前：getContentType namespace：dav：目的：accept acceptヘッダーなしで返されるコンテンツタイプのヘッダーが含まれます。説明：このgetContentTypeプロパティは、GETに応じてコンテンツタイプのヘッダーを返すDAV準拠のリソースで定義する必要があります。値：メディアタイプ。[RFC2068]のセクション3.7で定義されています
<!ELEMENT getcontenttype (#PCDATA) >
Name: getetag Namespace: DAV: Purpose: Contains the ETag header returned by a GET without accept headers. Description: The getetag property MUST be defined on any DAV compliant resource that returns the Etag header. Value: entity-tag ; defined in section 3.11 of [RFC2068]
名前：GetEtag NameSpace：DAV：目的：Get Accept Headerによって返されるETAGヘッダーが含まれています。説明：getETAGプロパティは、ETAGヘッダーを返すDAV準拠のリソースで定義する必要があります。値：Entity-Tag;[RFC2068]のセクション3.11で定義されています
<!ELEMENT getetag (#PCDATA) >
Name: getlastmodified Namespace: DAV: Purpose: Contains the Last-Modified header returned by a GET method without accept headers. Description: Note that the last-modified date on a resource may reflect changes in any part of the state of the resource, not necessarily just a change to the response to the GET method. For example, a change in a property may cause the last-modified date to change. The getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET. Value: HTTP-date ; defined in section 3.3.1 of [RFC2068]
名前：GetLastModified NameSpace：DAV：目的：受け入れヘッダーなしでGETメソッドによって返される永続修正ヘッダーが含まれます。説明：リソース上の最後の修正日は、リソースの状態のどの部分の変更を反映している可能性があることに注意してください。必ずしもGETメソッドへの応答に対する変更だけではありません。たとえば、プロパティの変更により、ラスト修正日が変更される場合があります。getLastModifiedプロパティは、GETに応じてラスト修飾ヘッダーを返すDAV準拠のリソースで定義する必要があります。値：http-date;[RFC2068]のセクション3.3.1で定義されています
<!ELEMENT getlastmodified (#PCDATA) >
Name: lockdiscovery Namespace: DAV: Purpose: Describes the active locks on a resource Description: The lockdiscovery property returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. The server is free to withhold any or all of this information if the requesting principal does not have sufficient access rights to see the requested data.
名前：Lock -Discovery NameSpace：DAV：目的：リソースのアクティブロックを説明する説明：Lock -Discoveryプロパティは、誰がロックを持っているか、ロックの種類、タイムアウトタイプとタイムアウトの残りの時間、および関連するロックトークン。リクエストプリンシパルが要求されたデータを見るのに十分なアクセス権を持っていない場合、サーバーはこの情報のいずれかまたはすべてを源泉徴収できます。
<!ELEMENT lockdiscovery (activelock)* >
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D='DAV:'>
<D:prop><D:lockdiscovery/></D:prop>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:href>http://www.foo.bar/container/</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
This resource has a single exclusive write lock on it, with an infinite timeout.
このリソースには、無限のタイムアウトを備えた単一の排他的な書き込みロックがあります。
Name: resourcetype Namespace: DAV: Purpose: Specifies the nature of the resource. Description: The resourcetype property MUST be defined on all DAV compliant resources. The default value is empty.
名前：ResourceType名空間：DAV：目的：リソースの性質を指定します。説明：ResourceTypeプロパティは、すべてのDAV準拠リソースで定義する必要があります。デフォルト値は空です。
<!ELEMENT resourcetype ANY >
Name: source Namespace: DAV: Purpose: The destination of the source link identifies the resource that contains the unprocessed source of the link's source. Description: The source of the link (src) is typically the URI of the output resource on which the link is defined, and there is typically only one destination (dst) of the link, which is the URI where the unprocessed source of the resource may be accessed. When more than one link destination exists, this specification asserts no policy on ordering.
名前：ソースネームスペース：DAV：目的：ソースリンクの宛先は、リンクのソースの未処理のソースを含むリソースを識別します。説明：リンクのソース（SRC）は通常、リンクが定義されている出力リソースのURIであり、通常、リンクの1つの宛先（DST）のみがあります。アクセスされる場合があります。複数のリンク宛先が存在する場合、この仕様は注文に関するポリシーを主張しません。
<!ELEMENT source (link)* >
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
<D:source>
<D:link>
<F:projfiles>Source</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.c</D:dst>
</D:link>
<D:link>
<F:projfiles>Library</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.lib</D:dst>
</D:link>
<D:link>
<F:projfiles>Makefile</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/makefile</D:dst>
</D:link>
</D:source>
</D:prop>
In this example the resource http://foo.bar/program has a source property that contains three links. Each link contains three elements, two of which, src and dst, are part of the DAV schema defined in this document, and one which is defined by the schema http://www.foocorp.com/project/ (Source, Library, and Makefile). A client which only implements the elements in the DAV spec will not understand the foocorp elements and will ignore them, thus seeing the expected source and destination links. An enhanced client may know about the foocorp elements and be able to present the user with additional information about the links. This example demonstrates the power of XML markup, allowing element values to be enhanced without breaking older clients.
この例では、リソースhttp://foo.bar/programには、3つのリンクを含むソースプロパティがあります。各リンクには3つの要素が含まれており、そのうち2つ、SRCとDSTはこのドキュメントで定義されているDAVスキーマの一部であり、1つはスキーマhttp://www.foocorp.com/project/（ソース、ライブラリ、ライブラリ、とmakefile）。DAV仕様の要素のみを実装するクライアントは、Foocorp要素を理解せず、それらを無視し、予想されるソースと宛先のリンクが表示されます。強化されたクライアントは、Foocorp要素について知っている場合があり、リンクに関する追加情報をユーザーに提示できる場合があります。この例は、XMLマークアップのパワーを示しており、高齢のクライアントを壊すことなく要素値を強化することができます。
Name: supportedlock Namespace: DAV: Purpose: To provide a listing of the lock capabilities supported by the resource. Description: The supportedlock property of a resource returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls so a server is not required to provide information the client is not authorized to see.
名前：supportedlock namespace：dav：目的：リソースがサポートするロック機能のリストを提供します。説明：リソースのsupportedlockプロパティは、リソースのロック要求で指定される可能性のあるスコープとアクセスタイプの組み合わせのリストを返します。実際のコンテンツ自体はアクセス制御によって制御されているため、サーバーはクライアントが確認する権限を与えられていない情報を提供する必要はありません。
<!ELEMENT supportedlock (lockentry)* >
>>Request
>>リクエスト
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop><D:supportedlock/></D:prop>
</D:propfind>
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foo.bar/container/</D:href>
<D:propstat>
<D:prop>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
14 Instructions for Processing XML in DAV
DAVでXMLを処理する14の指示
All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language.
すべてのDAVに準拠したリソースは、XMLをコマンド言語として使用するDAVメソッドを処理する際に、未知のXML要素を無視する必要があります。
This restriction also applies to the processing, by clients, of DAV property values where unknown XML elements SHOULD be ignored unless the property's schema declares otherwise.
この制限は、プロパティのスキーマが別の方法で宣言しない限り、不明なXML要素を無視する必要があるDAVプロパティ値の処理にも適用されます。
This restriction does not apply to setting dead DAV properties on the server where the server MUST record unknown XML elements.
この制限は、サーバーが不明なXML要素を記録する必要があるサーバー上のDead DAVプロパティの設定には適用されません。
Additionally, this restriction does not apply to the use of XML where XML happens to be the content type of the entity body, for example, when used as the body of a PUT.
さらに、この制限はXMLの使用には適用されません。たとえば、XMLはたまたまエンティティボディのコンテンツタイプです。たとえば、Putの本体として使用する場合です。
Since XML can be transported as text/xml or application/xml, a DAV server MUST accept DAV method requests with XML parameters transported as either text/xml or application/xml, and DAV client MUST accept XML responses using either text/xml or application/xml.
XMLはText/XMLまたはApplication/XMLとして輸送できるため、DAVサーバーは、Text/XMLまたはApplication/XMLとして輸送されるXMLパラメーターを使用してDAVメソッドリクエストを受け入れる必要があり、DAVクライアントはテキスト/XMLまたはアプリケーションのいずれかを使用してXML応答を受け入れる必要があります。/xml。
15 DAV Compliance Classes
15 DAVコンプライアンスクラス
A DAV compliant resource can choose from two classes of compliance. A client can discover the compliance classes of a resource by executing OPTIONS on the resource, and examining the "DAV" header which is returned.
DAVに準拠したリソースは、2つのクラスのコンプライアンスから選択できます。クライアントは、リソース上のオプションを実行し、返される「DAV」ヘッダーを調べることにより、リソースのコンプライアンスクラスを発見できます。
Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV compliant resources, clients, and proxies MUST be compliant with [RFC2068].
このドキュメントはHTTP/1.1プロトコルへの拡張を説明しているため、すべてのDAVに準拠したすべてのリソース、クライアント、およびプロキシは[RFC2068]に準拠する必要があります。
Compliance classes are not necessarily sequential. A resource that is class 2 compliant must also be class 1 compliant; but if additional compliance classes are defined later, a resource that is class 1, 2, and 4 compliant might not be class 3 compliant. Also note that identifiers other than numbers may be used as compliance class identifiers.
コンプライアンスクラスは必ずしも順次ではありません。クラス2に準拠したリソースは、クラス1に準拠している必要があります。ただし、後で追加のコンプライアンスクラスが定義されている場合、クラス1、2、および4コンプライアントのリソースは、クラス3に準拠していない場合があります。また、番号以外の識別子は、コンプライアンスクラス識別子として使用される場合があることに注意してください。
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document.
クラス1に準拠したリソースは、このドキュメントのすべてのセクションですべての「必須」要件を満たす必要があります。
Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
クラス1準拠のリソースは、Optionsメソッドへのすべての応答に関するDAVヘッダーの値「1」を少なくとも返す必要があります。
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the supportedlock property, the lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class "2" compliant resource SHOULD also support the Time-Out request header and the owner XML element.
クラス2準拠のリソースは、すべてのクラス1の要件を満たし、ロック方法、supportedLockプロパティ、Lock-Discoveryプロパティ、タイムアウト応答ヘッダー、ロックトークンリクエストヘッダーをサポートする必要があります。クラス「2」準拠リソースは、タイムアウトリクエストヘッダーと所有者XML要素もサポートする必要があります。
Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
クラス2準拠のリソースは、Optionsメソッドへのすべての応答について、DAVヘッダーの値「1」と「2」を少なくとも返す必要があります。
16 Internationalization Considerations
16国際化に関する考慮事項
In the realm of internationalization, this specification complies with the IETF Character Set Policy [RFC2277]. In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header, as defined in [RFC2376], as well as the XML "encoding" attribute, which together provide charset identification information for MIME and XML processors.
国際化の領域では、この仕様はIETF文字セットポリシー[RFC2277]に準拠しています。この仕様では、人間の読み取り可能なフィールドは、プロパティの値のいずれか、または応答エンティティ本体で返されるエラーメッセージのいずれかにあります。どちらの場合も、人間の読み取り可能なコンテンツはXMLを使用してエンコードされます。XMLは、文字セットのタグ付けとエンコードの明示的な規定があり、XMLプロセッサがUTF-8 [UTF-8]エンコードを使用して少なくともエンコードされたXML要素を読み取る必要があります。ISO 10646多言語平面。この仕様のXMLの例は、[RFC2376]で定義されているコンテンツタイプのヘッダーのcharsetパラメーターの使用と、MIMEおよびXMLプロセッサの憲章識別情報を一緒に提供するXML「エンコード」属性の使用を示しています。
XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. XML uses either IANA registered language tags (see [RFC1766]) or ISO 639 language tags [ISO-639] in the "xml:lang" attribute of an XML element to identify the language of its content and attributes.
XMLは、特定のXML要素の内容の言語を指定するための言語タグ付け機能も提供します。XMLは、IANA登録言語タグ（[RFC1766]を参照）またはISO 639言語タグ[ISO-639]を「XML：Lang」属性のいずれかを使用して、その内容と属性の言語を識別します。
WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" [RFC2376] for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header.
WebDAVアプリケーションは、XML仕様の文字セットのタグ付け、文字セットエンコード、および言語タグ機能をサポートする必要があります。WebDAVアプリケーションの実装者は、XMLトランスポートに使用するMIMEメディアタイプ、およびコンテンツタイプのヘッダーのcharsetパラメーターの使用について、「XMLメディアタイプ」[RFC2376]を読むことを強くお勧めします。
Names used within this specification fall into three categories: names of protocol elements such as methods and headers, names of XML elements, and names of properties. Naming of protocol elements follows the precedent of HTTP, using English names encoded in USASCII for methods and headers. Since these protocol elements are not visible to users, and are in fact simply long token identifiers, they do not need to support encoding in multiple character sets. Similarly, though the names of XML elements used in this specification are English names encoded in UTF-8, these names are not visible to the user, and hence do not need to support multiple character set encodings.
この仕様内で使用される名前は、メソッドとヘッダーなどのプロトコル要素の名前、XML要素の名前、プロパティの名前の3つのカテゴリに分類されます。プロトコル要素の命名は、HTTPの先例に従い、メソッドとヘッダーのUSASCIIでエンコードされた英語名を使用します。これらのプロトコル要素はユーザーには見えず、実際には単に長いトークン識別子であるため、複数の文字セットでのエンコードをサポートする必要はありません。同様に、この仕様で使用されるXML要素の名前はUTF-8でエンコードされている英語名ですが、これらの名前はユーザーには表示されないため、複数の文字セットエンコーディングをサポートする必要はありません。
The name of a property defined on a resource is a URI. Although some applications (e.g., a generic property viewer) will display property URIs directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name URI to a human-readable field when displaying the property name to a user. It is only in the case where
リソースで定義されているプロパティの名前はURIです。一部のアプリケーション（一般的なプロパティビューアなど）は、プロパティURIをユーザーに直接表示しますが、一般的なアプリケーションは固定プロパティセットを使用し、プロパティ名URIから人間の読み取り可能なマッピングを提供することが期待されています。フィールドユーザーにプロパティ名を表示するとき。それは場合にのみです
the set of properties is not known ahead of time that an application need display a property name URI to a user. We recommend that applications provide human-readable property names wherever feasible.
プロパティのセットは、アプリケーションがユーザーにプロパティ名URIを表示する必要があることを事前に知られていません。アプリケーションは、実行可能な場所に人間の読み取り可能なプロパティ名を提供することをお勧めします。
For error reporting, we follow the convention of HTTP/1.1 status codes, including with each status code a short, English description of the code (e.g., 423 (Locked)). While the possibility exists that a poorly crafted user agent would display this message to a user, internationalized applications will ignore this message, and display an appropriate message in the user's language and character set.
エラーレポートの場合、各ステータスコードを含むHTTP/1.1ステータスコードの慣習に従って、コードの短い英語の説明（423（ロック）など）を含みます。作成されていないユーザーエージェントがこのメッセージをユーザーに表示する可能性は存在しますが、国際化されたアプリケーションはこのメッセージを無視し、ユーザーの言語とキャラクターセットに適切なメッセージを表示します。
Since interoperation of clients and servers does not require locale information, this specification does not specify any mechanism for transmission of this information.
クライアントとサーバーの相互操作はロケール情報を必要としないため、この仕様ではこの情報の送信のメカニズムは指定されていません。
17 Security Considerations
17セキュリティ上の考慮事項
This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware.
このセクションは、WebDAVアプリケーションが認識する必要があるセキュリティへの影響に関する詳細な問題について提供されています。
All of the security considerations of HTTP/1.1 (discussed in [RFC2068]) and XML (discussed in [RFC2376]) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.
HTTP/1.1（[RFC2068]で説明）およびXML（[RFC2376]で説明）のセキュリティに関するすべての考慮事項もWebDavに適用されます。さらに、リモートオーサリングに固有のセキュリティリスクは、より強力な認証テクノロジーを必要とし、いくつかの新しいプライバシーの懸念を導入し、サーバーの設計が不十分であるための危険性を高める可能性があります。これらの問題については、以下に詳しく説明しています。
Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication.
オーサリングに重点を置いているため、WebDAVサーバーは認証テクノロジーを使用して、ネットワークリソースへのアクセスだけでなく、リソースの整合性も保護する必要があります。さらに、ロック機能の導入には、認証をサポートする必要があります。
A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to authenticate a WebDAV client to a server unless the connection is secure. Furthermore, a WebDAV server MUST NOT send Basic authentication credentials in a WWW-Authenticate header unless the connection is secure. Examples of secure connections include a Transport Layer Security (TLS) connection employing a strong cipher suite with mutual authentication of client and server, or a connection over a network which is physically secure, for example, an isolated network in a building with restricted access.
不安定なチャネルでクリアで送信されたパスワードは、パスワードが傍受されるため、リソースのアクセシビリティと整合性を保護するための不十分な手段です。HTTP/1.1の基本認証は、パスワードの本質的にクリアなテキスト送信を実行するため、接続が安全でない限り、WebDavクライアントをサーバーに認証するために基本認証を使用してはなりません。さらに、WebDAVサーバーは、接続が安全でない限り、www-authenticateヘッダーに基本認証資格情報を送信してはなりません。安全な接続の例には、クライアントとサーバーの相互認証を備えた強力な暗号スイートを採用するトランスポートレイヤーセキュリティ（TLS）接続、またはアクセスが制限された建物内の孤立したネットワークなど、物理的に安全なネットワーク上の接続が含まれます。
WebDAV applications MUST support the Digest authentication scheme [RFC2069]. Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication which is useful in a wide range of scenarios.
WebDAVアプリケーションは、ダイジェスト認証スキーム[RFC2069]をサポートする必要があります。ダイジェスト認証は、通信の両当事者が共有された秘密、パスワードを知っていることを確認するため、明確な秘密を明確にすることなく、ダイジェスト認証は基本認証に固有のセキュリティ問題を回避しながら、広範囲に役立つ認証レベルを提供します。シナリオの範囲。
Denial of service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial of service attacks on every part of a system's resources.
サービス拒否攻撃は、WebDavサーバーにとって特別な懸念事項です。WebDav Plus HTTPは、システムのリソースのすべての部分でサービス拒否攻撃を可能にします。
The underlying storage can be attacked by PUTting extremely large files.
基礎となるストレージは、非常に大きなファイルを配置することで攻撃できます。
Asking for recursive operations on large collections can attack processing time.
大規模なコレクションで再帰的な操作を求めることは、処理時間を攻撃する可能性があります。
Making multiple pipelined requests on multiple connections can attack network connections.
複数の接続で複数のパイプラインリクエストを作成すると、ネットワーク接続を攻撃できます。
WebDAV servers need to be aware of the possibility of a denial of service attack at all levels.
WebDAVサーバーは、あらゆるレベルでのサービス攻撃の拒否の可能性を認識する必要があります。
WebDAV provides, through the PROPFIND method, a mechanism for listing the member resources of a collection. This greatly diminishes the effectiveness of security or privacy techniques that rely only on the difficulty of discovering the names of network resources. Users of WebDAV servers are encouraged to use access control techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.
WebDavは、Propfindメソッドを通じて、コレクションのメンバーリソースをリストするメカニズムを提供します。これにより、ネットワークリソースの名前を発見することの難しさにのみ依存するセキュリティまたはプライバシーテクニックの有効性が大幅に低下します。WebDAVサーバーのユーザーは、アクセス制御手法を使用して、リソース名の相対的な不明瞭さに依存するのではなく、リソースへの不要なアクセスを防ぐことをお勧めします。
When submitting a lock request a user agent may also submit an owner XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a lockdiscovery property on the resource, and can be used by other collaborators to begin negotiation over access to the resource. However, in many cases this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the lockdiscovery property as appropriate. Furthermore, user agents
ロックリクエストを送信する場合、ユーザーエージェントは、ロックを取り出した人の連絡先情報を提供する所有者XMLフィールドを提出することもできます（ロボットではなく、ロックを取り除いている場合）。この連絡先情報は、リソース上のロックディスコーブリープロパティに保存され、他の協力者がリソースへのアクセスをめぐる交渉を開始することができます。ただし、多くの場合、この連絡先情報は非常にプライベートである可能性があり、広く普及してはなりません。サーバーは、必要に応じて、ロックディスコービリプロパティへの読み取りアクセスを制限する必要があります。さらに、ユーザーエージェント
SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
連絡先情報がまったく送信されているかどうか、および連絡先情報が送信された場合、送信される情報を正確に制御する必要があります。
Since property values are typically used to hold information such as the author of a document, there is the possibility that privacy concerns could arise stemming from widespread access to a resource's property data. To reduce the risk of inadvertent release of private information via properties, servers are encouraged to develop access control mechanisms that separate read access to the resource body and read access to the resource's properties. This allows a user to control the dissemination of their property data without overly restricting access to the resource's contents.
プロパティ値は通常、ドキュメントの著者などの情報を保持するために使用されるため、プライバシーの懸念がリソースのプロパティデータへの広範なアクセスに起因する可能性があります。プロパティを介して個人情報の不注意なリリースのリスクを減らすために、サーバーは、リソースボディへの読み取りアクセスを分離し、リソースのプロパティへのアクセスを読み取るアクセス制御メカニズムを開発することをお勧めします。これにより、ユーザーはリソースのコンテンツへのアクセスを過度に制限することなく、プロパティデータの普及を制御できます。
HTTP/1.1 warns against providing read access to script code because it may contain sensitive information. Yet WebDAV, via its source link facility, can potentially provide a URI for script resources so they may be authored. For HTTP/1.1, a server could reasonably prevent access to source resources due to the predominance of read-only access. WebDAV, with its emphasis on authoring, encourages read and write access to source resources, and provides the source link facility to identify the source. This reduces the security benefits of eliminating access to source resources. Users and administrators of WebDAV servers should be very cautious when allowing remote authoring of scripts, limiting read and write access to the source resources to authorized principals.
HTTP/1.1は、機密情報が含まれている可能性があるため、スクリプトコードへの読み取りアクセスを提供することに対して警告します。しかし、WebDavは、そのソースリンク機能を介して、スクリプトリソースにURIを提供する可能性があるため、作成される可能性があります。HTTP/1.1の場合、サーバーは、読み取り専用アクセスが優勢であるため、ソースリソースへのアクセスを合理的に防止できます。WebDavは、オーサリングに重点を置いて、ソースリソースへの読み取りおよび書き込みアクセスを奨励し、ソースリンク機能を提供してソースを識別します。これにより、ソースリソースへのアクセスを排除するセキュリティメリットが減ります。WebDAVサーバーのユーザーと管理者は、スクリプトのリモートオーサリングを許可する場合、ソースリソースへの読み取りおよび書き込みアクセスを認可されたプリンシパルに制限する場合、非常に慎重です。
XML supports a facility known as "external entities", defined in section 4.2.2 of [REC-XML], which instruct an XML processor to retrieve and perform an inline include of XML located at a particular URI. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non-validating XML, such as the XML used in this specification, including an external XML entity is not required by [REC-XML]. However, [REC-XML] does state that an XML processor may, at its discretion, include the external XML entity.
XMLは、[Rec-XML]のセクション4.2.2で定義されている「外部エンティティ」と呼ばれる施設をサポートしています。これは、XMLプロセッサに特定のURIにあるXMLのインラインを取得および実行するよう指示します。外部XMLエンティティを使用して、XMLドキュメントに関連付けられたドキュメントタイプ宣言（DTD）を追加または変更できます。外部XMLエンティティを使用して、XMLドキュメントのコンテンツ内にXMLを含めることもできます。この仕様で使用されるXMLなど、外部XMLエンティティを含む非検証XMLの場合、[Rec-XML]では必要ありません。ただし、[Rec-XML]は、XMLプロセッサには、その裁量により、外部XMLエンティティが含まれる可能性があると述べています。
External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst
外部XMLエンティティには固有の信頼性がなく、HTTP Getリクエストに固有のすべての攻撃の対象となります。さらに、外部XMLエンティティがDTDを変更し、したがって最悪の場合、XMLドキュメントの最終形式に影響を与える可能性があります。
case significantly modifying its semantics, or exposing the XML processor to the security risks discussed in [RFC2376]. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy.
ケースは、そのセマンティクスを大幅に変更するか、XMLプロセッサを[RFC2376]で説明したセキュリティリスクにさらします。したがって、実装者は、外部のXMLエンティティを信頼できないと扱う必要があることに注意する必要があります。
There is also the scalability risk that would accompany a widely deployed application which made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any server which fields requests for the resource containing the external XML entity.
また、外部XMLエンティティを使用した広く展開されたアプリケーションに伴うスケーラビリティリスクもあります。この状況では、1つの外部XMLエンティティに対してかなりの数の要求があり、外部XMLエンティティを含むリソースのリクエストをフィールドにリクエストするサーバーを過負荷にする可能性があります。
This specification, in section 6.4, requires the use of Universal Unique Identifiers (UUIDs) for lock tokens, in order to guarantee their uniqueness across space and time. UUIDs, as defined in [ISO-11578], contain a "node" field which "consists of the IEEE address, usually the host address. For systems with multiple IEEE 802 nodes, any available node address can be used." Since a WebDAV server will issue many locks over its lifetime, the implication is that it will also be publicly exposing its IEEE 802 address.
セクション6.4のこの仕様では、空間と時間を超えてそれらの独自性を保証するために、ロックトークンにユニバーサルユニークな識別子（UUID）を使用する必要があります。[ISO-11578]で定義されているUUIDSには、「IEEEアドレス、通常はホストアドレスで構成される「ノード」フィールドが含まれています。複数のIEEE 802ノードを持つシステムの場合、利用可能なノードアドレスを使用できます。」WebDavサーバーは寿命にわたって多くのロックを発行するため、IEEE 802アドレスを公開することも意味します。
There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:
IEEE 802アドレスの露出に関連するいくつかのリスクがあります。IEEE 802アドレスの使用：
* It is possible to track the movement of hardware from subnet to subnet.
* サブネットからサブネットへのハードウェアの動きを追跡することができます。
* It may be possible to identify the manufacturer of the hardware running a WebDAV server.
* WebDavサーバーを実行しているハードウェアのメーカーを識別することが可能かもしれません。
* It may be possible to determine the number of each type of computer running WebDAV.
* WebDavを実行している各タイプのコンピューターの数を決定することが可能かもしれません。
Section 6.4.1 of this specification details an alternate mechanism for generating the "node" field of a UUID without using an IEEE 802 address, which alleviates the risks associated with exposure of IEEE 802 addresses by using an alternate source of uniqueness.
この仕様のセクション6.4.1は、IEEE 802アドレスを使用せずにUUIDの「ノード」フィールドを生成するための代替メカニズムを詳述しています。これは、独自性の代替ソースを使用してIEEE 802アドレスの露出に関連するリスクを軽減します。
18 IANA Considerations
18 IANAの考慮事項
This document defines two namespaces, the namespace of property names, and the namespace of WebDAV-specific XML elements used within property values.
このドキュメントでは、プロパティ名の名前空間、プロパティ値内で使用されるWebDAV固有のXML要素の名前空間を2つの名前空間に定義します。
URIs are used for both names, for several reasons. Assignment of a URI does not require a request to a central naming authority, and hence allow WebDAV property names and XML elements to be quickly defined by any WebDAV user or application. URIs also provide a unique address space, ensuring that the distributed users of WebDAV will not have collisions among the property names and XML elements they create.
URIは、いくつかの理由で、両方の名前に使用されます。URIの割り当てでは、中央の命名当局への要求は必要ありません。したがって、WebDAVプロパティ名とXML要素をWebDAVユーザーまたはアプリケーションによって迅速に定義できるようにします。また、URISはユニークなアドレススペースを提供し、WebDavの分散ユーザーが、作成したプロパティ名とXML要素の間に衝突しないようにします。
This specification defines a distinguished set of property names and XML elements that are understood by all WebDAV applications. The property names and XML elements in this specification are all derived from the base URI DAV: by adding a suffix to this URI, for example, DAV:creationdate for the "creationdate" property.
この仕様では、すべてのWebDAVアプリケーションで理解されるプロパティ名の著名なセットとXML要素を定義します。この仕様のプロパティ名とXML要素はすべて、ベースURI DAVから派生しています。このURIに接尾辞を追加することにより、たとえば、DAV：「creationdate」プロパティのcreationdateです。
This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in section 6.4.
この仕様では、セクション6.4で説明されているオパレロックトークンURIスキームであるロックトークンのエンコードのURIスキームも定義しています。
To ensure correct interoperation based on this specification, IANA must reserve the URI namespaces starting with "DAV:" and with "opaquelocktoken:" for use by this specification, its revisions, and related WebDAV specifications.
この仕様に基づいて正しい相互操作を確保するために、IANAは「DAV：」と「OpaquelockToken：」から始まるURIネームスペースを予約する必要があります。
19 Intellectual Property
19知的財産
The following notice is copied from RFC 2026 [RFC2026], section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document.
次の通知は、RFC 2026 [RFC2026]、セクション10.4からコピーされ、この文書に対して行われた知的財産請求に関するIETFの位置について説明します。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、この文書に記載されている他のテクノロジーまたはそのような権利に基づくライセンスが利用可能である可能性がある範囲で、実装に関連する、またはその他の技術を使用すると主張される可能性のある知的財産またはその他の権利の有効性または範囲に関して立場を取得しません。;それは、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。公開のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実施者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するように勧めています。情報をIETFエグゼクティブディレクターに宛ててください。
20 Acknowledgements
20の謝辞
A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work.
このような仕様は、批判的なレビューを刺激し、無関心な無視から枯れていることに繁栄しています。著者は、私たちの仕事のあらゆる段階で洞察が非常に価値がある次の人々の貢献に感謝しています。
Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
テリー・アレン、ハラルド・アルベスランド、ジム・アムスデン、ベッキー・アンダーソン、アラン・バビッチ、サンフォード・バー、ディラン・バレル、バーナード・チェスター、ティム・バーナーズ・リー、ダン・コノリー、ジム・カニンガム、ロン・ダニエル、ジュニア、ジム・デイビス、キース・ドーソン、マーク・デイ、ブライアン・ディーン、マーティン・ドゥースト、デビッド・デュランド、リー・ファレル、チャック・フェイ、ウェスリー・フェルター、ロイ・フィールディング、マーク・フィッシャー、アラン・フライアー、ジョージ・フィレンツィーン、ジム・ゲッティズ、フィル・ハラム・ベーカー、デニス・ハミルトン、スティーブ・ヘニング、ミード・ヒメルシュタイン、アレックス・ホップマン、アンドレ・ファン・デル・ホーク、ベン・ローリー、ポール・リーチ、オラ・ラシラ、カレン・マッカーサー、スティーブン・マーティン、ラリー・マスインター、マイケル・ミールリング、キース・ムーア、トーマス・ナルテン、ヘンリック・ニールセン、ケンジ・オタ、ボブ・パーカー、グレン・ピーターソン、ジョン・ラドフ、セーブ・レディー、ヘンリー・サンダース、クリストファー・セイワルド、ジュディス・スリーイン、マイク・スプレッツァー、エイナー・ステフェルード、グレッグ・スタイン、ラルフ・スウィック、ケンジ・タカハシ、リチャード・N・テイラー、ロバート・タウ、ジョン・ターナー、サンカール・ヴァルハグリスワラン、ファビオ・ヴィタリ、グレゴリー・ウッドハウス、ラウレン・ウォッド。
Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable, both in helping the formation of the working group and in patiently coaching the authors along the way. In so many ways he has set high standards we have toiled to meet. The contributions of Judith Slein in clarifying the requirements, and in patiently reviewing draft after draft, both improved this specification and expanded our minds on document management.
このリストの2人は特別な言及に値します。Larry Masinterの貢献は、ワーキンググループの形成を支援することと、途中で著者を辛抱強く指導することの両方において、非常に貴重でした。非常に多くの点で、彼は高い基準を設定しています。要件を明確にし、ドラフト後のドラフトを辛抱強くレビューする際のジュディススリーンの貢献は、この仕様を改善し、ドキュメント管理に関する心を拡大しました。
We would also like to thank John Turner for developing the XML DTD.
また、XML DTDを開発してくれたJohn Turnerに感謝します。
21 References
21参照
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web Consortium Recommendation REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
[Rec-XML] T. Bray、J。Paoli、C。M。Sperberg-Mcqueen、「拡張可能なマークアップ言語（XML）」。World Wide Web Consortiumの推奨REC-XML-1980210。http://www.w3.org/tr/1998/rec-xml-19980210。
[REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
XML". World Wide Web Consortium Recommendation REC-
xml-names-19990114. http://www.w3.org/TR/1999/REC-
xml-names-19990114/
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P, Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.
[RFC2069] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Leach、P、Luotonen、A.、Sink、E。and L. Stewart、「HTTPの拡張：消化アクセス認証」、RFC2069年、1997年1月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2068、1997年1月。
[ISO-639] ISO (International Organization for Standardization). ISO 639:1988. "Code for the representation of names of languages."
[ISO-639] ISO（国際標準化機関）。ISO 639：1988。「言語名の表現のためのコード。」
[ISO-8601] ISO (International Organization for Standardization). ISO 8601:1988. "Data elements and interchange formats - Information interchange - Representation of dates and times."
[ISO-8601] ISO（国際標準化機関）。ISO 8601：1988。「データ要素と交換形式 - 情報交換 - 日付と時間の表現。」
[ISO-11578] ISO (International Organization for Standardization). ISO/IEC 11578:1996. "Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)"
[ISO-11578] ISO（国際標準化機関）。ISO/IEC 11578：1996。「情報技術 - オープンシステムの相互接続 - リモートプロシージャコール（RPC）」
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141] Moats、R。、「Urn Syntax」、RFC 2141、1997年5月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, January 1998.
[UTF-8] Yergeau、F。、「UTF-8、UnicodeおよびISO 10646の変換形式」、RFC 2279、1998年1月。
[RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス-Revision 3」、BCP 9、RFC 2026、1996年10月。
[RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic Records", RFC 1807, June 1995.
[RFC1807] Lasher、R。およびD. Cohen、「書誌記録の形式」、RFC 1807、1995年6月。
[WF] C. Lagoze, "The Warwick Framework: A Container
Architecture for Diverse Sets of Metadata", D-Lib
Magazine, July/August 1996.
http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
[USMARC] Network Development and MARC Standards, Office, ed. 1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC: Cataloging Distribution Service, Library of Congress.
[USMARC]ネットワーク開発とMARC Standards、Office、ed。1994.「書誌データのUSMARC形式」、1994。ワシントンDC：カタログ配信サービス、議会図書館。
[REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS Label Distribution Label Syntax and Communication Protocols" Version 1.1, World Wide Web Consortium Recommendation REC-PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
[Rec-Pics] J. Miller、T。Krauskopf、P。Resnick、W。Treese、「Pics Label Distribution Label Syntax and Communication Protocols」バージョン1.1、World Wide Webコンソーシアムの推奨Rec-Pics-Labels-961031。http://www.w3.org/pub/www/tr/rec-pics-labels-961031.html。
[RFC2291] Slein, J., Vitali, F., Whitehead, E. and D. Durand, "Requirements for Distributed Authoring and Versioning Protocol for the World Wide Web", RFC 2291, February 1998.
[RFC2291] Slein、J.、Vitali、F.、Whitehead、E。、およびD. Durand、「World Wide Webの分散オーサリングとバージョンプロトコルの要件」、RFC 2291、1998年2月。
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core Metadata for Resource Discovery", RFC 2413, September 1998.
[RFC2413] Weibel、S.、Kunze、J.、Lagoze、C。、およびM. Wolf、「リソース発見のためのダブリンコアメタデータ」、RFC 2413、1998年9月。
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.
[RFC2376]ホワイトヘッド、E。およびM.ムラタ、「XMLメディアタイプ」、RFC 2376、1998年7月。
22 Authors' Addresses
22著者の住所
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
EMail: yarong@microsoft.com
E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425
E. J.ホワイトヘッド、Jr。カリフォルニア州情報およびコンピューターサイエンス大学、アーバインアーバイン、CA 92697-3425
EMail: ejw@ics.uci.edu
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043
A. Faizi Netscape 685 East Middlefield Road Mountain View、CA 94043
EMail: asad@netscape.com
S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399
S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 OREM、UT 84097-2399
EMail: srcarter@novell.com
D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399
D.ジェンセンノベル1555 N.テクノロジーウェイM/S ORM F111 OREM、UT 84097-2399
EMail: dcjensen@novell.com
23 Appendices
23付録
This section provides a document type definition, following the rules in [REC-XML], for the XML elements used in the protocol stream and in the values of properties. It collects the element definitions given in sections 12 and 13.
このセクションでは、プロトコルストリームおよびプロパティの値で使用されるXML要素の[REC-XML]のルールに従うドキュメントタイプ定義を提供します。セクション12および13に示されている要素定義を収集します。
<!DOCTYPE webdav-1.0 [
<！doctype webdav-1.0 [
<!--============ XML Elements from Section 12 ==================-->
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?) >
<！要素activelock（lockscope、locktype、depth、owner？、timeout？、locktoken？）>
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT locktype (write) >
<!ELEMENT write EMPTY >
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT exclusive EMPTY >
<!ELEMENT shared EMPTY >
<!ELEMENT depth (#PCDATA) >
<!ELEMENT owner ANY >
<!ELEMENT timeout (#PCDATA) >
<!ELEMENT locktoken (href+) >
<!ELEMENT href (#PCDATA) >
<!ELEMENT link (src+, dst+) >
<!ELEMENT dst (#PCDATA) >
<!ELEMENT src (#PCDATA) >
<!ELEMENT multistatus (response+, responsedescription?) >
<!ELEMENT response (href, ((href*, status)|(propstat+)),
responsedescription?) >
<!ELEMENT status (#PCDATA) >
<!ELEMENT propstat (prop, status, responsedescription?) >
<!ELEMENT responsedescription (#PCDATA) >
<!ELEMENT prop ANY >
<!ELEMENT propertybehavior (omit | keepalive) >
<!ELEMENT omit EMPTY >
<!ELEMENT keepalive (#PCDATA | href+) >
<!ELEMENT propertyupdate (remove | set)+ >
<!ELEMENT remove (prop) >
<!ELEMENT set (prop) >
<!ELEMENT propfind (allprop | propname | prop) >
<!ELEMENT allprop EMPTY >
<!ELEMENT propname EMPTY >
<!ELEMENT collection EMPTY >
<!--=========== Property Elements from Section 13 ===============-->
<!ELEMENT creationdate (#PCDATA) >
<!ELEMENT displayname (#PCDATA) >
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT resourcetype ANY >
<!ELEMENT source (link)* >
<!ELEMENT supportedlock (lockentry)* >
]>
The creationdate property specifies the use of the ISO 8601 date format [ISO-8601]. This section defines a profile of the ISO 8601 date format for use with this specification. This profile is quoted from an Internet-Draft by Chris Newman, and is mentioned here to properly attribute his work.
CreationDateプロパティは、ISO 8601日付形式[ISO-8601]の使用を指定します。このセクションでは、この仕様で使用するISO 8601日付形式のプロファイルを定義します。このプロファイルは、クリス・ニューマンによってインターネットドラフトから引用されており、ここで彼の作品を適切に帰属させるために言及されています。
date-time = full-date "T" full-time
日付時間=フルデート "t"フルタイム
full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset
full-date = date-fulier " - " date-month " - " date-mdayフルタイム=パーティシャルタイムタイムオフセット
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second [time-secfrac]
Partial-Time = Time-hour "：" Time-Minute "：" Time-Second [Time-Secfrac]
Numeric offsets are calculated as local time minus UTC (Coordinated Universal Time). So the equivalent time in UTC can be determined by subtracting the offset from the local time. For example, 18:50:00- 04:00 is the same time as 22:58:00Z.
数値オフセットは、ローカルタイムからUTC（調整されたユニバーサル時間）から計算されます。したがって、UTCの同等の時間は、現地時間からオフセットを差し引くことで決定できます。たとえば、18：50：00-04：00は22：58：00Zと同じ時間です。
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs from an offset of "Z" which implies that UTC is the preferred reference point for the specified time.
UTCの時間がわかっているが、現地時間のオフセットが不明な場合、これは「-00：00」のオフセットで表すことができます。これは、「Z」のオフセットとは異なります。これは、UTCが指定された時間の優先参照ポイントであることを意味します。
XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form <A></A>. The second is to declare an XML element of the form <A/>. The two XML elements are semantically identical.
XMLは、XML要素にコンテンツがないことを示すための2つのメカニズムをサポートしています。1つ目は、フォーム<a> </a>のXML要素を宣言することです。2つ目は、フォーム<a/>のXML要素を宣言することです。2つのXML要素は意味的に同一です。
It is a violation of the XML specification to use the <A></A> form if the associated DTD declares the element to be EMPTY (e.g., <!ELEMENT A EMPTY>). If such a statement is included, then the empty element format, <A/> must be used. If the element is not declared to be EMPTY, then either form <A></A> or <A/> may be used for empty elements.
関連するDTDが要素を空であると宣言した場合、<a> </a>フォームを使用することはXML仕様の違反です（例：<！要素A空き>）。そのようなステートメントが含まれている場合、空の要素形式<a />を使用する必要があります。要素が空であると宣言されていない場合、フォーム<a> </a>または<a/>が空の要素に使用される場合があります。
23.3.2 Notes on Illegal XML Processing
23.3.2 違法なXML処理に関するメモ
XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of white space, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements.
XMLは、合法であるが実際にはそうではないデータを簡単に送信できる柔軟なデータ形式です。「あなたが受け入れるものに柔軟になり、あなたが送るものに厳格になる」という哲学はまだ当てはまりますが、それは不適切に適用してはなりません。XMLは、空白、要素の順序付け、新しい要素の挿入などの問題に対処するのに非常に柔軟です。この柔軟性は、特に要素の意味の領域ではなく、拡張を必要としません。
There is no kindness in accepting illegal combinations of XML elements. At best it will cause an unwanted result and at worst it can cause real damage.
XML要素の違法な組み合わせを受け入れることには優しさはありません。せいぜいそれは望ましくない結果を引き起こし、最悪の場合は本当の損傷を引き起こす可能性があります。
The following request body for a PROPFIND method is illegal.
Propfindメソッドの次の要求本体は違法です。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:propname/>
</D:propfind>
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 Elementの定義は、AllPropまたはPropname要素のみを可能にし、両方ではなく、Propname要素を許可します。したがって、上記はエラーであり、400（悪い要求）で応答する必要があります。
Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop.
しかし、サーバーが「親切」になりたいと思っていて、すべての要素を真の要素として選択して応答することを決めたと想像してください。サーバーがコマンドをAllPropとして扱った場合、プロップ名を実行することを意図した帯域幅の限定行を越えて走っているクライアントは、大きな驚きになります。
Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
さらに、サーバーが寛容でこのリクエストに返信することを決定した場合、結果はサーバーごとにランダムに異なり、一部のサーバーはAllPropディレクティブを実行し、他のサーバーがPropnameディレクティブを実行します。これにより、相互運用性が向上するのではなく、相互運用性が低下します。
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
前の例は、プロップファインド要素に一緒に表示されることを明示的に禁止された2つの要素が含まれていたため、違法でした。ただし、XMLは拡張可能な言語であるため、Propfindで使用するために新しい要素が定義されていると想像できます。以下はPropfindの要求本文であり、前の例と同様に、期限切れのプロップス要素を理解していないサーバーによって400（悪い要求）で拒否される必要があります。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.foo.bar/standards/props/">
<E:expired-props/>
</D:propfind>
To understand why a 400 (Bad Request) is returned let us look at the request body as the server unfamiliar with expired-props sees it.
400（悪いリクエスト）が返される理由を理解するために、期限切れのプロップに不慣れなサーバーがそれを見ているので、リクエスト本体を見てみましょう。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.foo.bar/standards/props/">
</D:propfind>
As the server does not understand the expired-props element, according to the WebDAV-specific XML processing rules specified in section 14, it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal.
サーバーは期限切れのプロップス要素を理解していないため、セクション14で指定されているWebDAV固有のXML処理ルールによれば、無視する必要があります。したがって、サーバーには空の推定が表示されます。これは、Propfind Elementの定義により違法です。
Please note that had the extension been additive it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
拡張機能が加算性であった場合、必ずしも400（悪い要求）になるとは限りませんでした。たとえば、次の要求本体を想像してください。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.foo.bar/standards/props/">
<D:propname/>
<E:leave-out>*boss*</E:leave-out>
</D:propfind>
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with leave-out, the only result would be that the leave-out element would be ignored and a propname would be executed.
前の例には、架空の要素の休暇が含まれています。その目的は、名前が提出されたパターンと一致するプロパティの返品を防ぐことです。前の例が休暇に不慣れなサーバーに送信された場合、唯一の結果は、除外要素が無視され、プロップ名が実行されることです。
All DAV compliant systems MUST support the XML namespace extensions as specified in [REC-XML-NAMES].
すべてのDAV準拠システムは、[rec-xml-names]で指定されているように、XMLネームスペース拡張機能をサポートする必要があります。
[Note to the reader: This section does not appear in [REC-XML-NAMES], but is necessary to avoid ambiguity for WebDAV XML processors.]
[読者への注意：このセクションは[rec-xml-names]には表示されませんが、webdav xmlプロセッサのあいまいさを避けるために必要です。]
WebDAV compliant XML processors MUST interpret a qualified name as a URI constructed by appending the LocalPart to the namespace name URI.
WebDAV準拠のXMLプロセッサは、LocalPartを名前空間名URIに追加することで構築されたURIとして適格な名前を解釈する必要があります。
Example
例
<del:glider xmlns:del="http://www.del.jensen.org/">
<del:glidername>
Johnny Updraft
</del:glidername>
<del:glideraccidents/>
</del:glider>
In this example, the qualified element name "del:glider" is interpreted as the URL "http://www.del.jensen.org/glider".
この例では、適格な要素名「del：glider」は、url「http://www.del.jensen.org/glider」として解釈されます。
<bar:glider xmlns:del="http://www.del.jensen.org/">
<bar:glidername>
Johnny Updraft
</bar:glidername>
<bar:glideraccidents/>
</bar:glider>
Even though this example is syntactically different from the previous example, it is semantically identical. Each instance of the namespace name "bar" is replaced with "http://www.del.jensen.org/" and then appended to the local name for each element tag. The resulting tag names in this example are exactly the same as for the previous example.
この例は前の例と構文的に異なりますが、意味的に同一です。名前空間名「bar」の各インスタンスは、「http://www.del.jensen.org/」に置き換えられ、各要素タグのローカル名に追加されます。この例の結果のタグ名は、前の例とまったく同じです。
<foo:r xmlns:foo="http://www.del.jensen.org/glide">
<foo:rname>
Johnny Updraft
</foo:rname>
<foo:raccidents/>
</foo:r>
This example is semantically identical to the two previous ones. Each instance of the namespace name "foo" is replaced with "http://www.del.jensen.org/glide" which is then appended to the local name for each element tag, the resulting tag names are identical to those in the previous examples.
この例は、以前の2つの例と意味的に同一です。名前空間名「foo」の各インスタンスは、「http://www.del.jensen.org/glide」に置き換えられます。これは、各要素タグのローカル名に追加されます。以前の例。
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明するか、その実装を支援する派生作品は、いかなる種類の制限なしに、準備、コピー、公開、配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準のプロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。