RFC2518 日本語訳
2518 HTTP Extensions for Distributed Authoring -- WEBDAV. Y. Goland,E. Whitehead, A. Faizi, S. Carter, D. Jensen. February 1999. (Format: TXT=202829 bytes) (Obsoleted by RFC4918) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
Golandがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2518年のマイクロソフトカテゴリ: 標準化過程E.ホワイトヘッドUCアーバインA.Faizi Netscape S.カーターノベルD.ジェンセンノベル1999年2月
HTTP Extensions for Distributed Authoring -- WEBDAV
分配されたオーサリングのためのHTTP拡大--WEBDAV
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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への付属の1セットのメソッド、ヘッダー、およびcontent typeを指定します。
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
要約…1 1序論…5 2の記号法のコンベンション…7 3用語…7 4のデータがリソースの特性のためにモデル化されます…8 4.1 リソース特性のモデル…8 4.2 既存のメタデータ提案…8 4.3の特性とHTTPヘッダ…9 4.4 特性の値…9 4.5 特性の名…10 4.6に、メディア無党派はリンクします…10 ウェブリソースの5つの収集…11
Goland, et al. Standards Track [Page 1] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[1ページ]。
5.1 HTTP URL Namespace Model .....................................11
5.2 Collection Resources .........................................11
5.3 Creation and Retrieval of Collection Resources ...............12
5.4 Source Resources and Output Resources ........................13
6 LOCKING .........................................................14
6.1 Exclusive Vs. Shared Locks ...................................14
6.2 Required Support .............................................16
6.3 Lock Tokens ..................................................16
6.4 opaquelocktoken Lock Token URI Scheme ........................16
6.4.1 Node Field Generation Without the IEEE 802 Address ........17
6.5 Lock Capability Discovery ....................................19
6.6 Active Lock Discovery ........................................19
6.7 Usage Considerations .........................................19
7 WRITE LOCK ......................................................20
7.1 Methods Restricted by Write Locks ............................20
7.2 Write Locks and Lock Tokens ..................................20
7.3 Write Locks and Properties ...................................20
7.4 Write Locks and Null Resources ...............................21
7.5 Write Locks and Collections ..................................21
7.6 Write Locks and the If Request Header ........................22
7.6.1 Example - Write Lock ......................................22
7.7 Write Locks and COPY/MOVE ....................................23
7.8 Refreshing Write Locks .......................................23
8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
8.1 PROPFIND .....................................................24
8.1.1 Example - Retrieving Named Properties .....................25
8.1.2 Example - Using allprop to Retrieve All Properties ........26
8.1.3 Example - Using propname to Retrieve all Property Names ...29
8.2 PROPPATCH ....................................................31
8.2.1 Status Codes for use with 207 (Multi-Status) ..............31
8.2.2 Example - PROPPATCH .......................................32
8.3 MKCOL Method .................................................33
8.3.1 Request ...................................................33
8.3.2 Status Codes ..............................................33
8.3.3 Example - MKCOL ...........................................34
8.4 GET, HEAD for Collections ....................................34
8.5 POST for Collections .........................................35
8.6 DELETE .......................................................35
8.6.1 DELETE for Non-Collection Resources .......................35
8.6.2 DELETE for Collections ....................................36
8.7 PUT ..........................................................36
8.7.1 PUT for Non-Collection Resources ..........................36
8.7.2 PUT for Collections .......................................37
8.8 COPY Method ..................................................37
8.8.1 COPY for HTTP/1.1 resources ...............................37
8.8.2 COPY for Properties .......................................38
8.8.3 COPY for Collections ......................................38
8.8.4 COPY and the Overwrite Header .............................39
5.1HTTP URL名前空間モデル…11 5.2 収集リソース…11 収集リソースの5.3作成と検索…12 5.4 ソースリソースと出力リソース…13 6 ロックします…14、6.1、排他的 錠を共有します…14 6.2は支持を要しました…16 6.3 トークンをロックしてください…16 6.4 opaquelocktoken Lock Token URI Scheme…16 6.4 IEEE802アドレスのない.1ノード分野世代…17 6.5 能力発見をロックしてください…19 6.6 活発なロック発見…19 6.7 用法問題…19 7 錠を書いてください…20 制限された7.1のメソッドが錠を書きます…20 7.2 錠とロックトークンを書いてください…20 7.3 錠と特性を書いてください…20 7.4 錠とヌルリソースを書いてください…21 7.5 錠と収集を書いてください…そして、7.6が錠を書く21、要求ヘッダーであるなら…22 7.6 .1 例--錠を書いてください…22 7.7 錠とコピー/移動を書いてください…23 7.8 リフレッシュして、錠を書いてください…23 8 分配されたオーサリングのためのHTTPメソッド…23 8.1PROPFIND…24 8.1 .1 例--検索は特性を命名しました…25 8.1 .2 例--Retrieve All Propertiesにallpropを使用します…26 8.1 .3 例--propnameに、すべてのProperty NamesをRetrieveに使用します…29 8.2PROPPATCH…31 8.2 .1 207が(マルチStatus)であることでの使用のための状態Codes…31 8.2 .2の例--、PROPPATCH…32 8.3 MKCOLメソッド…33 8.3 .1 要求します。33 8.3 .2 状態コード…33 8.3 .3の例--、MKCOL…34 8.4 得てください、そして、収集に向かってください…34 8.5 収集のためのポスト…35 8.6 削除します。35 8.6 .1 非収集リソースのために、削除します。35 8.6 .2 収集のために、削除します。36 8.7 置きます。36 8.7 .1 非収集リソースのために、置きます。36 8.7 .2 収集のために、置きます。37 8.8 メソッドをコピーしてください…37 8.8 HTTP/1.1のリソースのための.1COPY…37 8.8 .2 特性には、コピーしてください…38 8.8 .3 収集には、コピーしてください…38 8.8 .4 コピーと重ね書きヘッダー…39
Goland, et al. Standards Track [Page 2] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[2ページ]。
8.8.5 Status Codes ..............................................39
8.8.6 Example - COPY with Overwrite .............................40
8.8.7 Example - COPY with No Overwrite ..........................40
8.8.8 Example - COPY of a Collection ............................41
8.9 MOVE Method ..................................................42
8.9.1 MOVE for Properties .......................................42
8.9.2 MOVE for Collections ......................................42
8.9.3 MOVE and the Overwrite Header .............................43
8.9.4 Status Codes ..............................................43
8.9.5 Example - MOVE of a Non-Collection ........................44
8.9.6 Example - MOVE of a Collection ............................44
8.10 LOCK Method ..................................................45
8.10.1 Operation .................................................46
8.10.2 The Effect of Locks on Properties and Collections .........46
8.10.3 Locking Replicated Resources ..............................46
8.10.4 Depth and Locking .........................................46
8.10.5 Interaction with other Methods ............................47
8.10.6 Lock Compatibility Table ..................................47
8.10.7 Status Codes ..............................................48
8.10.8 Example - Simple Lock Request .............................48
8.10.9 Example - Refreshing a Write Lock .........................49
8.10.10 Example - Multi-Resource Lock Request ....................50
8.11 UNLOCK Method ................................................51
8.11.1 Example - UNLOCK ..........................................52
9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
9.1 DAV Header ...................................................52
9.2 Depth Header .................................................52
9.3 Destination Header ...........................................54
9.4 If Header ....................................................54
9.4.1 No-tag-list Production ....................................55
9.4.2 Tagged-list Production ....................................55
9.4.3 not Production ............................................56
9.4.4 Matching Function .........................................56
9.4.5 If Header and Non-DAV Compliant Proxies ...................57
9.5 Lock-Token Header ............................................57
9.6 Overwrite Header .............................................57
9.7 Status-URI Response Header ...................................57
9.8 Timeout Request Header .......................................58
10 STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
10.1 102 Processing ...............................................59
10.2 207 Multi-Status .............................................59
10.3 422 Unprocessable Entity .....................................60
10.4 423 Locked ...................................................60
10.5 424 Failed Dependency ........................................60
10.6 507 Insufficient Storage .....................................60
11 MULTI-STATUS RESPONSE .........................................60
12 XML ELEMENT DEFINITIONS .......................................61
12.1 activelock XML Element .......................................61
8.8.5 ステータスコード…39 8.8 .6 例--重ね書きで、コピーしてください…40 8.8 .7 例--重ね書きなしでコピーしてください…40 8.8 .8 例--収集のコピー…41 8.9 メソッドを動かしてください…42 8.9 .1 特性を提議してください…42 8.9 .2 収集は提議します…42 8.9 .3移動と重ね書きヘッダー…43 8.9 .4 状態コード…43 8.9 .5 例--非収集の移動…44 8.9 .6 例--収集の移動…44 8.10 メソッドをロックしてください…45 8.10.1 操作…46 8.10.2 特性と収集への錠の効果…46 8.10.3 ロックはリソースを模写しました…46 8.10.4 深さとロック…46 8.10.5 他のMethodsとの相互作用…47 8.10.6 互換性テーブルをロックしてください…47 8.10.7 ステータスコード…48 8.10.8、例--簡単なロック要求…48 8.10.9 例--aをリフレッシュして、錠を書いてください…49 8.10.10 例(マルチリソースのロック要求)…50 8.11 メソッドをアンロックしてください…51 8.11.1 例--アンロックしてください…52 9 分配されたオーサリングのためのHTTPヘッダー…52 9.1DAVヘッダー…52 9.2深さヘッダー…52 9.3目的地ヘッダー…54 9.4 ヘッダーであるなら…54 9.4 .1 タグリストがない生産…55 9.4 .2 タグ付けをされたリスト生産…55、9.4、生産ではなく、.3…56 9.4 .4マッチングは機能します…56 9.4 .5 ヘッダーと非DAVの言いなりになっているプロキシであるなら…57 9.5ロックトークンヘッダー…57 9.6 ヘッダーを上書きしてください…57 9.7 状態URI応答ヘッダ…57 9.8タイムアウト要求ヘッダー…HTTP/1.1の状態58 10のコード拡張対コード拡張…59 10.1 102 処理…59 10.2 207 マルチ状態…59 10.3 422は実体をUnprocessableします…60 10.4 423はロックされました…60 10.5 424 依存に失敗します…60 10.6 507 不十分なストレージ…60 11マルチ状態応答…60 12のXML要素定義…61 12.1activelock XML Element…61
Goland, et al. Standards Track [Page 3] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[3ページ]。
12.1.1 depth XML Element .........................................61
12.1.2 locktoken XML Element .....................................61
12.1.3 timeout XML Element .......................................61
12.2 collection XML Element .......................................62
12.3 href XML Element .............................................62
12.4 link XML Element .............................................62
12.4.1 dst XML Element ...........................................62
12.4.2 src XML Element ...........................................62
12.5 lockentry XML Element ........................................63
12.6 lockinfo XML Element .........................................63
12.7 lockscope XML Element ........................................63
12.7.1 exclusive XML Element .....................................63
12.7.2 shared XML Element ........................................63
12.8 locktype XML Element .........................................64
12.8.1 write XML Element .........................................64
12.9 multistatus XML Element ......................................64
12.9.1 response XML Element ......................................64
12.9.2 responsedescription XML Element ...........................65
12.10 owner XML Element ...........................................65
12.11 prop XML element ............................................66
12.12 propertybehavior XML element ................................66
12.12.1 keepalive XML element ....................................66
12.12.2 omit XML element .........................................67
12.13 propertyupdate XML element ..................................67
12.13.1 remove XML element .......................................67
12.13.2 set XML element ..........................................67
12.14 propfind XML Element ........................................68
12.14.1 allprop XML Element ......................................68
12.14.2 propname XML Element .....................................68
13 DAV PROPERTIES ................................................68
13.1 creationdate Property ........................................69
13.2 displayname Property .........................................69
13.3 getcontentlanguage Property ..................................69
13.4 getcontentlength Property ....................................69
13.5 getcontenttype Property ......................................70
13.6 getetag Property .............................................70
13.7 getlastmodified Property .....................................70
13.8 lockdiscovery Property .......................................71
13.8.1 Example - Retrieving the lockdiscovery Property ...........71
13.9 resourcetype Property ........................................72
13.10 source Property .............................................72
13.10.1 Example - A source Property ..............................72
13.11 supportedlock Property ......................................73
13.11.1 Example - Retrieving the supportedlock Property ..........73
14 INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
15 DAV COMPLIANCE CLASSES ........................................75
15.1 Class 1 ......................................................75
15.2 Class 2 ......................................................75
12.1.1 深さXML Element…61 12.1.2 locktoken XML Element…61 12.1.3 タイムアウトXML Element…61 12.2 収集XML Element…62 12.3href XML Element…62 12.4 XML Elementをリンクしてください…62 12.4.1 dst XML Element…62 12.4.2 src XML Element…62 12.5lockentry XML Element…63 12.6lockinfo XML Element…63 12.7lockscope XML Element…63 12.7.1 排他的なXML Element…63 12.7.2 共有されたXML Element…63 12.8locktype XML Element…64 12.8.1 XML Elementに書いてください…64 12.9multistatus XML Element…64 12.9.1 応答XML Element…64 12.9.2 responsedescription XML Element…65 12.10 所有者XML Element…65 12.11 XML要素を支えてください…66 12.12propertybehavior XML要素…66 12.12.1 keepalive XML要素…66 12.12.2 XML要素を省略してください…67 12.13propertyupdate XML要素…67 12.13.1 XML要素を取り除いてください…67 12.13.2 XML要素を設定してください…67 12.14propfind XML Element…68 12.14.1 allprop XML Element…68 12.14.2 propname XML Element…68 13のDAVの特性…68 13.1creationdate Property…69 13.2displayname Property…69 13.3getcontentlanguage Property…69 13.4getcontentlength Property…69 13.5getcontenttype Property…70 13.6getetag Property…70 13.7getlastmodified Property…70 13.8lockdiscovery Property…71 13.8.1、例--lockdiscovery Propertyを検索します…71 13.9resourcetype Property…72 13.10 ソースProperty…72 13.10.1 例(AソースProperty)…72 13.11supportedlock Property…73 13.11.1、例--supportedlock Propertyを検索します…DAVの処理XMLのための73 14の指示…74 15のDAV承諾クラス…75 15.1 クラス1…75 15.2 クラス2…75
Goland, et al. Standards Track [Page 4] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[4ページ]。
16 INTERNATIONALIZATION CONSIDERATIONS ...........................76
17 SECURITY CONSIDERATIONS .......................................77
17.1 Authentication of Clients ....................................77
17.2 Denial of Service ............................................78
17.3 Security through Obscurity ...................................78
17.4 Privacy Issues Connected to Locks ............................78
17.5 Privacy Issues Connected to Properties .......................79
17.6 Reduction of Security due to Source Link .....................79
17.7 Implications of XML External Entities ........................79
17.8 Risks Connected with Lock Tokens .............................80
18 IANA CONSIDERATIONS ...........................................80
19 INTELLECTUAL PROPERTY .........................................81
20 ACKNOWLEDGEMENTS ..............................................82
21 REFERENCES ....................................................82
21.1 Normative References .........................................82
21.2 Informational References .....................................83
22 AUTHORS' ADDRESSES ............................................84
23 APPENDICES ....................................................86
23.1 Appendix 1 - WebDAV Document Type Definition .................86
23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
23.3 Appendix 3 - Notes on Processing XML Elements ................89
23.3.1 Notes on Empty XML Elements ...............................89
23.3.2 Notes on Illegal XML Processing ...........................89
23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
23.4.1 Introduction ..............................................92
23.4.2 Meaning of Qualified Names ................................92
24 FULL COPYRIGHT STATEMENT ......................................94
16 国際化問題…76 17のセキュリティ問題…77 17.1 クライアントの認証…77 17.2サービス妨害…不鮮明を通した78 17.3セキュリティ…78 17.4 プライバシー問題は錠に接続しました…78 17.5 プライバシー問題は特性に接続しました…79 17.6 Source LinkによるSecurityの減少…XML外部実体の79 17.7の含意…79 17.8の危険がロックトークンに接続しました…80 18のIANA問題…80 19知的所有権…81 20の承認…82 21の参照箇所…82 21.1 標準の参照…82 21.2 情報の参照…83 22人の作者のアドレス…84 23個の付録…86 23.1 付録1--WebDAVは型定義を記録します…86 23.2 付録2--ISO8601日時のプロフィール…88 23.3 付録3--処理XML Elementsに関する注…89 23.3.1 空のXML Elementsに関する注…89 23.3.2 不法なXML処理に関する注…89 23.4 付録4--WebDAVのためのXML名前空間…92 23.4.1 序論…92 23.4.2 適切な名前の意味…92 24の完全な著作権宣言文…94
1 Introduction
1つの序論
This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for:
このドキュメントはクライアントがウェブのリモート内容書いている操作を実行できるHTTP/1.1プロトコルに拡大について説明します。 この拡大は操作を以下に提供するメソッド、ヘッダー、要求実体ボディー形式、および応答の実体の一貫性を持っているボディー形式を、提供します。
Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc. Also, the ability to link pages of any media type to related pages.
特性: 彼らの作者、作成日付などのウェブページの情報を作成して、取り除いて、質問する能力 どんなメディアタイプのページも関連するページにリンクする能力も。
Collections: The ability to create sets of documents and to retrieve a hierarchical membership listing (like a directory listing in a file system).
収集: ドキュメントのセットを創設して、階層的な会員資格リスト(ファイルシステムでリストアップされているディレクトリのような)を検索する能力。
Goland, et al. Standards Track [Page 5] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[5ページ]。
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.
名前空間操作: ウェブリソースをコピーして、動かすようサーバに命令する能力。
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].
これらの操作のための要件と原理は仲間ドキュメント、「WWWのための分配されたオーサリングとVersioningプロトコルのための要件」[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で説明された、WebDAV特有のHTTPメソッド、「分配されたオーサリングのための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要素を現体制に追加する能力によって動機づけられました、伸展性を提供して。 ISO10646文字集合における情報をコード化するXMLの性能で国際化サポートを提供すること。 それらには限りない長さがあるか、人間のユーザに示されて、またはしたがって、ISO10646文字集合でコード化するのが必要であるときに、原則として、親指では、パラメタは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はメソッド出力のためにXMLの利点を伸展性と国際化に提供して、メソッドから応答をコード化するのにWebDAVで使用されて、入力されます。
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メソッドが多くの上で作動するかもしれないので
Goland, et al. Standards Track [Page 6] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[6ページ]。
resources, the Multi-Status response has been introduced to return status information for multiple resources. The Multi-Status response is described in section 11.
リソースであり、複数のリソースのための状態情報を返すためにMulti-状態応答を導入しました。 Multi-状態応答はセクション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プロトコルに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].
「キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"であるだろう「推薦され」て、「5月」の、そして、「任意」のNOTがRFC2119[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--Uniform Resource IdentifierとUniform Resource Locator、それぞれ。 これらの用語(そして、それらの区別)は[RFC2396]で定義されます。
Collection - A resource that contains a set of URIs, termed member URIs, which identify member resources and meets the requirements in section 5 of this specification.
収集--メンバーリソースを特定するメンバーURIと呼ばれたURIのセットを含んでいて、この仕様のセクション5で条件を満たすリソース。
Member URI - A URI which is a member of the set of URIs contained by a collection.
メンバーURI--収集で含まれたURIのセットのメンバーであるURI。
Internal Member URI - A Member URI that is immediately relative to the URI of the collection (the definition of immediately relative is given in section 5.2).
内部のメンバーURI--すぐに収集(親類が与えられているすぐにの定義は5.2を区分する)のURIに比例しているメンバーURI。
Property - A name/value pair that contains descriptive information about a resource.
特性--リソースの描写的である情報を含む名前/値の組。
Goland, et al. Standards Track [Page 7] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[7ページ]。
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.
Propertyを住ませてください--意味論と構文がサーバによって励行される特性。例えば、精力の"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.
死んでいるProperty--意味論と構文がサーバによって実施されないで. サーバが死んでいる属性の価値を記録するだけであるということである特性。 クライアントは構文の一貫性と死んでいる特性の意味論を維持するのに責任があります。
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.
ヌルResource--404(Foundでない)でどんなHTTP/1.1やPUT、MKCOL、OPTIONS、およびLOCK以外のDAVメソッドにも応じるリソース。 NULLリソースは親収集のメンバーとして現れてはいけません。
4 Data Model for Resource Properties
リソースの特性のための4データモデル
4.1 The Resource Property Model
4.1 リソース特性のモデル
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) 属性の価値はクライアントによって維持されますが、提出された値について検査して、サーバは構文を実行します。 与えられた精力の特性のすべてのインスタンスがその特性の名に関連している定義に従わなければなりません。 死んでいる特性は、その構文と意味論がクライアントによって励行されるのを持っています。 サーバは単に属性の価値を逐語的に記録します。
4.2 Existing Metadata Proposals
4.2 既存のメタデータ提案
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
特性が長い間大きい文書収納庫のメインテナンスにおける重要な役割をプレーしていて、より一般に、多くの現在の提案が、特性の何らかの概念を含んでいるか、またはウェブメタデータについて議論します。 これらはHTMLの中に関係を表すときのPICS[REC-PICS]、PICS-NG、XML、ウェブCollections、およびいくつかの提案を含んでいます。 映画-NGに働いてください。
Goland, et al. Standards Track [Page 8] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[8ページ]。
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.
そして、ウェブCollectionsはワールドワイドウェブコンソーシアムのResource記述Framework(リモート・データ・ファシリティ)メタデータ活動で包括されました。 リモート・データ・ファシリティはネットワークベースのデータモデルとそのモデルの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.
いくつかの提案がデジタルライブラリ見解から来ます。 これらはダブリンCore[RFC2413]メタデータセットとウォリックFramework[WF]、異なったメタデータschemasのためのコンテナアーキテクチャを含んでいます。 文学はメタデータに関する多くの例を含んでいます、Dienstシステム[RFC1807]によって雇われたマーク[USMARC]、図書目録のメタデータ形式、および技術報告書の図書目録の形式を含んでいて。 さらに、最初のIEEE Metadata会議からの議事は多くの共同体特有のメタデータセットについて説明します。
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.
「ネットワークでつながれたインフラストラクチャが熟すとき新しいメタデータセットが発展して、異なった共同体は、異なったタイプに関するメタデータに提案して、設計して、責任があるでしょう。」と、ウォリックの1996Metadata II Workshopの関係者(イギリス[WF])は述べました。 多くの共同体の特定のメタデータが既に存在することに注意することによって、これらの観測を確証できます、そして、多くの共同体がますますデジタル方式でそれらのデータを利用可能にするとき、新しいフォームに関するメタデータの開発に関する重要な動機があります、データ位置とカタログに載せることを補助するためにメタデータ形式を必要として。
4.3 Properties and HTTP Headers
4.3 特性とHTTPヘッダ
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ヘッダにわたってそれらを設定するか、または返すのが効率が悪いです。 したがって元本がまさしくそれらの特性を主体が興味を持っている1セットの特性を特定して、設定するか、または検索するメカニズムが、必要です。
4.4 Property Values
4.4 特性の値
The value of a property when expressed in XML MUST be well formed.
値、特性では、XML MUSTで言い表されたら、整形式になってください。
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の複数の人間の言語のサポート
Goland, et al. Standards Track [Page 9] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[9ページ]。
using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages.
「xml: lang」属性、同じ文字集合が複数の人間の言語によって使われるハンドルケースを使用します。
4.5 Property Names
4.5 特性の名
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.
XML名前空間メカニズム(URI[RFC2396]に基づいている)は、名前空間衝突を防ぐので特性を命名するのに使用されて、異なった度合いの運営管理コントロールに備えます。
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.
最終的に、ただ一つのリソースで二度同じ特性を定義するのは可能ではありません、これがリソースの特性の名前空間における衝突を引き起こすだろうというとき。
4.6 Media Independent Links
無党派がリンクする4.6のメディア
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リソースは他のリソースへのリンクを支えますが、ウェブはどんなメディアタイプに関するリソースの間のリンクの、より一般的なサポートを必要とします(また、メディアタイプはMIMEの種類、またはcontent typeとして知られています)。 WebDAVはそのようなリンクを提供します。 WebDAVリンクはタイプされた接続がどんなメディアタイプに関するリソースの間でも確立されるのを許容するセクション12.4で正式に定義された特別なタイプの資産価値です。 資産価値はソースと目的地Uniform Resource Identifier(URI)から成ります。 特性の名はリンク型を特定します。
Goland, et al. Standards Track [Page 10] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[10ページ]。
5 Collections of Web Resources
ウェブリソースの5つの収集
This section provides a description of a new type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace.
このセクションは、新しいタイプに関するウェブリソースの記述、収集を提供して、HTTP URL名前空間との相互作用について論じます。 収集リソースの目的はサーバの名前空間の中で収集のようなオブジェクト(例えば、ファイルシステム・ディレクトリ)をモデル化することです。
All DAV compliant resources MUST support the HTTP URL namespace model specified herein.
すべてのDAV対応することのリソースがここに指定されたHTTP URL名前空間モデルをサポートしなければなりません。
5.1 HTTP URL Namespace Model
5.1 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]で暗黙ですが、収集リソースを含むどんなリソースも1つ以上のURIによって特定されるかもしれません。 例えば、複数のHTTP URLはリソースを特定できました。
5.2 Collection Resources
5.2 収集リソース
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のリストと1セットの特性から成りますが、GETが実体本体などの追加状態を返すかもしれないリソースです。 内部のメンバーURIはすぐに、収集のベースURIに比例しているに違いありません。 収集リソースに関して「非収集しているリソースに、すなわち、内部のメンバーURIが含んでいる収集のURIと追加セグメントと等しいか、または追加セグメントと引きずるのは」 /をなでぎりします」。そこでは、セグメントが[RFC2396]のセクション3.3で定義されます。
Any given internal member URI MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URI in a collection. Properties defined on collections behave exactly as do properties on non-collection resources.
どんな与えられた内部のメンバーURIもかつて収集に属すだけでよいです、すなわち、収集に同じURIの複数のインスタンスを持っているのは不法です。 収集のときに定義された特性はちょうど非収集リソースの特性のように振る舞います。
Goland, et al. Standards Track [Page 11] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[11ページ]。
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.
UがすぐにVに比例しているURI UとVによって特定されたすべてのWebDAV対応することのリソースAとBに関しては、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.
HTTP URL名前空間階層構造にどんなWebDAV対応することの子供も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.
収集であるときに引きずっているスラッシュのない名前によって言及される地位のコンベンションがあって、自動的に引きずっているスラッシュを追加します。 収集へのポイントに「aが」 /を引きずらないで、このため、リソースはURIを受け入れるかもしれません」。 「この場合それ、SHOULDがURI結末を示しながら応答で満足している位置のヘッダーを返す、」 /、」 例えば、クライアントが http://foo.bar/blah (引きずっているスラッシュがない)にメソッドを呼び出すなら、リソース http://foo.bar/blah/ (引きずっているスラッシュ)はまるで操作がそれに呼び出されるかのように応じるかもしれなくて、それの http://foo.bar/blah/ で満足している位置のヘッダーを返すはずです。 「一般に、クライアントSHOULDが使用する、」 」 収集のフォームが命名する/。
A resource MAY be a collection but not be WebDAV compliant. That is, the resource may comply with all the rules set out in this specification regarding how a collection is to behave without necessarily supporting all methods that a WebDAV compliant resource is required to support. In such a case the resource may return the DAV:resourcetype property with the value DAV:collection but MUST NOT return a DAV header containing the value "1" on an OPTIONS response.
リソースは、収集ですが、WebDAV対応しないかもしれません。 すなわち、リソースはどう必ず、WebDAV対応することのリソースがサポートするのに必要であるすべてのメソッドをサポートするというわけではなくて振る舞うかに関する収集がことであるこの仕様を始められるすべての規則に応じるかもしれません。 このような場合にはリソースは、値のDAV: 収集と共にDAV: resourcetype資産を返すかもしれませんが、値「オプション応答での1インチ」を含むDAVヘッダーは返してはいけません。
5.3 Creation and Retrieval of Collection Resources
5.3 収集リソースの作成と検索
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.1PUTかポストメソッドを使用するよりむしろ新しい収集リソースを作成するMKCOLメソッドを指定します、以下の理由で:
Goland, et al. Standards Track [Page 12] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[12ページ]。
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メソッドは、Request-URIによって指定された位置に要求本体を保存するために定義されます。 PUTとの使用のために容易に収集のための記述形式を構成できますが、そのような記述をサーバに送る含意は望ましくありません。 例えば、いくつかの既存のリソースを省略した収集の記述がサーバへのPUTであるなら、これはそれらのメンバーを免職するコマンドとして解釈されるでしょうに。 これで、PUTの意味論を変えるので望ましくないDELETEの機能性を実行するためにPUTを広げていて、メソッドに基づくアクセス制御体系でDELETEの機能性を制御するのは難しくなります。
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.
ポストメソッドが十分制限のない間、「収集を作成してください」というポストが命令するのを組み立てることができました、ポストの他の用途と収集作成のためのアクセスコントロールを切り離すのは難しいでしょう、したがって、これが望ましくありません。
The exact definition of the behavior of GET and PUT on collections is defined later in this document.
収集でのGETとPUTの動きの正確な定義は後で本書では定義されます。
5.4 Source Resources and Output Resources
5.4 ソースリソースと出力リソース
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と日付)によって返されるものはリソース(HTMLと指示)の永続的な状態と異なっています。 未加工の指示を含む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名前空間における位置がしさえしないかもしれない)です。 単一のデータを作り出すプロセスはダイナミックに潜在的に多くの出力リソースの状態を生成するかもしれません。 この例は地図が離れさせるサーバの名前空間の「指」ゲートウェイプロセスについて指の要求に説明するCGIスクリプトです、 http://www.foo.bar.org/finger_gateway/user@host などのように。
Goland, et al. Standards Track [Page 13] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[13ページ]。
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は出力リソースにリンクにタイプ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人のアクセス型だけのためのロックを定義して、書いてください。 しかしながら、構文は、広げることができて、他のアクセス型のためにロックする最後の仕様を可能にします。
6.1 Exclusive Vs. Shared Locks
6.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.
最も基本的な形式の錠は排他的な錠です。 これは問題のアクセス権がただ一つの元本に与えられるだけである錠です。 この仲裁の必要性は結果を合併しなければならないのを避ける願望から生じます。
Goland, et al. Standards Track [Page 14] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[14ページ]。
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.
ウェブの分配されたオーサリングシステムからの経験が、排他的な錠がしばしば堅過ぎるのを示したので、共有された錠は含まれています。 排他的な錠は特定の編集プロセスを実施するのに使用されます: 排他的な錠を取り出してください、そして、リソースを読んでください、そして、編集を実行してください、そして、リソースを書いてください、そして、錠をリリースしてください。 この編集プロセスには、錠がいつも適切にリリースされるというわけではないという問題があります、例えば、プログラムがダウンするか、またはロック所有者がリソースをアンロックしないでいなくなるとき。 怒っている錠を取り外すのにタイムアウトと管理動作の両方を使用できる間、必要である場合、どちらのメカニズムも利用可能でないかもしれません。 タイムアウトが長いかもしれませんか、または管理者は手があいていないかもしれません。
Goland, et al. Standards Track [Page 15] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[15ページ]。
6.2 Required Support
6.2 必要なサポート
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.
理由は、この柔軟性がそのロック方針であるので、様々なストレージ倉庫によって使われた資源管理とversioningシステムのまさしくその中心に打ちます。 これらの倉庫はどういうロックを利用可能にするかのコントロールを必要とします。 例えば、他のものがサポートを提供しているだけである間、サポートだけが共有したいくつかの倉庫が錠を書く、排他的である、しかし、他のものが全くロックでないのを使用している間、錠を書いてください。 それぞれのシステムが、あるロックの特徴の除外に値することができるくらい異なっているとき、この仕様は、交渉の唯一の軸としてWebDAVの中でロックしながら、いなくなります。
6.3 Lock Tokens
6.3 ロックトークン
A lock token is a type of state token, represented as a URI, which identifies a particular lock. A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body, and can also be found through lock discovery on a resource.
ロックトークンは特定の錠を特定するURIとして表された一種の州のトークンです。 ロックトークンを応答本体のlockdiscovery所有地であらゆるうまくいっているLOCK操作で返して、また、リソースでロック発見で見つけることができます。
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.
ロックトークンを持っているのはどんな特別なアクセス権も提供しません。 だれでも、ロック発見を実行することによって、他の誰のロックトークンも見つけることができます。 トークン値の秘密保持に基づいているのではなく、サーバによって使用されるどんな認証機構にも基づいた状態で錠を実施しなければなりません。
6.4 opaquelocktoken Lock Token URI Scheme
6.4 opaquelocktoken Lock Token URI Scheme
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体系を認めて、ロックトークンがリソースの傑出している錠について言及しないと認めなければなりません。
Goland, et al. Standards Track [Page 16] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[16ページ]。
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はUniversal Unique Identifier(UUID)メカニズムの使用を必要とします、[ISO-11578]で説明されるように。
Opaquelocktoken generators, however, have a choice of how they create these tokens. They can either generate a new UUID for every lock token they create or they can create a single UUID and then add extension characters. If the second method is selected then the program generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID.
しかしながら、Opaquelocktokenジェネレータには、それらがどうこれらのトークンを作成するかの選択があります。 彼らが作成するあらゆるロックトークンのために新しいUUIDを生成することができるか、彼らは、独身のUUIDを作成して、次に、拡大キャラクタを加えることができます。 2番目のメソッドが選択されるなら、拡大を生成するプログラムは、同じ拡張子が関連UUIDと共に二度決して使用されないのを保証しなければなりません。
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID, as defined in [ISO-11578]. Note that white space (LWS) is not allowed between elements of this production.
OpaqueLockToken-URI=は「以下をopaquelocktokenします」。 UUID[拡大]。 UUID生産は[ISO-11578]で定義されるようにUUIDのストリング表現です。 余白(LWS)がこの生産の要素の間に許容されていないことに注意してください。
Extension = path ; path is defined in section 3.2.1 of RFC 2068 [RFC2068]
拡大は経路と等しいです。 経路は.1セクション3.2RFC2068で定義されます。[RFC2068]
6.4.1 Node Field Generation Without the IEEE 802 Address
6.4.1IEEE802アドレスのないノード分野世代
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はサーバマシンのためのIEEE802アドレスの1つを含む「ノード」分野を含んでいます。 セクション17.8で注意されるように、マシンのIEEE802がアドレスであると暴露すると関連しているいくつかのセキュリティリスクがあります。 このセクションはIEEE802アドレスを使わないUUIDの「ノード」分野を生成するのに代替のメカニズムを提供します。 WebDAVサーバは、UUIDsを生成するときノード分野を作成するのにこのアルゴリズムを使用するかもしれません。 このセクションのテキストは元々ポール・リーチとリッシュ・ザルツによるインターネット草稿から来ています。(ザルツは、適切に彼らの仕事を結果と考えるためにここに述べられます)。
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に設定したノードの最初の八重奏の最も重要なビットで。 このビットはユニキャスト/マルチキャストビットです。(それは、ネットワークカードから得られたIEEE802アドレスに決して設定されないでしょう)。 したがって、ネットワークカードのあるなしにかかわらずマシンによって生成されたUUIDsの間の闘争が決してあることができません。
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:
aがシステムで暗号の上質の乱数を生成するために原始的にならないなら、ほとんどのシステムには、通常、どれを生成することができるかから利用可能な偶発性の多くの源があります。 システム特有ですが、しばしばそのようなソース特有です。
Goland, et al. Standards Track [Page 17] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[17ページ]。
- the percent of memory in use
- the size of main memory in bytes
- the amount of free main memory in bytes
- the size of the paging or swap file in bytes
- free bytes of paging or swap file
- the total size of user virtual address space in bytes
- the total available user address space bytes
- the size of boot disk drive in bytes
- the free disk space on boot drive in bytes
- the current time
- the amount of time since the system booted
- the individual sizes of files in various system directories
- the creation, last read, and modification times of files in
various system directories
- the utilization factors of various system resources (heap, etc.)
- current mouse cursor position
- current caret position
- current number of running processes, threads
- handles or IDs of the desktop window and the active window
- the value of stack pointer of the caller
- the process and thread ID of caller
- various processor architecture specific performance counters
(instructions executed, cache misses, TLB misses)
- 使用中の記憶のパーセント--バイトで表現される主記憶装置のサイズ--バイト--バイトで表現されるページングかスワップファイルのサイズ--空き領域バイトのページングかスワップファイル--バイトで表現されるユーザ仮想アドレス空間の総サイズ--合計における、無料の主記憶装置の量; 有効なユーザアドレス空間バイト--バイトで表現される起動ディスクドライブのサイズ--システム以来の時間がブートしたバイト(現在の時間)におけるブートドライブの空きのディスクスペース--様々なシステム・ディレクトリのファイルの個々のサイズ--作成; 様々なシステム・ディレクトリのファイルの最後に読まれて、変更倍--様々なシステム資源(山など)に関するユーティライゼーション係数 - スレッド--デスクトップウィンドウとアクティブウィンドウ--訪問者のスタックポインタの値--プロセスのハンドルかIDと訪問者のスレッドID--現在のマウスカーソル位置--現在の脱字記号位置--最新号の実行しているプロセス、様々なプロセッサアーキテクチャ特定の性能カウンタ(実行された指示、TLBが逃すキャッシュミス)
(Note that it is precisely the above kinds of sources of randomness that are used to seed cryptographic quality random number generators on systems without special hardware for their construction.)
(それが正確に特別なハードウェアのない彼らの工事のシステムを暗号の上質の乱数発生器に種を蒔くのに使用される上の種類の偶発性の源であることに注意してください。)
In addition, items such as the computer's name and the name of the operating system, while not strictly speaking random, will help differentiate the results from those obtained by other systems.
さらに、コンピュータの名前やオペレーティングシステムの名前などの項目は、厳密に言うと、無作為でない間、他のシステムによって得られたものと結果を区別するのを助けるでしょう。
The exact algorithm to generate a node ID using these data is system specific, because both the data available and the functions to obtain them are often very system specific. However, assuming that one can concatenate all the values from the randomness sources into a buffer, and that a cryptographic hash function such as MD5 is available, then any 6 bytes of the MD5 hash of the buffer, with the multicast bit (the high bit of the first byte) set will be an appropriately random node ID.
ノードがIDであるとこれらのデータを使用することで生成する正確なアルゴリズムはシステム特有です、利用可能なデータとそれらを得る機能の両方がシステムしばしば非常に特有であるので。 しかしながら、1つが偶発性ソースからのすべての値をバッファの中に連結できて、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などの他のハッシュ関数を使用できます。 唯一の要件は結果が一様に入力を広げて、1ビット、入力における変化が、出力ビットの半分が変化することを引き起こすと予想できるというセットからの出力が一様に分配した意味で適当に無作為の_であるということです。
Goland, et al. Standards Track [Page 18] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[18ページ]。
6.5 Lock Capability Discovery
6.5 ロック能力発見
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. Lock capability discovery differs from discovery of supported access control types, since there may be access control types without corresponding lock types. A client can determine what lock types the server supports by retrieving the supportedlock property.
サーバロックサポートが任意であるので、サーバに関するリソースをロックしようとするクライアントは、サーバがどんなロック能力をサポートするかを決定するために何らかの形式の発見を錠を試して、うまくいくことを望むか、または実行できます。 これはロック能力発見として知られています。 ロック能力発見はサポートしているアクセス制御タイプの発見と異なっています、アクセス制御タイプが対応するロックタイプなしであるかもしれないので。 クライアントは、サーバがsupportedlockの特性を検索することによってどんなロックタイプをサポートするかを決心できます。
Any DAV compliant resource that supports the LOCK method MUST support the supportedlock property.
LOCKがメソッドであるとサポートするどんなDAV対応することのリソースも、supportedlockが特性であるとサポートしなければなりません。
6.6 Active Lock Discovery
6.6 活発なロック発見
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番目の主体の役に立った状態でアクセスする主要な願望、それがそうであるリソースをロックするなら。 このためにlockdiscovery資産を提供します。 この特性は、すべての傑出している錠を記載して、入手できるところで彼らのタイプについて説明して、それらのロックトークンを提供します。
Any DAV compliant resource that supports the LOCK method MUST support the lockdiscovery property.
LOCKがメソッドであるとサポートするどんなDAV対応することのリソースも、lockdiscoveryが特性であるとサポートしなければなりません。
6.7 Usage Considerations
6.7 用法問題
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は、LOCKをして、GETを実行して、編集し始めます。 クライアントBは、編集し終えて、PUTを実行して、その時はUNLOCKです。 ビーズ変化のすべてを上書きして、失って、クライアントAはPUTを実行します。
There are several reasons why the WebDAV protocol itself cannot prevent this situation. First, it cannot force all clients to use locking because it must be compatible with HTTP clients that do not comprehend locking. Second, it cannot require servers to support locking because of the variety of repository implementations, some of which rely on reservations and merging rather than on locking. Finally, being stateless, it cannot enforce a sequence of operations like LOCK / GET / PUT / UNLOCK.
WebDAVプロトコル自体がこの状況を防ぐことができないいくつかの理由があります。 まず最初に、すべてのクライアントは、それによってそれはロックを理解しないHTTPクライアントと互換性があるに違いないので、やむを得ずロックを使用できません。 2番目に、ロックに関してというよりむしろ倉庫実装のバラエティーによるロックをサポートするのがサーバを必要とすることができません。それの或るものは実装のために予約と合併に依存します。 最終的に、状態がなくて、それはLOCK/GET/PUT/UNLOCKのような操作の系列を実施できません。
Goland, et al. Standards Track [Page 19] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[19ページ]。
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サーバはそれらを変更する前にクライアントがリソースをロックするのを必要とすることによってクライアントが互いの変化を偶然上書きするという見込みを減少させることができます。 そのようなサーバによって、事実上、HTTP1.0とHTTP1.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.
このセクションが意味論詳細について説明する、ロックタイプに書いてください。 書いてください。錠は、ロックタイプの特定のインスタンスであり、この仕様で説明されて、唯一のロックタイプです。
7.1 Methods Restricted by Write Locks
制限された7.1のメソッドが錠を書きます。
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.
Aは、錠のない元本がロックされたリソースで首尾よくPUT、ポスト、PROPPATCH、LOCK、UNLOCK、MOVE、DELETE、またはMKCOLを実行するのを防がなければならないと錠を書きます。 他のすべての現在のメソッド(特にGET)が錠の如何にかかわらず機能します。
Note, however, that as new methods are created it will be necessary to specify how they interact with a write lock.
注意、しかしながら、新しいメソッドが作成されるときそれらがどうaと対話するかを指定するのが必要であることが錠を書きます。
7.2 Write Locks and Lock Tokens
7.2は、錠を書いて、トークンをロックします。
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つの主体が一翼を担うなら、5つのロックトークン(各主体あたり1つ)をある同じリソースの錠に書いてください。
7.3 Write Locks and Properties
7.3は錠と特性を書きます。
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.
aのないものが書いている間、錠は精力の特性の値が変えるのが、まだ可能であるリソースの特性を変更しないかもしれません、ロックされてさえいる間、それらのschemasの要件のため。
Goland, et al. Standards Track [Page 20] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[20ページ]。
Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked.
錠を尊敬するために定義された死んでいる特性と精力の特性だけが変化しないように保証される、ロックされていた状態で、書いてください。
7.4 Write Locks and Null Resources
7.4は錠とヌルリソースを書きます。
It is possible to assert a write lock on a null resource in order to lock the name.
aが名前をロックするためにヌルリソースに錠を書くと断言するのは可能です。
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.
a404(Foundでない)か405(メソッドNot Allowed)でどんなHTTP/1.1やPUT、MKCOL、OPTIONS、PROPFIND、LOCK、およびUNLOCK以外のDAVメソッドにも応じなければなりませんAが、ロックヌルリソースと呼ばれたロックされたヌルリソースを書く。 ロックヌルリソースは親収集のメンバーとして現れなければなりません。 さらに、ロックヌルリソースはそれですべての義務的なDAVの特性を定義したに違いありません。 すべてなどのこれらの特性の大部分、*資産を手に入れてください、そして、ロックヌルリソースがGETメソッドをサポートしないとき値を全く持たないために望んでください。 ロックヌルリソースはlockdiscoveryとsupportedlockの特性のために値を定義したに違いありません。
Until a method such as PUT or MKCOL is successfully executed on the lock-null resource the resource MUST stay in the lock-null state. However, once a PUT or MKCOL is successfully executed on a lock-null resource the resource ceases to be in the lock-null state.
PUTかMKCOLなどのメソッドがロックヌルリソースで首尾よく実行されるまで、リソースはロックヌル状態にいなければなりません。 しかしながら、PUTかMKCOLがロックヌルリソースでいったん首尾よく実行されると、リソースは、ロックヌル状態にあるのをやめます。
If the resource is unlocked, for any reason, without a PUT, MKCOL, or similar method having been successfully executed upon it then the resource MUST return to the null state.
リソースの錠がどんな理由でも開いているなら、その時それで首尾よく実行されたPUTも、MKCOLも、または同様のメソッドがなければ、リソースはヌル状態に戻らなければなりません。
7.5 Write Locks and Collections
7.5は錠と収集を書きます。
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.
aによって作成されるか否かに関係なく、Aが収集のときに錠を書く、「深さ:」 または、0インチ、「深さ:」 錠が要求する「無限」は非ロック所有者による収集のメンバーURIの追加か取り外しを防ぎます。 元本がaの既存の内部のメンバーURIであるURIがロックされた収集を書くリソースを取り除くためにaの内部のメンバーであるそれの必要性がHTTP名前空間の一貫性を維持するためにロックされた収集を書くURIの下で新しいリソースを作成するという要求をPUTかポストに発行するか、または問題にDELETEを発行するとき、結果として、校長がaに収集のときに錠を書かせないなら、この要求は失敗しなければなりません。
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.
しかしながら、aが書くならロック要求が衝突する方法が現在閉じ込められるリソースを特定するメンバーURIを含む収集に出される、錠を書いてください、そして、要求はa423(ロックされる)ステータスコードで失敗しなければなりません。
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を加えさせるなら、自動的に新しいリソースを錠に加えなければなりません。 これが唯一のメカニズムである、それ
Goland, et al. Standards Track [Page 21] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[21ページ]。
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が、書く加えられるのを許容します。 このようにして、例えば収集/a/b/がロックされていた状態で書くことであり、リソース/cが当時のリソース/a/b/cが加えられる/a/b/cに動かされる、錠を書いてください。
7.6 Write Locks and the If Request Header
そして、7.6が錠を書く、要求ヘッダーです。
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.
ユーザエージェントはロックされたリソースで操作を要求するとき、錠の周りで心得があるのに必要でないなら、以下のシナリオが起こるかもしれません。 User Aによって実行されたAをプログラムしてください、そして、aからの撮影はリソースに錠を書きます。 また、User Aが動かされるプログラムBは、Program Aに錠に関する知識を全く取り出させませんが、ロックされたリソースにPUTを実行します。 錠がプログラムではなく、元本に関連しているので、このシナリオに、PUTは成功します、そして、その結果、プログラムBは主体Aのもので資格証明に行動しているので、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つのロックトークンを提出しなければならないなら。
7.6.1 Example - Write Lock
7.6.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>)
コピー/~フィールディング/index.html HTTP/1.1ホスト: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html 、: <http://www.ics.uci.edu/ユーザ/f/フィールディング/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つのロックトークンだけを提出しなければなりません、目的地の錠のために。 これがソースリソースでCOPYによって変更されないで、したがって、影響を受けないからである錠を書いてください。 この例では、ユーザエージェント認証は以前にHTTPプロトコルの範囲の外のメカニズムで起こりました、基本的なトランスポート層の中で。
Goland, et al. Standards Track [Page 22] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[22ページ]。
7.7 Write Locks and COPY/MOVE
7.7は錠とコピー/移動を書きます。
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.
実施がコピーしてはいけないCOPYメソッドはソースでアクティブな状態でロックされますいずれも、書く。 しかしながら、COPYが収集にリソースをコピーするなら上述しているようにそれでロックされる、「深さ:」 「無限」、次にリソースは錠に加えられるでしょう。
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.
aに関する要求が移行してはいけないとロックされたリソースに書くうまくいっているMOVE、リソースで錠を書いてください。 しかしながら、リソースはセクション7.5で指定されるように目的地の既存の錠に加えられるのを受けることがあります。 MOVEが例えばそれがロックされる収集の子供にリソースを作る、「深さ:」 「無限」、次にリソースはその収集の錠に加えられるでしょう。 さらに、リソースがaであるならロックされた、「深さ:」 「無限」は目的地に動かされます、すなわち、同じ錠(例えば、錠でカバーされた名前空間木の中の)の範囲の中では、動くリソースが再び錠に加えられたaになるでしょう。 これらの例の両方では、セクション7.6で指定されるように、ソースと目的地の両方へのロックトークンを含んでいて、Ifヘッダーを提出しなければなりません。
7.8 Refreshing Write Locks
7.8 リフレッシュは錠を書きます。
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.
クライアントが同じように提出してはいけないAは二度ロック要求を書きます。 クライアントがいつも既にロックされるリソースに関する要求をするように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ヘッダーにもかかわらず、ボディーなしでLOCKメソッドを提出するかもしれません。 これはLOCK MUSTを形成します。錠を「リフレッシュすること」が単に使用されてください。 最小限におけるどんなタイマも錠に関連づけた意味をリセットしなければなりません。
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.
サーバは錠がリフレッシュするaがある錠が元々要求されたとき、Timeoutヘッダーが戻ったより異なったTimeoutヘッダーを返すかもしれません。 さらに、クライアントは任意のヘッダーが彼らの錠で要求をリフレッシュするのを評価するTimeoutを提出するかもしれません。 サーバはいつものようにクライアントによって提出されたTimeoutヘッダーを無視するかもしれません。
If an error is received in response to a refresh LOCK request the client SHOULD assume that the lock was not refreshed.
aに対応して誤りを受けるなら、錠がリフレッシュされなかったというクライアントSHOULDが仮定するLOCK要求をリフレッシュしてください。
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が整形式であるに違いありません。 サーバが受信されるなら
Goland, et al. Standards Track [Page 23] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[23ページ]。
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(悪いRequest)で全体の要求を拒絶します。 クライアントが応答で不適格なXMLを受け取るなら、実行されたメソッドの結果に関して何も仮定してはいけません、そして、SHOULDは誤動作としてサーバを扱います。
8.1 PROPFIND
8.1 PROPFIND
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メソッドはリソースにどれか内部のメンバーがいないならRequest-URIによって特定されたリソースの上、または、Request-URIと潜在的にそのメンバーリソースによって特定されたリソースの上で定義された特性を検索します、リソースが内部のメンバーURIを持っている収集であるなら。 すべての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.
クライアントがa値があるDepthヘッダーを提出するかもしれない、「0インチ、「1インチ、またはPROPFINDが内部のメンバーURIがある収集リソースにある「無限」。」 DAV対応することのサーバがサポートしなければならない、「何0インチも、「1インチと「無限」の振舞い。」 デフォルトで、Depthヘッダーのない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要素を提出するかもしれません。 リソースの特性の名前の特定の特性の値、すべての特性の値、またはリストを要求するのは可能です。 クライアントは、要求本体を提出しないのを選ぶかもしれません。 すべての特性の名前と値を求める要求として空のPROPFIND要求ボディーを扱わなければなりません。
All servers MUST support returning a response of content type text/xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties.
すべてのサーバが、帰りが様々な特性を検索する試みの結果について説明するmultistatus XML要素を含むcontent typeテキスト/xmlかアプリケーション/xmlの応答であるとサポートしなければなりません。
If there is an error retrieving a property then a proper error result MUST be included in the response. A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a multistatus XML element, with a response XML element which contains a 404 (Not Found) status value.
特性を検索する誤りがあれば、応答に適切な誤り結果を含まなければなりません。 存在しない属性の価値を検索するという要求を誤りであり、注意しなければなりません、応答がmultistatus XML要素を使用するなら、404(Foundでない)状態値を含む応答XML要素で。
Consequently, the multistatus XML element for a collection resource with member URIs MUST include a response XML element for each member URI of the collection, to whatever depth was requested. Each response XML element MUST contain an href XML element that gives the URI of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URIs are returned as a flat list whose order of entries is not significant.
その結果、メンバーURIがある収集リソースのためのmultistatus XML要素は収集のそれぞれのメンバーURIのための応答XML要素を含まなければなりません、要求されたどんな深さにも。 それぞれの応答XML要素は支柱XML要素の特性が定義されるリソースのURIを与えるhref XML要素を含まなければなりません。 内部のメンバーURIがある収集リソースのPROPFINDのための結果はエントリーの注文が重要でない平坦なリストとして返されます。
Goland, et al. Standards Track [Page 24] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[24ページ]。
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.
結果、このメソッドSHOULD NOTでは、キャッシュされてください。
8.1.1 Example - Retrieving Named Properties
8.1.1 例--検索は特性を命名しました。
>>Request
>>要求
PROPFIND /file HTTP/1.1 Host: www.foo.bar Content-type: text/xml; charset="utf-8" Content-Length: xxxx
PROPFIND/ファイルHTTP/1.1ホスト: www.foo.bar文書内容: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV:、「><D: 支柱xmlns: Rが等しい、「 http://www.foo.bar/boxschema/ 、「><R: bigbox/><R: 作者/><R: DingALing/><R: 無作為の/></D: ></D: propfind>を支えてください」
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foo.bar/file</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Johnson</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop><R:DingALing/><R:Random/></D:prop>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:multistatus xmlns:Dが等しい、「DAV:、「><D: 応答><D: href>http://www.foo.bar/ファイル</D: href><D: propstat><D: 支柱xmlns: Rが等しい、「 http://www.foo.bar/boxschema/ 、「><R: bigbox><R: BoxType>BoxタイプA</R: BoxType></R: bigbox><R: 作者><R: 名前>J。」; J.ペニス</R: </Rと>を命名してください: ></Dを書いてください: ><D: 状態>HTTP/1.1 200OK</D: 状態></D: propstat><D: propstat><Dを支えてください: ><R: おばかさん/><R: 無作為の/></Dを支えてください: >を支えてください。
Goland, et al. Standards Track [Page 25] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[25ページ]。
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to
the DingALing property.
</D:responsedescription>
</D:propstat>
</D:response>
<D:responsedescription> There has been an access violation error.
</D:responsedescription>
</D:multistatus>
<D: 状態>HTTP/1.1 403Forbidden</D: 状態><D: ユーザのresponsedescription>はDingALingの特性に近づく手段を持っていません。 </D: responsedescription></D: propstat></D: 応答><D: responsedescription>Thereはアクセス違反誤りです。 </D: responsedescription></D: 「マルチ-状態」>。
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つの特性の名前を指定します。 この場合、2つの資産だけを返しました、要求を出す校長が3番目を見ることができるくらいのアクセス権と第4特性を持っていなかったので。
8.1.2 Example - Using allprop to Retrieve All Properties
8.1.2 例--Retrieve All Propertiesにallpropを使用すること。
>>Request
>>要求
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
PROPFIND/コンテナ/HTTP/1.1ホスト: www.foo.bar Depth: 1つのコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
</D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV: 「><D: allprop/></D: propfind>」
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foo.bar/container/</D:href>
<D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:multistatus xmlns:Dが等しい、「DAV:、「><D: 応答><D: href>http://www.foo.bar/container/</D: href><D: propstat><D: 支柱xmlns: Rが等しい、「 http://www.foo.bar/boxschema/ 、「><R: bigbox><R: BoxType>BoxはA</R: BoxType></R: bigbox><Rをタイプします: >を書いてください」
Goland, et al. Standards Track [Page 26] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[26ページ]。
<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: lockscope><D: locktype><D: /></D: locktype></D: lockentry><D: lockentry><D: lockscope><D: 共有された/></D: lockscope><D: locktype><Dを書いてください: /></Dを書いてください: locktype></D: lockentry></D: supportedlock></D: > @Dを支えてください: 状態?HTTP/1。>をifiedしました。
Goland, et al. Standards Track [Page 27] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[27ページ]。
<D:resourcetype/>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<D: resourcetype/><D: supportedlock><D: lockentry><D: lockscope><D: 排他的な/></D: lockscope><D: locktype><D: /></D: locktype></D: lockentry><Dを書いてください:; lockentry><D: lockscope><D: 共有された/></D: lockscope><D: locktype><D: /></Dを書いてください: locktype></D: lockentry></D: supportedlock></D: ><Dを支えてください: 状態>HTTP/1; 1 200OK</D: 状態></D: propstat></D: 応答></D: 「マルチ-状態」>。
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.
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.
The resource http://www.foo.bar/container/ has six properties defined on it:
The 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/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).
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).
The resource http://www.foo.bar/container/front.html has nine properties defined on it:
The resource http://www.foo.bar/container/front.html has nine properties defined on it:
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 (another instance of the "bigbox" property type), DAV:creationdate, DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
Goland, et al. Standards Track [Page 28] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 28] RFC 2518 WEBDAV February 1999
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).
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).
8.1.3 Example - Using propname to Retrieve all Property Names
8.1.3 Example - Using propname to Retrieve all Property Names
>>Request
>>Request
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:">
<propname/>
</propfind>
<?xml version="1.0" encoding="utf-8" ?> <propfind xmlns="DAV:"> <propname/> </propfind>
>>Response
>>Response
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://www.foo.bar/container/</href>
<propstat>
<prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/>
<R:author/>
<creationdate/>
<displayname/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>http://www.foo.bar/container/front.html</href>
<?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://www.foo.bar/container/</href> <propstat> <prop xmlns:R="http://www.foo.bar/boxschema/"> <R:bigbox/> <R:author/> <creationdate/> <displayname/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>http://www.foo.bar/container/front.html</href>
Goland, et al. Standards Track [Page 29] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 29] RFC 2518 WEBDAV February 1999
<propstat>
<prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/>
<creationdate/>
<displayname/>
<getcontentlength/>
<getcontenttype/>
<getetag/>
<getlastmodified/>
<resourcetype/>
<supportedlock/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
<propstat> <prop xmlns:R="http://www.foo.bar/boxschema/"> <R:bigbox/> <creationdate/> <displayname/> <getcontentlength/> <getcontenttype/> <getetag/> <getlastmodified/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus>
In this example, PROPFIND is invoked on the collection resource http://www.foo.bar/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its progeny should be returned.
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.
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.
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.
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.
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.
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.
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.
Goland, et al. Standards Track [Page 30] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 30] RFC 2518 WEBDAV February 1999
8.2 PROPPATCH
8.2 PROPPATCH
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.
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.
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.
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.
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.
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.
8.2.1 Status Codes for use with 207 (Multi-Status)
8.2.1 Status Codes for use with 207 (Multi-Status)
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.
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.
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) - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 (Created) seems inappropriate.
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
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 (Conflict) - The client has provided a value whose semantics are not appropriate for the property. This includes trying to set read- only properties.
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 (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.
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
Goland, et al. Standards Track [Page 31] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 31] RFC 2518 WEBDAV February 1999
8.2.2 Example - PROPPATCH
8.2.2 Example - PROPPATCH
>>Request
>>Request
PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:authors>
</D:prop>
</D:set>
<D:remove>
<D:prop><Z:Copyright-Owner/></D:prop>
</D:remove>
</D:propertyupdate>
<?xml version="1.0" encoding="utf-8" ?> <D:propertyupdate xmlns:D="DAV:" xmlns:Z="http://www.w3.com/standards/z39.50/"> <D:set> <D:prop> <Z:authors> <Z:Author>Jim Whitehead</Z:Author> <Z:Author>Roy Fielding</Z:Author> </Z:authors> </D:prop> </D:set> <D:remove> <D:prop><Z:Copyright-Owner/></D:prop> </D:remove> </D:propertyupdate>
>>Response
>>Response
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50">
<D:response>
<D:href>http://www.foo.com/bar.html</D:href>
<D:propstat>
<D:prop><Z:Authors/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
<D:propstat>
<D:prop><Z:Copyright-Owner/></D:prop>
<D:status>HTTP/1.1 409 Conflict</D:status>
</D:propstat>
<D:responsedescription> Copyright Owner can not be deleted or
altered.</D:responsedescription>
</D:response>
</D:multistatus>
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:Z="http://www.w3.com/standards/z39.50"> <D:response> <D:href>http://www.foo.com/bar.html</D:href> <D:propstat> <D:prop><Z:Authors/></D:prop> <D:status>HTTP/1.1 424 Failed Dependency</D:status> </D:propstat> <D:propstat> <D:prop><Z:Copyright-Owner/></D:prop> <D:status>HTTP/1.1 409 Conflict</D:status> </D:propstat> <D:responsedescription> Copyright Owner can not be deleted or altered.</D:responsedescription> </D:response> </D:multistatus>
Goland, et al. Standards Track [Page 32] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 32] RFC 2518 WEBDAV February 1999
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.
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.
8.3 MKCOL Method
8.3 MKCOL Method
The MKCOL method is used to create a new collection. All DAV compliant resources MUST support the MKCOL method.
The MKCOL method is used to create a new collection. All DAV compliant resources MUST support the MKCOL method.
8.3.1 Request
8.3.1 Request
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 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.
When MKCOL is invoked without a request body, the newly created collection SHOULD have no members.
When MKCOL is invoked without a request body, the newly created collection SHOULD have no members.
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.
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.
8.3.2 Status Codes
8.3.2 Status Codes
Responses from a MKCOL request MUST NOT be cached as MKCOL has non- idempotent semantics.
Responses from a MKCOL request MUST NOT be cached as MKCOL has non- idempotent semantics.
201 (Created) - The collection or structured resource was created in its entirety.
201 (Created) - The collection or structured resource was created in its entirety.
Goland, et al. Standards Track [Page 33] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 33] RFC 2518 WEBDAV February 1999
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 (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.
405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource.
405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource.
409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created.
409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created.
415 (Unsupported Media Type)- The server does not support the request type of the body.
415 (Unsupported Media Type)- The server does not support the request type of the body.
507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
8.3.3 Example - MKCOL
8.3.3 Example - MKCOL
This example creates a collection called /webdisc/xfiles/ on the server www.server.org.
This example creates a collection called /webdisc/xfiles/ on the server www.server.org.
>>Request
>>Request
MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.server.org
MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.server.org
>>Response
>>Response
HTTP/1.1 201 Created
HTTP/1.1 201 Created
8.4 GET, HEAD for Collections
8.4 GET, HEAD for Collections
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.
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.
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.
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.
Goland, et al. Standards Track [Page 34] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 34] RFC 2518 WEBDAV February 1999
8.5 POST for Collections
8.5 POST for Collections
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.
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.
8.6 DELETE
8.6 DELETE
8.6.1 DELETE for Non-Collection Resources
8.6.1 DELETE for Non-Collection Resources
If the DELETE method is issued to a non-collection resource whose URIs are an internal member of one or more collections, then during DELETE processing a server MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member.
URIが1つ以上の収集の内部のメンバーである非収集リソースにDELETEメソッドを発行するなら、サーバが取り除かなければならないDELETE処理の間、何かリソースのためのURIが、収集からのRequest-URIでどれがメンバーとしてそれを含むかを特定しました。
8.6.2 DELETE for Collections
8.6.2、収集のための削除
The DELETE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity.
収集でのDELETEメソッドが行動しなければならない、「深さ:」 「無限」ヘッダーはそれで使用されました。 クライアントは収集でのDELETEと共にどんな値にもかかわらず、無限でもDepthヘッダーを提出してはいけません。
DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URIs are to be deleted.
DELETEは、Request-URIで指定された収集と内部のメンバーURIによって特定されたすべてのリソースが削除されることであるよう命令します。
If any resource identified by a member URI cannot be deleted then all of the member's ancestors MUST NOT be deleted, so as to maintain namespace consistency.
メンバーURIによって特定されたどんなリソースも削除できないなら、メンバーの先祖のすべてを削除してはいけません、名前空間の一貫性を維持するために。
Any headers included with DELETE MUST be applied in processing every resource to be deleted.
DELETE MUSTが処理で適用されている状態で、どんなヘッダーも、削除されるためにあらゆるリソースを入れました。
When the DELETE method has completed processing it MUST result in a consistent namespace.
DELETEメソッドが、処理するのを完了したとき、それは一貫した名前空間をもたらさなければなりません。
If an error occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status). 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi- Status). They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
誤りがRequest-URIで特定されたリソース以外のリソースで発生するなら、応答は207であるに違いありません(マルチStatus)。 424 (Dependencyに失敗します) 誤りSHOULD NOTは207(マルチStatus)でそうです。 クライアントが、クライアントが先祖の子孫のために誤りを受けるとき、リソースの先祖を削除できなかったのを知るので、安全にそれらを省くことができます。 Content) いいえ、誤りSHOULD NOT。さらに、204、(207(マルチStatus)では、返してください。 この禁止の理由は204(Contentがない)がデフォルト成功コードであるということです。
Goland, et al. Standards Track [Page 35] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[35ページ]。
8.6.2.1 Example - DELETE
8.6.2.1 例--、削除
>>Request
>>要求
DELETE /container/ HTTP/1.1 Host: www.foo.bar
/container/ HTTP/1.1ホストを削除してください: www.foo.bar
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.foo.bar/container/resource3</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
</d:response>
</d:multistatus>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><d:multistatus xmlns:dが等しい、「DAV: 「><d: 応答><d: href>http://www.foo.bar/コンテナ/resource3</d: href><d: 状態>HTTP/1.1 423Locked</d: 状態></d: 応答></d: 「マルチ-状態」>」
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/ を削除する試みがまた、子供が削除されていない場合親を削除できないので失敗したに違いないのを知っています。 Depthヘッダーは含まれていませんが、収集にはメソッドがあるので、無限の深さは想定されます。
8.7 PUT
8.7 置かれました。
8.7.1 PUT for Non-Collection Resources
8.7.1 非収集リソースのために、置かれました。
A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be recomputed during PUT processing but are not otherwise affected. For example, if a server recognizes the content type of the request body, it may be able to automatically extract information that could be profitably exposed as properties.
既存のリソースに実行されたPUTはリソースのGET応答実体を取り替えます。 リソースで定義された特性は、PUT処理の間再計算されるかもしれませんが、別の方法で影響を受けません。 例えば、サーバが要求本体のcontent typeを認識するなら、自動的に有益にばれることができた特性である情報は抜粋できるかもしれません。
A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict).
409(闘争)に応じて、適切に見られた親収集なしでリソースの作成をもたらすPUTは失敗しなければなりません。
Goland, et al. Standards Track [Page 36] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[36ページ]。
8.7.2 PUT for Collections
8.7.2 収集のために、置かれました。
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]に基づき定義されるように、「同封の実体が供給されたRequest-URIの下で保存されるというPUTメソッド要求。」です。 収集を表す実体の服従はそれとなくリソースの作成と削除をコード化するでしょう、したがって、この仕様はPUTを使用することで収集を作成するために故意にトランスミッション書式を定義しません。 代わりに、MKCOLメソッドは、収集を作成するために定義されます。
When the PUT operation creates a new non-collection resource all ancestors MUST already exist. If all ancestors do not exist, the method MUST fail with a 409 (Conflict) status code. For example, if resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, then the request must fail.
PUT操作が新しい非収集リソースを作成するとき、すべての先祖が既に存在しなければなりません。 すべての先祖が存在しないなら、メソッドは409(闘争)ステータスコードで失敗しなければなりません。 例えば、リソース/a/b/c/d.htmlが作成されることになっていて、/a/b/c/が存在していないなら、要求は失敗しなければなりません。
8.8 COPY Method
8.8 コピーメソッド
The COPY method creates a duplicate of the source resource, identified by the Request-URI, in the destination resource, identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource.
COPYメソッドはDestinationヘッダーのURIによって特定された目的地リソースでRequest-URIによって特定されたソースリソースの写しを作成します。 Destinationヘッダーは出席しているに違いありません。 COPYメソッドの正確な振舞いはソースリソースのタイプに頼っています。
All WebDAV compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server.
すべてのWebDAV対応することのリソースが、COPYがメソッドであるとサポートしなければなりません。 しかしながら、COPYメソッドのサポートはリソースをコピーする能力を保証しません。 例えば、別々のプログラムは同じサーバに関するリソースを制御するかもしれません。その結果、同じサーバにあるように見える位置にリソースをコピーするのは可能でないかもしれません。
8.8.1 COPY for HTTP/1.1 resources
8.8.1 HTTP/1.1のリソースのためのCOPY
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.
ソースリソースが収集でないときに、COPYメソッドの結果は州と振舞いができるだけ密接にソースリソースのものに合っている目的地の新しいリソースの作成です。 うまくいっているCOPY実施の後に、ヘッダーとXML要素を変更することを条件として目的地リソースにソースリソースのすべての特性をコピーしなければなりません、特性をコピーするための定義に続いて。 目的地の環境が要素でソースより異なるかもしれないので、外では、リソースの欠如などのサーバの見える範囲が正しい操作に必要であり、目的地にリソースの振舞いを完全にコピーするのは可能でないかもしれません。 目的地リソースへのその後の変更はソースリソースを変更しないでしょう。 ソースリソースへのその後の変更は目的地リソースを変更しないでしょう。
Goland, et al. Standards Track [Page 37] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[37ページ]。
8.8.2. COPY for Properties
8.8.2. 特性のためのコピー
The following section defines how properties on a resource are handled during a COPY operation.
以下のセクションはリソースの特性がCOPY操作の間、どう扱われるかを定義します。
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.
目的地のコピーされた同じくらい同様に振る舞っている精力の特性がリソースであったなら特性のSHOULDを住ませてください。 ライブな状態で特性をコピーできないなら、値をコピーしなければなりません、八重奏のための八重奏、propertybehavior XML要素の効果を条件とした目的地リソースの同様に命名されて、死んでいる所有地で。
The propertybehavior XML element can specify that properties are copied on best effort, that all live properties must be successfully copied or the method must fail, or that a specified list of live properties must be successfully copied or the method must fail. The propertybehavior XML element is defined in section 12.12.
propertybehavior XML要素は、特性がベストエフォート型にコピーされるか、首尾よくすべての精力の特性をコピーしなければならないか、メソッドが失敗しなければならない、首尾よく精力の特性に関する明細表をコピーしなければならないか、またはメソッドが失敗しなければならないと指定できます。 propertybehavior XML要素はセクション12.12で定義されます。
8.8.3 COPY for Collections
8.8.3 収集のためのコピー
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.
まるで値の「無限」があるDepthヘッダーが含まれているかのようにDepthヘッダーのない収集でのCOPYメソッドは行動しなければなりません。 クライアントは収集のときに「0インチか「無限」」の値でCOPYの上のDepthヘッダーを提出するかもしれません。 DAV対応することのサーバは「0インチと「無限」深さヘッダーの振舞い」をサポートしなければなりません。
A COPY of depth infinity instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy.
深さ無限のCOPYは、すべての内部のメンバーリソースがRequest-URIによって特定された収集リソースがDestinationヘッダーの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.
Aがコピーする、「深さ:」 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.
COPY MUSTが処理で適用されている状態で、どんなヘッダーも、Destinationヘッダーを除いて、コピーされるためにあらゆるリソースを入れました。
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.
DestinationヘッダーはRequest-URIに目的地URIを指定するだけです。 Request-URIによって特定された収集のメンバーに適用されると、Destinationの値は現在の位置を階層構造に反映するように変更されることです。 それで、Request URIがHostヘッダー価値の http://fun.com/ と/a/であり、Destinationが http://fun.com/b/ であるなら、 http://fun.com/a/c/d が処理されるとき、それは http://fun.com/b/c/d のDestinationを使用しなければなりません。
Goland, et al. Standards Track [Page 38] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[38ページ]。
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.
COPYメソッドが、処理するのを完了したとき、それは目的地で一貫した名前空間を作成したに違いありません(名前空間の一貫性の定義に関してセクション5.1を見てください)。 しかしながら、誤りが内部の収集をコピーしている間、発生するなら、サーバはこの収集のメンバーによって特定されたどんなリソースもコピーしてはいけません(すなわち、サーバはこの下位木をスキップしなければなりません)、これが矛盾した名前空間を作成するだろうというとき。 誤りを検出した後に、COPY操作SHOULDはできるだけ多くの原本操作を終えようとします(すなわち、サーバが、他の下位木と彼らのメンバーをコピーするのをまだ試みているべきであり、それは誤りを引き起こす収集のdescendentsではありません)。 /a/は収集の/a/b/と/a/c/を含みます。そのように、例えば、無限の深さコピー操作が収集/a/に実行されて、誤りが/a/b/をコピーしながら発生するなら、/a/c/をコピーするのをまだ試みをしているべきです。無限の深さコピーの一部として非収集しているリソースをコピーする誤りに遭遇した後に、同様に、サーバSHOULDはできるだけ多くの原本操作を終えようとします。
If an error in executing the COPY method occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status).
COPYメソッドを実行することにおける誤りがRequest-URIで特定されたリソース以外のリソースで発生するなら、応答は207であるに違いありません(マルチStatus)。
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(失敗したDependency)状態は返されたコネがCOPYメソッドからの207(マルチStatus)応答であったならSHOULD NOTをコード化します。 クライアントが、クライアントが親のために誤りを受けるとき、リソースの子孫をコピーできなかったのを知るので、安全にこれらの応答を省略できます。 さらに、201(作成される)/204(Contentがありません)状態はCOPYからの207における値として返された(マルチStatusの)応答がメソッドであったならSHOULD NOTをコード化します。 それらがデフォルト成功コードであるので、また、安全にそれらを省略できます。
8.8.4 COPY and the Overwrite Header
8.8.4 コピーと重ね書きヘッダー
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.
リソースが目的地とOverwriteヘッダーに存在しているならそして、サーバが実行しなければならないコピーを実行する前の「T」がaである、削除、「深さ:」 目的地リソースに関する「無限。」 Overwriteヘッダーが「F」に用意ができていると、操作は失敗するでしょう。
8.8.5 Status Codes
8.8.5 ステータスコード
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 (Contentがありません)--ソースリソースは首尾よく先在の目的地リソースにコピーされました。
403 (Forbidden) _ The source and destination URIs are the same.
403 (禁じられます) _ソースと目的地URIは同じです。
Goland, et al. Standards Track [Page 39] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[39ページ]。
409 (Conflict) _ A resource cannot be created at the destination until one or more intermediate collections have been created.
1つ以上の中間的収集が作成されるまで、目的地で409(闘争)_Aリソースを作成できません。
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 (前提条件Failed)--サーバはpropertybehavior XML要素かOverwriteヘッダーに記載された特性の活性が「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 (不十分なStorage)--目的地リソースには、このメソッドの実行の後にリソースの状態を記録できるくらいのスペースがありません。
8.8.6 Example - COPY with Overwrite
8.8.6 例--重ね書きで、コピーしてください。
This example shows resource http://www.ics.uci.edu/~fielding/index.html being copied to the location http://www.ics.uci.edu/users/f/fielding/index.html. The 204 (No Content) status code indicates the existing resource at the destination was overwritten.
この例は、リソース http://www.ics.uci.edu/~fielding/index.html が位置の http://www.ics.uci.edu/users/f/fielding/index.html までコピーされるのを示します。 204(Contentがない)ステータスコードは、目的地の既存のリソースが上書きされたのを示します。
>>Request
>>要求
COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html
コピー/~フィールディング/index.html HTTP/1.1ホスト: 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いいえ内容
8.8.7 Example - COPY with No Overwrite
8.8.7 例--重ね書きなしでコピーしてください。
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.
以下の例は、同じコピー操作が実行されますが、Overwriteヘッダーセットであるのを「F.」に示します。 目的地リソースには非ヌル状態があるので、412(前提条件Failed)の応答を返します。
>>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
コピー/~フィールディング/index.html HTTP/1.1ホスト: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html 重ね書き: F
Goland, et al. Standards Track [Page 40] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[40ページ]。
>>Response
>>応答
HTTP/1.1 412 Precondition Failed
HTTP/1.1 412前提条件は失敗しました。
8.8.8 Example - COPY of a Collection
8.8.8 例--収集のコピー
>>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
/container/ HTTP/1.1ホストをコピーしてください: www.foo.bar Destination: http://www.foo.bar/othercontainer/ の深さ: 無限コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d="DAV:">
<d:keepalive>*</d:keepalive>
</d:propertybehavior>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><d:propertybehavior xmlns:dが等しい、「DAV: 「><d: keepalive>*</d: keepalive></d: propertybehavior>」
>>Response
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.foo.bar/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 412 Precondition Failed</d:status>
</d:response>
</d:multistatus>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><d:multistatus xmlns:dが等しい、「DAV: 「><d: 応答><d: href>http://www.foo.bar/othercontainer/R2/</d: href><d: 状態>HTTP/1.1 412Precondition Failed</d: 状態></d: 応答></d: 「マルチ-状態」>」
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example most of the resources, along with the collection, were copied successfully. However the collection R2 failed, most likely due to a problem with maintaining the liveness of properties (this is specified by the propertybehavior XML element). Because there was an error copying R2, none of R2's members were copied. However no errors were listed for those members due to the error minimization rules given in section 8.8.3.
Depthヘッダーが収集のCOPYのデフォルト動きが行動することであるので不要である、「深さ:」 「無限」ヘッダーを提出しました。 この例では、リソースの大部分は収集と共に首尾よくコピーされました。 しかしながら、収集R2は失敗しました、たぶん特性の活性を維持することに関する問題のため(これはpropertybehavior XML要素によって指定されます)。 R2をコピーする誤りがあったので、R2のメンバーのだれもコピーされませんでした。 しかしながら、誤りは全くセクション8.8.3で与えられた誤り最小化規則のためそれらのメンバーのために記載されませんでした。
Goland, et al. Standards Track [Page 41] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[41ページ]。
8.9 MOVE Method
8.9 移動メソッド
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.
続かれて、非収集リソースにおけるMOVE操作は一貫性メインテナンス処理があとに続いたコピー(COPY)の論理的な同等物です。aはソースに削除します。そこでは、すべての3つの動作が原子論的に実行されます。 サーバは一貫性メインテナンスステップで移動で引き起こされたアップデートを実行できます、Request-URI以外の新しい目的地リソースを示すためにソースリソースを特定するすべてのURIをアップデートするのなどように。 その結果、Destinationヘッダーは、すべてのMOVEメソッドに存在していなければならなくて、MOVEメソッドのCOPY部分にすべてのCOPY要件の後をつけなければなりません。 すべてのDAV対応することのリソースが、MOVEがメソッドであるとサポートしなければなりません。 しかしながら、MOVEメソッドのサポートは特定の目的地へのリソースを運動能力に保証しません。
For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server.
例えば、別々のプログラムは実際に異なったセットの同じサーバに関するリソースを制御するかもしれません。したがって、同じサーバに属すように見える名前空間の中でリソースを動かすのは可能でないかもしれません。
If a resource exists at the destination, the destination resource will be DELETEd as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
リソースが目的地に存在していると、目的地リソースはOverwriteヘッダーの制限を条件としたMOVE操作の副作用としてDELETEdになるでしょう。
8.9.1 MOVE for Properties
8.9.1 特性を提議してください。
The behavior of properties on a MOVE, including the effects of the propertybehavior XML element, MUST be the same as specified in section 8.8.2.
propertybehavior XML要素の効果を含むMOVEにおける特性の動きはセクション8.8.2で指定されるのと同じであるに違いありません。
8.9.2 MOVE for Collections
8.9.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.
Aが移行する、「深さ:」 「無限」は、Request-URIによって特定された収集がDestinationヘッダーで指定されたURIに動かされるよう命令します、そして、内部のメンバーURIによって特定されたすべてのリソースは収集階層構造のすべてのレベルを通してそれに比例して位置に再帰的に動かされることです。
The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity".
収集でのMOVEメソッドが行動しなければならない、「深さ:」 「無限」ヘッダーはそれで使用されました。 クライアントは収集のときにどんな値にもかかわらず、「無限」でもMOVEの上のDepthヘッダーを提出してはいけません。
Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header.
MOVE MUSTが処理で適用されている状態で、どんなヘッダーも、Destinationヘッダーを除いて、動かされるためにあらゆるリソースを入れました。
The behavior of the Destination header is the same as given for COPY on collections.
Destinationヘッダーの動きは収集のときにCOPYのために与えるのと同じです。
Goland, et al. Standards Track [Page 42] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[42ページ]。
When the MOVE method has completed processing it MUST have created a consistent namespace at both the source and destination (see section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members, that are not descendents of an error-causing collection). So, for example, if an infinite depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite depth move, the server SHOULD try to finish as much of the original move operation as possible.
MOVEメソッドが、処理するのを完了したとき、それはソースと目的地の両方で一貫した名前空間を作成したに違いありません(名前空間の一貫性の定義に関してセクション5.1を見てください)。 しかしながら、誤りが内部の収集が感動的である間、発生するなら、サーバは失敗した収集のメンバーによって特定されたどんなリソースも動かしてはいけません(すなわち、サーバは誤りを引き起こす下位木をスキップしなければなりません)、これが矛盾した名前空間を作成するだろうというとき。 この場合、誤りを検出した後に、移動命令SHOULDはできるだけ多くのオリジナルの移動を終えようとします(すなわち、サーバが、彼らのメンバーによって特定された他の下位木とリソースを動かすのをまだ試みているべきであり、それは誤りを引き起こす収集のdescendentsではありません)。 /a/は収集の/a/b/と/a/c/を含みます。そのように、例えば、無限の深さ移動が収集/a/に実行されて、誤りが/a/b/を動かしながら発生するなら、/a/c/を動かしてみるのをまだ試みをしているべきです。無限の深さ移動の一部として非収集リソースを動かす誤りに遭遇した後に、同様に、サーバSHOULDはできるだけ多くのオリジナルの移動命令を終えようとします。
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であるに違いありません(マルチStatus)。
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(失敗したDependency)状態は返されたコネがMOVEメソッドからの207(マルチStatus)応答であったならSHOULD NOTをコード化します。 クライアントが、クライアントが親のために誤りを受けるとき、リソースの子孫を動かすことができなかったのを知るので、安全にこれらの誤りを省略できます。 Content) いいえ、応答SHOULD NOT。さらに、201(作成される)/204、(207(マルチStatus)の応答における値として、MOVEから、返してください。 それらがデフォルト成功コードであるので、安全にこれらの応答を省略できます。
8.9.3 MOVE and the Overwrite Header
8.9.3 移動と重ね書きヘッダー
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.
リソースが目的地とOverwriteヘッダーに存在しているならそして、サーバが実行しなければならない移動を実行する前の「T」がaである、削除、「深さ:」 目的地リソースに関する「無限。」 Overwriteヘッダーが「F」に用意ができていると、操作は失敗するでしょう。
8.9.4 Status Codes
8.9.4 ステータスコード
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 (Contentがありません)--ソースリソースは首尾よく先在の目的地リソースに動かされました。
403 (Forbidden) _ The source and destination URIs are the same.
403 (禁じられます) _ソースと目的地URIは同じです。
Goland, et al. Standards Track [Page 43] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[43ページ]。
409 (Conflict) _ A resource cannot be created at the destination until one or more intermediate collections have been created.
1つ以上の中間的収集が作成されるまで、目的地で409(闘争)_Aリソースを作成できません。
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 (前提条件Failed)--サーバはpropertybehavior XML要素かOverwriteヘッダーに記載された特性の活性が「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 (悪いゲートウェイ)--目的地が別のサーバにあって、目的地サーバが、リソースを受け入れるのを拒否するとき、これは起こるかもしれません。
8.9.5 Example - MOVE of a Non-Collection
8.9.5 例--非収集の移動
This example shows resource http://www.ics.uci.edu/~fielding/index.html being moved to the location http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination resource had been non-null. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
この例は、リソース http://www.ics.uci.edu/~fielding/index.html が位置の http://www.ics.uci.edu/users/f/fielding/index.html に動かされるのを示します。 目的地リソースが非ヌルであったなら、目的地リソースのコンテンツは上書きされたでしょうに。 目的地リソースには何もなかったので、この場合、応答コードは201(作成される)です。
>>Request
>>要求
MOVE /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html
移動/~フィールディング/index.html HTTP/1.1ホスト: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html
>>Response
>>応答
HTTP/1.1 201 Created Location: http://www.ics.uci.edu/users/f/fielding/index.html
HTTP/1.1 201は位置を作成しました: http://www.ics.uci.edu/users/f/fielding/index.html
8.9.6 Example - MOVE of a Collection
8.9.6 例--収集の移動
>>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
/container/ HTTP/1.1ホストを動かしてください: www.foo.bar Destination: http://www.foo.bar/othercontainer/ 重ね書き: F、: (<opaquelocktoken: fe184f2e-6eec-41d0-c765-01adc56e6bb4>) (<opaquelocktoken: e454f3f3-acdc-452a-56c7-00a5c91e4b77>) コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
Goland, et al. Standards Track [Page 44] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[44ページ]。
<?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d='DAV:'>
<d:keepalive>*</d:keepalive>
</d:propertybehavior>
<?xmlバージョン=「1インチのコード化=「utf-8インチ?><d:propertybehavior xmlns:dは'DAV:'><dと等しいです: </d: keepalive></d: keepalive>*propertybehavior>'」
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d='DAV:'>
<d:response>
<d:href>http://www.foo.bar/othercontainer/C2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status>
</d:response>
</d:multistatus>
<?xmlバージョンは「=「utf-8インチ?><d:multistatus xmlns:d='DAVをコード化する1インチ: '><d: 応答><d: href>http://www.foo.bar/othercontainer/C2/</d: href><d: 状態>HTTP/1.1 423Locked</d: 状態></d: 応答></d: 「マルチ-状態」>'」と等しいです。
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/ に提出しませんでした。これは、リソース/container/C2/を動かすことができなかったことを意味します。 /container/C2/をコピーする誤りがあったので、/container/C2のメンバーのだれもコピーされませんでした。 しかしながら、誤りは全くセクション8.8.3で与えられた誤り最小化規則のためそれらのメンバーのために記載されませんでした。 ユーザエージェント認証は以前にHTTPプロトコルの範囲の外のメカニズムで起こりました、基本的なトランスポート層の中で。
8.10 LOCK Method
8.10 ロックメソッド
The following sections describe the LOCK method, which is used to take out a lock of any access type. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested.
以下のセクションはLOCKメソッドを説明します。(それは、どんなアクセス型の錠も取り出すのに使用されます)。 LOCKメソッドのこれらのセクションは、LOCKメソッドに特定の状態でそれらの意味論だけについて説明して、要求されている錠のアクセス型から独立しています。
Any resource which supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein.
最小限で、LOCKがメソッドであるとサポートするどんなリソースも、XML要求と応答がここに定義された書式であると、サポートしなければなりません。
Goland, et al. Standards Track [Page 45] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[45ページ]。
8.10.1 Operation
8.10.1 操作
A LOCK method invocation creates the lock specified by the lockinfo XML element on the Request-URI. Lock method requests SHOULD have a XML request body which contains an owner XML element for this lock request, unless this is a refresh request. The LOCK request may have a Timeout header.
LOCKメソッド実施はRequest-URIのlockinfo XML要素によって指定された錠を作成します。 SHOULDには所有者XML要素を含むXML要求ボディーがあるというロックメソッド要求はこれがこのロック要求aでないなら要求をリフレッシュします。 LOCK要求には、Timeoutヘッダーがあるかもしれません。
Clients MUST assume that locks may arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if "extraordinary" circumstances do not occur. For example, an administrator may remove a lock at any time or the system may crash in such a way that it loses the record of the lock's existence. The response MUST contain the value of the lockdiscovery property in a prop XML element.
クライアントは、錠がいつでもTimeoutヘッダーで与えられた値にかかわらず任意に見えなくなるかもしれないと仮定しなければなりません。 「並はずれた」事情が現れない場合にだけ、Timeoutヘッダーはサーバの働きを示します。 例えば、管理者がいつでも、錠を取り外すかもしれませんか、またはシステムは錠の存在に関する記録を失うような方法でダウンするかもしれません。 応答は支柱XML要素のlockdiscovery属性の価値を含まなければなりません。
In order to indicate the lock token associated with a newly created lock, a Lock-Token response header MUST be included in the response for every successful LOCK request for a new lock. Note that the Lock-Token header would not be returned in the response for a successful refresh LOCK request because a new lock was not created.
新たに作成された錠に関連しているロックトークンを示すために、新しい錠を求めるあらゆるうまくいっているLOCK要求のための応答にLock-トークン応答ヘッダを含まなければなりません。 新しい錠が作成されなかったので、Lock-トークンヘッダーがaのための応答でうまくいった状態で返されないだろうというメモはLOCK要求をリフレッシュします。
8.10.2 The Effect of Locks on Properties and Collections
8.10.2 特性と収集への錠の効果
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.
また、収集のために、錠はメンバーを加えるか、または免職する能力に影響します。 効果の本質はコントロールがかかわったアクセスのタイプに頼っています。
8.10.3 Locking Replicated Resources
8.10.3 ロックはリソースを模写しました。
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.
リソースを1つ以上のURIを通して利用可能にするかもしれません。 しかしながら、錠はURIではなく、リソースに適用されます。 したがって、缶が光栄に思わないなら、リソースに関するLOCK要求はリソースがアドレス可能であるすべてのURIで成功してはいけません。
8.10.4 Depth and Locking
8.10.4 深さとロック
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.
DepthヘッダーはLOCKメソッドで使用されるかもしれません。 LOCKメソッドのDepthヘッダーと共に0か無限以外の値を使用してはいけません。 LOCKがメソッドであるとサポートするすべてのリソースがDepthヘッダーを支えなければなりません。
A Depth header of value 0 means to just lock the resource specified by the Request-URI.
価値0のDepthヘッダーは、ただRequest-URIによって指定されたリソースをロックするのを意図します。
Goland, et al. Standards Track [Page 46] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[46ページ]。
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.
Depthヘッダーが無限で用意ができているなら、リソースがRequest-URIですべての内部のメンバーと、いっぱいな階層構造の下側に指定されて、ロックされることになっていてください。 好成績はロックされたすべてのリソースを表すただ一つのロックトークンを返さなければなりません。 UNLOCKがこのトークンで首尾よく実行されるなら、すべての関連リソースの錠は開いています。 すべてのリソースに錠を与えることができないなら、応答実体本体がどのリソースが、錠が与えられるのを防いだかを説明するmultistatus 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.
LOCK要求のときにDepthヘッダーを全く提出しないなら要求が行動しなければならない、「深さ: 無限」を提出しました。
8.10.5 Interaction with other Methods
8.10.5 他のMethodsとの相互作用
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.
様々なメソッドとのLOCKの相互作用はロックタイプに依存しています。 しかしながら、ロックタイプの如何にかかわらず、リソースのうまくいっているDELETEは錠のすべてを取り除かせなければなりません。
8.10.6 Lock Compatibility Table
8.10.6 ロック互換性テーブル
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* ------------------------------------------------------
現在のロック状態/| 共有された錠| 排他的なLock要求| | 錠=====================+=================+============== なし| 本当| 本当---------------------+-----------------+-------------- 共有された錠| 本当| 誤る---------------------+-----------------+-------------- 排他的な錠| 誤る| 誤った*------------------------------------------------------
Legend: True = lock may be granted. False = lock MUST NOT be granted. *=It is illegal for a principal to request the same lock twice.
伝説: 本当の=錠を与えるかもしれません。 偽の=錠を与えてはいけません。 *=元本が二度同じ錠を要求するのは、不法です。
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.
一番左コラムでリソースの現在のロック状態を与えます、そして、ファースト・ローにロック要求をリストアップします。 行と1つのコラムの交差点はロック要求の結果を与えます。 例えば、共有された錠がリソースで持たれて、排他的な錠が要求されるなら、テーブル項目は「誤っています」、錠を与えてはいけないのを示して。
Goland, et al. Standards Track [Page 47] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[47ページ]。
8.10.7 Status Codes
8.10.7 ステータスコード
200 (OK) - The lock request succeeded and the value of the lockdiscovery property is included in the body.
200 (OK)--ロック要求は成功して、lockdiscovery属性の価値はボディーに含まれています。
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 (前提条件Failed)--含まれているロックトークンがこのリソースで実施できなかったか、またはサーバはlockinfo XML要素における要望に応じることができませんでした。
423 (Locked) - The resource is locked, so the method has been rejected.
423 (ロックされます)--リソースがロックされるので、メソッドは拒絶されました。
8.10.8 Example - Simple Lock Request
8.10.8 例--簡単なロック要求
>>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="..."
/workspace/webdav/proposal.doc HTTP/1.1ホストをロックしてください: webdav.sb.aol.com Timeout: 無限の2番目-4100000000コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx Authorization: 「」 ダイジェストユーザ名="ejw"、分野=" ejw@webdav.sb.aol.com "一回だけ=…」, 「uriは"/workspace/webdav/proposal.doc"と等しく、応答は」 …と等しいです」, 「不透明なものは」 …と等しいです」
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
<?xmlバージョンは「1インチのコード化は「utf-8インチ?><D:lockinfo xmlns:Dは'DAV:'><D: lockscope><D: 排他的な/></D: lockscope><D: locktype><Dと等しいです: /></D: locktype><D: 所有者><D: href>http://www.ics.uci.edu/~ejw/contact.html</D: href></D: 所有者></D: lockinfo>に書いてください'と等しいこと」と等しいです。
>>Response
>>応答
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 200はコンテントタイプを承認します: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>Infinity</D:depth>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 支柱xmlns: Dが等しい、「DAV: 「><D: lockdiscovery><D: activelock><D: locktype><D: : 深さ>Infinity</D: /></D: locktype><D: lockscope><D: 排他的な/></D: lockscope><D徹底的な>に書いてください」
Goland, et al. Standards Track [Page 48] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[48ページ]。
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D: 所有者><D: href> http://www.ics.uci.edu/~ejw/contact.html </D: href></D: 所有者><D: タイムアウト>Second-604800</D: タイムアウト><D: locktoken><D: href>opaquelocktoken: e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D: href></D: locktoken></D: activelock></D: lockdiscovery></D: >を支えてください。
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秒)後に自動的に錠を取り外します)。 一回だけ、応答、および不透明な分野がAuthorization要求ヘッダーで計算されていないことに注意してください。
8.10.9 Example - Refreshing a Write Lock
8.10.9 例--aをリフレッシュして、錠を書いてください。
>>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="..."
/workspace/webdav/proposal.doc HTTP/1.1ホストをロックしてください: webdav.sb.aol.com Timeout: 無限、2番目-4100000000、: (<opaquelocktoken: e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) 認可: 「」 ダイジェストユーザ名="ejw"、分野=" ejw@webdav.sb.aol.com "一回だけ=…」, 「uriは"/workspace/webdav/proposal.doc"と等しく、応答は」 …と等しいです」, 「不透明なものは」 …と等しいです」
>>Response
>>応答
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 200はコンテントタイプを承認します: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 支柱xmlns: Dが等しい、「DAV: 「><D: lockdiscovery><D: activelock><D: locktype><D: /></D: locktype>に書いてください」
Goland, et al. Standards Track [Page 49] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[49ページ]。
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>Infinity</D:depth>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D: lockscope><D: 排他的な/></D: lockscope><D: 深さ>無限</D: 深さ><D: 所有者><D: href> http://www.ics.uci.edu/~ejw/contact html</D: href></D: 所有者><D: タイムアウト>Second-604800</D: タイムアウト><D: locktoken><D: href>opaquelocktoken: e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D: href></D: locktoken></D: activelock></D: lockdiscovery></D: >を支えてください。
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.
いつでもアウトをリセットして、この要求は錠をリフレッシュするでしょう。 無限のタイムアウトにもかかわらず、サーバが求められたクライアントが、要求を無視するのを選ぶのに注意してください。 この例では、一回だけ、応答、および不透明な分野はAuthorization要求ヘッダーで計算されていません。
8.10.10 Example - Multi-Resource Lock Request
8.10.10 例--マルチリソースロック要求
>>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="..."
/webdav/ HTTP/1.1ホストをロックしてください: webdav.sb.aol.com Timeout: 無限の2番目-4100000000の深さ: 無限コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx Authorization: 「」 ダイジェストユーザ名="ejw"、分野=" ejw@webdav.sb.aol.com "一回だけ=…」, 「uriは"/workspace/webdav/proposal.doc"と等しく、応答は」 …と等しいです」, 「不透明なものは」 …と等しいです」
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D="DAV:">
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:lockinfo xmlns:Dが等しい、「DAV: 「><D: locktype><D: : href>http://www.ics.uci.edu/~ejw/contact.html</D: href></D: 所有者></D: /></D: locktype><D: lockscope><D: 排他的な/></D: lockscope><D: 所有者><D lockinfo>に書いてください」
>>Response
>>応答
Goland, et al. Standards Track [Page 50] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[50ページ]。
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
<D:response>
<D:href>http://webdav.sb.aol.com/webdav/</D:href>
<D:propstat>
<D:prop><D:lockdiscovery/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:multistatus xmlns:Dが等しい、「DAV: 「: ><D: 応答><D: href>http://webdav.sb.aol.com/webdav/秘密</D: href><D: 状態>HTTP/1.1 403Forbidden</D: 状態></D: 応答><D: 応答><D href>http://webdav。」; sb.aol.com/webdav/</D: href><D: propstat><D: ><D: lockdiscovery/></Dを支えてください: ><D: 状態の>HTTP/1.1 424の失敗した依存</D: 状態></D: propstat></D: 応答></D: 「マルチ-状態」>を支えてください。
This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock, in this case a web page URL.
この例が要求を示している、排他的である、収集とそのすべての子供の上に錠を書いてください。 この要求では、クライアントは利用可能であるなら無限の長さの錠を望んでいて、そうでなければ、41億のタイムアウトが秒であると指定しました、利用可能であるなら。 要求実体本体は錠を取り出す校長、この場合ウェブページURLのための問い合わせ先を含んでいます。
The error is a 403 (Forbidden) response on the resource http://webdav.sb.aol.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the lockdiscovery property for the Request-URI has been included as required. In this example the lockdiscovery property is empty which means that there are no outstanding locks on the resource.
誤りはリソース http://webdav.sb.aol.com/webdav/secret における403(禁じられる)応答です。 このリソースをロックできなかったので、リソースのいずれもロックされませんでした。 また、Request-URIのためのlockdiscoveryの特性が必要に応じて含まれていることに注意してください。 この例では、lockdiscoveryの特性は空です(どんな傑出している錠もリソースにないことを意味します)。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、一回だけ、応答、および不透明な分野はAuthorization要求ヘッダーで計算されていません。
8.11 UNLOCK Method
8.11 アンロック方法
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.
Lock-象徴要求ヘッダーでロック象徴によってRequest-URIから特定されて、錠に他のすべてのリソースを含んでいて、UNLOCK方法は錠を取り外します。 提出されたロック象徴の下でロックされたすべてのリソースの錠が開くことができないなら、UNLOCK要求は失敗しなければなりません。
Any DAV compliant resource which supports the LOCK method MUST support the UNLOCK method.
LOCK方法を支持するどんなDAV対応することのリソースもUNLOCK方法を支持しなければなりません。
Goland, et al. Standards Track [Page 51] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[51ページ]。
8.11.1 Example - UNLOCK
8.11.1 例--アンロック
>>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="..."
/workspace/webdav/info.doc HTTP/1.1ホストをアンロックしてください: webdav.sb.aol.com Lock-象徴: <opaquelocktoken: a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>認可: 「」 ダイジェストユーザ名="ejw"、分野=" ejw@webdav.sb.aol.com "一回だけ=…」, 「uriは"/workspace/webdav/proposal.doc"と等しく、応答は」 …と等しいです」, 「不透明なものは」 …と等しいです」
>>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(Contentがない)ステータスコードは200(OK)の代わりに使用されます。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、一回だけ、応答、および不透明な分野はAuthorization要求ヘッダーで計算されていません。
9 HTTP Headers for Distributed Authoring
分配されたオーサリングのための9つのHTTPヘッダ
9.1 DAV Header
9.1 DAVヘッダー
DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
「DAVは"DAV"と等しい」:、」 "1" ["," "2"] [「」、#、が広げる1]
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対応することのリソースがすべてのOPTIONS応答のときに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を参照してください。 一般に、しかしながら、1つの承諾クラスのサポートはいかなる他のサポートも伴いません。
9.2 Depth Header
9.2 深さヘッダー
Depth = "Depth" ":" ("0" | "1" | "infinity")
「深さは「深さ」と等しい」:、」 (「0インチ|、「1インチ| 「無限」、)、」
Goland, et al. Standards Track [Page 52] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[52ページ]。
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").
Depthヘッダーが方法がリソースだけに適用されるかどうかことであることを示すのに潜在的に内部のメンバーを持つことができたリソースで実行される方法で使用される、(「深さ: 0インチ)、リソースとその即座の子供に(「深さ: 1インチ)、リソースとそのすべての子孫(「深さ: 無限」)、」
The Depth header is only supported if a method's definition explicitly provides for such support.
方法の定義が明らかにそのようなサポートに備える場合にだけ、Depthヘッダーは支えられます。
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.
以下の規則はDepthヘッダーを支えるどんな方法のためのデフォルトの振舞いです。 方法は、定義における異なった振舞いを定義することによって、これらのデフォルトをくつがえすかもしれません。
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.
Depthヘッダーを支える方法は、ヘッダーの値のすべてを支持しないのを選んで、定義されるかもしれません、オンである、ケースバイケース、基礎、方法の振舞いはDepthヘッダーであるなら存在していません。 例えば、MOVE方法が支持するだけである、「深さ:」 「無限」とDepthヘッダーが現在の意志の条例でないかどうか、「深さ:」 「無限」ヘッダーは適用されました。
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.
実行のときに、Depthヘッダーがある方法は、できるだけ多くの割り当てられた仕事を実行して、次に、何を達成できたか、そして、それが何をしなかったかを指定する応答を返すでしょう。
So, for example, an attempt to COPY a hierarchy may result in some of the members being copied and some not.
そのように、例えば、COPY a階層構造への試み。コピーされるメンバーの何人かの結果と何かはそうしませんように。
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.
代替の振舞いが明らかに定義されるところ以外の方法の範囲のすべてのリソースにDepthヘッダーとの定義された相互作用を持っている方法のどんなヘッダーも適用しなければなりません。 例えば、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.
Depthヘッダーがある方法の範囲の中でリソース、ソースまたは目的地を方法のうまくいっている実行を防ぐほどそのような方法でロックするなら、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.
Depthヘッダーはあいさつによる方法の振舞いを内部の子供に指定するだけです。 リソースに内部の子供がいないなら、Depthヘッダーを無視しなければなりません。
Goland, et al. Standards Track [Page 53] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[53ページ]。
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.
しかしながら、方法の定義で許容されていないDepthヘッダーのために値を提出するために、いつもそれは誤りです。 その結果、aを提出する、「深さ:」 リソースに内部のメンバーがいないでも、COPYの上の1インチは400(悪いRequest)をもたらすでしょう。 方法はリソースには内部のメンバーがいませんが、ヘッダーの不法な値で失敗するべきです。
9.3 Destination Header
9.3 目的地ヘッダー
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].
Destinationヘッダーはパラメタとして2つのURIをみなすCOPYやMOVEなどの方法のための目的地リソースを特定するURIを指定します。 absoluteURI生産が[RFC2396]で定義されることに注意してください。
9.4 If Header
9.4、ヘッダーです。
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List
Tagged-list = Resource 1*List
Resource = Coded-URL
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
State-token = Coded-URL
Coded-URL = "<" absoluteURI ">"
「=“If"であるなら」:、」 (1*いいえ、タグリスト| 1つの*タグ付けをされたリスト) リストTagged-リスト=リソース1タグリストがない=*リストResourceがコード化されたURL List=と等しい、「(「1*[“Not"]、(州象徴|、「[「実体タグ」]」)、」、)、」 州象徴=コード化されたURLコード化されたURL="<"absoluteURI">"
The If header is intended to have similar functionality to the If- Match header defined in section 14.25 of [RFC2068]. However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification.
Ifヘッダーが[RFC2068]のセクション14.25で定義されたIfマッチヘッダーに同様の機能性を持っていることを意図します。 しかしながら、IfヘッダーはETagsと同様にリソースに関して州の象徴と呼ばれた州の情報を表すどんな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.
Ifヘッダーの目的は一連の州のリストについて説明することです。 ヘッダーが適用されているリソースの州が指定された州のリストのいずれにも合っていないなら、要求は412で失敗しなければなりません(Failedをあらかじめ調整してください)。 説明された州のリストの1つがリソースの状態に合っているなら、要求は成功するかもしれません。
Note that the absoluteURI production is defined in [RFC2396].
absoluteURI生産が[RFC2396]で定義されることに注意してください。
Goland, et al. Standards Track [Page 54] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[54ページ]。
9.4.1 No-tag-list Production
9.4.1 タグリストがない生産
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.
タグリストがない生産は一連の州の象徴とETagsについて説明します。 複数のタグリストがない創作が使用されているなら、人は、続くのが許容されるべき方法のためのリソースの状態を合わせる必要があるだけです。
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.
方法がDepthかDestinationヘッダーの存在のため複数のリソースに適用されるなら、方法が適用される各リソースにタグリストがない生産を適用しなければなりません。
9.4.1.1 Example - No-tag-list If Header
9.4.1.1 例--タグリストがない、ヘッダーです。
If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another ETag"])
: (<locktoken: aロック象徴を書いている>[「私はETagです」]) ([「私は別の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です」ETagによって特定された州か第2ETag「私は別のETagであること」によって特定された状態でメソッドの範囲の中のどんなリソースもロックしなければならないのを必要とするでしょう。 または、 より明らかにその物質を置くために、人がフォームにいると前のIfヘッダーを思うことができる、((<locktoken: そして、aロックトークンを書いている>[「私はETagである」)(そして、[「私は別のETagです」])。)
9.4.2 Tagged-list Production
9.4.2 タグ付けをされたリスト生産
The tagged-list production scopes a list production. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any.
タグ付けをされたリスト生産はリスト生産を見ます。 すなわち、リソース仕様に従うリストが指定されたリソースに適用されるだけであるのは指定します。 リソース生産の範囲は、リスト生産がすぐにリソース生産に続いていて始まって、次のリソース生産でもしあれば終わります。
When the If header is applied to a particular resource, the Tagged- list productions MUST be searched to determine if any of the listed resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section.
Ifヘッダーが特定のリソースに適用されるとき、記載されたリソースのどれかが現在のメソッドのためのオペランドリソースに合っているかどうか決定するためにTaggedリスト創作を捜さなければなりません。 リソース創作のいずれも現在のリソースに合っていないなら、ヘッダーを無視しなければなりません。 リソース創作の1つが考慮中にリソースの名前に合っているなら、リソース生産に続くリスト創作を前項で指定された方法によるリソースに適用しなければなりません。
The same URI MUST NOT appear more than once in a resource production in an If header.
同じURIはIfヘッダーでリソース生産で一度より多く見えてはいけません。
Goland, et al. Standards Track [Page 55] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[55ページ]。
9.4.2.1 Example - Tagged List If header
9.4.2.1 例--List 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"])
コピー/resource1HTTP/1.1ホスト: www.foo.bar Destination: http://www.foo.bar/resource2 、: 「<http://www.foo.bar/resource1>、(<はlocktokenされます: aロックトークンの>の[W/"Aの弱いETagに書きます」である、)、([「強いETag」])<http://www.bar.bar/無作為の>。([「別の強い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ロックトークンの>の[W/"Aの弱いETagに書きます」である、)、([「強いETag」])、」、ロックトークンですなわち、それをロックしなければならない、弱い実体にW/「A弱いETag」にタグ付けをさせるか、または「locktoken: aはロックトークンを書い」て、強い実体はそれで「強いETag」にタグ付けをしなければなりません。
That is the only success condition since the resource http://www.bar.bar/random never has the method applied to it (the only other resource listed in the If header) and http://www.foo.bar/resource2 is not listed in the If header.
すなわち、唯一の成功状態は、リソース http://www.bar.bar/random がそれ(Ifヘッダーにリストアップされた他の唯一のリソース)と http://www.foo.bar/resource2 にメソッドを決して適用させないので、Ifヘッダーにリストアップされていません。
9.4.3 not Production
9.4.3 生産でない
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を合わせる操作が本当の、または、誤った値に決議する論理演算子。 どんな生産も、その値を逆にするのに使用されません。 範囲、どんな生産も、すぐにそれに続く州トークンでなくて、またまたは実体タグでもありません。
If: (Not <locktoken:write1> <locktoken:write2>)
: (<locktoken: write1><locktoken: write2>でない)
When submitted with a request, this If header requires that all operand resources must not be locked with locktoken:write1 and must be locked with locktoken:write2.
要求で提出すると、このIfヘッダーが、すべてのオペランドリソースをlocktoken: write1でロックされてはいけなくて、locktokenでロックしなければなりません: write2が必要です。
9.4.4 Matching Function
9.4.4 マッチングは機能します。
When performing If header processing, the definition of a matching state token or entity tag is as follows.
Ifヘッダー処理を実行するとき、合っている州のトークンか実体タグの定義は以下の通りです。
Matching entity tag: Where the entity tag matches an entity tag associated with that resource.
合っている実体タグ: 実体タグが合っているところでは、実体タグはそのリソースと交際しました。
Matching state token: Where there is an exact match between the state token in the If header and any state token on the resource.
マッチングはトークンを述べます: Ifヘッダーの州のトークンとどんな州のトークンとの完全な一致もリソースにあるところ。
Goland, et al. Standards Track [Page 56] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[56ページ]。
9.4.5 If Header and Non-DAV Compliant Proxies
9.4.5 ヘッダーと非DAVの言いなりになっているプロキシです。
Non-DAV compliant proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the "Cache-Control: no-cache" request header MUST be used so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" request header MUST be used for the same reason.
非DAVの言いなりになっているプロキシはIfヘッダーを尊敬しないでしょう、彼らがIfヘッダーを理解しないで、HTTPが、非理解されているヘッダーが無視されるのを必要とするので。 HTTP/1.1のプロキシとコミュニケートするとき「キャッシュ制御:」 キャッシュからプロキシが不適切に要求を修理しようとするのを防ぐのに「キャッシュがありません」要求ヘッダーを使用しなければなりません。 HTTP/1.0のプロキシに対処する、「Pragma:」 同じ理由から「キャッシュがありません」要求ヘッダーを使用しなければなりません。
9.5 Lock-Token Header
9.5 ロックトークンヘッダー
Lock-Token = "Lock-Token" ":" Coded-URL
「ロックトークン=「ロックトークン」」:、」 コード化されたURL
The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed. The lock token in the Lock-Token request header MUST identify a lock that contains the resource identified by Request-URI as a member.
Lock-トークン要求ヘッダーは取り除くために錠を特定するUNLOCKメソッドで使用されます。 Lock-トークン要求ヘッダーのロックトークンはメンバーとしてRequest-URIによって特定されたリソースを含む錠を特定しなければなりません。
The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.
Lock-トークン応答ヘッダは新しい錠を作成するといううまくいっているLOCK要求の結果、作成されたロックトークンを示すLOCKメソッドで使用されます。
9.6 Overwrite Header
9.6 重ね書きヘッダー
Overwrite = "Overwrite" ":" ("T" | "F")
「重ね書き=「重ね書き」」:、」 (「T」| 「F」)
The Overwrite header specifies whether the server should overwrite the state of a non-null destination resource during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the state of the destination resource is non-null. If the overwrite header is not included in a COPY or MOVE request then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of the If-Match: * header of HTTP/1.1, If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE.
Overwriteヘッダーは、サーバがCOPYかMOVEの間、非ヌル目的地リソースの状態を上書きするべきであるかどうか指定します。 「F」の値は、目的地リソースの状態が非ヌルであるならサーバがコピーか移動命令を実行してはいけないと述べます。 重ね書きヘッダーがCOPYかMOVE要求に含まれていないなら、まるでそれには価値「T」の重ね書きヘッダーがあるかのようにリソースは要求を扱わなければなりません。 Overwriteヘッダーは、If-マッチの機能性をコピーするように見えますが: * 1.1に、If-マッチがCOPYかMOVEのDestinationではなく、Request-URIだけに適用するHTTP/のヘッダー。
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.
COPYかMOVEがOverwriteヘッダーの値のため実行されないなら、メソッドは412(前提条件Failed)ステータスコードで失敗しなければなりません。
All DAV compliant resources MUST support the Overwrite header.
すべてのDAV対応することのリソースがOverwriteヘッダーを支えなければなりません。
9.7 Status-URI Response Header
9.7 状態URI応答ヘッダ
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.
Status-URI応答ヘッダは、メソッドの状態に関してクライアントに知らせるのに102(処理)ステータスコードと共に使用されるかもしれません。
Goland, et al. Standards Track [Page 57] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[57ページ]。
Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code is defined in 6.1.1 of [RFC2068]
「状態URI=「状態URI」」:、」 *(ステータスコードのコード化されたURL) ; 状態コードが6.1で定義される、.1[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は傑出しているメソッドで影響を受けたソースリソースです。 ステータスコードは特定されたリソースにおけるメソッドの解決を示します。 そのように、例えば、収集でのMOVEメソッドが傑出していて、Status-URI応答ヘッダによる102(処理)応答を返すと、含まれているURIはそれらと結果が何であるかということであったのに移動を試みたリソースを示すでしょう。
9.8 Timeout Request Header
9.8 タイムアウト要求ヘッダー
TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
DAVTimeOutVal = 1*digit
Other = "Extend" field-value ; See section 4.2 of [RFC2068]
「タイムアウトは「タイムアウト」と等しい」:、」 1#TimeType TimeTypeは= 「広がってください」という(「2番目」のDAVTimeOutVal|「無限」|もう一方)DAVTimeOutVal=1*ケタOther分野価値と等しいです。 セクション4.2を見ます。[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.
クライアントは彼らのLOCK要求でTimeoutヘッダーを入れるかもしれません。 しかしながら、サーバは、これらの要求を光栄に思うか、または考えるのさえ必要ではありません。 クライアントはLOCKメソッド以外のどんなメソッドでもTimeout要求ヘッダーを提出してはいけません。
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.
Timeout要求ヘッダーは、少なくとも1TimeTypeを含まなければならなくて、複数のTimeTypeエントリーを含むかもしれません。 複数のTimeTypeエントリーを記載する目的はクライアントにとって、許容している複数の異価と値のタイプを示すことです。 クライアントは好みの順にTimeTypeエントリーを記載します。
Timeout response values MUST use a Second value, Infinite, or a TimeType the client has indicated familiarity with. The server may assume a client is familiar with any TimeType submitted in a Timeout header.
Infinite、タイムアウト応答値がSecond値を使用しなければならない、さもなければ、TimeTypeはクライアントを使用します。示された親しみを持っています。 サーバは、クライアントがTimeoutヘッダーで提出するどんなTimeTypeにも詳しいと仮定するかもしれません。
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はサーバにおける錠を与えるのと、錠の自動除去の間で経過する秒数を指定します。 TimeType「2番目」のためのタイムアウト値は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.
タイムアウトは再開しているいずれかが錠の所有者が錠のどんなメンバーにもメソッドを送る時であったならSHOULDを打ち返します、サポートされないメソッド、または失敗のメソッドを含んでいて。 aがリフレッシュするならどのように錠をリフレッシュしなければならなくても、首尾よくLOCKメソッドを受け取ります。
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
タイムアウトが期限が切れるなら、錠はなくされるかもしれません。 明確に、サーバがタイムアウトで錠を取り入れたいと思うなら、まるでUNLOCKメソッドがリソースのサーバによって調節された錠のロックトークンを使用することで実行されるかのようにサーバSHOULDは行動します、実行される状態で
Goland, et al. Standards Track [Page 58] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[58ページ]。
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.
そのオーバーライド権威。 したがって、錠の気質でログをアップデートするべきであり、通知を送るべきですなど、ちょうどそれらがUNLOCK要求のためのものであるだろうというときに。
Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going 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]で定義されたものに加えられます。
10.1 102 Processing
10.1 102処理
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(処理)ステータスコードはサーバが完全な要求を受け入れましたが、まだそれを完成していないことをクライアントに知らせるのに使用される当座の応答です。 この状態はSHOULDをコード化します。サーバに要求が完成するには重要な時かかる合理的な期待があると、単に送ってください。 指導として、メソッドがサーバを処理するには20秒(妥当な、しかし、任意の値)より長い間かかっているなら、SHOULDは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.
メソッドは潜在的に処理する長い期間、特にDepthヘッダーを支えるメソッドを取ることができます。 そのような場合クライアントは応答を待つ接続がゆったり過ごすタイムアウトがそうするかもしれません。 サーバがそれをクライアントに示すために102(処理)ステータスコードを返すかもしれないこれを防ぐために、サーバはまだメソッドを処理しています。
10.2 207 Multi-Status
10.2 207マルチ状態
The 207 (Multi-Status) status code provides status for multiple independent operations (see section 11 for more information).
207(マルチStatus)ステータスコードは複数の単独操業に状態を提供します(詳しい情報に関してセクション11を見てください)。
Goland, et al. Standards Track [Page 59] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[59ページ]。
10.3 422 Unprocessable Entity
10.3 422Unprocessable実体
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(Unprocessable Entity)ステータスコードが、サーバが要求実体のcontent typeを理解していることを(したがって、415(サポートされないメディアType)ステータスコードは不適当です)意味して、要求実体の構文は、正しいのですが(その結果、400(悪いRequest)ステータスコードは不適当です)、含まれた指示を処理できませんでした。 例えば、XML要求ボディーが整形式(すなわち、シンタクス上正しい)の、しかし、意味的に誤ったXML指示を含むなら、このエラー条件は起こるかもしれません。
10.4 423 Locked
10.4 423はロックされました。
The 423 (Locked) status code means the source or destination resource of a method is locked.
423(ロックされる)ステータスコードは、メソッドに関するソースか目的地リソースがロックされることを意味します。
10.5 424 Failed Dependency
10.5 424の失敗した依存
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(失敗したDependency)ステータスコードは、要求された動作が別の動作によったのでリソースにメソッドを実行できないで、動作が失敗したことを意味します。 例えば、また、PROPPATCHメソッドにおけるコマンドがその時最小限で失敗すると、コマンドの残りは424(失敗したDependency)で失敗するでしょう。
10.6 507 Insufficient Storage
10.6 507 不十分なストレージ
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(不十分なStorage)ステータスコードは、サーバが首尾よく要求を終了するのに必要である表現を保存できないのでリソースにメソッドを実行できなかったことを意味します。 この状態が一時的であると考えられます。 このステータスコードを受け取った要求がユーザ動作の結果であったなら、それが別々のユーザ動きで要求されるまで、要求を繰り返してはいけません。
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(マルチStatus)応答本体が「マルチ-状態」と呼ばれるただ一つのXML要素を含むテキスト/xmlかアプリケーション/xml HTTP実体である、どれが1セットのXML要素を含んでいるかが応答をどれが200、300、400を含んでいるか、そして、メソッド実施の間に生成された500のシリーズステータスコードと呼びました。 記録されていて、100シリーズ状態は応答XML要素でSHOULD NOTをコード化します。
Goland, et al. Standards Track [Page 60] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[60ページ]。
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]で定義された書式を使用することで要素型の宣言をします。 「値」分野は、XML要素の許容できるコンテンツで存在しているところでBNF(すなわち、さらにPCDATA要素の値を制限する)を使用することでさらなる制限を指定します。
12.1 activelock XML Element
12.1 activelock XML Element
Name: activelock Namespace: DAV: Purpose: Describes a lock on a resource.
以下を命名してください。 activelock Namespace: DAV: 目的: リソースで錠について説明します。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?) >
<!ELEMENT activelock(lockscope、locktype、深さ、所有者?、タイムアウト?locktokenであるか、) >。
12.1.1 depth XML Element
12.1.1 深さXML Element
Name: depth Namespace: DAV: Purpose: The value of the Depth header. Value: "0" | "1" | "infinity"
以下を命名してください。 深さNamespace: DAV: 目的: Depthヘッダーの値。 値: "0" | "1" | 「無限」
<!ELEMENT depth (#PCDATA) >
<!ELEMENTの深さ(#PCDATA) >。
12.1.2 locktoken XML Element
12.1.2 locktoken XML Element
Name: locktoken Namespace: DAV: Purpose: The lock token associated with a lock. Description: The href contains one or more opaque lock token URIs which all refer to the same lock (i.e., the OpaqueLockToken-URI production in section 6.4).
以下を命名してください。 locktoken Namespace: DAV: 目的: 錠に関連しているロックトークン。 記述: hrefは同じ錠(すなわち、セクション6.4でのOpaqueLockToken-URI生産)について言及する1つ以上の不透明なロックトークンURIをすべて、含んでいます。
<!ELEMENT locktoken (href+) >
<!ELEMENT locktoken(href+) >。
12.1.3 timeout XML Element
12.1.3 タイムアウトXML Element
Name: timeout Namespace: DAV: Purpose: The timeout associated with a lock Value: TimeType ;Defined in section 9.8
以下を命名してください。 タイムアウトNamespace: DAV: 目的: ロックValueに関連しているタイムアウト: TimeType; セクション9.8で、定義されます。
<!ELEMENT timeout (#PCDATA) >
<!ELEMENTタイムアウト(#PCDATA) >。
Goland, et al. Standards Track [Page 61] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[61ページ]。
12.2 collection XML Element
12.2 収集XML Element
Name: collection Namespace: DAV: Purpose: Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST have this value.
以下を命名してください。 収集Namespace: DAV: 目的: 関連リソースが収集であると認識します。 収集リソースのresourcetypeの特性に、この値がなければなりません。
<!ELEMENT collection EMPTY >
<!ELEMENT収集EMPTY>。
12.3 href XML Element
12.3 href XML Element
Name: href Namespace: DAV: Purpose: Identifies the content of the element as a URI. Value: URI ; See section 3.2.1 of [RFC2068]
以下を命名してください。 href Namespace: DAV: 目的: 要素の内容がURIであると認識します。 値: URI。 セクション3.2.1を見ます。[RFC2068]
<!ELEMENT href (#PCDATA)>
<!ELEMENT href(#PCDATA)>。
12.4 link XML Element
12.4 リンクXML Element
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.
以下を命名してください。 Namespaceをリンクしてください: DAV: 目的: 特性がリンクであると認識して、そのリンクのソースと目的地を含んでいます。 記述: リンクXML要素は、リンクのソースと目的地を提供するのに使用されます。 リンクXML要素を含む特性の名前はリンクのタイプを提供します。 リンクがマルチ評価された要素である、とても複数のリンクが、同じタイプとの複数のリンクを示すのに一緒に使用されるかもしれません。 彼らが存在しないリソースを示すなら、リンクXML要素のsrcとdst XML要素におけるhref XML要素の値を拒絶してはいけません。
<!ELEMENT link (src+, dst+) >
ELEMENTがリンクする<!(src+、dst+) >。
12.4.1 dst XML Element
12.4.1 dst XML Element
Name: dst Namespace: DAV: Purpose: Indicates the destination of a link Value: URI
以下を命名してください。 dst Namespace: DAV: 目的: リンクValueの目的地を示します: URI
<!ELEMENT dst (#PCDATA) >
<!ELEMENT dst(#PCDATA) >。
12.4.2 src XML Element
12.4.2 src XML Element
Name: src Namespace: DAV: Purpose: Indicates the source of a link.
以下を命名してください。 src Namespace: DAV: 目的: リンクの源を示します。
Goland, et al. Standards Track [Page 62] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[62ページ]。
Value: URI
値: URI
<!ELEMENT src (#PCDATA) >
<!ELEMENT src(#PCDATA) >。
12.5 lockentry XML Element
12.5 lockentry XML Element
Name: lockentry Namespace: DAV: Purpose: Defines the types of locks that can be used with the resource.
以下を命名してください。 lockentry Namespace: DAV: 目的: リソースと共に使用できる錠のタイプを定義します。
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockentry(lockscope、locktype) >。
12.6 lockinfo XML Element
12.6 lockinfo XML Element
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要素はクライアントが作成したがっていた錠のタイプを指定するLOCKメソッドで使用されます。
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT lockinfo(lockscope、locktype、所有者)? >。
12.7 lockscope XML Element
12.7 lockscope XML Element
Name: lockscope Namespace: DAV: Purpose: Specifies whether a lock is an exclusive lock, or a shared lock.
以下を命名してください。 lockscope Namespace: DAV: 目的: 錠が排他的な錠、または共有された錠であるかを指定します。
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT lockscope(排他的|、共有、) >。
12.7.1 exclusive XML Element
12.7.1 排他的なXML Element
Name: exclusive Namespace: DAV: Purpose: Specifies an exclusive lock
以下を命名してください。 排他的なNamespace: DAV: 目的: 排他的な錠を指定します。
<!ELEMENT exclusive EMPTY >
<!のELEMENTの排他的なEMPTY>。
12.7.2 shared XML Element
12.7.2 共有されたXML Element
Name: shared Namespace: DAV: Purpose: Specifies a shared lock
以下を命名してください。 Namespaceは共有しました: DAV: 目的: 共有された錠を指定します。
<!ELEMENT shared EMPTY >
<!ELEMENTはEMPTY>を共有しました。
Goland, et al. Standards Track [Page 63] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[63ページ]。
12.8 locktype XML Element
12.8 locktype XML Element
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) >
<!ELEMENT locktype(書きます) >。
12.8.1 write XML Element
12.8.1 XML Elementに書いてください。
Name: write Namespace: DAV: Purpose: Specifies a write lock.
以下を命名してください。 Namespaceに書いてください: DAV: 目的: 指定、aは錠を書きます。
<!ELEMENT write EMPTY >
ELEMENTがEMPTY>に書く<!
12.9 multistatus XML Element
12.9 multistatus XML Element
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: 目的: 複数の応答メッセージを含んでいます。 記述: トップレベルにおけるresponsedescriptionは、応答のアーチをかける本質について説明する一般的なメッセージを提供するのに使用されます。 この値が利用可能であるなら、応答の中に含まれた個々の応答記述を提示することの代わりにアプリケーションはそれを使用するかもしれません。
<!ELEMENT multistatus (response+, responsedescription?) >
<!ELEMENT multistatus(応答+、responsedescription)? >。
12.9.1 response XML Element
12.9.1 応答XML Element
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.
以下を命名してください。 応答Namespace: DAV: 目的: メソッドの効果をリソース、そして/または、所有地に説明するただ一つの応答を保持します。 記述: 特定のhrefは応答XML要素の子供としてmultistatus XML要素の下で一度より多く見えてはいけません。 この要件が、直線的な時間への応答のためにコストを処理し続けるのに必要です。 本質的には、これは、hrefによるすべての応答を一緒に分類するために探さなければならないのを防ぎます。 しかしながら、href値に基づく注文に関する要件が全くありません。
<!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?) >
<!ELEMENT応答(href、(href*、状態)| (propstat+)、responsedescription?) >。
Goland, et al. Standards Track [Page 64] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[64ページ]。
12.9.1.1 propstat XML Element
12.9.1.1 propstat XML Element
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つの支柱XML要素と1つの状態XML要素を含まなければなりません。 支柱XML要素のコンテンツは状態要素の結果が適用される特性の名前を記載するだけでよいです。
<!ELEMENT propstat (prop, status, responsedescription?) >
<!ELEMENT propstat(支柱、状態、responsedescription)? >。
12.9.1.2 status XML Element
12.9.1.2 状態XML Element
Name: status Namespace: DAV: Purpose: Holds a single HTTP status-line Value: status-line ;status-line defined in [RFC2068]
以下を命名してください。 状態Namespace: DAV: 目的: ただ一つのHTTP状況表示行のValueは保持します: 状況表示行; 中で定義された状況表示行[RFC2068]
<!ELEMENT status (#PCDATA) >
<!ELEMENT状態(#PCDATA) >。
12.9.2 responsedescription XML Element
12.9.2 responsedescription XML Element
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.
以下を命名してください。 responsedescription Namespace: DAV: 目的: 応答の本質について説明するユーザに表示できるメッセージを含んでいます。 記述: このXML要素はユーザに提示されるのにおいて適当な情報を提供します。
<!ELEMENT responsedescription (#PCDATA) >
<!ELEMENT responsedescription(#PCDATA) >。
12.10 owner XML Element
12.10 所有者XML Element
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.
以下を命名してください。 所有者Namespace: DAV: 目的: 錠を取り出す校長の情報を提供します。 記述: 所有者XML要素は錠を所有している直接元本に連絡するか(電話番号かメールURIなどの)、または主体を発見するのに(ホームページのURLなどの)十分な情報を提供します。
<!ELEMENT owner ANY>
<!ELEMENT所有者いずれも>。
Goland, et al. Standards Track [Page 65] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[65ページ]。
12.11 prop XML element
12.11 支柱XML要素
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.
以下を命名してください。 Namespaceを支えてください: DAV: 目的: リソースに関連する特性を含んでいます。 記述: 支柱XML要素はリソースで定義された特性のためのジェネリックコンテナです。 支柱XML要素におけるすべての要素がリソースに関連する特性を定義しなければなりません。 他のどんな要素も中で支柱要素で使用されていないかもしれません。
<!ELEMENT prop ANY>
<!ELEMENTはどんな>も支えます。
12.12 propertybehavior XML element
12.12 propertybehavior XML要素
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 Namespace: DAV: 目的: 特性がCOPYかMOVEの間、どう扱われるかを指定します。 記述: propertybehavior XML要素は特性がCOPYかMOVEの間、どう扱われるかを指定します。 このXML要素が要求本体に含まれていないなら、サーバが関連メソッドのデフォルト特性の取り扱いの振舞いで定義されるように行動すると予想されます。 すべてのWebDAV対応することのリソースがpropertybehavior XML要素を支えなければなりません。
<!ELEMENT propertybehavior (omit | keepalive) >
<!ELEMENT propertybehavior(| keepaliveを省略します) >。
12.12.1 keepalive XML element
12.12.1 keepalive XML要素
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の値として含まれているなら、それらがCOPY(または、MOVE)に関する目的地リソースにコピーされた(動かされます)後に命名された特性は「ライブでなければなりません」。 値の「*」であるなら、keepalive XML要素のために、これがソースリソースの精力の特性が精力であるに違いないすべてにそれを指定するという当然のことは目的地ですか? keepalive要素によって指定された要件を光栄に思うことができないなら、メソッドは412で失敗しなければなりません(Failedをあらかじめ調整してください)。 すべてのDAV対応することのリソースが使用のためにCOPYとMOVEメソッドでkeepalive XML要素を支えなければなりません。 値: "*" ; #PCDATA値は「*」であることができるだけです。
<!ELEMENT keepalive (#PCDATA | href+) >
<!ELEMENT keepalive(PCDATA| #href+) >。
Goland, et al. Standards Track [Page 66] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[66ページ]。
12.12.2 omit XML element
12.12.2 XML要素を省略してください。
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.
以下を命名してください。 Namespaceを省略してください: DAV: 目的: 要素が特性が失敗するメソッドを引き起こしてはいけないコピーに特性をコピーするためにはベストエフォート型にもかかわらず、a失敗を使用するようそれがそうするべきであるサーバに命令するXMLを省略してください。 記述: COPYかMOVEのためのデフォルトの振舞いは、すべての特性をコピーするか、動かす、またはメソッドに失敗することです。 サーバがFTPなどの別のプロトコルの上にリソースをコピーする時などのある事情では、リソースに関連している特性をコピーするか、または動かすのが可能でないかもしれません。 したがって、FTPをコピーするか、または譲るどんな試みも特性を譲ることができなかったので、いつも失敗しなければならないでしょう、死んでいる特性としてさえ。 すべてのDAV対応することのリソースがサポートしなければならない、COPY/MOVEメソッドのXML要素を省略してください。
<!ELEMENT omit EMPTY >
<!ELEMENTはEMPTY>を省略します。
12.13 propertyupdate XML element
12.13 propertyupdate XML要素
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 Namespace: DAV: 目的: リソースに特性を変更するという要求を含んでいます。 記述: このXML要素はリソースの特性を変更するのに必要である情報のためのコンテナです。 このXML要素はマルチ評価されています。
<!ELEMENT propertyupdate (remove | set)+ >
<!ELEMENT propertyupdate(取り外してください| セットする)+>。
12.13.1 remove XML element
12.13.1 XML要素を取り除いてください。
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.
以下を命名してください。 Namespaceを取り外してください: DAV: 目的: リソースから取り除くためにDAVの特性を記載します。 記述: 取り外してください。支柱で指定された資産が取り外されるべきであるよう命令します。 存在しない特性の取り外しを指定するのは、誤りではありません。 aの支柱XML要素内部のすべてのXML要素が取り外されます。XML要素は空であるに違いありません、取り除かれるべき特性の名前が必要であるだけであるように。
<!ELEMENT remove (prop) >
ELEMENTが取り外す<!(支柱) >。
12.13.2 set XML element
12.13.2 XML要素を設定してください。
Name: set Namespace: DAV: Purpose: Lists the DAV property values to be set for a resource.
以下を命名してください。 Namespaceを設定してください: DAV: 目的: DAVの特性がリソースに設定されるために評価するリスト。
Goland, et al. Standards Track [Page 67] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[67ページ]。
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.
記述: セットXML要素は支柱XML要素だけを含まなければなりません。 セットXML要素の中に支柱XML要素によって含まれた要素はRequest-URIによって特定されたリソースに設定される属性の名前と価値を指定しなければなりません。 特性が既に存在しているなら、値を取り替えます。 特性の値(「xml: lang」属性存在しているなら)における言語タグ付け情報は、特性と共に持続して保存しなければならなくて、PROPFINDを使用して、次に、回収可能であるに違いありません。
<!ELEMENT set (prop) >
ELEMENTが設定する<!(支柱) >。
12.14 propfind XML Element
12.14 propfind XML Element
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メソッドから返される資産を指定します。 2つの特別な要素がpropfind、allprop、およびpropnameとの使用に指定されます。 支柱がpropfindの中で使用されるなら、それは値ではなく特性の名を含むだけでよいです。
<!ELEMENT propfind (allprop | propname | prop) >
<!ELEMENT propfind(allprop|propname|支柱) >。
12.14.1 allprop XML Element
12.14.1 allprop XML Element
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 >
<!ELEMENT allprop EMPTY>。
12.14.2 propname XML Element
12.14.2 propname XML Element
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 >
<!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]で定義された書式を使用することで要素型の宣言をします。 「値」分野は、XML要素の許容できるコンテンツで存在しているところでBNF(すなわち、さらにPCDATA要素の値を制限する)を使用することでさらなる制限を指定します。
Goland, et al. Standards Track [Page 68] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[68ページ]。
13.1 creationdate Property
13.1 creationdate Property
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) >
<!ELEMENT creationdate(#PCDATA) >。
13.2 displayname Property
13.2 displayname Property
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) >
<!ELEMENT displayname(#PCDATA) >。
13.3 getcontentlanguage Property
13.3 getcontentlanguage Property
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: 目的: 含有、Content-言語はヘッダーがa GETで戻ったヘッダー記述を受け入れます: GETの上のContent-言語ヘッダーを返すどんなDAV対応することのリソースでもgetcontentlanguageの特性を定義しなければなりません。 値: 言語言語タグ;タグはセクション14.13で定義されます。[RFC2068]
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlanguage(#PCDATA) >。
13.4 getcontentlength Property
13.4 getcontentlength Property
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: 目的: 含有、Content-長さはヘッダーがa GETで戻ったヘッダーを受け入れます。 記述: GETに対応してContent-長さのヘッダーを返すどんなDAV対応することのリソースでもgetcontentlengthの特性を定義しなければなりません。
Goland, et al. Standards Track [Page 69] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[69ページ]。
Value: content-length ; see section 14.14 of [RFC2068]
値: コンテンツの長さ。 セクション14.14を見ます。[RFC2068]
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontentlength(#PCDATA) >。
13.5 getcontenttype Property
13.5 getcontenttype Property
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: 目的: 含有、コンテントタイプはヘッダーがa GETで戻ったヘッダーを受け入れます。 記述: GETに対応してコンテントタイプヘッダーを返すどんなDAV対応することのリソースでもこのgetcontenttypeの特性を定義しなければなりません。 値: メディアタイプ。 定義されたコネは3.7を区分します。[RFC2068]
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getcontenttype(#PCDATA) >。
13.6 getetag Property
13.6 getetag Property
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: 目的: 含有、ETagはヘッダーがa GETで戻ったヘッダーを受け入れます。 記述: Etagヘッダーを返すどんなDAV対応することのリソースでもgetetagの特性を定義しなければなりません。 値: 実体タグ。 定義されたコネは3.11を区分します。[RFC2068]
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getetag (#PCDATA) >
13.7 getlastmodified Property
13.7 getlastmodified Property
Name: getlastmodified Namespace: DAV: Purpose: Contains the Last-Modified header returned by a GET method without accept headers. Description: Note that the last-modified date on a resource may reflect changes in any part of the state of the resource, not necessarily just a change to the response to the GET method. For example, a change in a property may cause the last-modified date to change. The getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET. Value: HTTP-date ; defined in section 3.3.1 of [RFC2068]
Name: getlastmodified 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]
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT getlastmodified (#PCDATA) >
Goland, et al. Standards Track [Page 70] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 70] RFC 2518 WEBDAV February 1999
13.8 lockdiscovery Property
13.8 lockdiscovery Property
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.
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.
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT lockdiscovery (activelock)* >
13.8.1 Example - Retrieving the lockdiscovery Property
13.8.1 Example - Retrieving the lockdiscovery Property
>>Request
>>Request
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8"
PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D='DAV:'>
<D:prop><D:lockdiscovery/></D:prop>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D='DAV:'> <D:prop><D:lockdiscovery/></D:prop> </D:propfind>
>>Response
>>Response
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:href>http://www.foo.bar/container/</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D='DAV:'> <D:response> <D:href>http://www.foo.bar/container/</D:href> <D:propstat> <D:prop> <D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>0</D:depth> <D:owner>Jane Smith</D:owner> <D:timeout>Infinite</D:timeout> <D:locktoken>
Goland, et al. Standards Track [Page 71] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 71] RFC 2518 WEBDAV February 1999
<D:href>
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<D:href> opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 </D:href> </D:locktoken> </D:activelock> </D:lockdiscovery> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
This resource has a single exclusive write lock on it, with an infinite timeout.
This resource has a single exclusive write lock on it, with an infinite timeout.
13.9 resourcetype Property
13.9 resourcetype Property
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.
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.
<!ELEMENT resourcetype ANY >
<!ELEMENT resourcetype ANY >
13.10 source Property
13.10 source Property
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.
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.
<!ELEMENT source (link)* >
<!ELEMENT source (link)* >
13.10.1 Example - A source Property
13.10.1 Example - A source Property
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
<D:source>
<D:link>
<F:projfiles>Source</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<?xml version="1.0" encoding="utf-8" ?> <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/"> <D:source> <D:link> <F:projfiles>Source</F:projfiles> <D:src>http://foo.bar/program</D:src>
Goland, et al. Standards Track [Page 72] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 72] RFC 2518 WEBDAV February 1999
<D:dst>http://foo.bar/src/main.c</D:dst>
</D:link>
<D:link>
<F:projfiles>Library</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.lib</D:dst>
</D:link>
<D:link>
<F:projfiles>Makefile</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/makefile</D:dst>
</D:link>
</D:source>
</D:prop>
<D:dst>http://foo.bar/src/main.c</D:dst> </D:link> <D:link> <F:projfiles>Library</F:projfiles> <D:src>http://foo.bar/program</D:src> <D:dst>http://foo.bar/src/main.lib</D:dst> </D:link> <D:link> <F:projfiles>Makefile</F:projfiles> <D:src>http://foo.bar/program</D:src> <D:dst>http://foo.bar/src/makefile</D:dst> </D:link> </D:source> </D:prop>
In this example the resource http://foo.bar/program has a source property that contains three links. Each link contains three elements, two of which, src and dst, are part of the DAV schema defined in this document, and one which is defined by the schema http://www.foocorp.com/project/ (Source, Library, and Makefile). A client which only implements the elements in the DAV spec will not understand the foocorp elements and will ignore them, thus seeing the expected source and destination links. An enhanced client may know about the foocorp elements and be able to present the user with additional information about the links. This example demonstrates the power of XML markup, allowing element values to be enhanced without breaking older clients.
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.
13.11 supportedlock Property
13.11 supportedlock Property
Name: supportedlock Namespace: DAV: Purpose: To provide a listing of the lock capabilities supported by the resource. Description: The supportedlock property of a resource returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls so a server is not required to provide information the client is not authorized to see.
Name: supportedlock 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.
<!ELEMENT supportedlock (lockentry)* >
<!ELEMENT supportedlock (lockentry)* >
13.11.1 Example - Retrieving the supportedlock Property
13.11.1 Example - Retrieving the supportedlock Property
>>Request
>>Request
PROPFIND /container/ HTTP/1.1
PROPFIND /container/ HTTP/1.1
Goland, et al. Standards Track [Page 73] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 73] RFC 2518 WEBDAV February 1999
Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8"
Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop><D:supportedlock/></D:prop>
</D:propfind>
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop><D:supportedlock/></D:prop> </D:propfind>
>>Response
>>Response
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.foo.bar/container/</D:href>
<D:propstat>
<D:prop>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.foo.bar/container/</D:href> <D:propstat> <D:prop> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
14 Instructions for Processing XML in DAV
14 Instructions for Processing XML in DAV
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.
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.
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.
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.
Goland, et al. Standards Track [Page 74] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 74] RFC 2518 WEBDAV February 1999
This restriction does not apply to setting dead DAV properties on the server where the server MUST record unknown XML elements.
This restriction does not apply to setting dead DAV properties on the server where the server MUST record unknown XML elements.
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.
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.
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.
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.
15 DAV Compliance Classes
15 DAV Compliance Classes
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.
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.
Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV compliant resources, clients, and proxies MUST be compliant with [RFC2068].
Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV compliant resources, clients, and proxies MUST be compliant with [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.
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.
15.1 Class 1
15.1 Class 1
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document.
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document.
Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
15.2 Class 2
15.2 Class 2
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.
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the supportedlock property, the lockdiscovery property, the Time-Out response header and the Lock- Token request header. A class "2" compliant resource SHOULD also support the Time-Out request header and the owner XML element.
Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
Goland, et al. Standards Track [Page 75] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 75] RFC 2518 WEBDAV February 1999
16 Internationalization Considerations
16 Internationalization Considerations
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.
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.
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 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.
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 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.
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.
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.
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
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
Goland, et al. Standards Track [Page 76] RFC 2518 WEBDAV February 1999
Goland, et al. Standards Track [Page 76] RFC 2518 WEBDAV February 1999
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.
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.
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.
クライアントとサーバのinteroperationが現場情報を必要としないので、この仕様はこの情報の伝達にどんなメカニズムも指定しません。
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に適用されます。 さらに、リモートオーサリングに固有のセキュリティリスクは、より強い認証技術を必要として、いくつかの新しいプライバシーの問題を紹介して、貧しいサーバデザインから危険を増強するかもしれません。 これらの問題は以下で詳細です。
17.1 Authentication of Clients
17.1 クライアントの認証
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のためのBasic認証がパスワードの本質的には明確なテキスト伝送を実行するので、接続が安全でない場合、WebDAVクライアントをサーバに認証するのにBasic認証を使用してはいけません。 aはヘッダーをWWW認証します。その上、WebDAVサーバがBasic認証資格証明書を送ってはいけない、接続が安全でない場合。 安全な接続に関する例はクライアントとサーバの互いの認証、または例えば、肉体的に安全なネットワーク、孤立しているネットワークの上の接続と共にビルで制限されたアクセサリーで堅固な暗号スイートを使うTransport Layer Security(TLS)接続を含んでいます。
Goland, et al. Standards Track [Page 77] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[77ページ]。
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アプリケーションは、Digest認証が体系[RFC2069]であるとサポートしなければなりません。 Digest認証が、コミュニケーションへの双方が共有秘密キー、パスワードを知っていることを確かめるので、その秘密を送る必要はなくて、明確なDigest認証はさまざまなシナリオで役に立つ認証のレベルを提供している間、Basic認証の固有である警備上の問題を避けます。
17.2 Denial of Service
17.2 サービス妨害
Denial of service attacks are of special concern to WebDAV servers. WebDAV plus HTTP enables denial of service attacks on every part of a system's resources.
サービス不能攻撃はWebDAVサーバへの特別な関心のものです。 WebDAVとHTTPはシステムのリソースのあらゆる部分でサービス不能攻撃を可能にします。
The underlying storage can be attacked by PUTting extremely large files.
PUTtingは基本的なストレージを攻撃できます。非常に大きいファイル。
Asking for recursive operations on large collections can attack processing time.
大きい収集のときに再帰的な操作を求めるのは攻撃処理時間がそうすることができます。
Making multiple pipelined requests on multiple connections can attack network connections.
複数の接続に関する複数のpipelined要求をすると、ネットワーク接続を攻撃できます。
WebDAV servers need to be aware of the possibility of a denial of service attack at all levels.
WebDAVサーバは、すべてのレベルでサービス不能攻撃の可能性を意識している必要があります。
17.3 Security through Obscurity
17.3 不鮮明を通したセキュリティ
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サーバのユーザがそれらのリソース名の相対的な不鮮明によるよりむしろリソースへの求められていないアクセスを防ぐのにアクセス制御方法を使用するよう奨励されます。
17.4 Privacy Issues Connected to Locks
17.4 錠に接続されたプライバシー問題
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分野を提出するかもしれないよう要求してください。 この問い合わせ先をリソースのlockdiscovery所有地に保存して、他の共同制作者は、リソースへのアクセスの上で交渉を始めるのに使用できます。 しかしながら、多くの場合、この問い合わせ先を非常に個人的である場合があり、広く広めるべきではありません。 SHOULDが制限するサーバは適宜lockdiscoveryの特性へのアクセスを読みます。 その上、ユーザエージェント
Goland, et al. Standards Track [Page 78] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[78ページ]。
SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
SHOULDは問い合わせ先を全く送るかどうかと、問い合わせ先を送るかどうかのコントロールを提供します、まさにどんな情報を送るかのコントロール。
17.5 Privacy Issues Connected to Properties
17.5 特性に関連づけられたプライバシー問題
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.
特性の値がドキュメントの作者などの情報を保持するのに通常使用されるので、プライバシーの問題がリソースの特性のデータへの広範囲のアクセスに由来しながら起こることができた可能性があります。 特性で個人情報の不注意なリリースの危険を減少させるために、サーバは、そんなに別々の制御機構がリソース本体へのアクセスを読み込むアクセスを開発して、リソースの特性へのアクセスを読むよう奨励されます。 これで、アクセスをリソースのコンテンツにひどく制限しないで、ユーザはそれらの特性のデータの普及を制御できます。
17.6 Reduction of Security due to Source Link
17.6 Source LinkによるSecurityの減少
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を提供できるので、それらは書かれるかもしれません。 1.1に、サーバが合理的に優位によるソースリソースへのアクセスを防ぐことができたHTTP/のために、アクセサリーだけを読んでください。 WebDAVは、ソースを特定するために読まれて、オーサリングへの強調で奨励して、ソースリソースへのアクセスを書いて、ソースリンク施設を提供します。 これはソースリソースへのアクセスを排除するセキュリティ利益を下げます。 WebDAVサーバのユーザと管理者は、スクリプト、読まれた制限のリモートオーサリングを許容するとき、非常に用心深く、ソースリソースへのアクセスを認可された主体に書くべきです。
17.7 Implications of XML External Entities
17.7 XML外部実体の含意
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は、特定のURIで位置するXMLのインラインインクルードを検索して、実行するためにXMLプロセッサを命令する.2セクション4.2[REC-XML]で定義された「外部実体」として知られている施設をサポートします。 XMLドキュメントに関連しているドキュメント型の宣言(DTD)を追加するか、または変更するのに外部のXML実体を使用できます。 また、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ドキュメントの最終形態に影響するのは、可能です、最悪で
Goland, et al. Standards Track [Page 79] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[79ページ]。
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.
[RFC2376]で議論したセキュリティ危険に意味論をかなり変更するか、またはXMLプロセッサを暴露するケース。 したがって、implementersは外部の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実体を含むリソースに関する要求をさばくどんなサーバも積みすぎて。
17.8 Risks Connected with Lock Tokens
17.8の危険がロックトークンに接続しました。
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では、この仕様はUniversal Unique Identifiers(UUIDs)のロックトークンの使用を必要とします、スペースと時間の向こう側にそれらのユニークさを保証するために。 [ISO11578]で定義されるUUIDsは「IEEEアドレス、通常ホスト・アドレスから成る」「ノード」分野を含んでいます。 「複数のIEEE802ノードがあるシステムのために、どんな利用可能なノードアドレスも使用できます。」 WebDAVサーバが一生のうちに多くの錠を支給するので、含意はまた、IEEEが802アドレスであると公的に暴露するということです。
There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:
IEEE802アドレスの暴露に関連しているいくつかのリスクがあります。 IEEE802を使用して、以下を扱ってください。
* 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.
この.1のセクション6.4仕様が、ユニークさの代替の源を使用することによってIEEE802アドレスの暴露に関連している危険を軽減するIEEE802アドレスを使用しないでUUIDの「ノード」分野を生成するために代替のメカニズムについて詳述します。
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.
このドキュメントは特性の値の中で使用された2つの名前空間、特性の名の名前空間、およびWebDAV特有のXML要素の名前空間を定義します。
Goland, et al. Standards Track [Page 80] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[80ページ]。
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ユーザやアプリケーションでもすばやく定義されるのを主要な命名権威に要求を必要として、したがって、許容しません。 また、URIはユニークなアドレス空間を提供します、WebDAVの分配されたユーザがそれらが作成する特性の名とXML要素の中に衝突を持たないのを確実にして。
This specification defines a distinguished set of property names and XML elements that are understood by all WebDAV applications. The property names and XML elements in this specification are all derived from the base URI DAV: by adding a suffix to this URI, for example, DAV:creationdate for the "creationdate" property.
この仕様はすべてのWebDAVアプリケーションに解釈される顕著なセットの特性の名とXML要素を定義します。 ベースURI DAVからこの仕様による特性の名とXML要素をすべて得ます: "creationdate"の特性のためにDAV: 例えば、このURI creationdateに接尾語を加えることによって。
This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in section 6.4.
また、この仕様はロックトークンのコード化のURI体系を定義します、とopaquelocktoken URI体系はセクション6.4で説明しました。
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.
この仕様に基づく正しいinteroperationを確実にするために、IANAが始動していた状態でURI名前空間を予約しなければならない、「DAV:」 そして、「opaquelocktoken:」 そのこの仕様、改正、および関連するWebDAV仕様による使用のために。
19 Intellectual Property
19知的所有権
The following notice is copied from RFC 2026 [RFC2026], section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document.
以下の通知は、RFC2026[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は正当性、実装に関係するか、または本書では説明された他の技術を使用すると主張されるかもしれないどんな知的所有権や他の権利の範囲またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Goland, et al. Standards Track [Page 81] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[81ページ]。
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.
ティムBernersテリー・アレン、ハラルドAlvestrand、ジムAmsden、ベッキー・アンダーソン、アランBabich、サンフォードバール、ディランBarrell、バーナード・チェスター、リー、ダン・コノリー、ジムカニンハム、ロンダニエル、Jr; ジム・デイヴィス、キース・ドーソン、マーク・デー、ブライアン・ディーン、マーチンDuerst、デヴィッド・ジュランド・リー・ファレル、チャックFay、ウエスリーFelter、ロイFielding、マーク・フィッシャー、アラン・フライア、ジョージFlorentine、ジムGettys、フィル・ハラム-ベイカー、デニス・ハミルトン、スティーブ・ヘニング、Mead Himelstein、アレックスHopmann、アンドレ・バンderフック、ベン・ローリー、ポール・リーチ; 花粉の内口Lassila、カレン・マッカーサー、スティーブン・マーチン、ラリーMasinter、マイケルMealling、キース・ムーア、トーマスNarten、Henrikニールセン、Kenji織田、ボブ・パーカー、グレン・ピーターソン、ジョンRadoff、Saveenレディ、ヘンリーSandersクリストファーSeiwald、ジュディスSlein、マイクSpreitzer、Einar Stefferud、グレッグ・シタイン、ラルフSwick、Kenji高橋、リチャードN; テイラー、ロバート・トー、ジョン・ターナー、Sankar Virdhagriswaran、ファビオVitali、グレゴリー・ウッドハウス、およびローレンWood。
Two from this list deserve special mention. The contributions by Larry Masinter have been invaluable, both in helping the formation of the working group and in patiently coaching the authors along the way. In so many ways he has set high standards we have toiled to meet. The contributions of Judith Slein in clarifying the requirements, and in patiently reviewing draft after draft, both improved this specification and expanded our minds on document management.
このリストからの2は特記に値します。 ラリーMasinterによる貢献は非常に貴重です、ワーキンググループの構成を助けて、道に沿って我慢強く作者をコーチすることにおける両方。 とても多くの方法で、彼は、私たちが疲れさせた高い規格に会うように設定しました。 要件をはっきりさせて、我慢強く次々と草稿を見直すことにおける、ジュディスSleinの貢献は、この仕様を改良して、私たちの心を文書管理に広くしました。
We would also like to thank John Turner for developing the XML DTD.
また、XML DTDを開発して頂いて、ジョン・ターナーに感謝申し上げます。
21 References
21の参照箇所
21.1 Normative References
21.1 標準の参照
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC1766]Alvestrand、H.、「言語の識別のためのタグ」、RFC1766、1995年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Goland, et al. Standards Track [Page 82] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[82ページ]。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、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. J.パオリ、C.M.Sperberg-マックィーン、「拡張マークアップ言語(XML)」をいななかせてください。 ワールドワイドウェブコンソーシアム推薦REC-xml-19980210 http://www.w3.org/TR/1998/REC-xml-19980210 。
[REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
XML". World Wide Web Consortium Recommendation REC-
xml-names-19990114. http://www.w3.org/TR/1999/REC-
xml-names-19990114/
[REC-XML-名前] T. D.オランダ人、A.俗人、「XMLの名前空間」をいななかせてください。 ワールドワイドウェブコンソーシアムRecommendation REC- xml名19990114 http://www.w3.org/TR/1999/REC- xml名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] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、リーチ、P、Luotonen、A.、流し台、E.、およびL.スチュワート、「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] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月」。
[ISO-639] ISO (International Organization for Standardization).
ISO 639:1988. "Code for the representation of names
of languages."
[ISO-639]ISO(国際標準化機構)。 ISO639: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(国際標準化機構)。 ISO8601: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/IEC11578:1996。 「情報技術--オープン・システム・インターコネクション--リモートProcedure Call(RPC)」
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]モウツ(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 2279, January 1998.
[UTF-8]Yergeau、1998年1月のF.、「UTF-8、ユニコードとISO10646の変換形式」RFC2279。
21.2 Informational References
21.2 情報の参照
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
Goland, et al. Standards Track [Page 83] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[83ページ]。
[RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic
Records", RFC 1807, June 1995.
1995年6月の[RFC1807]ラッシャ、R. and D.コーエン、「図書目録の記録のための形式」RFC1807。
[WF] C. Lagoze, "The Warwick Framework: A Container
Architecture for Diverse Sets of Metadata", D-Lib
Magazine, July/August 1996.
http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
[WF]C.Lagoze、「ウォリックフレームワーク:」 「さまざまのセットのメタデータのためのコンテナアーキテクチャ」、D-リブ雑誌、1996年7月/8月の 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]はDevelopmentとマークStandards、オフィス、教育をネットワークでつなぎます。 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-映画] ミラー、T.Krauskopf、P.レズニック、W.Treese、「映画はラベル構文と通信プロトコルと分配をラベルする」というJ.バージョン1.1、REC映画が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.、ヴィターリ、F.、ホワイトヘッド、E.、およびD.ジュランド、「分配されたオーサリングとVersioningのための要件はWWWのために議定書を作ります」、RFC2291、1998年2月。
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin
Core Metadata for Resource Discovery", RFC 2413, September
1998.
[RFC2413] ウェイベルとS.とクンツェとJ.とLagozeとC.とM.ヴォルフ、「リソース発見のためのダブリンコアメタデータ」、RFC2413、1998年9月。
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
July 1998.
[RFC2376] ホワイトヘッドとE.とM.ムラタ、「XMLメディアタイプ」、RFC2376、1998年7月。
22 Authors' Addresses
22人の作者のアドレス
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Y.Y.Golandマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: yarong@microsoft.com
メール: yarong@microsoft.com
E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425
E.J.ホワイトヘッド、Jr.部 情報とコンピュータサイエンスカリフォルニア大学アーバイン校アーバイン、カリフォルニア92697-3425について
EMail: ejw@ics.uci.edu
メール: ejw@ics.uci.edu
Goland, et al. Standards Track [Page 84] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[84ページ]。
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043
A.Faizi Netscape685の東Middlefield Roadマウンテンビュー、カリフォルニア 94043
EMail: asad@netscape.com
メール: asad@netscape.com
S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399
S.R.カーターノベル1555N.技術道S ORM F111オレーム、M/ユタ84097-2399
EMail: srcarter@novell.com
メール: srcarter@novell.com
D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399
D.ジェンセンノベル1555N.技術道S ORM F111オレーム、M/ユタ84097-2399
EMail: dcjensen@novell.com
メール: dcjensen@novell.com
Goland, et al. Standards Track [Page 85] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[85ページ]。
23 Appendices
23個の付録
23.1 Appendix 1 - WebDAV Document Type Definition
23.1付録1--WebDAVドキュメント型定義
This section provides a document type definition, following the rules in [REC-XML], for the XML elements used in the protocol stream and in the values of properties. It collects the element definitions given in sections 12 and 13.
このセクションはドキュメント型定義を提供します、[REC-XML]で約束を守って、プロトコルストリームと特性の値に使用されるXML要素のために。 それはセクション12と13で与えられた要素定義を集めます。
<!DOCTYPE webdav-1.0 [
<!DOCTYPE webdav-1.0、[
<!--============ XML Elements from Section 12 ==================-->
<!--============ セクション12からのXML Elements==================-->。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?) >
<!ELEMENT activelock(lockscope、locktype、深さ、所有者?、タイムアウト?locktokenであるか、) >。
<!ELEMENT lockentry (lockscope, locktype) > <!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT lockentry(lockscope、locktype)><!ELEMENT lockinfo(lockscope、locktype、所有者)? >。
<!ELEMENT locktype (write) > <!ELEMENT write EMPTY >
ELEMENTがEMPTY>に書く<!ELEMENT locktype(書く)><!
<!ELEMENT lockscope (exclusive | shared) > <!ELEMENT exclusive EMPTY > <!ELEMENT shared EMPTY >
<!ELEMENT lockscope、(排他的|、共有、)、>のELEMENTの排他的なEMPTY><!<!ELEMENTはEMPTY>を共有しました。
<!ELEMENT depth (#PCDATA) >
<!ELEMENTの深さ(#PCDATA) >。
<!ELEMENT owner ANY >
<!ELEMENT所有者いずれも>。
<!ELEMENT timeout (#PCDATA) >
<!ELEMENTタイムアウト(#PCDATA) >。
<!ELEMENT locktoken (href+) >
<!ELEMENT locktoken(href+) >。
<!ELEMENT href (#PCDATA) >
<!ELEMENT href(#PCDATA) >。
<!ELEMENT link (src+, dst+) > <!ELEMENT dst (#PCDATA) > <!ELEMENT src (#PCDATA) >
<!ELEMENTリンク(src+、dst+)><!ELEMENT dst(#PCDATA)><!ELEMENT src(#PCDATA) >。
<!ELEMENT multistatus (response+, responsedescription?) >
<!ELEMENT multistatus(応答+、responsedescription)? >。
<!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?) > <!ELEMENT status (#PCDATA) > <!ELEMENT propstat (prop, status, responsedescription?) > <!ELEMENT responsedescription (#PCDATA) >
<!ELEMENT応答(href、(href*、状態)| (propstat+)、responsedescription?) ><!ELEMENT状態(#PCDATA)><!ELEMENT propstat(支柱、状態、responsedescription?) ><!ELEMENT responsedescription(#PCDATA) >。
Goland, et al. Standards Track [Page 86] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[86ページ]。
<!ELEMENT prop ANY >
<!ELEMENTはどんな>も支えます。
<!ELEMENT propertybehavior (omit | keepalive) > <!ELEMENT omit EMPTY >
<!ELEMENT propertybehavior(| keepaliveを省略する)><!ELEMENTはEMPTY>を省略します。
<!ELEMENT keepalive (#PCDATA | href+) >
<!ELEMENT keepalive(PCDATA| #href+) >。
<!ELEMENT propertyupdate (remove | set)+ > <!ELEMENT remove (prop) > <!ELEMENT set (prop) >
<!ELEMENT propertyupdate(取り外してください| セットする)+><!ELEMENTはELEMENTが設定する(支柱)><!を取り外します。(支柱) >。
<!ELEMENT propfind (allprop | propname | prop) > <!ELEMENT allprop EMPTY > <!ELEMENT propname EMPTY >
<!ELEMENT propfind(allprop|propname|支柱)><!ELEMENT allprop EMPTY><!ELEMENT propname EMPTY>。
<!ELEMENT collection EMPTY >
<!ELEMENT収集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)* > ]>
<!--=========== セクション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はどんな><!ELEMENTソース(リンク)*><!ELEMENT supportedlock(lockentry)*>です。>。
Goland, et al. Standards Track [Page 87] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[87ページ]。
23.2 Appendix 2 - ISO 8601 Date and Time Profile
23.2付録2--ISO8601日時のプロフィール
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の特性はISO8601日付の形式[ISO-8601]の使用を指定します。 このセクションは使用のためにこの仕様でISO8601日付の形式のプロフィールを定義します。 このプロフィールは、クリス・ニューマンによってインターネット草稿から引用されて、適切に彼の仕事を結果と考えるのにここに参照されます。
date-time = full-date "T" full-time
日付-時間は常勤に完全な期日の「T」と等しいです。
full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset
=日付-fullyear「-」日付-月の「-」日付-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
日付-fullyearは4DIGIT日付-月=2DIGITと等しいです。 01-12 日付-mdayは2DIGITと等しいです。 01-28(01-29)は01-30に、01-31に2DIGITを月/年の時間-時間=に基礎づけました。 00-23 時間-分は2DIGITと等しいです。 00-59 時間-2番目は2DIGITと等しいです。 「00-59に、00-60に、閏秒に基づいて、時間-secfrac=を統治する」、」 「1*DIGITは-numoffsetに=(「+」/「-」)時間-時間を調節する」:、」 時間-分時間オフセット=時間「Z」/numoffset
partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
「部分的な時間=時間-時間」:、」 「時間-分」:、」 時間-2番目[時間-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: 0インチ」 これはUTCが指定された時間の都合のよい基準点であることを含意する「Z」のオフセットと異なっています。
Goland, et al. Standards Track [Page 88] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[88ページ]。
23.3 Appendix 3 - Notes on Processing XML Elements
23.3付録3--処理XML Elementsに関する注
23.3.1 Notes on Empty XML Elements
23.3.1 空のXML Elementsに関する注
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></の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が、要素がEMPTY(例えば、<!ELEMENT A EMPTY>)であると宣言するなら、それは>が形成する<A></を使用するXML仕様の違反です。 そのような声明が含まれているなら、空の要素形式、<A/>を使用しなければなりません。 EMPTYであり、次に、要素が<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要素の不法な組み合わせを受け入れるのにおいて親切が全くありません。 せいぜい、求められていない結果を引き起こすでしょう、そして、最悪の場合はそれは本当の損害をもたらすことができます。
23.3.2.1 Example - XML Syntax Error
23.3.2.1 例--XML構文エラー
The following request body for a PROPFIND method is illegal.
PROPFINDメソッドのための以下の要求本体は不法です。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<D:propname/>
</D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV: 「><D: allprop/><D: propname/></D: propfind>」
The definition of the propfind element only allows for the allprop or the propname element, not both. Thus the above is an error and must be responded to with a 400 (Bad Request).
propfind要素の定義は両方ではなく、allpropかpropname要素を考慮するだけです。 したがって、上記に誤りであり、400(悪いRequest)で応じなければなりません。
Goland, et al. Standards Track [Page 89] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[89ページ]。
Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop.
しかしながら、サーバが「親切でありたく」、真の要素としてallprop要素を選んで、それに応じると決めたと想像してください。 サーバがallpropとしてコマンドを扱うなら、propnameを実行つもりであったいことである帯域幅の限られた系列をひいているクライアントは大きい驚きを受けそうでいるでしょうに。
Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it.
さらに、サーバが、寛大であり、この要求に答えると決めるなら、サーバによって結果は手当たりしだいに異なるでしょうに、いくつかのサーバがallprop指示を実行していて、他のものがpropname指示を実行していて。 これはそれを増強するより相互運用性をむしろ減少させます。
23.3.2.2 Example - Unknown XML Element
23.3.2.2 例--未知のXML要素
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
propfind要素に一緒に現れるのが明らかに禁止された2つの要素を含んだので、前の例は不法でした。 しかしながら、XMLが広げることができる言語であるので、人は、新しい要素がpropfindとの使用のために定義されると想像できます。 前の例のように、下をPROPFINDの要求ボディーであり、満期の支柱要素を理解していないサーバによるa400(悪いRequest)で拒絶しなければなりません。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.foo.bar/standards/props/">
<E:expired-props/>
</D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV:」、」 xmlns: Eが等しい、「 http://www.foo.bar/standards/props/ 、「><E: 満期の支柱/></D: propfind>」
To understand why a 400 (Bad Request) is returned let us look at the request body as the server unfamiliar with expired-props sees it.
(悪いRequest)が返される400が私たちになぜサーバとしての要求本体を満期の支柱になじみがなく見させることができるかを理解しているのがそれを見ます。
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.foo.bar/standards/props/">
</D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「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を見ます。(propfind要素の定義で、propfindは不法です)。
Please note that had the extension been additive it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
拡大が付加的であったなら、それは必ず、400(悪いRequest)をもたらしたというわけではないでしょうに。 例えば、PROPFINDのために以下の要求本体を想像してください:
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.foo.bar/standards/props/">
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV:」、」 xmlns: Eが等しい、「 http://www.foo.bar/standards/props/ ">"
Goland, et al. Standards Track [Page 90] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[90ページ]。
<D:propname/>
<E:leave-out>*boss*</E:leave-out>
</D:propfind>
<D: propname/><E: >*ボス*</Eを省いてください: ></D: propfind>を置いてください。
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with leave-out, the only result would be that the leave-out element would be ignored and a propname would be executed.
前の例は、要素外からいなくなるのを架空の含んでいます。 目的は名前が提出されたパターンに合っているどんな特性の復帰も防ぐことです。 外からいなくなるのになじみのないサーバに前の例を提出するなら、唯一の結果は外からいなくなり要素が無視されて、propnameが実行されるだろうということでしょうに。
Goland, et al. Standards Track [Page 91] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[91ページ]。
23.4 Appendix 4 -- XML Namespaces for WebDAV
23.4付録4--WebDAVのためのXML名前空間
23.4.1 Introduction
23.4.1 序論
All DAV compliant systems MUST support the XML namespace extensions as specified in [REC-XML-NAMES].
すべてのDAV対応することのシステムが[REC-XML-NAMES]の指定されるとしてのXML名前空間拡張子をサポートしなければなりません。
23.4.2 Meaning of Qualified Names
23.4.2 適切な名前の意味
[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プロセッサはURIという名前空間名にLocalPartを追加することによって構成されたURIとして適切な名前を解釈しなければなりません。
Example
例
<del:glider xmlns:del="http://www.del.jensen.org/">
<del:glidername>
Johnny Updraft
</del:glidername>
<del:glideraccidents/>
</del:glider>
xmlns: <del: グライダーdelが等しい、「 http://www.del.jensen.org/ 、「><del: glidername>ジョニーUpdraft</del: glidername><del: glideraccidents/></del: グライダー>」
In this example, the qualified element name "del:glider" is interpreted as the URL "http://www.del.jensen.org/glider".
この例では、要素が「del: グライダー」と命名する適切は" http://www.del.jensen.org/glider "というURLとして解釈されます。
<bar:glider xmlns:del="http://www.del.jensen.org/">
<bar:glidername>
Johnny Updraft
</bar:glidername>
<bar:glideraccidents/>
</bar:glider>
xmlns: <バー: グライダーdelが等しい、「 http://www.del.jensen.org/ 、「><バー: glidername>ジョニーUpdraft</バー: glidername><バー: glideraccidents/></バー: グライダー>」
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.
この例は前の例とシンタクス上異なっていますが、それは意味的に同じです。 「バー」という名前空間名の各例を" http://www.del.jensen.org/ "に取り替えて、次に、それぞれの要素タグのために地方名に追加します。 この例の結果として起こるタグ名はまさに前の例のように同じです。
<foo:r xmlns:foo="http://www.del.jensen.org/glide">
<foo:rname>
Johnny Updraft
</foo:rname>
<foo:raccidents/>
</foo:r>
<foo: r xmlns: fooが等しい、「 http://www.del.jensen.org/glide 、「><foo: rname>ジョニーUpdraft</foo: rname><foo: raccidents/></foo: r>」
Goland, et al. Standards Track [Page 92] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[92ページ]。
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つのものと意味的に同じです。 存在という次にそれぞれの要素タグのために地方名に追加される" http://www.del.jensen.org/glide "に取り替えられた名前空間名の"foo"の各例、結果として起こるタグ名は前の例のそれらと同じです。
Goland, et al. Standards Track [Page 93] RFC 2518 WEBDAV February 1999
Goland、他 規格はWEBDAV1999年2月にRFC2518を追跡します[93ページ]。
24. Full Copyright Statement
24. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Goland, et al. Standards Track [Page 94]
Goland、他 標準化過程[94ページ]
一覧
スポンサーリンク
