RFC4918 日本語訳
4918 HTTP Extensions for Web Distributed Authoring and Versioning(WebDAV). L. Dusseault, Ed.. June 2007. (Format: TXT=276352 bytes) (Obsoletes RFC2518) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L. Dusseault, Ed. Request for Comments: 4918 CommerceNet Obsoletes: 2518 June 2007 Category: Standards Track
ワーキンググループL.Dusseault、エドをネットワークでつないでください。コメントのために以下を要求してください。 4918CommerceNetは以下を時代遅れにします。 2518 2007年6月のカテゴリ: 標準化過程
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
ウェブの分配されたオーサリングとVersioningのためのHTTP拡大(WebDAV)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).
ウェブDistributed AuthoringとVersioning(WebDAV)はリソースの特性の管理、リソース収集の作成と管理、URL名前空間操作、およびリソースロック(衝突回避用レーダー警報装置)における、HTTP/1.1への付属の1セットのメソッド、ヘッダー、およびcontent typeから成ります。
RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience.
RFC2518は1999年2月に発行されました、そして、この仕様はわずかな修正を加えてほとんど相互運用性経験のためRFC2518を時代遅れにします。
Dusseault Standards Track [Page 1] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................7 2. Notational Conventions ..........................................8 3. Terminology .....................................................8 4. Data Model for Resource Properties .............................10 4.1. The Resource Property Model ...............................10 4.2. Properties and HTTP Headers ...............................10 4.3. Property Values ...........................................10 4.3.1. Example - Property with Mixed Content ..............12 4.4. Property Names ............................................14 4.5. Source Resources and Output Resources .....................14 5. Collections of Web Resources ...................................14 5.1. HTTP URL Namespace Model ..................................15 5.2. Collection Resources ......................................15 6. Locking ........................................................17 6.1. Lock Model ................................................18 6.2. Exclusive vs. Shared Locks ................................19 6.3. Required Support ..........................................20 6.4. Lock Creator and Privileges ...............................20 6.5. Lock Tokens ...............................................21 6.6. Lock Timeout ..............................................21 6.7. Lock Capability Discovery .................................22 6.8. Active Lock Discovery .....................................22 7. Write Lock .....................................................23 7.1. Write Locks and Properties ................................24 7.2. Avoiding Lost Updates .....................................24 7.3. Write Locks and Unmapped URLs .............................25 7.4. Write Locks and Collections ...............................26 7.5. Write Locks and the If Request Header .....................28 7.5.1. Example - Write Lock and COPY ......................28 7.5.2. Example - Deleting a Member of a Locked Collection .........................................29 7.6. Write Locks and COPY/MOVE .................................30 7.7. Refreshing Write Locks ....................................30 8. General Request and Response Handling ..........................31 8.1. Precedence in Error Handling ..............................31 8.2. Use of XML ................................................31 8.3. URL Handling ..............................................32 8.3.1. Example - Correct URL Handling .....................32 8.4. Required Bodies in Requests ...............................33 8.5. HTTP Headers for Use in WebDAV ............................33 8.6. ETag ......................................................33 8.7. Including Error Response Bodies ...........................34 8.8. Impact of Namespace Operations on Cache Validators ........34 9. HTTP Methods for Distributed Authoring .........................35 9.1. PROPFIND Method ...........................................35 9.1.1. PROPFIND Status Codes ..............................37
1. 序論…7 2. 記号法のコンベンション…8 3. 用語…8 4. データはリソースの特性のためにモデル化されます…10 4.1. リソース特性のモデル…10 4.2. 特性とHTTPヘッダ…10 4.3. 特性の値…10 4.3.1. 例--Mixedがある特性は…を満足させます…12 4.4. 特性の名…14 4.5. ソースリソースと出力リソース…14 5. ウェブリソースの収集…14 5.1. HTTP URL名前空間モデル…15 5.2. 収集リソース…15 6. ロックします…17 6.1. モデルをロックしてください…18 6.2. 共有された錠に対して限る…19 6.3. 支持を要します…20 6.4. 創造者と特権をロックしてください…20 6.5. トークンをロックしてください…21 6.6. タイムアウトをロックしてください…21 6.7. 能力発見をロックしてください…22 6.8. 活発なロック発見…22 7. 錠を書いてください…23 7.1. 錠と特性を書いてください…24 7.2. 避けるのはアップデートを失いました…24 7.3. 錠とUnmapped URLを書いてください…25 7.4. 錠と収集を書いてください…26 7.5. そして、錠を書いてください、要求ヘッダーであるなら…28 7.5.1. 例--錠とコピーを書いてください…28 7.5.2. 例--ロックされた収集のメンバーを削除します…29 7.6. 錠とコピー/移動を書いてください…30 7.7. リフレッシュして、錠を書いてください…30 8. 一般要求と応答取り扱い…31 8.1. 先行の間違った取り扱い…31 8.2. XMLの使用…31 8.3. URL取り扱い…32 8.3.1. 例--URL取り扱いを修正してください…32 8.4. 要求でボディーを必要とします…33 8.5. WebDAVにおける使用のためのHTTPヘッダ…33 8.6. ETag…33 8.7. 誤り応答本体を含んでいます…34 8.8. キャッシュValidatorsにおける名前空間操作の影響…34 9. 分配されたオーサリングのためのHTTPメソッド…35 9.1. PROPFINDメソッド…35 9.1.1. PROPFINDステータスコード…37
Dusseault Standards Track [Page 2] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[2ページ]。
9.1.2. Status Codes for Use in 'propstat' Element .........37 9.1.3. Example - Retrieving Named Properties ..............38 9.1.4. Example - Using 'propname' to Retrieve All Property Names .....................................39 9.1.5. Example - Using So-called 'allprop' ................41 9.1.6. Example - Using 'allprop' with 'include' ...........43 9.2. PROPPATCH Method ..........................................44 9.2.1. Status Codes for Use in 'propstat' Element .........44 9.2.2. Example - PROPPATCH ................................45 9.3. MKCOL Method ..............................................46 9.3.1. MKCOL Status Codes .................................47 9.3.2. Example - MKCOL ....................................47 9.4. GET, HEAD for Collections .................................48 9.5. POST for Collections ......................................48 9.6. DELETE Requirements .......................................48 9.6.1. DELETE for Collections .............................49 9.6.2. Example - DELETE ...................................49 9.7. PUT Requirements ..........................................50 9.7.1. PUT for Non-Collection Resources ...................50 9.7.2. PUT for Collections ................................51 9.8. COPY Method ...............................................51 9.8.1. COPY for Non-collection Resources ..................51 9.8.2. COPY for Properties ................................52 9.8.3. COPY for Collections ...............................52 9.8.4. COPY and Overwriting Destination Resources .........53 9.8.5. Status Codes .......................................54 9.8.6. Example - COPY with Overwrite ......................55 9.8.7. Example - COPY with No Overwrite ...................55 9.8.8. Example - COPY of a Collection .....................56 9.9. MOVE Method ...............................................56 9.9.1. MOVE for Properties ................................57 9.9.2. MOVE for Collections ...............................57 9.9.3. MOVE and the Overwrite Header ......................58 9.9.4. Status Codes .......................................59 9.9.5. Example - MOVE of a Non-Collection .................60 9.9.6. Example - MOVE of a Collection .....................60 9.10. LOCK Method ..............................................61 9.10.1. Creating a Lock on an Existing Resource ...........61 9.10.2. Refreshing Locks ..................................62 9.10.3. Depth and Locking .................................62 9.10.4. Locking Unmapped URLs .............................63 9.10.5. Lock Compatibility Table ..........................63 9.10.6. LOCK Responses ....................................63 9.10.7. Example - Simple Lock Request .....................64 9.10.8. Example - Refreshing a Write Lock .................65 9.10.9. Example - Multi-Resource Lock Request .............66 9.11. UNLOCK Method ............................................68 9.11.1. Status Codes ......................................68
9.1.2. 状態は使用のために'propstat'で要素をコード化します…37 9.1.3. 例--検索は特性を命名しました…38 9.1.4. 例--すべての特性の名を検索するのに'propname'を使用します…39 9.1.5. 例--いわゆる'allprop'を使用します…41 9.1.6. 例--'包含'がある………'allprop'を使用します。43 9.2. PROPPATCHメソッド…44 9.2.1. 状態は使用のために'propstat'で要素をコード化します…44 9.2.2. 例--、PROPPATCH…45 9.3. MKCOLメソッド…46 9.3.1. MKCOLステータスコード…47 9.3.2. 例--、MKCOL…47 9.4. 得てください、そして、収集に向かってください…48 9.5. 収集のためのポスト…48 9.6. 要件を削除してください…48 9.6.1. 収集のために、削除します。49 9.6.2. 例--削除します。49 9.7. 要件を置いてください…50 9.7.1. 非収集リソースのために、置きます。50 9.7.2. 収集のために、置きます。51 9.8. メソッドをコピーしてください…51 9.8.1. 非収集リソースには、コピーしてください…51 9.8.2. 特性には、コピーしてください…52 9.8.3. 収集には、コピーしてください…52 9.8.4. コピーと目的地リソースを上書きします…53 9.8.5. 状態コード…54 9.8.6. 例--重ね書きで、コピーしてください…55 9.8.7. 例--重ね書きなしでコピーしてください…55 9.8.8. 例--収集のコピー…56 9.9. メソッドを動かしてください…56 9.9.1. 特性を提議してください…57 9.9.2. 収集は提議します…57 9.9.3. 移動と重ね書きヘッダー…58 9.9.4. 状態コード…59 9.9.5. 例--非収集の移動…60 9.9.6. 例--収集の移動…60 9.10. メソッドをロックしてください…61 9.10.1. 既存のリソースに錠を作成します…61 9.10.2. リフレッシュはロックされます…62 9.10.3. 深さであってロックすること…62 9.10.4. Unmapped URLをロックします…63 9.10.5. 互換性テーブルをロックしてください…63 9.10.6. 応答をロックしてください…63 9.10.7. 例--簡単なロック要求…64 9.10.8. 例--aをリフレッシュして、錠を書いてください…65 9.10.9. 例--マルチリソースロック要求…66 9.11. メソッドをアンロックしてください…68 9.11.1. 状態コード…68
Dusseault Standards Track [Page 3] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[3ページ]。
9.11.2. Example - UNLOCK ..................................69 10. HTTP Headers for Distributed Authoring ........................69 10.1. DAV Header ...............................................69 10.2. Depth Header .............................................70 10.3. Destination Header .......................................71 10.4. If Header ................................................72 10.4.1. Purpose ...........................................72 10.4.2. Syntax ............................................72 10.4.3. List Evaluation ...................................73 10.4.4. Matching State Tokens and ETags ...................74 10.4.5. If Header and Non-DAV-Aware Proxies ...............74 10.4.6. Example - No-tag Production .......................75 10.4.7. Example - Using "Not" with No-tag Production ......75 10.4.8. Example - Causing a Condition to Always Evaluate to True ..................................75 10.4.9. Example - Tagged List If Header in COPY ...........76 10.4.10. Example - Matching Lock Tokens with Collection Locks .................................76 10.4.11. Example - Matching ETags on Unmapped URLs ........76 10.5. Lock-Token Header ........................................77 10.6. Overwrite Header .........................................77 10.7. Timeout Request Header ...................................78 11. Status Code Extensions to HTTP/1.1 ............................78 11.1. 207 Multi-Status .........................................78 11.2. 422 Unprocessable Entity .................................78 11.3. 423 Locked ...............................................78 11.4. 424 Failed Dependency ....................................79 11.5. 507 Insufficient Storage .................................79 12. Use of HTTP Status Codes ......................................79 12.1. 412 Precondition Failed ..................................79 12.2. 414 Request-URI Too Long .................................79 13. Multi-Status Response .........................................80 13.1. Response Headers .........................................80 13.2. Handling Redirected Child Resources ......................81 13.3. Internal Status Codes ....................................81 14. XML Element Definitions .......................................81 14.1. activelock XML Element ...................................81 14.2. allprop XML Element ......................................82 14.3. collection XML Element ...................................82 14.4. depth XML Element ........................................82 14.5. error XML Element ........................................82 14.6. exclusive XML Element ....................................83 14.7. href XML Element .........................................83 14.8. include XML Element ......................................83 14.9. location XML Element .....................................83 14.10. lockentry XML Element ...................................84 14.11. lockinfo XML Element ....................................84 14.12. lockroot XML Element ....................................84
9.11.2. 例--アンロックしてください…69 10. 分配されたオーサリングのためのHTTPヘッダ…69 10.1. DAVヘッダー…69 10.2. 深さヘッダー…70 10.3. 目的地ヘッダー…71 10.4. ヘッダーであるなら…72 10.4.1. 目的…72 10.4.2. 構文…72 10.4.3. 評価を記載してください…73 10.4.4. マッチングはトークンとETagsを述べます…74 10.4.5. そして、ヘッダーである、非DAV意識する、プロキシ…74 10.4.6. 例--生産にタグ付けをしないでください…75 10.4.7. 例--タグがない生産がある“Not"を使用します…75 10.4.8. 例--いつも本当に評価する状態を引き起こします…75 10.4.9. 例--コピーのヘッダーであるならリストにタグ付けをします…76 10.4.10. 例--マッチングは収集錠でトークンをロックします…76 10.4.11. 例--Unmapped URLの合っているETags…76 10.5. ロックトークンヘッダー…77 10.6. ヘッダーを上書きしてください…77 10.7. タイムアウト要求ヘッダー…78 11. HTTP/1.1へのステータスコード拡大…78 11.1. 207 マルチ状態…78 11.2. 422は実体をUnprocessableします…78 11.3. 423はロックされました…78 11.4. 424 依存に失敗します…79 11.5. 507 不十分なストレージ…79 12. HTTPステータスコードの使用…79 12.1. 412前提条件は失敗しました…79 12.2. 414要求URIも長さ…79 13. マルチ状態応答…80 13.1. 応答ヘッダー…80 13.2. 取り扱いは子供リソースを向け直しました…81 13.3. 内部のステータスコード…81 14. XML要素定義…81 14.1. activelock XML Element…81 14.2. allprop XML Element…82 14.3. 収集XML Element…82 14.4. 深さXML Element…82 14.5. 誤りXML Element…82 14.6. 排他的なXML Element…83 14.7. href XML Element…83 14.8. XML Elementを含めてください…83 14.9. 位置のXML Element…83 14.10. lockentry XML Element…84 14.11. lockinfo XML Element…84 14.12. lockroot XML Element…84
Dusseault Standards Track [Page 4] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[4ページ]。
14.13. lockscope XML Element ...................................84 14.14. locktoken XML Element ...................................85 14.15. locktype XML Element ....................................85 14.16. multistatus XML Element .................................85 14.17. owner XML Element .......................................85 14.18. prop XML Element ........................................86 14.19. propertyupdate XML Element ..............................86 14.20. propfind XML Element ....................................86 14.21. propname XML Element ....................................87 14.22. propstat XML Element ....................................87 14.23. remove XML Element ......................................87 14.24. response XML Element ....................................88 14.25. responsedescription XML Element .........................88 14.26. set XML Element .........................................88 14.27. shared XML Element ......................................89 14.28. status XML Element ......................................89 14.29. timeout XML Element .....................................89 14.30. write XML Element .......................................89 15. DAV Properties ................................................90 16. Precondition/Postcondition XML Elements .......................98 17. XML Extensibility in DAV .....................................101 18. DAV Compliance Classes .......................................103 18.1. Class 1 .................................................103 18.2. Class 2 .................................................103 18.3. Class 3 .................................................103 19. Internationalization Considerations ..........................104 20. Security Considerations ......................................105 20.1. Authentication of Clients ...............................105 20.2. Denial of Service .......................................106 20.3. Security through Obscurity ..............................106 20.4. Privacy Issues Connected to Locks .......................106 20.5. Privacy Issues Connected to Properties ..................107 20.6. Implications of XML Entities ............................107 20.7. Risks Connected with Lock Tokens ........................108 20.8. Hosting Malicious Content ...............................108 21. IANA Considerations ..........................................109 21.1. New URI Schemes .........................................109 21.2. XML Namespaces ..........................................109 21.3. Message Header Fields ...................................109 21.3.1. DAV ..............................................109 21.3.2. Depth ............................................110 21.3.3. Destination ......................................110 21.3.4. If ...............................................110 21.3.5. Lock-Token .......................................110 21.3.6. Overwrite ........................................111 21.3.7. Timeout ..........................................111 21.4. HTTP Status Codes .......................................111 22. Acknowledgements .............................................112
14.13. lockscope XML Element…84 14.14. locktoken XML Element…85 14.15. locktype XML Element…85 14.16. multistatus XML Element…85 14.17. 所有者XML Element…85 14.18. XML Elementを支えてください…86 14.19. propertyupdate XML Element…86 14.20. propfind XML Element…86 14.21. propname XML Element…87 14.22. propstat XML Element…87 14.23. XML Elementを取り外してください…87 14.24. 応答XML Element…88 14.25. responsedescription XML Element…88 14.26. XML Elementを設定してください…88 14.27. 共有されたXML Element…89 14.28. 状態XML Element…89 14.29. タイムアウトXML Element…89 14.30. XML Elementに書いてください…89 15. DAVの特性…90 16. 前提条件/Postcondition XML Elements…98 17. DAVのXML伸展性…101 18. DAVコンプライアンスは属します…103 18.1. クラス1…103 18.2. クラス2…103 18.3. クラス3…103 19. 国際化問題…104 20. セキュリティ問題…105 20.1. クライアントの認証…105 20.2. サービス妨害…106 20.3. 不鮮明を通したセキュリティ…106 20.4. プライバシーの問題は錠に接続しました…106 20.5. プライバシーの問題は特性に接続しました…107 20.6. XML実体の含意…107 20.7. 危険はロックトークンに接続しました…108 20.8. 悪意がある内容をホスティングします…108 21. IANA問題…109 21.1. 新しいURI体系…109 21.2. XML名前空間…109 21.3. メッセージヘッダーフィールド…109 21.3.1. DAV…109 21.3.2. 深さ…110 21.3.3. 目的地…110 21.3.4. …110 21.3.5. ロックトークン…110 21.3.6. 上書きしてください…111 21.3.7. タイムアウト…111 21.4. HTTPステータスコード…111 22. 承認…112
Dusseault Standards Track [Page 5] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[5ページ]。
23. Contributors to This Specification ...........................113 24. Authors of RFC 2518 ..........................................113 25. References ...................................................114 25.1. Normative References.....................................114 25.2. Informative References ..................................115 Appendix A. Notes on Processing XML Elements ....................117 A.1. Notes on Empty XML Elements ..............................117 A.2. Notes on Illegal XML Processing ..........................117 A.3. Example - XML Syntax Error ...............................117 A.4. Example - Unexpected XML Element .........................118 Appendix B. Notes on HTTP Client Compatibility ...................119 Appendix C. The 'opaquelocktoken' Scheme and URIs ................120 Appendix D. Lock-null Resources ..................................120 D.1. Guidance for Clients Using LOCK to Create Resources ......121 Appendix E. Guidance for Clients Desiring to Authenticate ........121 Appendix F. Summary of Changes from RFC 2518 .....................123 F.1. Changes for Both Client and Server Implementations .......123 F.2. Changes for Server Implementations .......................125 F.3. Other Changes ............................................126
23. この仕様への貢献者…113 24. RFC2518の作者…113 25. 参照…114 25.1. 標準の参照…114 25.2. 有益な参照…115 付録A.は処理XMLでElementsに注意します…117 A.1。 空のXML Elementsに関する注…117 A.2。 不法なXML処理に関する注…117 A.3。 例--XML構文エラー…117 A.4。 例--予期していなかったXML要素…118 付録B.はHTTPクライアントの上で互換性に注意します…119の付録C.'opaquelocktoken'体系とURI…120 付録D.ロックヌルリソース…120 D.1。 リソースを作成するのに錠を使用しているクライアントのための指導…121 認証するクライアントの望みのための付録E.指導…RFC2518からの変化の121付録F.概要…123 F.1。 クライアントとサーバ実装の両方のための変化…123 F.2。 サーバ実装のための変化…125 F.3。 他の変化…126
Dusseault Standards Track [Page 6] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[6ページ]。
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.
特性: 彼らの作者、作成日付などのウェブページの情報を作成して、取り除いて、質問する能力
Collections: The ability to create sets of documents and to retrieve a hierarchical membership listing (like a directory listing in a file system).
収集: ドキュメントのセットを創設して、階層的な会員資格リスト(ファイルシステムでリストアップされているディレクトリのような)を検索する能力。
Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem", in which modifications are lost as first one author, then another, writes changes without merging the other author's changes.
ロックします: 複数の人が同時にドキュメントに取り組むのを妨げる能力。 これは「無くなっているアップデート問題」を防ぎます。(最初の1人の作者(当時の別のもの)がもう片方の作者の変化を合併しないで変更を書くとき、変更はそれで無くなっています)。
Namespace Operations: The ability to instruct the server to copy and move Web resources, operations that change the mapping from URLs to resources.
名前空間操作: ウェブリソース、マッピングをURLからリソースに変える操作をコピーして、動かすようサーバに命令する能力。
Requirements and rationale for these operations are described in a companion document, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web" [RFC2291].
これらの操作のための要件と原理は仲間ドキュメント、「WWWのための分配されたオーサリングとVersioningプロトコルのための要件」[RFC2291]で説明されます。
This document does not specify the versioning operations suggested by [RFC2291]. That work was done in a separate document, "Versioning Extensions to WebDAV" [RFC3253].
このドキュメントは[RFC2291]によって示されたversioning操作を指定しません。 別々のドキュメント、「WebDAVへのVersioning拡張子」[RFC3253]でその仕事をしました。
The sections below provide a detailed introduction to various WebDAV abstractions: resource properties (Section 4), collections of resources (Section 5), locks (Section 6) in general, and write locks (Section 7) specifically.
下のセクションは様々なWebDAV抽象化に詳細な序論を提供します: リソースの特性(セクション4)(リソース(セクション5)の収集)は、一般に、(セクション6)をロックして、明確に、錠(セクション7)を書きます。
These abstractions are manipulated by the WebDAV-specific HTTP methods (Section 9) and the extra HTTP headers (Section 10) used with WebDAV methods. General considerations for handling HTTP requests and responses in WebDAV are found in Section 8.
WebDAV特有のHTTPメソッド(セクション9)とWebDAVメソッドで使用される付加的なHTTPヘッダ(セクション10)によってこれらの抽象化は操られます。 取り扱いHTTP要求のための一般問題とWebDAVの応答はセクション8で見つけられます。
While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebDAV methods, there are some errors that do not fall neatly into the existing categories. This specification defines extra status codes developed for WebDAV methods (Section 11) and describes existing HTTP status codes (Section 12) as used in WebDAV. Since some WebDAV methods may
HTTP/1.1提供されたステータスコードはWebDAVメソッドで遭遇するほとんどのエラー条件について説明するために十分ですが、既存のカテゴリにきちんとならないいくつかの誤りがあります。 この仕様は、WebDAVメソッド(セクション11)のために開発された付加的なステータスコードを定義して、WebDAVで使用されるように状態がコード化する既存のHTTP(セクション12)について説明します。 いくつかのWebDAVメソッドがそうするかもしれないので
Dusseault Standards Track [Page 7] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[7ページ]。
operate over many resources, the Multi-Status response (Section 13) has been introduced to return status information for multiple resources. Finally, this version of WebDAV introduces precondition and postcondition (Section 16) XML elements in error response bodies.
多くのリソースの上で作動してください、そして、複数のリソースのための状態情報を返すために、Multi-状態応答(セクション13)を導入しました。 最終的に、WebDAVのこのバージョンは誤り応答本体で前提条件とpostcondition(セクション16)XML要素を紹介します。
WebDAV uses XML ([REC-XML]) for property names and some values, and also uses XML to marshal complicated requests and responses. This specification contains DTD and text definitions of all properties (Section 15) and all other XML elements (Section 14) used in marshalling. WebDAV includes a few special rules on extending WebDAV XML marshalling in backwards-compatible ways (Section 17).
WebDAVは、特性の名といくつかの値に、XML([REC-XML])を使用して、また、複雑な要求と応答を整理するのにXMLを使用します。 この仕様は整理に使用されるすべての特性(セクション15)と他のすべてのXML要素(セクション14)のDTDとテキスト定義を含んでいます。 WebDAVは後方にコンパチブル方法(セクション17)で整理するWebDAV XMLを広げるときのいくつかの特別な規則を含んでいます。
Finishing off the specification are sections on what it means for a resource to be compliant with this specification (Section 18), on internationalization support (Section 19), and on security (Section 20).
仕様を仕上げるのは、それがリソースがこの仕様で対応であることを意味すること(セクション18)の上と、そして、国際化サポート(セクション19)の上と、そして、セキュリティ(セクション20)の上のセクションです。
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 [RFC2616], including the rules about implied linear whitespace. Since this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], these rules apply to this document as well. Note this is not the standard BNF syntax used in other RFCs.
このドキュメントがHTTP/1.1プロトコルに1セットの拡大について説明するので、プロトコル要素について説明するのにここに使用される増大しているBNFはまさに[RFC2616]のセクション2.1で説明されるのと同じです、暗示している直線的な空白に関する規則を含んでいて。 この増大しているBNFが[RFC2616]のセクション2.2に提供された基本的なプロダクションルールを使用するので、これらの規則はまた、このドキュメントに適用されます。 これが他のRFCsで使用される標準のBNF構文でないことに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Note that in natural language, a property like the "creationdate" property in the "DAV:" XML namespace is sometimes referred to as "DAV:creationdate" for brevity.
中に自然言語、"creationdate"の特性のような所有地にそれを述べてください、「DAV:」 XML名前空間は簡潔さのために時々「DAV: creationdate」と呼ばれます。
3. Terminology
3. 用語
URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, respectively. These terms (and the distinction between them) are defined in [RFC3986].
URI/URL--Uniform Resource IdentifierとUniform Resource Locator、それぞれ。 これらの用語(そして、それらの区別)は[RFC3986]で定義されます。
URI/URL Mapping - A relation between an absolute URI and a resource. Since a resource can represent items that are not network retrievable, as well as those that are, it is possible for a resource to have zero, one, or many URI mappings. Mapping a resource to an "http" scheme URI makes it possible to submit HTTP protocol requests to the resource using the URI.
URI/URL Mapping--絶対URIとリソースとの関係。 リソースがそうするそれらと同様に回収可能なネットワークでない項目を表すことができるので、リソースにはゼロ、1、または多くのURIマッピングがあるのは、可能です。 "http"体系URIにリソースを写像するのに、URIを使用することでHTTPプロトコル要求をリソースに提出するのは可能になります。
Dusseault Standards Track [Page 8] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[8ページ]。
Path Segment - Informally, the characters found between slashes ("/") in a URI. Formally, as defined in Section 3.3 of [RFC3986].
経路Segment--非公式に、キャラクタはユリでスラッシュ(「/」)の間で見つけました。 正式である、[RFC3986]のセクション3.3で定義されるように。
Collection - Informally, a resource that also acts as a container of references to child resources. Formally, a resource that contains a set of mappings between path segments and resources and meets the requirements defined in Section 5.
収集--非公式に、またそれがコンテナとして機能するリソースは子供にリソースに参照をつけます。 正式に、経路セグメントとリソースの間に1セットのマッピングを含んでいて、条件を満たすリソースはセクションで5を定義しました。
Internal Member (of a Collection) - Informally, a child resource of a collection. Formally, a resource referenced by a path segment mapping contained in the collection.
内部のメンバー(Collectionの)--非公式である、収集に関する子供リソース。 正式に、リソースは経路のそばで収集に含まれたセグメントマッピングに参照をつけました。
Internal Member URL (of a Collection) - A URL of an internal member, consisting of the URL of the collection (including trailing slash) plus the path segment identifying the internal member.
内部のメンバーURL(Collectionの)--収集(スラッシュを引きずるのを含んでいる)と内部のメンバーを特定する経路セグメントのURLから成る内部のメンバーの1つのURL。
Member (of a Collection) - Informally, a "descendant" of a collection. Formally, an internal member of the collection, or, recursively, a member of an internal member.
メンバー(Collectionの)--、非公式である、a収集で「下降しています」。 正式である、収集の内部のメンバー、または内部のメンバーの再帰的にメンバー。
Member URL (of a Collection) - A URL that is either an internal member URL of the collection itself, or is an internal member URL of a member of that collection.
メンバーURL(Collectionの)--収集自体の内部のメンバーURLである、またはその収集のメンバーの内部のメンバーURLであるURL。
Property - A name/value pair that contains descriptive information about a resource.
特性--リソースの描写的である情報を含む名前/値の組。
Live Property - A property whose semantics and syntax are enforced by the server. For example, the live property DAV:getcontentlength has its value, the length of the entity returned by a GET request, automatically calculated by the server.
Propertyを住ませてください--意味論と構文がサーバによって励行される特性。例えば、DAV: 精力の特性のgetcontentlengthには、値、サーバによって自動的に計算されたGET要求で返された実体の長さがあります。
Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property.
死んでいるProperty--意味論と構文がサーバによって実施されないで. サーバが死んでいる属性の価値を記録するだけであるということである特性。 クライアントは構文の一貫性と死んでいる特性の意味論を維持するのに責任があります。
Principal - A distinct human or computational actor that initiates access to network resources.
主体--ネットワーク資源へのアクセスを開始する異なった人間の、または、コンピュータの俳優。
State Token - A URI that represents a state of a resource. Lock tokens are the only state tokens defined in this specification.
Tokenを述べてください--リソースの状態を表すURI。 ロックトークンはこの仕様に基づき定義された唯一の州のトークンです。
Dusseault Standards Track [Page 9] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[9ページ]。
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 protected and maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.
特性の2つのカテゴリがあります: 「生きてください」と「全く。」 精力の特性は、その構文と意味論がサーバによって励行されるのを持っています。精力の特性はa) 属性の価値がサーバによって保護されて、維持されて、b) 属性の価値がクライアントによって維持されるケースを含んでいますが、提出された値について検査して、サーバは構文を実行します。 与えられた精力の特性のすべてのインスタンスがその特性の名に関連している定義に従わなければなりません。 死んでいる特性は、その構文と意味論がクライアントによって励行されるのを持っています。 サーバは単に属性の価値を逐語的に記録します。
4.2. Properties and HTTP Headers
4.2. 特性と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 that allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.
特性はHTTPメッセージヘッダーに既に狭い意味で存在しています。 しかしながら、分散書いている環境で、比較的多くの特性がリソースの状態について説明するのに必要であり、HTTPヘッダにわたってそれらを設定するか、または返すのが効率が悪いです。 したがって、元本がまさしくそれらの特性を主体が興味を持っている1セットの特性を特定して、設定するか、または検索するメカニズムが、必要です。
4.3. Property Values
4.3. 特性の値
The value of a property is always a (well-formed) XML fragment.
いつも属性の価値は(整形式)のXML断片です。
XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self- describing nature allows any property's value to be extended by adding elements. Clients will not break when they encounter extensions because they will still have the data specified in the original schema and MUST ignore elements they do not understand.
XMLはそれが豊かな図式定義をサポートするフレキシブルで、自己について説明していて、構造化されたデータの形式であるためとその複数の文字集合のサポートので選ばれました。 自然について説明するXMLの自己は、どんな特性の値も要素を加えることによって広げられるのを許します。 彼らがそれでも、オリジナルの図式でデータを指定させて、彼らが理解していない要素を無視しなければならないので拡大に遭遇する場合、クライアントは中断しないでしょう。
Dusseault Standards Track [Page 10] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 10] RFC 4918 WebDAV June 2007
XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml: lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so an xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. Note that a property only has one value, in one language (or language MAY be left undefined); a property does not have multiple values in different languages or a single value in multiple languages.
XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml: lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so an xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. Note that a property only has one value, in one language (or language MAY be left undefined); a property does not have multiple values in different languages or a single value in multiple languages.
A property is always represented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist:
A property is always represented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist:
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
The value of the property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. Servers MUST preserve the following XML Information Items (using the terminology from [REC-XML-INFOSET]) in storage and transmission of dead properties:
The value of the property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. Servers MUST preserve the following XML Information Items (using the terminology from [REC-XML-INFOSET]) in storage and transmission of dead properties:
For the property name Element Information Item itself:
For the property name Element Information Item itself:
[namespace name]
[namespace name]
[local name]
[local name]
[attributes] named "xml:lang" or any such attribute in scope
[attributes] named "xml:lang" or any such attribute in scope
[children] of type element or character
[children] of type element or character
On all Element Information Items in the property value:
On all Element Information Items in the property value:
[namespace name]
[namespace name]
[local name]
[local name]
[attributes]
[attributes]
[children] of type element or character
[children] of type element or character
Dusseault Standards Track [Page 11] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 11] RFC 4918 WebDAV June 2007
On Attribute Information Items in the property value:
On Attribute Information Items in the property value:
[namespace name]
[namespace name]
[local name]
[local name]
[normalized value]
[normalized value]
On Character Information Items in the property value:
On Character Information Items in the property value:
[character code]
[character code]
Since prefixes are used in some XML vocabularies (XPath and XML Schema, for example), servers SHOULD preserve, for any Information Item in the value:
Since prefixes are used in some XML vocabularies (XPath and XML Schema, for example), servers SHOULD preserve, for any Information Item in the value:
[prefix]
[prefix]
XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. The above rules would also apply by default to live properties, unless defined otherwise.
XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. The above rules would also apply by default to live properties, unless defined otherwise.
Servers MUST ignore the XML attribute xml:space if present and never use it to change whitespace handling. Whitespace in property values is significant.
Servers MUST ignore the XML attribute xml:space if present and never use it to change whitespace handling. Whitespace in property values is significant.
4.3.1. Example - Property with Mixed Content
4.3.1. Example - Property with Mixed Content
Consider a dead property 'author' created by the client as follows:
Consider a dead property 'author' created by the client as follows:
<D:prop xml:lang="en" xmlns:D="DAV:"> <x:author xmlns:x='http://example.com/ns'> <x:name>Jane Doe</x:name> <!-- Jane's contact info --> <x:uri type='email' added='2005-11-26'>mailto:jane.doe@example.com</x:uri> <x:uri type='web' added='2005-11-27'>http://www.example.com</x:uri> <x:notes xmlns:h='http://www.w3.org/1999/xhtml'> Jane has been working way <h:em>too</h:em> long on the long-awaited revision of <![CDATA[<RFC2518>]]>. </x:notes> </x:author> </D:prop>
<D:prop xml:lang="en" xmlns:D="DAV:"> <x:author xmlns:x='http://example.com/ns'> <x:name>Jane Doe</x:name> <!-- Jane's contact info --> <x:uri type='email' added='2005-11-26'>mailto:jane.doe@example.com</x:uri> <x:uri type='web' added='2005-11-27'>http://www.example.com</x:uri> <x:notes xmlns:h='http://www.w3.org/1999/xhtml'> Jane has been working way <h:em>too</h:em> long on the long-awaited revision of <![CDATA[<RFC2518>]]>. </x:notes> </x:author> </D:prop>
Dusseault Standards Track [Page 12] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 12] RFC 4918 WebDAV June 2007
When this property is requested, a server might return:
When this property is requested, a server might return:
<D:prop xmlns:D='DAV:'><author xml:lang='en' xmlns:x='http://example.com/ns' xmlns='http://example.com/ns' xmlns:h='http://www.w3.org/1999/xhtml'> <x:name>Jane Doe</x:name> <x:uri added="2005-11-26" type="email" >mailto:jane.doe@example.com</x:uri> <x:uri added="2005-11-27" type="web" >http://www.example.com</x:uri> <x:notes> Jane has been working way <h:em>too</h:em> long on the long-awaited revision of <RFC2518>. </x:notes> </author> </D:prop>
<D:prop xmlns:D='DAV:'><author xml:lang='en' xmlns:x='http://example.com/ns' xmlns='http://example.com/ns' xmlns:h='http://www.w3.org/1999/xhtml'> <x:name>Jane Doe</x:name> <x:uri added="2005-11-26" type="email" >mailto:jane.doe@example.com</x:uri> <x:uri added="2005-11-27" type="web" >http://www.example.com</x:uri> <x:notes> Jane has been working way <h:em>too</h:em> long on the long-awaited revision of <RFC2518>. </x:notes> </author> </D:prop>
Note in this example:
Note in this example:
o The [prefix] for the property name itself was not preserved, being non-significant, whereas all other [prefix] values have been preserved,
o The [prefix] for the property name itself was not preserved, being non-significant, whereas all other [prefix] values have been preserved,
o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and attribute order has not been preserved,
o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and attribute order has not been preserved,
o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope),
o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope),
o whitespace between tags has been preserved everywhere (whitespace between attributes not so),
o whitespace between tags has been preserved everywhere (whitespace between attributes not so),
o CDATA encapsulation was replaced with character escaping (the reverse would also be legal),
o CDATA encapsulation was replaced with character escaping (the reverse would also be legal),
o the comment item was stripped (as would have been a processing instruction item).
o the comment item was stripped (as would have been a processing instruction item).
Implementation note: there are cases such as editing scenarios where clients may require that XML content is preserved character by character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing.
Implementation note: there are cases such as editing scenarios where clients may require that XML content is preserved character by character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing.
Dusseault Standards Track [Page 13] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 13] RFC 4918 WebDAV June 2007
4.4. Property Names
4.4. Property Names
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.
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.
Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition.
The XML namespace mechanism, which is based on URIs ([RFC3986]), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control.
The XML namespace mechanism, which is based on URIs ([RFC3986]), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control.
The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced that will address issues relating to hierarchical properties.
The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced that will address issues relating to hierarchical properties.
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.
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.5. Source Resources and Output Resources
4.5. Source Resources and Output Resources
Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one, or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.
Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one, or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.
5. Collections of Web Resources
5. Collections of Web Resources
This section provides a description of a type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace and with HTTP methods. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace.
This section provides a description of a type of Web resource, the collection, and discusses its interactions with the HTTP URL namespace and with HTTP methods. The purpose of a collection resource is to model collection-like objects (e.g., file system directories) within a server's namespace.
Dusseault Standards Track [Page 14] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 14] RFC 4918 WebDAV June 2007
All DAV-compliant resources MUST support the HTTP URL namespace model specified herein.
All DAV-compliant resources MUST support the HTTP URL namespace model specified herein.
5.1. HTTP URL Namespace Model
5.1. HTTP URL Namespace Model
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.
The HTTP URL namespace is a hierarchical namespace where the hierarchy is delimited with the "/" character.
An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member URL. The root, or top-level collection of the namespace under consideration, is exempt from the previous rule. The top-level collection of the namespace under consideration is not necessarily the collection identified by the absolute path '/' -- it may be identified by one or more path segments (e.g., /servlets/webdav/...)
An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member URL. The root, or top-level collection of the namespace under consideration, is exempt from the previous rule. The top-level collection of the namespace under consideration is not necessarily the collection identified by the absolute path '/' -- it may be identified by one or more path segments (e.g., /servlets/webdav/...)
Neither HTTP/1.1 nor WebDAV requires that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.
Neither HTTP/1.1 nor WebDAV requires that the entire HTTP URL namespace be consistent -- a WebDAV-compatible resource may not have a parent collection. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies.
As is implicit in [RFC2616] and [RFC3986], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
As is implicit in [RFC2616] and [RFC3986], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs.
5.2. Collection Resources
5.2. Collection Resources
Collection resources differ from other resources in that they also act as containers. Some HTTP methods apply only to a collection, but some apply to some or all of the resources inside the container defined by the collection. When the scope of a method is not clear, the client can specify what depth to apply. Depth can be either zero levels (only the collection), one level (the collection and directly contained resources), or infinite levels (the collection and all contained resources recursively).
Collection resources differ from other resources in that they also act as containers. Some HTTP methods apply only to a collection, but some apply to some or all of the resources inside the container defined by the collection. When the scope of a method is not clear, the client can specify what depth to apply. Depth can be either zero levels (only the collection), one level (the collection and directly contained resources), or infinite levels (the collection and all contained resources recursively).
A collection's state consists of at least a set of mappings between path segments and resources, and a set of properties on the collection itself. In this document, a resource B will be said to be contained in the collection resource A if there is a path segment mapping that maps to B and that is contained in A. A collection MUST contain at most one mapping for a given path segment, i.e., it is illegal to have the same path segment mapped to more than one resource.
A collection's state consists of at least a set of mappings between path segments and resources, and a set of properties on the collection itself. In this document, a resource B will be said to be contained in the collection resource A if there is a path segment mapping that maps to B and that is contained in A. A collection MUST contain at most one mapping for a given path segment, i.e., it is illegal to have the same path segment mapped to more than one resource.
Dusseault Standards Track [Page 15] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 15] RFC 4918 WebDAV June 2007
Properties defined on collections behave exactly as do properties on non-collection resources. A collection MAY have additional state such as entity bodies returned by GET.
Properties defined on collections behave exactly as do properties on non-collection resources. A collection MAY have additional state such as entity bodies returned by GET.
For all WebDAV-compliant resources A and B, identified by URLs "U" and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain exactly one mapping from "blah" to B.
For all WebDAV-compliant resources A and B, identified by URLs "U" and "V", respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain exactly one mapping from "blah" to B.
Although commonly a mapping consists of a single segment and a resource, in general, a mapping consists of a set of segments and a resource. This allows a server to treat a set of segments as equivalent (i.e., either all of the segments are mapped to the same resource, or none of the segments are mapped to a resource). For example, a server that performs case-folding on segments will treat the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can then use any of these segments to identify the resource. Note that a PROPFIND result will select one of these equivalent segments to identify the mapping, so there will be one PROPFIND response element per mapping, not one per segment in the mapping.
Although commonly a mapping consists of a single segment and a resource, in general, a mapping consists of a set of segments and a resource. This allows a server to treat a set of segments as equivalent (i.e., either all of the segments are mapped to the same resource, or none of the segments are mapped to a resource). For example, a server that performs case-folding on segments will treat the segments "ab", "Ab", "aB", and "AB" as equivalent. A client can then use any of these segments to identify the resource. Note that a PROPFIND result will select one of these equivalent segments to identify the mapping, so there will be one PROPFIND response element per mapping, not one per segment in the mapping.
Collection resources MAY have mappings to non-WebDAV-compliant resources in the HTTP URL namespace hierarchy but are not required to do so. For example, if resource X with URL "http://example.com/bar/blah" is not WebDAV compliant and resource A with "URL http://example.com/bar/" identifies a WebDAV collection, then A may or may not have a mapping from "blah" to X.
Collection resources MAY have mappings to non-WebDAV-compliant resources in the HTTP URL namespace hierarchy but are not required to do so. For example, if resource X with URL "http://example.com/bar/blah" is not WebDAV compliant and resource A with "URL http://example.com/bar/" identifies a WebDAV collection, then A may or may not have a mapping from "blah" to X.
If a WebDAV-compliant resource has no WebDAV-compliant internal members in the HTTP URL namespace hierarchy, then the WebDAV- compliant resource is not required to be a collection.
If a WebDAV-compliant resource has no WebDAV-compliant internal members in the HTTP URL namespace hierarchy, then the WebDAV- compliant resource is not required to be a collection.
There is a standing convention that when a collection is referred to by its name without a trailing slash, the server MAY handle the request as if the trailing slash were present. In this case, it SHOULD return a Content-Location header in the response, pointing to the URL ending with the "/". For example, if a client invokes a method on http://example.com/blah (no trailing slash), the server may respond as if the operation were invoked on http://example.com/blah/ (trailing slash), and should return a Content-Location header with the value http://example.com/blah/. Wherever a server produces a URL referring to a collection, the server SHOULD include the trailing slash. In general, clients SHOULD use the trailing slash form of collection names. If clients do not use the trailing slash form the client needs to be prepared to see a redirect response. Clients will
There is a standing convention that when a collection is referred to by its name without a trailing slash, the server MAY handle the request as if the trailing slash were present. In this case, it SHOULD return a Content-Location header in the response, pointing to the URL ending with the "/". For example, if a client invokes a method on http://example.com/blah (no trailing slash), the server may respond as if the operation were invoked on http://example.com/blah/ (trailing slash), and should return a Content-Location header with the value http://example.com/blah/. Wherever a server produces a URL referring to a collection, the server SHOULD include the trailing slash. In general, clients SHOULD use the trailing slash form of collection names. If clients do not use the trailing slash form the client needs to be prepared to see a redirect response. Clients will
Dusseault Standards Track [Page 16] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 16] RFC 4918 WebDAV June 2007
find the DAV:resourcetype property more reliable than the URL to find out if a resource is a collection.
find the DAV:resourcetype property more reliable than the URL to find out if a resource is a collection.
Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if an OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections.
Clients MUST be able to support the case where WebDAV resources are contained inside non-WebDAV resources. For example, if an OPTIONS response from "http://example.com/servlet/dav/collection" indicates WebDAV support, the client cannot assume that "http://example.com/servlet/dav/" or its parent necessarily are WebDAV collections.
A typical scenario in which mapped URLs do not appear as members of their parent collection is the case where a server allows links or redirects to non-WebDAV resources. For instance, "/col/link" might not appear as a member of "/col/", although the server would respond with a 302 status to a GET request to "/col/link"; thus, the URL "/col/link" would indeed be mapped. Similarly, a dynamically- generated page might have a URL mapping from "/col/index.html", thus this resource might respond with a 200 OK to a GET request yet not appear as a member of "/col/".
写像しているURLが彼らの親収集のメンバーとして現れない典型的なシナリオはサーバがリンクを許容するか、または非WebDAVにリソースを向け直すケースです。 例えば、"/col/link"は"/col/"のメンバーとして現れないかもしれません、サーバは302状態で"/col/link"へのGET要求に応じるでしょうが。 したがって、本当に、URL"/col/link"は写像されるでしょう。 同様に、ダイナミックに生成しているページには"/col/index.html"からのURLマッピングがあるかもしれなくて、その結果、このリソースは、200OKでGET要求に応じますが、"/col/"のメンバーとして現れないかもしれません。
Some mappings to even WebDAV-compliant resources might not appear in the parent collection. An example for this case are servers that support multiple alias URLs for each WebDAV-compliant resource. A server may implement case-insensitive URLs, thus "/col/a" and "/col/A" identify the same resource, yet only either "a" or "A" is reported upon listing the members of "/col". In cases where a server treats a set of segments as equivalent, the server MUST expose only one preferred segment per mapping, consistently chosen, in PROPFIND responses.
WebDAV対応することのリソースさえへのいくつかのマッピングは親収集に載らないかもしれません。 例はこのような場合それぞれのWebDAV対応することのリソースのために複数の別名がURLであるとサポートするサーバです。 「サーバはその結果、大文字と小文字を区別しないURL、"/col/a"を実装するかもしれません、そして、"/col/A"は同じリソースを特定します、そして、しかし、“a"か「A」のどちらかだけが」 /あん部のメンバーを記載しながら、報告されます。」 サーバが1セットの同等な同じくらい区分を扱う場合では、サーバはPROPFIND応答で一貫して選ばれた1マッピングあたり1つの都合のよいセグメントだけを暴露しなければなりません。
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人のアクセス型だけのためのロックを定義して、書いてください。 しかしながら、構文は、広げることができて、他のアクセス型のためにロックする最後の仕様を可能にします。
Dusseault Standards Track [Page 17] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[17ページ]。
6.1. Lock Model
6.1. ロックモデル
This section provides a concise model for how locking behaves. Later sections will provide more detail on some of the concepts and refer back to these model statements. Normative statements related to LOCK and UNLOCK method handling can be found in the sections on those methods, whereas normative statements that cover any method are gathered here.
このセクションはロックがどう振る舞うかに簡潔なモデルを提供します。 後のセクションは、概念のいくつかに関するその他の詳細を提供して、これらのモデル文を差し戻すでしょう。 それらのメソッドのセクションでLOCKに関連する規範的陳述とUNLOCKメソッド取り扱いを見つけることができますが、どんなメソッドもカバーする規範的陳述がここに集められます。
1. A lock either directly or indirectly locks a resource.
1. 錠は直接か間接的にリソースをロックします。
2. A resource becomes directly locked when a LOCK request to a URL of that resource creates a new lock. The "lock-root" of the new lock is that URL. If at the time of the request, the URL is not mapped to a resource, a new empty resource is created and directly locked.
2. リソースはそのリソースの1つのURLへのLOCK要求が新しい錠を作成すると直接ロックされるようになります。 新しい錠の「ロック根」はそのURLです。 URLが要求時点でリソースに写像されないなら、新しい空のリソースは、作成されて、直接ロックされます。
3. An exclusive lock (Section 6.2) conflicts with any other kind of lock on the same resource, whether either lock is direct or indirect. A server MUST NOT create conflicting locks on a resource.
3. 排他的な錠(セクション6.2)は同じリソースでいかなる他の種類の錠とも衝突します、どちらかの錠が直接である、または間接的であることにかかわらず。 サーバは闘争錠をリソースに作成してはいけません。
4. For a collection that is locked with a depth-infinity lock L, all member resources are indirectly locked. Changes in membership of such a collection affect the set of indirectly locked resources:
4. 深さ無限錠Lでロックされる収集において、すべてのメンバーリソースが間接的にロックされます。 そのような収集の会員資格における変化は間接的にロックされたリソースのセットに影響します:
* If a member resource is added to the collection, the new member resource MUST NOT already have a conflicting lock, because the new resource MUST become indirectly locked by L.
* メンバーリソースが収集に追加されるなら、新しいメンバーリソースには闘争錠が既にあってはいけません、新しいリソースがLによって間接的にロックされるようにならなければならないので。
* If a member resource stops being a member of the collection, then the resource MUST no longer be indirectly locked by L.
* メンバーリソースが、収集のメンバーであることを止めるなら、リソースはもうLによって間接的にロックされてはいけません。
5. Each lock is identified by a single globally unique lock token (Section 6.5).
5. ただ一つのグローバルにユニークなロックトークン(セクション6.5)によって各錠は特定されます。
6. An UNLOCK request deletes the lock with the specified lock token. After a lock is deleted, no resource is locked by that lock.
6. UNLOCK要求は指定されたロックトークンで錠を削除します。 錠が削除された後に、リソースは全くその錠によってロックされません。
7. A lock token is "submitted" in a request when it appears in an "If" header (Section 7, "Write Lock", discusses when token submission is required for write locks).
7. “If"ヘッダーに現れるとロックトークンが要求で「提出される」、(「錠を書いてください」というセクション7が、トークン服従がいつの間、必要であるかを論ずる、書く、錠)
8. If a request causes the lock-root of any lock to become an unmapped URL, then the lock MUST also be deleted by that request.
8. また、どんな錠のロック根も要求によって非写像しているURLになるなら、その要求で錠を削除しなければなりません。
Dusseault Standards Track [Page 18] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[18ページ]。
6.2. Exclusive vs. Shared Locks
6.2. 共有された錠に対して限ります。
The most basic form of lock is an exclusive lock. Exclusive locks avoid having to deal with content change conflicts, without requiring any coordination other than the methods described in this specification.
最も基本的な形式の錠は排他的な錠です。 排他的な錠は、満足している変化闘争に対処しなければならないのを避けます、この仕様で説明されたメソッド以外のコーディネートを必要としないで。
However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal that has both access privileges and a valid lock can use the locked resource.
しかしながら、校長が、自己のアクセス権を運動させるつもりであるのを示すようにアクセス権を運動させるのに他のものを入れないようにするのではなく、むしろメカニズムを提供する錠の目標がことである回があります。 このような場合共有された錠を提供します。 共有された錠で、複数の主体が錠を受け取ることができます。 したがって、アクセス権と有効な錠の両方を持っているどんな校長もロックされたリソースを使用できます。
With shared locks, there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set.
共有された錠で、リソースに影響する2つの信頼セットがあります。 最初の信頼セットはアクセス許容で創設されます。 そうする主体が信じられて、例えば、リソースに書く許可を持っているかもしれません。 また、リソース、主体のセットに書く参照許可を持っている人の中では、だれが共有された錠を取り出したかが互いを信じなければならなくて、参照許可の中の(通常)小さい信頼セットが書く作成はセットしました。
Starting with every possible principal on the Internet, in most situations the vast majority of these principals will not have write access to a given resource. Of the small number who do have write access, some principals may decide to guarantee their edits are free from overwrite conflicts by using exclusive write locks. Others may decide they trust their collaborators will not overwrite their work (the potential set of collaborators being the set of principals who have write permission) and use a shared lock, which informs their collaborators that a principal may be working on the resource.
インターネットのあらゆる可能な主体から始まって、これらの校長のかなりの大部分が持っていないほとんどの状況で、与えられたリソースへのアクセスを書いてください。 小ささでは、そうする数は決めました。アクセスを書いてください、そして、数人の校長が、彼らの編集には使用することによって排他的な闘争が錠を書く重ね書きがないのを保証すると決めてもよいです。 他のものは、自分達が、彼らの共同制作者が彼らの仕事(そうした主体のセットである潜在的セットの共同制作者は許可を書く)を上書きして、元本がリソースに働いているかもしれないことを彼らの共同制作者に知らせる共有された錠を使用しないと信じると決めるかもしれません。
The WebDAV extensions to HTTP do not need to provide all of the communications paths necessary for principals to coordinate their activities. When using shared locks, principals may use any out-of- band communication channel to coordinate their work (e.g., face-to- face interaction, written notes, post-it notes on the screen, telephone conversation, email, etc.) The intent of a shared lock is to let collaborators know who else may be working on a resource.
HTTPへのWebDAV拡張子は校長が彼らの活動を調整するのに必要なコミュニケーション経路のすべてを提供する必要はありません。 共有された錠を使用するとき、校長がどんなアウトも使用するかもしれない、-、-通信チャネルを括って、彼らの仕事(例えば、表面から表面への相互作用、書かれた注意、スクリーンの上のそれを掲示している注意、電話での会話、メールなど)を調整してください。 共有された錠の意図は他のだれがリソースに取り組んでいるかもしれないかを共同制作者に知らせることです。
Shared locks are included because experience from Web-distributed authoring systems has indicated that exclusive locks are often too rigid. An exclusive lock is used to enforce a particular editing process: take out an exclusive lock, read the resource, perform edits, write the resource, release the lock. This editing process has the problem that locks are not always properly released, for example, when a program crashes or when a lock creator leaves without
ウェブで分配されたオーサリングシステムからの経験が、排他的な錠がしばしば堅過ぎるのを示したので、共有された錠は含まれています。 排他的な錠は特定の編集プロセスを実施するのに使用されます: 排他的な錠を取り出してください、そして、リソースを読んでください、そして、編集を実行してください、そして、リソースを書いてください、そして、錠をリリースしてください。 この編集プロセスにはプログラムがダウンするか、またはロッククリエイターがいなくなるとき、例えば、錠がいつも適切にリリースされるというわけではないという問題がある
Dusseault Standards Track [Page 19] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[19ページ]。
unlocking a resource. While both timeouts (Section 6.6) and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.
リソースをアンロックします。 怒っている錠を取り外すのにタイムアウト(セクション6.6)と管理動作の両方を使用できる間、必要である場合、どちらのメカニズムも利用可能でないかもしれません。 タイムアウトが長いかもしれませんか、または管理者は手があいていないかもしれません。
A successful request for a new shared lock MUST result in the generation of a unique lock associated with the requesting principal. Thus, if five principals have taken out shared write locks on the same resource, there will be five locks and five lock tokens, one for each principal.
新しい共有された錠を求めるうまくいっている要求は要求主体に関連しているユニークな錠の世代で結果として生じなければなりません。 5個の錠があるでしょう、そして、したがって、共有されていた状態で取り出されて、5つの主体がそうしたなら、同じリソースに錠を書いてください、そして、5はトークン(各主体あたり1つ)をロックします。
6.3. Required Support
6.3. 支持を要します。
A WebDAV-compliant resource is not required to support locking in any form. If the resource does support locking, it may choose to support any combination of exclusive and shared locks for any access types.
WebDAV対応することのリソースは、どんなフォームでもロックをサポートするのに必要ではありません。 リソースがロックをサポートするなら、それは、どんなアクセス型のためにも排他的で共有された錠のどんな組み合わせもサポートするのを選ぶかもしれません。
The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks, while others only provide support for exclusive write locks, while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.
理由は、この柔軟性がそのロック方針であるので、様々なストレージ倉庫によって使われた資源管理とversioningシステムのまさしくその中心に打ちます。 これらの倉庫はどういうロックを利用可能にするかのコントロールを必要とします。 例えば、サポートだけが共有したいくつかの倉庫が錠を書きます、他のものがサポートを提供するだけですが排他的である、錠を書いてください、しかし、他のものは全くロックでないのを使用しますが。 それぞれのシステムが、あるロックの特徴の除外に値することができるくらい異なっているとき、この仕様は、交渉の唯一の軸としてWebDAVの中でロックしながら、いなくなります。
6.4. Lock Creator and Privileges
6.4. ロック創造者と特権
The creator of a lock has special privileges to use the lock to modify the resource. When a locked resource is modified, a server MUST check that the authenticated principal matches the lock creator (in addition to checking for valid lock token submission).
錠のクリエイターには、リソースを変更するのに錠を使用する特権があります。 ロックされたリソースが変更されているとき、サーバは、認証された校長がロッククリエイター(有効なロックトークン服従がないかどうかチェックすることに加えた)に合っているのをチェックしなければなりません。
The server MAY allow privileged users other than the lock creator to destroy a lock (for example, the resource owner or an administrator). The 'unlock' privilege in [RFC3744] was defined to provide that permission.
サーバで、ロッククリエイター以外の特権ユーザは錠(例えば、リソース所有者か管理者)を破壊できるかもしれません。 [RFC3744]の'アンロック'特権は、その許可を提供するために定義されました。
There is no requirement for servers to accept LOCK requests from all users or from anonymous users.
サーバがすべてのユーザ、または、匿名のユーザからLOCK要求を受け入れるという要件が全くありません。
Note that having a lock does not confer full privilege to modify the locked resource. Write access and other privileges MUST be enforced through normal privilege or authentication mechanisms, not based on the possible obscurity of lock token values.
錠を持っているのがロックされたリソースを変更するために完全な特権を与えないことに注意してください。 アクセスを書いてください、他の特権はロックトークン値の可能な不鮮明に基づいているのではなく、正常な特権か認証機構を通して励行されなければなりません。
Dusseault Standards Track [Page 20] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[20ページ]。
6.5. Lock Tokens
6.5. ロックトークン
A lock token is a type of state token that identifies a particular lock. Each lock has exactly one unique lock token generated by the server. Clients MUST NOT attempt to interpret lock tokens in any way.
ロックトークンは特定の錠を特定する一種の州のトークンです。 サーバは各錠でまさに1つのユニークなロックトークンを生成します。クライアントは、何らかの方法でロックトークンを解釈するのを試みてはいけません。
Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. Since lock tokens are unique, a client MAY submit a lock token in an If header on a resource other than the one that returned it.
ロックトークンURIは時間中にすべてのリソースの向こう側にユニークであるに違いありません。 この一意性制約は、リソースとサーバの向こう側に混乱への恐怖なしでロックトークンを提出するのを許容します。 ロックトークンがユニークであるので、クライアントはそれを返したもの以外のリソースでIfヘッダーでロックトークンを提出するかもしれません。
When a LOCK operation creates a new lock, the new lock token is returned in the Lock-Token response header defined in Section 10.5, and also in the body of the response.
LOCK操作が新しい錠を作成すると、セクション10.5で定義されたLock-トークン応答ヘッダ、および応答のボディーでも新しいロックトークンを返します。
Servers MAY make lock tokens publicly readable (e.g., in the DAV: lockdiscovery property). One use case for making lock tokens readable is so that a long-lived lock can be removed by the resource owner (the client that obtained the lock might have crashed or disconnected before cleaning up the lock). Except for the case of using UNLOCK under user guidance, a client SHOULD NOT use a lock token created by another client instance.
サーバで、ロックトークンは公的に読み込み可能に(DAV: 例えば、lockdiscovery所有地の)なるかもしれません。 使用がロックトークンを読み込み可能にするようにケースに入れる1つはしたがって、リソース所有者がそのa長命の錠を取り外すことができるという(錠を掃除する前に、錠を入手したクライアントは、ダウンするか、または切断したかもしれません)ことです。 ユーザ指導、ロックトークンが別のクライアントインスタンスで作成したクライアントSHOULD NOT使用でUNLOCKを使用するケースを除いて。
This specification encourages servers to create Universally Unique Identifiers (UUIDs) for lock tokens, and to use the URI form defined by "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]). However, servers are free to use any URI (e.g., from another scheme) so long as it meets the uniqueness requirements. For example, a valid lock token might be constructed using the "opaquelocktoken" scheme defined in Appendix C.
この仕様は、サーバがロックトークンのためのUniversally Unique Identifiers(UUIDs)を作成して、「一般にユニークな識別子(UUID)つぼの名前空間」([RFC4122])によって定義されたURI書式を使用するよう奨励します。 しかしながら、ユニークさの必要条件を満たす限り、サーバは無料で、どんなURI(例えば、別の体系からの)も使用できます。 例えば、有効なロックトークンは、Appendix Cで定義された"opaquelocktoken"体系を使用することで構成されるかもしれません。
Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
例: 「つぼ:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"」
6.6. Lock Timeout
6.6. ロックタイムアウト
A lock MAY have a limited lifetime. The lifetime is suggested by the client when creating or refreshing the lock, but the server ultimately chooses the timeout value. Timeout is measured in seconds remaining until lock expiration.
錠には、限られた寿命があるかもしれません。 錠を作成するか、またはリフレッシュするとき、寿命はクライアントによって提案されますが、サーバは結局、タイムアウト値を選びます。 タイムアウトは、秒にロック満了まで残りながら、測定されます。
The timeout counter MUST be restarted if a refresh lock request is successful (see Section 9.10.2). The timeout counter SHOULD NOT be restarted at any other time.
タイムアウトカウンタによるaがリフレッシュするなら再開されて、ロック要求がうまくいっているという(セクション9.10.2を見てください)ことでなければなりません。 タイムアウトはSHOULD NOTを打ち返します。他の時ならいつでも、再開されます。
If the timeout expires, then the lock SHOULD be removed. In this case the server SHOULD act as if an UNLOCK method was executed by the
タイムアウトは期限が切れて、次に、錠はSHOULDです。取り除きます。 この場合、まるでUNLOCKメソッドが実行されるかのようにサーバSHOULDは行動します。
Dusseault Standards Track [Page 21] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[21ページ]。
server on the resource using the lock token of the timed-out lock, performed with its override authority.
オーバーライド権威で実行された調節された錠のロックトークンを使用するリソースに関するサーバ。
Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going offline.
サーバがクライアントによって提出された値への周到な注意を支払うように教えられます、彼らがクライアントが実行するつもりである活動のタイプを暗示するとき。 例えば、ブラウザへ駆け込むアプレットは、リソースをロックする必要があるかもしれませんが、アプレットが稼働している環境の不安定性のために、アプレットはいきなりオフにされるかもしれません。 その結果、アプレットは、アプレットが死ぬなら、すぐに錠を取り入れることができるように比較的小さいタイムアウト値を求めそうです。 しかしながら、ユーザが、オフラインで行くのを計画しているかもしれないので、ドキュメント管理システムは非常に長いタイムアウトを求めそうです。
A client MUST NOT assume that just because the timeout has expired, the lock has immediately been removed.
クライアントは、ただタイムアウトが期限が切れたので錠がすぐに取り外されたと仮定してはいけません。
Likewise, a client MUST NOT assume that just because the timeout has not expired, the lock still exists. Clients MUST assume that locks can arbitrarily disappear at any time, regardless of the value given in the Timeout header. The Timeout header only indicates the behavior of the server if extraordinary circumstances do not occur. For example, a sufficiently privileged user may remove a lock at any time, or the system may crash in such a way that it loses the record of the lock's existence.
同様に、クライアントは、タイムアウトが期限が切れているだけではないので錠がまだ存在していると仮定してはいけません。 クライアントは、錠がいつでもTimeoutヘッダーで与えられた値にかかわらず任意に見えなくなることができると仮定しなければなりません。 特別事情が起こらない場合にだけ、Timeoutヘッダーはサーバの働きを示します。 例えば、十分特権があるユーザがいつでも、錠を取り外すかもしれませんか、またはシステムは錠の存在に関する記録を失うような方法でダウンするかもしれません。
6.7. Lock Capability Discovery
6.7. ロック能力発見
Since server lock support is optional, a client trying to lock a resource on a server can either try the lock and hope for the best, or perform some form of discovery to determine what lock capabilities the server supports. This is known as lock capability discovery. A client can determine what lock types the server supports by retrieving the DAV:supportedlock property.
サーバロックサポートが任意であるので、サーバに関するリソースをロックしようとするクライアントは、サーバがどんなロック能力をサポートするかを決定するために何らかの形式の発見を錠を試して、うまくいくことを望むか、または実行できます。 これはロック能力発見として知られています。 クライアントは、サーバがDAVを検索することによってどんなロックタイプをサポートするかを決心できます: supportedlockの特性。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:supportedlock property.
LOCKがメソッドであるとサポートするどんなDAV対応することのリソースもDAVをサポートしなければなりません: supportedlockの特性。
6.8. Active Lock Discovery
6.8. 活発なロック発見
If another principal locks a resource that a principal wishes to access, it is useful for the second principal to be able to find out who the first principal is. For this purpose the DAV:lockdiscovery property is provided. This property lists all outstanding locks, describes their type, and MAY even provide the lock tokens.
別の校長が最初の主体がだれであるかを見つけることができる2番目の主体の役に立った状態でアクセスする主要な願望、それがそうであるリソースをロックするなら。 このためにDAV: lockdiscovery資産を提供します。 この特性は、すべての傑出している錠を記載して、彼らのタイプについて説明して、ロックトークンを提供さえするかもしれません。
Any DAV-compliant resource that supports the LOCK method MUST support the DAV:lockdiscovery property.
LOCKがメソッドであるとサポートするどんなDAV対応することのリソースもDAVをサポートしなければなりません: lockdiscoveryの特性。
Dusseault Standards Track [Page 22] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[22ページ]。
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.
このセクションが意味論詳細について説明する、ロックタイプに書いてください。 書いてください。錠は、ロックタイプの特定の例であり、この仕様で説明されて、唯一のロックタイプです。
An exclusive write lock protects a resource: it prevents changes by any principal other than the lock creator and in any case where the lock token is not submitted (e.g., by a client process other than the one holding the lock).
書いてください。排他的である、錠はリソースを保護します: 何かロック創造者以外の校長とどのような場合でも、どこでロック象徴を提出しないかによって(例えば、錠を持っているもの以外のクライアント工程で)それは変化を防ぎます。
Clients MUST submit a lock-token they are authorized to use in any request that modifies a write-locked resource. The list of modifications covered by a write-lock include:
クライアントがaを変更するどんな要求でも彼らが認可されるロック象徴使用を提出しなければならない、書く、-、ロック、リソース。 変更箇所一覧は錠を書いているインクルードをカバーしました:
1. A change to any of the following aspects of any write-locked resource:
1. いずれの以下の局面のどれかへの変化、書く、-、ロック、リソース:
* any variant,
* どんな異形
* any dead property,
* どんな死んでいる特性
* any live property that is lockable (a live property is lockable unless otherwise defined.)
* どんなロックできる精力の特性(別の方法で定義されない場合、精力の特性はロックできます。)
2. For collections, any modification of an internal member URI. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. More discussion on write locks and collections is found in Section 7.4.
2. 収集、内部のメンバーURIのどんな変更のためにも。 加えられるか、取り外すか、または異なったリソースを特定するなら、収集の内部のメンバーURIが変更されると考えられます。 より多くの議論、錠は書いて、収集はセクション7.4で備え付けています。
3. A modification of the mapping of the root of the write lock, either to another resource or to no resource (e.g., DELETE).
3. 根に関するマッピングの変更、別のリソース、または、どんなリソース(例えば、DELETE)にも錠を書かないでください。
Of the methods defined in HTTP and WebDAV, PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY (for the destination resource), DELETE, and MKCOL are affected by write locks. All other HTTP/WebDAV methods defined so far -- GET in particular -- function independently of a write lock.
HTTPで定義された方法WebDAV、ポスト、PROPPATCH、LOCK、UNLOCK、MOVE、COPY(目的地リソースのための)、DELETE、およびMKCOLが影響を受けるPUTでは、錠を書いてください。 今までのところ定義されているすべての他のHTTP/WebDAV方法--特にGET--aが独自に機能するのが錠を書きます。
The next few sections describe in more specific terms how write locks interact with various operations.
次の数セクションが、より特定でどのようにが様々な操作と対話すると錠に書く用語について説明します。
Dusseault Standards Track [Page 23] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[23ページ]。
7.1. Write Locks and Properties
7.1. 錠と特性を書いてください。
While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined as lockable are guaranteed not to change while write locked.
aのないものが書いている間、錠は精力の特性の値が変えるのが、まだ可能であるリソースの特性を変更しないかもしれません、ロックされてさえいる間、それらのschemasの要件のため。 ロックできると定義された死んでいる特性と精力の特性だけが変化しないように保証される、ロックされていた状態で、書いてください。
7.2. Avoiding Lost Updates
7.2. 無くなっているアップデートを避けます。
Although the write locks provide some help in preventing lost updates, they cannot guarantee that updates will never be lost. Consider the following scenario:
書いてください。錠は無くなっているアップデートを防ぐのに何らかの助けを提供して、それらは、アップデートが決して失われないのを保証できません。 以下のシナリオを考えてください:
Two clients A and B are interested in editing the resource 'index.html'. Client A is an HTTP client rather than a WebDAV client, and so does not know how to perform locking.
2人のクライアントAとBが'index.html'というリソースを編集したがっています。 クライアントAは、WebDAVクライアントよりむしろHTTPクライアントであるのでロックを実行する方法を知りません。
Client A doesn't lock the document, but does a GET, and begins editing.
クライアントAは、ドキュメントをロックしませんが、GETをして、編集し始めます。
Client B does LOCK, performs a GET and begins editing.
クライアントBは、LOCKをして、GETを実行して、編集し始めます。
Client B finishes editing, performs a PUT, then an UNLOCK.
クライアントBは、編集し終えて、PUTを実行して、その時はUNLOCKです。
Client A performs a PUT, overwriting and losing all of B's changes.
ビーズ変化のすべてを上書きして、失って、クライアントAは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のような操作の系列を実施できません。
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サーバと対話するときはいつも、善良な市民が錠/を使用することによって操作(少なくともデフォルトで)の系列を検索するか、書く、またはアンロックするということであるかもしれません。
Dusseault Standards Track [Page 24] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[24ページ]。
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.3. Write Locks and Unmapped URLs
7.3. 錠とUnmapped URLを書いてください。
WebDAV provides the ability to send a LOCK request to an unmapped URL in order to reserve the name for use. This is a simple way to avoid the lost-update problem on the creation of a new resource (another way is to use If-None-Match header specified in Section 14.26 of [RFC2616]). It has the side benefit of locking the new resource immediately for use of the creator.
WebDAVは使用のために名前を予約するためにLOCK要求を非写像しているURLに送る能力を提供します。 これは新しいリソースの創造のときに無くなっているアップデート問題を避ける簡単な方法(別の方法は[RFC2616]のセクション14.26で指定されたなにも合わせないIfヘッダーを使用することである)です。 それには、すぐ創造者の使用のための新しいリソースをロックする役得があります。
Note that the lost-update problem is not an issue for collections because MKCOL can only be used to create a collection, not to overwrite an existing collection. When trying to lock a collection upon creation, clients can attempt to increase the likelihood of getting the lock by pipelining the MKCOL and LOCK requests together (but because this doesn't convert two separate operations into one atomic operation, there's no guarantee this will work).
無くなっているアップデート問題が既存の収集を上書きするのではなく、収集を作成するのにMKCOLを使用できるだけであるので収集のための問題でないことに注意してください。 創造に関する収集をロックしようとするとき、クライアントは、一緒にパイプライン処理による錠にMKCOLを得て、要求をLOCKに得る可能性を広げるのを試みることができます(これが2つの別々の操作を1つの原子操作に変換しないので、これが働くという保証が全くありません)。
A successful lock request to an unmapped URL MUST result in the creation of a locked (non-collection) resource with empty content. Subsequently, a successful PUT request (with the correct lock token) provides the content for the resource. Note that the LOCK request has no mechanism for the client to provide Content-Type or Content- Language, thus the server will use defaults or empty values and rely on the subsequent PUT request for correct values.
非写像しているURLへのうまくいっているロック要求は空の内容があるロックされた(非収集している)リソースの創造をもたらさなければなりません。 次に、うまくいっているPUT要求(正しいロック象徴がある)はリソースのための内容を提供します。 LOCK要求にはクライアントがコンテントタイプかContent言語を提供するメカニズムが全くなくて、その結果、サーバがデフォルトか空の値を使用して、正しい値を求めるその後のPUT要求に依存することに注意してください。
A resource created with a LOCK is empty but otherwise behaves in every way as a normal resource. It behaves the same way as a resource created by a PUT request with an empty body (and where a Content-Type and Content-Language was not specified), followed by a LOCK request to the same resource. Following from this model, a locked empty resource:
LOCKと共に作成されたリソースは、空ですが、そうでなければ、あらゆる点で正常なリソースとして振る舞います。 それは同じリソースへのLOCK要求があとに続いた空のボディー(コンテントタイプとContent-言語が指定されなかったところ)でPUT要求で作成されたリソースと同じ道を振る舞わせます。 このモデル、ロックされた空のリソースから、続きます:
o Can be read, deleted, moved, and copied, and in all ways behaves as a regular non-collection resource.
o 読んで、削除されて、動かされて、コピーできて、通常の非収集リソースとしてすべての方法で振る舞います。
o Appears as a member of its parent collection.
o 親収集のメンバーとして、現れます。
o SHOULD NOT disappear when its lock goes away (clients must therefore be responsible for cleaning up their own mess, as with any other operation or any non-empty resource).
o 錠が遠ざかるとき(したがって、クライアントはそれら自身の混乱をきれいにするのに責任があるに違いありません、いかなる他の操作やどんな非空のリソースのようにも)、SHOULD NOTは見えなくなります。
Dusseault Standards Track [Page 25] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[25ページ]。
o MAY NOT have values for properties like DAV:getcontentlanguage that haven't been specified yet by the client.
o DAV: getcontentlanguageのようなクライアントによってまだ指定されていない特性のための値を持っていないかもしれません。
o Can be updated (have content added) with a PUT request.
o PUT要求でアップデートできます(内容を加えさせます)。
o MUST NOT be converted into a collection. The server MUST fail a MKCOL request (as it would with a MKCOL request to any existing non-collection resource).
o 収集に変換されてはいけません。 サーバはMKCOL要求に失敗しなければなりません(どんな既存の非収集リソースへのMKCOL要求でもそうするように)。
o MUST have defined values for DAV:lockdiscovery and DAV: supportedlock properties.
o DAV: lockdiscoveryとDAVのために値を定義したに違いありません: supportedlockの特性。
o The response MUST indicate that a resource was created, by use of the "201 Created" response code (a LOCK request to an existing resource instead will result in 200 OK). The body must still include the DAV:lockdiscovery property, as with a LOCK request to an existing resource.
o 応答は、リソースが作成されたのを示さなければなりません、「作成された201」応答コードの使用で(既存のリソースへのLOCK要求は代わりに200OKをもたらすでしょう)。 ボディーは既存のリソースへのLOCK要求ならまだDAV: lockdiscoveryの特性を含まなければなりません。
The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH.
PUTとことによるとPROPPATCHを使用して、それをロックしたすぐ後にクライアントがロックされた空のリソースをアップデートすると予想されます。
Alternatively and for backwards compatibility to [RFC2518], servers MAY implement Lock-Null Resources (LNRs) instead (see definition in Appendix D). Clients can easily interoperate both with servers that support the old model LNRs and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET, and by not relying on specific properties of LNRs.
代わりにと[RFC2518]への遅れている互換性のために、サーバは代わりに、Lock-ヌルResources(LNRs)を実行するかもしれません(Appendix Dとの定義を見てください)。 クライアントは、年取ったモデルLNRsを支持するサーバと「ロックされた空のリソース」のお勧めのモデルと共にLOCKの後にMKCOLかGETではなく、非写像しているURLにPUTを試みるだけ、そして、LNRsの特定の性質を当てにしないことによって、容易に共同利用できます。
7.4. Write Locks and Collections
7.4. 錠と収集を書いてください。
There are two kinds of collection write locks. A depth-0 write lock on a collection protects the collection properties plus the internal member URLs of that one collection, while not protecting the content or properties of member resources (if the collection itself has any entity bodies, those are also protected). A depth-infinity write lock on a collection provides the same protection on that collection and also provides write lock protection on every member resource.
収集の種類が錠を書く2があります。 メンバーリソース(また、収集自体に何か実体本体があるなら、ものは保護される)の内容か特性を保護していない間、その1つの収集の収集の特性と内部のメンバーURLを保護します深さ-0が、収集での錠を書く。 深さ無限がその収集のときに同じ保護を提供して、また、提供すると収集での錠に書くAはあらゆるメンバーリソースにロック保護を書きます。
Expressed otherwise, a write lock of either kind protects any request that would create a new resource in a write locked collection, any request that would remove an internal member URL of a write locked collection, and any request that would change the segment name of any internal member.
別の方法で言い表されて、aはaがロックされた収集を書くとロックされた収集、aの内部のメンバーURLを取り除くどんな要求にも書く種類が新しいリソースを作成するどんな要求も保護するどちらかの錠、およびどんな内部のメンバーのセグメント名も変えるどんな要求も書きます。
Thus, a collection write lock protects all the following actions:
その結果、以下のすべての動作を保護します収集が、錠を書く:
o DELETE a collection's direct internal member,
o a収集のDELETEものは内部のメンバーを指示します。
Dusseault Standards Track [Page 26] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[26ページ]。
o MOVE an internal member out of the collection,
o MOVE、収集からの内部のメンバー
o MOVE an internal member into the collection,
o MOVE、収集への内部のメンバー
o MOVE to rename an internal member within a collection,
o 収集の中で内部のメンバーを改名するMOVE
o COPY an internal member into a collection, and
o そしてCOPY、収集への内部のメンバー。
o PUT or MKCOL request that would create a new internal member.
o PUTかMKCOLが、それが新しい内部のメンバーを創造するよう要求します。
The collection's lock token is required in addition to the lock token on the internal member itself, if it is locked separately.
収集のロック象徴が内部のメンバー自身の上のロック象徴に加えて必要です、それが別々にロックされるなら。
In addition, a depth-infinity lock affects all write operations to all members of the locked collection. With a depth-infinity lock, the resource identified by the root of the lock is directly locked, and all its members are indirectly locked.
添加、感情がすべて、ロックされた収集のすべてのメンバーへの操作を書く深さ無限錠で。 深さ無限錠で、錠の根によって特定されたリソースは直接ロックされます、そして、すべてのメンバーが間接的にロックされます。
o Any new resource added as a descendant of a depth-infinity locked collection becomes indirectly locked.
o 深さ無限の子孫が収集をロックしたので加えられたどんな新しいリソースも間接的にロックされるようになります。
o Any indirectly locked resource moved out of the locked collection into an unlocked collection is thereafter unlocked.
o ロックされた収集からアンロックされた収集に動かされたどんな間接的にロックされたリソースの錠もその後、開いています。
o Any indirectly locked resource moved out of a locked source collection into a depth-infinity locked target collection remains indirectly locked but is now protected by the lock on the target collection (the target collection's lock token will thereafter be required to make further changes).
o ロックされたソース収集から深さ無限に動かされたどんな間接的にロックされたリソースも、間接的にロックされたターゲット収集の残りをロックしますが、ターゲット収集のときに現在、錠によって保護されます(ターゲット収集のロック象徴はその後、一層の変更を行わなければならないでしょう)。
If a depth-infinity write LOCK request is issued to a collection containing member URLs identifying resources that are currently locked in a manner that conflicts with the new lock (see Section 6.1, point 3), the request MUST fail with a 423 (Locked) status code, and the response SHOULD contain the 'no-conflicting-lock' precondition.
深さ無限が書くなら、LOCK要求は新しい錠と衝突する方法が現在閉じ込められるリソースを特定するメンバーURLを含む収集に出されます、そして、(セクション6.1を見てください、ポイント3)要求は423(ロックされる)ステータスコードで失敗しなければなりません、そして、応答SHOULDは'闘争していない錠'前提条件を含んでいます。
If a lock request causes the URL of a resource to be added as an internal member URL of a depth-infinity locked collection, then the new resource MUST be automatically protected by the lock. For example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c, then resource /a/b/c will be added to the write lock.
深さ無限の内部のメンバーURLが収集をロックしたのでロック要求でリソースのURLを加えるなら、錠で自動的に新しいリソースを保護しなければなりません。 例えば、収集/a/b/がロックされていた状態で書くことであり、リソース/cが/a/b/cに動かされるならリソース/a/b/cに加えられる、錠を書いてください。
Dusseault Standards Track [Page 27] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[27ページ]。
7.5. Write Locks and the If Request Header
7.5. そして、錠を書いてください、要求ヘッダーです。
A user agent has to demonstrate knowledge of a lock when requesting an operation on a locked resource. Otherwise, the following scenario might occur. In the scenario, program A, run by User A, takes out a write lock on a resource. Program B, also run by User A, has no knowledge of the lock taken out by program A, yet performs a PUT to the locked resource. In this scenario, the PUT succeeds because locks are associated with a principal, not a program, and thus program B, because it is acting with principal A's credential, is allowed to perform the PUT. However, had program B known about the lock, it would not have overwritten the resource, preferring instead to present a dialog box describing the conflict to the user. Due to this scenario, a mechanism is needed to prevent different programs from accidentally ignoring locks taken out by other programs with the same authorization.
ロックされたリソースで操作を要求するとき、ユーザエージェントは錠に関する知識を示さなければなりません。 さもなければ、以下のシナリオは起こるかもしれません。 シナリオ、User Aによって動かされたプログラムAでは、aからの撮影はリソースに錠を書きます。 また、User Aが動かされるプログラムBは、プログラムAで錠に関する知識を全く取り出させませんが、ロックされたリソースにPUTを実行します。 錠がプログラムではなく、元本に関連しているので、このシナリオに、PUTは成功します、そして、その結果、プログラムBは校長Aのものと共に信任しているのに行動しているので、PUTを実行できます。 しかしながら、プログラムBが錠に関して知っていたなら、リソースを上書きしなかったでしょうに、代わりに闘争について説明するダイアログボックスをユーザに提示するのを好んで。 このシナリオのため、メカニズムが、異なったプログラムが偶然同じ認可で他のプログラムで取り出された錠を無視するのを防ぐのに必要です。
In order to prevent these collisions, a lock token MUST be submitted by an authorized principal for all locked resources that a method may change or the method MUST fail. A lock token is submitted when it appears in an If header. For example, if a resource is to be moved and both the source and destination are locked, then two lock tokens must be submitted in the If header, one for the source and the other for the destination.
これらの衝突を防いで、認可された元本が方法が変えるかもしれないすべてのロックされたリソースのためにロック象徴を提出しなければなりませんか、または方法は失敗しなければなりません。 Ifヘッダーに現れると、ロック象徴を提出します。 例えば、リソースが動くことであり、ソースと目的地の両方をロックするなら、Ifヘッダー、ソースともう片方のためのもので2つのロック象徴を目的地に提出しなければなりません。
7.5.1. Example - Write Lock and COPY
7.5.1. 例--錠とコピーを書いてください。
>>Request
>>要求
COPY /~fielding/index.html HTTP/1.1 Host: www.example.com Destination: http://www.example.com/users/f/fielding/index.html If: <http://www.example.com/users/f/fielding/index.html> (<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
コピー/~フィールディング/index.html HTTP/1.1ホスト: www.example.com Destination: http://www.example.com/users/f/fielding/index.html 、: <http://www.example.com/ユーザ/f/フィールディング/index.html>。(<つぼ:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204いいえ内容
In this example, even though both the source and destination are locked, only one lock token must be submitted (the one for the lock on the destination). This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.
この例では、両方ですが、ソースと目的地をロックして、1つのロック象徴だけを提出しなければなりません(目的地の錠のためのもの)。 これがソースリソースでCOPYによって変更されないで、したがって、影響を受けないからである錠を書いてください。 この例では、ユーザエージェント認証は以前にHTTPプロトコルの範囲の外のメカニズムで起こりました、基本的なトランスポート層の中で。
Dusseault Standards Track [Page 28] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[28ページ]。
7.5.2. Example - Deleting a Member of a Locked Collection
7.5.2. 例--ロックされた収集のメンバーを削除すること。
Consider a collection "/locked" with an exclusive, depth-infinity write lock, and an attempt to delete an internal member "/locked/ member":
「」 /がロックしたa収集を考える」、排他的であることで、徹底的な無限は錠、および内部のメンバーのために"/locked/ member"を削除する試みを書きます:
>>Request
>>要求
DELETE /locked/member HTTP/1.1 Host: example.com
/locked/member HTTP/1.1ホストを削除してください: example.com
>>Response
>>応答
HTTP/1.1 423 Locked Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 423はコンテントタイプをロックしました: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:lock-token-submitted> <D:href>/locked/</D:href> </D:lock-token-submitted> </D:error>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 誤りxmlns: Dが等しい、「DAV: 「><D: ロック象徴で提出された><D: href>/locked/</D: href></D: ロック象徴で提出された></D: 誤り>」
Thus, the client would need to submit the lock token with the request to make it succeed. To do that, various forms of the If header (see Section 10.4) could be used.
したがって、クライアントは、成功させるという要求でロック象徴を提出する必要があるでしょう。 それをするために、Ifヘッダー(セクション10.4を見る)の様々なフォームを使用できました。
"No-Tag-List" format:
「タグリストがありません」形式:
If: (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
: (<つぼ:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
"Tagged-List" format, for "http://example.com/locked/":
" http://example.com/locked/ "のための「タグ付けをされたリスト」形式:
If: <http://example.com/locked/> (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
: <http://example.com/locked/>。(<つぼ:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
"Tagged-List" format, for "http://example.com/locked/member":
" http://example.com/locked/member "のための「タグ付けをされたリスト」形式:
If: <http://example.com/locked/member> (<urn:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
: <http://example.com/固定された/メンバー>。(<つぼ:uuid:150852e2-3847-42d5-8cbe-0f4f296f26cf>)
Note that, for the purpose of submitting the lock token, the actual form doesn't matter; what's relevant is that the lock token appears in the If header, and that the If header itself evaluates to true.
実際のフォームがロックトークンを提出する目的のために重要でないことに注意してください。 関連ことはロックトークンがIfヘッダーに現れて、Ifヘッダー自体が本当に評価するそれです。
Dusseault Standards Track [Page 29] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[29ページ]。
7.6. Write Locks and COPY/MOVE
7.6. 錠とコピー/移動を書いてください。
A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with a depth-infinity lock, then the resource will be added to the lock.
実施がコピーしてはいけないCOPYメソッドはソースでアクティブな状態でロックされますいずれも、書く。 しかしながら、上述しているように、COPYが深さ無限錠でロックされる収集にリソースをコピーすると、リソースは錠に加えられるでしょう。
A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, if there is an existing lock at the destination, the server MUST add the moved resource to the destination lock scope. For example, if the MOVE makes the resource a child of a collection that has a depth-infinity lock, then the resource will be added to that collection's lock. Additionally, if a resource with a depth-infinity lock is moved to a destination that is within the scope of the same lock (e.g., within the URL namespace tree covered by the lock), the moved resource will again be added to the lock. In both these examples, as specified in Section 7.5, an If header must be submitted containing a lock token for both the source and destination.
aに関する要求が移行してはいけないとロックされたリソースに書くうまくいっているMOVE、リソースで錠を書いてください。 しかしながら、既存の錠が目的地にあれば、サーバは目的地のロック範囲に動くリソースを加えなければなりません。 例えば、MOVEが深さ無限錠を持っている収集の子供にリソースを作ると、リソースはその収集の錠に加えられるでしょう。 さらに、深さ無限錠があるリソースが同じ錠(例えば、錠でカバーされたURL名前空間木の中の)の範囲の中にある目的地に動かされるなら、動くリソースは再び錠に加えられるでしょう。 これらの例の両方では、セクション7.5で指定されるように、ソースと目的地の両方へのロックトークンを含んでいて、Ifヘッダーを提出しなければなりません。
7.7. Refreshing Write Locks
7.7. リフレッシュして、錠を書いてください。
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 request with an If header but without a body. A server receiving a LOCK request with no body MUST NOT create a new lock -- this form of the LOCK request is only to be used to "refresh" an existing lock (meaning, at minimum, that any timers associated with the lock MUST be reset).
しかしながら、クライアントはIfヘッダーにもかかわらず、ボディーなしでLOCK要求を提出するかもしれません。 ボディーなしでLOCK要求を受け取るサーバは新しい錠を作成してはいけません--LOCK要求のこのフォームは既存の錠を「リフレッシュすること」に単に使用される(最小限におけるどんなタイマも錠に関連づけた意味をリセットしなければなりません)ことです。
Clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client, and a server MAY refresh a lock with a timeout period that is different than the previous timeout period used for the lock, provided it advertises the new value in the LOCK refresh response.
クライアントは任意のヘッダーが彼らの錠で要求をリフレッシュするのを評価するTimeoutを提出するかもしれません。 サーバ、いつも、クライアントによって提出されたTimeoutヘッダーを無視するかもしれなくて、サーバが錠のために費やされた前のタイムアウト時間と異なったタイムアウト時間がある錠をリフレッシュするとき、広告を出すなら、LOCKの新しい値は応答をリフレッシュします。
If an error is received in response to a refresh LOCK request, the client MUST NOT assume that the lock was refreshed.
aに対応して誤りを受けるなら、LOCK要求をリフレッシュしてください、そして、クライアントは、錠がリフレッシュされたと仮定してはいけません。
Dusseault Standards Track [Page 30] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[30ページ]。
8. General Request and Response Handling
8. 一般要求と応答取り扱い
8.1. Precedence in Error Handling
8.1. 先行の間違った取り扱い
Servers MUST return authorization errors in preference to other errors. This avoids leaking information about protected resources (e.g., a client that finds that a hidden resource exists by seeing a 423 Locked response to an anonymous request to the resource).
サーバは他の誤りに優先して承認誤りを返さなければなりません。 これは、保護されたリソース(例えば、隠されたリソースが匿名の要求への423Locked応答をリソースに見ることによって存在するのがわかるクライアント)に関して情報を漏らすのを避けます。
8.2. Use of XML
8.2. XMLの使用
In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter information either in an XML ([REC-XML]) request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, providing extensibility; and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support.
HTTP/1.1では、メソッドパラメタ情報はHTTPヘッダで排他的にコード化されました。 HTTP/1.1と異なって、WebDAVはXML([REC-XML])要求実体ボディー、またはHTTPヘッダにおけるメソッドパラメタ情報をコード化します。 メソッドパラメタをコード化するXMLの使用は付加的なXML要素を現体制に追加する能力によって動機づけられました、伸展性を提供して。 ISO10646文字集合における情報をコード化するXMLの性能で国際化サポートを提供すること。
In addition to encoding method parameters, XML is used in WebDAV to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input.
メソッドパラメタをコード化することに加えて、XMLはメソッド出力のためにXMLの利点を伸展性と国際化に提供して、メソッドから応答をコード化するのにWebDAVで使用されて、入力されます。
When XML is used for a request or response body, the Content-Type type SHOULD be application/xml. Implementations MUST accept both text/xml and application/xml in request and response bodies. Use of text/xml is deprecated.
XMLが使用されているときには要求か応答本体、コンテントタイプタイプSHOULDにおける、アプリケーション/xmlになってください。 実装は要求と応答本体でテキスト/xmlとアプリケーション/xmlの両方を受け入れなければなりません。 テキスト/xmlの使用は推奨しないです。
All DAV-compliant clients and resources MUST use XML parsers that are compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either requests or responses MUST be, at minimum, well formed and use namespaces correctly. If a server receives XML that is not well- formed, then the server MUST reject the entire request with a 400 (Bad Request). If a client receives XML that is not well-formed in a response, then the client MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning.
すべてのDAV対応することのクライアントとリソースは[REC-XML]と[REC-XML-NAMES]と共に言いなりになっているXMLパーサを使用しなければなりません。 要求か応答のどちらかに使用されるすべてのXMLが最小限で整形式であり、正しく名前空間を使用しなければなりません。 サーバがよく形成されないXMLを受けるなら、サーバは400(悪いRequest)で全体の要求を拒絶しなければなりません。 クライアントが応答で整形式でないXMLを受け取るなら、クライアントは実行されたメソッドの結果に関して何でも仮定してはいけません、そして、SHOULDは誤動作としてサーバを扱います。
Note that processing XML submitted by an untrusted source may cause risks connected to privacy, security, and service quality (see Section 20). Servers MAY reject questionable requests (even though they consist of well-formed XML), for instance, with a 400 (Bad Request) status code and an optional response body explaining the problem.
信頼できないソースによって提出された処理XMLがプライバシー、セキュリティ、およびサービス品質に関連づけられた危険を引き起こすかもしれないことに注意してください(セクション20を見てください)。 例えば、サーバは400(悪いRequest)ステータスコードと問題がわかる任意の応答本体で疑わしい要求(整形式のXMLから成りますが)を拒絶するかもしれません。
Dusseault Standards Track [Page 31] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[31ページ]。
8.3. URL Handling
8.3. URL取り扱い
URLs appear in many places in requests and responses. Interoperability experience with [RFC2518] showed that many clients parsing Multi-Status responses did not fully implement the full Reference Resolution defined in Section 5 of [RFC3986]. Thus, servers in particular need to be careful in handling URLs in responses, to ensure that clients have enough context to be able to interpret all the URLs. The rules in this section apply not only to resource URLs in the 'href' element in Multi-Status responses, but also to the Destination and If header resource URLs.
URLは要求と応答における多くの場所に現れます。 [RFC2518]の相互運用性経験は、Multi-状態応答を分析する多くのクライアントが完全に[RFC3986]のセクション5で定義された完全なReference Resolutionを実装したというわけではないのを示しました。 したがって、サーバは、特にすべてのURLを解釈できるようにクライアントには十分な文脈があるのを保証するために応答でURLを扱うのにおいて慎重である必要があります。 このセクションの規則はMulti-状態応答における'href'要素のリソースURLに適用するだけではなく、DestinationとIfヘッダーリソースURLにも適用されます。
The sender has a choice between two approaches: using a relative reference, which is resolved against the Request-URI, or a full URI. A server MUST ensure that every 'href' value within a Multi-Status response uses the same format.
送付者は2つのアプローチの間に選択を持っています: 相対参照か完全なURIを使用します。(相対参照はRequest-URIに対して決議されています)。 サーバは、Multi-状態応答の中のあらゆる'href'値が同じ形式を使用するのを確実にしなければなりません。
WebDAV only uses one form of relative reference in its extensions, the absolute path.
WebDAVは拡大、絶対パスに1つの形式に関する相対参照を使用するだけです。
Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )
純真な審判は絶対URIと等しいです。| (経路絶対[“?"質問])です。
The absolute-URI, path-absolute and query productions are defined in Sections 4.3, 3.3, and 3.4 of [RFC3986].
絶対URIであり、経路絶対と質問創作は[RFC3986]のセクション4.3、3.3、および3.4で定義されます。
Within Simple-ref productions, senders MUST NOT:
Simple-審判創作の中では、送付者はそうしてはいけません:
o use dot-segments ("." or ".."), or
o または、「ドットセグメントを使用してください、(「.」、」、」、)
o have prefixes that do not match the Request-URI (using the comparison rules defined in Section 3.2.3 of [RFC2616]).
o Request-URI(.3セクション3.2[RFC2616]で定義された比較規則を使用する)に合っていない接頭語を持ってください。
Identifiers for collections SHOULD end in a '/' character.
'収集SHOULDのための識別子は'/'キャラクタに終わります。
8.3.1. Example - Correct URL Handling
8.3.1. 例--正しいURL取り扱い
Consider the collection http://example.com/sample/ with the internal member URL http://example.com/sample/a%20test and the PROPFIND request below:
収集が http://example.com/sample/a%20test とPROPFINDが以下で要求する内部のメンバーURLがある http://example.com/sample/ であると考えてください:
>>Request:
>>要求:
PROPFIND /sample/ HTTP/1.1 Host: example.com Depth: 1
PROPFIND/サンプル/HTTP/1.1ホスト: example.com Depth: 1
Dusseault Standards Track [Page 32] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[32ページ]。
In this case, the server should return two 'href' elements containing either
この場合、サーバはどちらかを含む2つの'href'要素を返すべきです。
o 'http://example.com/sample/' and 'http://example.com/sample/a%20test', or
o または' http://example.com/sample/ 'と' http://example.com/sample/a%20test '。
o '/sample/' and '/sample/a%20test'
o '/sample/'と'/sample/a%20test'
Note that even though the server may be storing the member resource internally as 'a test', it has to be percent-encoded when used inside a URI reference (see Section 2.1 of [RFC3986]). Also note that a legal URI may still contain characters that need to be escaped within XML character data, such as the ampersand character.
サーバが'テスト'として内部的にメンバーリソースを保存しているかもしれませんが、URI参照に使用されるとそれがパーセントによってコード化されていなければならないことに注意してください([RFC3986]のセクション2.1を見てください)。 また、法的なURIがまだアンパーサンドキャラクタなどのXMLキャラクタデータの中で逃げられる必要があるキャラクタを含んでいるかもしれないことに注意してください。
8.4. Required Bodies in Requests
8.4. 要求における必要なボディー
Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as the client intended.
これらの新しいメソッドのいくつかがボディーを定義しません。 ボディーが予想さえされなかったとき、サーバはボディーを求めるすべての要求を調べなければなりません。 要求本体が存在していますが、サーバによって無視される場合では、サーバは415(サポートされないメディアType)で要求を拒絶しなければなりません。 これは、クライアントが意図したようにボディーを処理できなかったことをクライアント(拡張子を使用するのを試みていたかもしれない)に知らせます。
8.5. HTTP Headers for Use in WebDAV
8.5. WebDAVにおける使用のためのHTTPヘッダ
HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible (see Section 14.18, [RFC2616]).
HTTPはWebDAV要求と応答に使用できる多くのヘッダーを定義します。 これらのすべてがすべての状況で適切であるというわけではありません、そして、いくつかの相互作用が未定義であるかもしれません。 できれば、HTTP1.1がすべての応答でDateヘッダーを必要とすることに注意してください([RFC2616]、セクション14.18を見てください)。
The server MUST do authorization checks before checking any HTTP conditional header.
どんなHTTPの条件付きのヘッダーもチェックする前に、サーバは許可検査をしなければなりません。
8.6. ETag
8.6. ETag
HTTP 1.1 recommends the use of ETags rather than modification dates, for cache control, and there are even stronger reasons to prefer ETags for authoring. Correct use of ETags is even more important in a distributed authoring environment, because ETags are necessary along with locks to avoid the lost-update problem. A client might fail to renew a lock, for example, when the lock times out and the client is accidentally offline or in the middle of a long upload. When a client fails to renew the lock, it's quite possible the resource can still be relocked and the user can go on editing, as long as no changes were made in the meantime. ETags are required for the client to be able to distinguish this case. Otherwise, the
HTTP1.1は変更日付よりむしろETagsの使用を推薦します、キャッシュ制御のために、そして、オーサリングのためにETagsを好むさらに強い理由があります。 ETagsの正しい使用は分散書いている環境でさらに重要です、ETagsが無くなっているアップデート問題を避ける錠と共に必要であるので。 ロック回であるときに、例えば、クライアントが外で錠を取り替えないかもしれなくて、クライアントは、偶然オフラインである、または長いアップロードの途中で取り替えます。 クライアントが錠を取り替えないとき、まだリソースを再ロックできて、ユーザが、編集し続けることができるのは、かなり可能です、変更が全く差し当たり行われなかった限り。 クライアントはETagsが本件を区別できなければなりません。 そうでなければ
Dusseault Standards Track [Page 33] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[33ページ]。
client is forced to ask the user whether to overwrite the resource on the server without even being able to tell the user if it has changed. Timestamps do not solve this problem nearly as well as ETags.
クライアントは、それが変化したかどうかユーザに言うことさえできないでリソースをサーバに上書きするかどうかやむを得ずユーザに尋ねます。 タイムスタンプはほとんどETagsと同様にこの問題を解決しません。
Strong ETags are much more useful for authoring use cases than weak ETags (see Section 13.3.3 of [RFC2616]). Semantic equivalence can be a useful concept but that depends on the document type and the application type, and interoperability might require some agreement or standard outside the scope of this specification and HTTP. Note also that weak ETags have certain restrictions in HTTP, e.g., these cannot be used in If-Match headers.
強いETagsは弱いETagsより書いている使用のはるかに役に立つケース(.3セクション13.3[RFC2616]を見る)です。 意味等価性が役に立つ概念であるかもしれませんが、場合によりけりです、ドキュメントタイプとアプリケーションタイプで相互運用性は何らかの協定かこの仕様とHTTPの範囲の外の規格を必要とするかもしれません。 また、弱いETagsにはHTTPにおける、ある制限があることに注意してください、そして、例えば、If-マッチヘッダーでこれらは使用できません。
Note that the meaning of an ETag in a PUT response is not clearly defined either in this document or in RFC 2616 (i.e., whether the ETag means that the resource is octet-for-octet equivalent to the body of the PUT request, or whether the server could have made minor changes in the formatting or content of the document upon storage). This is an HTTP issue, not purely a WebDAV issue.
PUT応答におけるETagの意味がこのドキュメントかRFC2616で明確に定義されないことに注意してください(すなわち、ETagが、リソースが八重奏のためのPUT要求のボディーに同等な八重奏であることを意味するか、またはサーバがストレージのときにドキュメントの形式か中身におけるマイナーチェンジを作ったかもしれないことにかかわらず)。 これは純粋にWebDAV問題ではなく、HTTP問題です。
Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or the Last-Modified time) for a resource that has an unchanged body and location. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed.
ユーザをうながすか、またはクライアントがやむを得ず投げるかもしれないので、ETagが変化するなら内容が遠くで変化して、WebDAVサーバSHOULD NOT変化は変わりのないボディーと位置を持っているリソースのためのETag(または、最終更新日時間)です。 ETagはボディーの状態かリソースのコンテンツを表します。 資産が変化したかどうか言うどんな同様の方法もありません。
8.7. Including Error Response Bodies
8.7. 誤り応答本体を含んでいます。
HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until the specification for Versioning Extensions to WebDAV introduced a mechanism to include more specific information in the body of an error response (Section 1.6 of [RFC3253]). The error body mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This error body mechanism is covered in Section 16.
WebDAVへのVersioning Extensionsのための仕様が誤り応答([RFC3253]のセクション1.6)のボディーにより特定の情報を含むようにメカニズムを紹介したとき、HTTPとWebDAVは初めて、マシン-「パー-可能」情報にほとんどの誤り応答のボディーを使用しました。 誤りボディーメカニズムはボディーを取るかもしれませんが、既にボディーを定義しないどんな誤り応答と共にも使用するのは適切です。 ステータスコードが多くのものを意味できるとき(例えば、400Bad Requestは、必要であることで、ヘッダーが行方不明であることを意味できますか、フォーマットされて、ヘッダーが不当にそうであるか多くが以上です)、メカニズムは特に適切です。 この誤りボディーメカニズムはセクション16でカバーされています。
8.8. Impact of Namespace Operations on Cache Validators
8.8. キャッシュValidatorsにおける名前空間操作の影響
Note that the HTTP response headers "Etag" and "Last-Modified" (see [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per resource), and are used by clients for caching. Therefore servers must ensure that executing any operation that affects the URL namespace (such as COPY, MOVE, DELETE, PUT, or MKCOL) does preserve their semantics, in particular:
HTTP応答ヘッダ"Etag"と「最終更新日」([RFC2616]を見てください、セクション14.19と14.29)がURL(1リソースでないのあたりの)単位で定義されて、キャッシュにクライアントによって使用されることに注意してください。 したがって、サーバは、URL名前空間(COPY、MOVE、DELETE、PUT、またはMKCOLなどの)に影響するどんな操作も実行するとそれらの意味論が保存されるのを確実にしなければなりません、特に:
Dusseault Standards Track [Page 34] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[34ページ]。
o For any given URL, the "Last-Modified" value MUST increment every time the representation returned upon GET changes (within the limits of timestamp resolution).
o どんな与えられたURLのためにも、「最終更新日」値は毎回、GET変化(タイムスタンプ解決の限界の中の)で返された表現を増加しなければなりません。
o For any given URL, an "ETag" value MUST NOT be reused for different representations returned by GET.
o どんな与えられたURLにおいても、GETによって返された異なった表現のために"ETag"値を再利用してはいけません。
In practice this means that servers
実際には、これはそのサーバを意味します。
o might have to increment "Last-Modified" timestamps for every resource inside the destination namespace of a namespace operation unless it can do so more selectively, and
o そしてより選択的にそうができないなら名前空間操作の目的地名前空間であらゆるリソースのための「最終更新日」タイムスタンプを増加しなければならないかもしれない。
o similarly, might have to re-assign "ETag" values for these resources (unless the server allocates entity tags in a way so that they are unique across the whole URL namespace managed by the server).
o 同様に、力はこれらのリソースのために"ETag"値を再選任しなければなりません(サーバが方法で実体タグを割り当てるので彼らがサーバによって管理された全体のURL名前空間の向こう側にユニークでない場合)。
Note that these considerations also apply to specific use cases, such as using PUT to create a new resource at a URL that has been mapped before, but has been deleted since then.
また、これらの問題がケースを特定的用法に適用するというそれが持っているURLで新しいリソースを作成するのにPUTを使用などなどのメモは、以前写像されますが、それ以来、削除されています。
Finally, WebDAV properties (such as DAV:getetag and DAV: getlastmodified) that inherit their semantics from HTTP headers must behave accordingly.
最終的にWebDAVの特性、(DAV: getetagやDAVのように:、getlastmodifiedする、)、それは必須がそれに従って、振る舞わせるHTTPヘッダからそれらの意味論を引き継ぎます。
9. HTTP Methods for Distributed Authoring
9. 分配されたオーサリングのためのHTTPメソッド
9.1. PROPFIND Method
9.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 URLs. All DAV-compliant resources MUST support the PROPFIND method and the propfind XML element (Section 14.20) along with all XML elements defined for use with that element.
PROPFINDメソッドはリソースにどれか内部のメンバーがいないならRequest-URIによって特定されたリソースの上、または、Request-URIと潜在的にそのメンバーリソースによって特定されたリソースの上で定義された特性を検索します、リソースが内部のメンバーURLを持っている収集であるなら。 すべてのDAV対応することのリソースが、使用のためにその要素で定義されたすべてのXML要素と共にPROPFINDメソッドとpropfind XML要素が(セクション14.20)であるとサポートしなければなりません。
A client MUST submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request. Servers MUST support "0" and "1" depth requests on WebDAV-compliant resources and SHOULD support "infinity" requests. In practice, support for infinite-depth requests MAY be disabled, due to the performance and security concerns associated with this behavior. Servers SHOULD treat a request without a Depth header as if a "Depth: infinity" header was included.
クライアントがa値があるDepthヘッダーを提出しなければならない、「何0インチも、「1インチ、またはPROPFIND要求がある「無限」。」 サーバがサポートしなければならない、「0インチと「深さがWebDAV対応することのリソースで要求して、「無限」要求をサポートするべきである1インチ。」 実際には、無限の深さ要求のサポートはこの振舞いに関連している性能と安全上の配慮のため無効にされるかもしれません。 サーバSHOULDがDepthヘッダーなしで要求を扱う、「深さ:」 「無限」ヘッダーは含まれていました。
Dusseault Standards Track [Page 35] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[35ページ]。
A client may submit a 'propfind' XML element in the body of the request method describing what information is being requested. It is possible to:
クライアントはどんな情報が要求されているかを説明する要求メソッドのボディーで'propfind'XML要素を提出するかもしれません。 それは以下に可能です。
o Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by the server),
o Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by the server),
o Request property values for those properties defined in this specification (at a minimum) plus dead properties, by using the 'allprop' element (the 'include' element can be used with 'allprop' to instruct the server to also include additional live properties that may not have been returned otherwise),
o Request property values for those properties defined in this specification (at a minimum) plus dead properties, by using the 'allprop' element (the 'include' element can be used with 'allprop' to instruct the server to also include additional live properties that may not have been returned otherwise),
o Request a list of names of all the properties defined on the resource, by using the 'propname' element.
o Request a list of names of all the properties defined on the resource, by using the 'propname' element.
A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request.
A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request.
Note that 'allprop' does not return values for all live properties. WebDAV servers increasingly have expensively-calculated or lengthy properties (see [RFC3253] and [RFC3744]) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what live properties exist, and request named properties when retrieving values. For a live property defined elsewhere, that definition can specify whether or not that live property would be returned in 'allprop' requests.
Note that 'allprop' does not return values for all live properties. WebDAV servers increasingly have expensively-calculated or lengthy properties (see [RFC3253] and [RFC3744]) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what live properties exist, and request named properties when retrieving values. For a live property defined elsewhere, that definition can specify whether or not that live property would be returned in 'allprop' requests.
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.
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.
If there is an error retrieving a property, then a proper error result MUST be included in the response. A request to retrieve the value of a property that does not exist is an error and MUST be noted with a 'response' XML element that contains a 404 (Not Found) status value.
If there is an error retrieving a property, then a proper error result MUST be included in the response. A request to retrieve the value of a property that does not exist is an error and MUST be noted with a 'response' XML element that contains a 404 (Not Found) status value.
Consequently, the 'multistatus' XML element for a collection resource MUST include a 'response' XML element for each member URL of the collection, to whatever depth was requested. It SHOULD NOT include any 'response' elements for resources that are not WebDAV-compliant. Each 'response' element MUST contain an 'href' element that contains the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource are returned as a flat list whose order of entries is not
Consequently, the 'multistatus' XML element for a collection resource MUST include a 'response' XML element for each member URL of the collection, to whatever depth was requested. It SHOULD NOT include any 'response' elements for resources that are not WebDAV-compliant. Each 'response' element MUST contain an 'href' element that contains the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource are returned as a flat list whose order of entries is not
Dusseault Standards Track [Page 36] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 36] RFC 4918 WebDAV June 2007
significant. Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses.
significant. Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses.
Properties may be subject to access control. In the case of 'allprop' and 'propname' requests, if a principal does not have the right to know whether a particular property exists, then the property MAY be silently excluded from the response.
Properties may be subject to access control. In the case of 'allprop' and 'propname' requests, if a principal does not have the right to know whether a particular property exists, then the property MAY be silently excluded from the response.
Some PROPFIND results MAY be cached, with care, as there is no cache validation mechanism for most properties. This method is both safe and idempotent (see Section 9.1 of [RFC2616]).
Some PROPFIND results MAY be cached, with care, as there is no cache validation mechanism for most properties. This method is both safe and idempotent (see Section 9.1 of [RFC2616]).
9.1.1. PROPFIND Status Codes
9.1.1. PROPFIND Status Codes
This section, as with similar sections for other methods, provides some guidance on error codes and preconditions or postconditions (defined in Section 16) that might be particularly useful with PROPFIND.
This section, as with similar sections for other methods, provides some guidance on error codes and preconditions or postconditions (defined in Section 16) that might be particularly useful with PROPFIND.
403 Forbidden - A server MAY reject PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body.
403 Forbidden - A server MAY reject PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body.
9.1.2. Status Codes for Use in 'propstat' Element
9.1.2. Status Codes for Use in 'propstat' Element
In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
200 OK - A property exists and/or its value is successfully returned.
200 OK - A property exists and/or its value is successfully returned.
401 Unauthorized - The property cannot be viewed without appropriate authorization.
401 Unauthorized - The property cannot be viewed without appropriate authorization.
403 Forbidden - The property cannot be viewed regardless of authentication.
403 Forbidden - The property cannot be viewed regardless of authentication.
404 Not Found - The property does not exist.
404 Not Found - The property does not exist.
Dusseault Standards Track [Page 37] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 37] RFC 4918 WebDAV June 2007
9.1.3. Example - Retrieving Named Properties
9.1.3. Example - Retrieving Named Properties
>>Request
>>Request
PROPFIND /file HTTP/1.1 Host: www.example.com Content-type: application/xml; charset="utf-8" Content-Length: xxxx
PROPFIND /file HTTP/1.1 Host: www.example.com Content-type: application/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox/> <R:author/> <R:DingALing/> <R:Random/> </D:prop> </D:propfind>
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox/> <R:author/> <R:DingALing/> <R:Random/> </D:prop> </D:propfind>
>>Response
>>Response
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response xmlns:R="http://ns.example.com/boxschema/"> <D:href>http://www.example.com/file</D:href> <D:propstat> <D:prop> <R:bigbox> <R:BoxType>Box type A</R:BoxType> </R:bigbox> <R:author> <R:Name>J.J. Johnson</R:Name> </R:author> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> <D:propstat> <D:prop><R:DingALing/><R:Random/></D:prop> <D:status>HTTP/1.1 403 Forbidden</D:status> <D:responsedescription> The user does not have access to the DingALing property. </D:responsedescription> </D:propstat>
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response xmlns:R="http://ns.example.com/boxschema/"> <D:href>http://www.example.com/file</D:href> <D:propstat> <D:prop> <R:bigbox> <R:BoxType>Box type A</R:BoxType> </R:bigbox> <R:author> <R:Name>J.J. Johnson</R:Name> </R:author> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> <D:propstat> <D:prop><R:DingALing/><R:Random/></D:prop> <D:status>HTTP/1.1 403 Forbidden</D:status> <D:responsedescription> The user does not have access to the DingALing property. </D:responsedescription> </D:propstat>
Dusseault Standards Track [Page 38] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 38] RFC 4918 WebDAV June 2007
</D:response> <D:responsedescription> There has been an access violation error. </D:responsedescription> </D:multistatus>
</D:response> <D:responsedescription> There has been an access violation error. </D:responsedescription> </D:multistatus>
In this example, PROPFIND is executed on a non-collection resource http://www.example.com/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case, only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
In this example, PROPFIND is executed on a non-collection resource http://www.example.com/file. The propfind XML element specifies the name of four properties whose values are being requested. In this case, only two properties were returned, since the principal issuing the request did not have sufficient access rights to see the third and fourth properties.
9.1.4. Example - Using 'propname' to Retrieve All Property Names
9.1.4. Example - Using 'propname' to Retrieve All Property Names
>>Request
>>Request
PROPFIND /container/ HTTP/1.1 Host: www.example.com Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
PROPFIND /container/ HTTP/1.1 Host: www.example.com Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <propfind xmlns="DAV:"> <propname/> </propfind>
<?xml version="1.0" encoding="utf-8" ?> <propfind xmlns="DAV:"> <propname/> </propfind>
>>Response
>>Response
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://www.example.com/container/</href> <propstat> <prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox/> <R:author/> <creationdate/> <displayname/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status>
<?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://www.example.com/container/</href> <propstat> <prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox/> <R:author/> <creationdate/> <displayname/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status>
Dusseault Standards Track [Page 39] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 39] RFC 4918 WebDAV June 2007
</propstat> </response> <response> <href>http://www.example.com/container/front.html</href> <propstat> <prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox/> <creationdate/> <displayname/> <getcontentlength/> <getcontenttype/> <getetag/> <getlastmodified/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus>
</propstat> </response> <response> <href>http://www.example.com/container/front.html</href> <propstat> <prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox/> <creationdate/> <displayname/> <getcontentlength/> <getcontenttype/> <getetag/> <getlastmodified/> <resourcetype/> <supportedlock/> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus>
In this example, PROPFIND is invoked on the collection resource http://www.example.com/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its descendants should be returned.
In this example, PROPFIND is invoked on the collection resource http://www.example.com/container/, with a propfind XML element containing the propname XML element, meaning the name of all properties should be returned. Since no Depth header is present, it assumes its default value of "infinity", meaning the name of the properties on the collection and all its descendants should be returned.
Consistent with the previous example, resource http://www.example.com/container/ has six properties defined on it: bigbox and author in the "http://ns.example.com/boxschema/" namespace, and creationdate, displayname, resourcetype, and supportedlock in the "DAV:" namespace.
Consistent with the previous example, resource http://www.example.com/container/ has six properties defined on it: bigbox and author in the "http://ns.example.com/boxschema/" namespace, and creationdate, displayname, resourcetype, and supportedlock in the "DAV:" namespace.
The resource http://www.example.com/container/index.html, a member of the "container" collection, has nine properties defined on it, bigbox in the "http://ns.example.com/boxschema/" namespace and creationdate, displayname, getcontentlength, getcontenttype, getetag, getlastmodified, resourcetype, and supportedlock in the "DAV:" namespace.
The resource http://www.example.com/container/index.html, a member of the "container" collection, has nine properties defined on it, bigbox in the "http://ns.example.com/boxschema/" namespace and creationdate, displayname, getcontentlength, getcontenttype, getetag, getlastmodified, resourcetype, and supportedlock in the "DAV:" namespace.
This example also demonstrates the use of XML namespace scoping and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all enclosed elements. Hence, all elements that do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.
This example also demonstrates the use of XML namespace scoping and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all enclosed elements. Hence, all elements that do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.
Dusseault Standards Track [Page 40] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 40] RFC 4918 WebDAV June 2007
9.1.5. Example - Using So-called 'allprop'
9.1.5. Example - Using So-called 'allprop'
Note that 'allprop', despite its name, which remains for backward- compatibility, does not return every property, but only dead properties and the live properties defined in this specification.
Note that 'allprop', despite its name, which remains for backward- compatibility, does not return every property, but only dead properties and the live properties defined in this specification.
>>Request
>>Request
PROPFIND /container/ HTTP/1.1 Host: www.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
PROPFIND /container/ HTTP/1.1 Host: www.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> </D:propfind>
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> </D:propfind>
>>Response
>>Response
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/container/</D:href> <D:propstat> <D:prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox><R:BoxType>Box type A</R:BoxType></R:bigbox> <R:author><R:Name>Hadrian</R:Name></R:author> <D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate> <D:displayname>Example collection</D:displayname> <D:resourcetype><D:collection/></D:resourcetype> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop>
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/container/</D:href> <D:propstat> <D:prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox><R:BoxType>Box type A</R:BoxType></R:bigbox> <R:author><R:Name>Hadrian</R:Name></R:author> <D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate> <D:displayname>Example collection</D:displayname> <D:resourcetype><D:collection/></D:resourcetype> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop>
Dusseault Standards Track [Page 41] RFC 4918 WebDAV June 2007
Dusseault Standards Track [Page 41] RFC 4918 WebDAV June 2007
<D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/container/front.html</D:href> <D:propstat> <D:prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox><R:BoxType>Box type B</R:BoxType> </R:bigbox> <D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate> <D:displayname>Example HTML resource</D:displayname> <D:getcontentlength>4525</D:getcontentlength> <D:getcontenttype>text/html</D:getcontenttype> <D:getetag>"zzyzx"</D:getetag> <D:getlastmodified >Mon, 12 Jan 1998 09:25:56 GMT</D:getlastmodified> <D:resourcetype/> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/container/front.html</D:href> <D:propstat> <D:prop xmlns:R="http://ns.example.com/boxschema/"> <R:bigbox><R:BoxType>Box type B</R:BoxType> </R:bigbox> <D:creationdate>1997-12-01T18:27:21-08:00</D:creationdate> <D:displayname>Example HTML resource</D:displayname> <D:getcontentlength>4525</D:getcontentlength> <D:getcontenttype>text/html</D:getcontenttype> <D:getetag>"zzyzx"</D:getetag> <D:getlastmodified >Mon, 12 Jan 1998 09:25:56 GMT</D:getlastmodified> <D:resourcetype/> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
In this example, PROPFIND was invoked on the resource http://www.example.com/container/ with a Depth header of 1, meaning the request applies to the resource and its children, and a propfind XML element containing the allprop XML element, meaning the request should return the name and value of all the dead properties defined on the resources, plus the name and value of all the properties defined in this specification. This example illustrates the use of relative references in the 'href' elements of the response.
In this example, PROPFIND was invoked on the resource http://www.example.com/container/ with a Depth header of 1, meaning the request applies to the resource and its children, and a propfind XML element containing the allprop XML element, meaning the request should return the name and value of all the dead properties defined on the resources, plus the name and value of all the properties defined in this specification. This example illustrates the use of relative references in the 'href' elements of the response.
The resource http://www.example.com/container/ has six properties defined on it: 'bigbox' and 'author in the "http://ns.example.com/boxschema/" namespace, DAV:creationdate, DAV: displayname, DAV:resourcetype, and DAV:supportedlock.
リソース http://www.example.com/container/ には、それで定義された6つの特性があります: 'bigbox'と'DAV、" http://ns.example.com/boxschema/ "名前空間、DAVにcreationdateに以下を書いてください' displayname、DAV: resourcetype、およびDAV: supportedlock。
Dusseault Standards Track [Page 42] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[42ページ]。
The last four properties are WebDAV-specific, defined in Section 15. Since GET is not supported on this resource, the get* properties (e.g., DAV:getcontentlength) are not defined on this resource. The WebDAV-specific properties assert that "container" was created on December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT (DAV:creationdate), has a name of "Example collection" (DAV: displayname), a collection resource type (DAV:resourcetype), and supports exclusive write and shared write locks (DAV:supportedlock).
最後の4つの性質が、WebDAV特有で、セクション15で定義されています。 以来GETがこのリソースでサポートされない、特性(例えば、DAV: getcontentlength)が定義されない*にこのリソースを得てください。 WebDAV特有の性質は「コンテナ」は1997年12月1日に作成されました、5:42に: aを「例の収集」(DAV: displayname)、収集リソースタイプ(DAV: resourcetype)で名義にして、21PMがグリニッジ標準時の8時間西の時間帯(DAV: creationdate)でサポートを排他的にするのを書いて、共有されて、錠(DAV: supportedlock)を書くように断言します。
The resource http://www.example.com/container/front.html has nine properties defined on it:
リソース http://www.example.com/container/front.html には、それで定義された9つの特性があります:
'bigbox' in the "http://ns.example.com/boxschema/" namespace (another instance of the "bigbox" property type), DAV:creationdate, DAV: displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
" http://ns.example.com/boxschema/ "名前空間("bigbox"特性のタイプの別のインスタンス)における'bigbox'、DAV: creationdate、DAV: DAV: displayname、DAV: getcontentlength、DAV: getcontenttype、getetag、DAV:、getlastmodifiedする、DAV: DAV: resourcetype、およびsupportedlock。
The DAV-specific properties assert that "front.html" was created on December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT (DAV:creationdate), has a name of "Example HTML resource" (DAV: displayname), a content length of 4525 bytes (DAV:getcontentlength), a MIME type of "text/html" (DAV:getcontenttype), an entity tag of "zzyzx" (DAV:getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT (DAV:getlastmodified), has an empty resource type, meaning that it is not a collection (DAV:resourcetype), and supports both exclusive write and shared write locks (DAV:supportedlock).
DAV特有の性質は、"front.html"が1997年12月1日に作成されたと断言します、6:27に: グリニッジ標準時の8時間西の時間帯(DAV: creationdate)では、21PMは「例のHTMLリソース」(DAV: displayname)の名前を持っています、4525バイト(DAV: getcontentlength)のコンテンツの長さ、1998年1月12日月曜日の(DAV: getcontenttype)("zzyzx"(DAV: getetag)の実体タグ)が最後に変更された「テキスト/html」のMIMEの種類、09時に:; 収集(DAV: resourcetype)、およびサポートはともに排他的ではありません。25 : グリニッジ標準時56、(DAV:、getlastmodifiedする、)、それを意味して、空のリソースタイプがある、それ、書いて、共有されて、錠(DAV: supportedlock)を書いてください。
9.1.6. Example - Using 'allprop' with 'include'
9.1.6. 例--'包含'がある'allprop'を使用すること。
>>Request
>>要求
PROPFIND /mycol/ HTTP/1.1 Host: www.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
PROPFIND/mycol/HTTP/1.1ホスト: www.example.com Depth: 1つのコンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> <D:include> <D:supported-live-property-set/> <D:supported-report-set/> </D:include> </D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV: 「><D: allprop/><D: ><D: サポートしているライブ特性のセット/><D: サポートしているレポートセット/></Dを含めてください: ></D: propfind>を含めてください」
Dusseault Standards Track [Page 43] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[43ページ]。
In this example, PROPFIND is executed on the resource http://www.example.com/mycol/ and its internal member resources. The client requests the values of all live properties defined in this specification, plus all dead properties, plus two more live properties defined in [RFC3253]. The response is not shown.
この例では、PROPFINDはリソース http://www.example.com/mycol/ とその内部のメンバーリソースで実行されます。 クライアントはこの仕様、およびすべての死んでいる特性で定義された、すべての精力の特性、および[RFC3253]で定義された2つのより精力の特性の値を要求します。 応答は示されません。
9.2. PROPPATCH Method
9.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.
PROPPATCHメソッドはRequest-URIによって特定されたリソースで定義された資産を設定する、そして/または、取り外すために要求本体で指定された指示を処理します。
All DAV-compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements. Execution of the directives in this method is, of course, subject to access control constraints. DAV-compliant resources SHOULD support the setting of arbitrary dead properties.
すべてのDAV対応することのリソースが、PROPPATCHがメソッドであることを支えなければならなくて、用意ができているpropertyupdateを使用することで指定される指示を処理して、XML要素を取り除かなければなりません。 このメソッドにおける、指示の実行はもちろんアクセス制御規制を受けることがあります。 DAV対応することのリソースSHOULDは任意の死んでいる特性の設定をサポートします。
The request message body of a PROPPATCH method MUST contain the propertyupdate XML element.
PROPPATCHメソッドの要求メッセージ本体はpropertyupdate XML要素を含まなければなりません。
Servers MUST process PROPPATCH instructions in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus, if any error occurs during processing, all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in Sections 14.23 and 14.26.
サーバはドキュメントオーダー(注文が無関係であるという正常な規則への例外)におけるPROPPATCH指示を処理しなければなりません。 なにもに実行されていた状態で指示をすべて実行しなければなりません。 したがって、何か誤りが処理の間、発生するなら、すべての実行された指示を元に戻さなければなりませんでした、そして、適切な誤り結果は戻りました。 指示処理の詳細は、セットの定義で見つけられて、セクション14.23と14.26で指示を取り除くことができます。
If a server attempts to make any of the property changes in a PROPPATCH request (i.e., the request is not rejected for high-level errors before processing the body), the response MUST be a Multi- Status response as described in Section 9.2.1.
サーバが、PROPPATCHにおける変化が要求する特性のどれかを作るのを試みるなら(ボディーを処理する前に、すなわち、要求はハイレベルの誤りで拒絶されません)、応答はセクション9.2.1で説明されるようにMulti状態応答であるに違いありません。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドは金庫ではなく、ベキ等元([RFC2616]のセクション9.1を見る)です。 このメソッドへの応答をキャッシュしてはいけません。
9.2.1. Status Codes for Use in 'propstat' Element
9.2.1. 'propstat'要素における使用のためのステータスコード
In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat'; however, clients should be prepared to handle other 2/3/4/5xx series status codes as well.
PROPPATCH応答では、'propstat'要素の中で個人財産の情報を返します(セクション14.22を見てください)、それぞれそれに現れる特性の情報を含む個々の'状態'要素を含んでいて。 以下のリストは'propstat'で使用される中で最も一般的なステータスコードをまとめます。 しかしながら、クライアントはまた、他の2/3/4/5xxシリーズステータスコードを扱う用意ができているべきです。
Dusseault Standards Track [Page 44] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[44ページ]。
200 (OK) - The property set or change succeeded. Note that if this appears for one property, it appears for every property in the response, due to the atomicity of PROPPATCH.
200 (OK)--特性がセットしたか、または変化は成功しました。 PROPPATCHの最小単位のためこれが1つの特性の弁護に出廷するなら、応答であらゆる特性の弁護に出廷することに注意してください。
403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot alter one of the properties.
403 (禁じられます)--サーバが、指定しないのを選ぶ理由で、クライアントは特性の1つを変更できません。
403 (Forbidden): The client has attempted to set a protected property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'cannot-modify-protected-property' inside the response body.
403 (禁制): クライアントは、DAVなどの保護された特性を設定するのを試みました: getetag。 この誤り、サーバSHOULD使用に前提条件を返すなら、応答本体の中で'保護された特性を変更できないこと'をコード化してください。
409 (Conflict) - The client has provided a value whose semantics are not appropriate for the property.
409 (闘争)--クライアントは特性には、意味論が適切でない値を提供しました。
424 (Failed Dependency) - The property change could not be made because of another property change that failed.
424 (Dependencyに失敗します)--失敗した別の特性の変化のために特性の変更を行うことができませんでした。
507 (Insufficient Storage) - The server did not have sufficient space to record the property.
507 (不十分なStorage)--サーバには、特性を記録できるくらいのスペースがありませんでした。
9.2.2. Example - PROPPATCH
9.2.2. 例--PROPPATCH
>>Request
>>要求
PROPPATCH /bar.html HTTP/1.1 Host: www.example.com Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
PROPPATCH /bar.html HTTP/1.1ホスト: www.example.comコンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:propertyupdate xmlns:D="DAV:" xmlns:Z="http://ns.example.com/standards/z39.50/"> <D:set> <D:prop> <Z:Authors> <Z:Author>Jim Whitehead</Z:Author> <Z:Author>Roy Fielding</Z:Author> </Z:Authors> </D:prop> </D:set> <D:remove> <D:prop><Z:Copyright-Owner/></D:prop> </D:remove> </D:propertyupdate>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propertyupdate xmlns:Dが等しい、「DAV:」、」 xmlns: Zが等しい、「 http://ns.example.com/standards/z39.50/ 、「><D: ><Dを設定してください: ><Z: 作者><Z: 作者>ジムホワイトヘッド</Z: 作者><Zを支えてください: </Zをさばいている>ロイを書いてください: ></Z: 作者のために></Dを書いてください: ></D: 設定><Dを支えてください: ><Dを取り外してください: ><Z: 版権の所有者/></Dを支えてください: ></Dを支えてください: @?/D: propertyupdate hを取り外してください?br />
Dusseault Standards Track [Page 45] RFC 4918 WebDAV June 2007
>>Response
HTTP/1.1 207マルチ状態コンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:multistatus xmlns:Dが等しい、「DAV:」、」 xmlns: Zが等しい、「 http://ns.example.com/standards/z39.50/ 、「><D: 応答><D: href>http://www.example.com/bar.html</D: href><D: propstat><D: ><Z: 作者/></Dを支えてください: ><Dを支えてください: 状態>HTTP/1」; 1 424の失敗したDependency</D: 状態></D: propstat><D: propstat><D: ><Z: 著作権所有者/></Dを支えてください: ><D: 状態>HTTP/1.1 409Conflict</D: 状態></D: propstat><Dを支えてください: responsedescription>Copyright Ownerは削除できませんでしたし. </D: responsedescription></D: 応答></D: 「マルチ-状態」>を変更もしました。
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:Z="http://ns.example.com/standards/z39.50/"> <D:response> <D:href>http://www.example.com/bar.html</D:href> <D:propstat> <D:prop><Z:Authors/></D:prop> <D:status>HTTP/1.1 424 Failed Dependency</D:status> </D:propstat> <D:propstat> <D:prop><Z:Copyright-Owner/></D:prop> <D:status>HTTP/1.1 409 Conflict</D:status> </D:propstat> <D:responsedescription> Copyright Owner cannot be deleted or altered.</D:responsedescription> </D:response> </D:multistatus>
この例では、クライアントは" http://ns.example.com/standards/z39.50/ "名前空間における、「作者」属性の価値を設定して、同じ名前空間で特性の「版権の所有者」を取り除くようサーバに要求します。 Copyright-所有者資産を取り外すことができなかったので、改質は全く起こりません。 Authorsの特性のための424(失敗したDependency)ステータスコードは、Copyright-所有者資産を取り外すとの闘争がなければ、この動作が成功したのを示します。
In this example, the client requests the server to set the value of the "Authors" property in the "http://ns.example.com/standards/z39.50/" namespace, and to remove the property "Copyright-Owner" in the same namespace. Since the Copyright-Owner property could not be removed, no property modifications occur. The 424 (Failed Dependency) status code for the Authors property indicates this action would have succeeded if it were not for the conflict with removing the Copyright-Owner property.
9.3. MKCOLメソッド
9.3. MKCOL Method
MKCOLはRequest-URIによって指定された位置で新しい収集リソースを作成します。 Request-URIが既にリソースに写像されるなら、MKCOL MUSTは失敗します。 「MKCOL処理の間、サーバは親収集の内部のメンバーにRequest-URIを作らなければなりません、Request-URIがそうでないなら」/、」 どれかそのような先祖が存在しないなら、メソッドは失敗しなければなりません。 MKCOL操作が新しい収集リソースを作成するとき、すべての先祖が既に存在しなければなりませんか、またはメソッドは409(闘争)ステータスコードで失敗しなければなりません。 例えば、収集/a/b/c/d/を作成するという要求をして、/a/b/c/が存在していないなら、要求は失敗しなければなりません。
MKCOL creates a new collection resource at the location specified by the Request-URI. If the Request-URI is already mapped to a resource, then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI an internal member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the request must fail.
MKCOLが要求本体なしで呼び出されるとき、新たに作成された収集SHOULDには、メンバーが全くいません。
When MKCOL is invoked without a request body, the newly created collection SHOULD have no members.
Dusseault Standards Track [Page 46] RFC 4918 WebDAV June 2007
A MKCOL request message may contain a message body. The precise behavior of a MKCOL request when the body is present is undefined, but limited to creating collections, members of a collection, bodies of members, and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand, it MUST respond with a 415 (Unsupported Media Type) status code. If the server decides to reject the request based on the presence of an entity or the type of an entity, it should use the 415 (Unsupported Media Type) status code.
このメソッドは金庫ではなく、ベキ等元([RFC2616]のセクション9.1を見る)です。 このメソッドへの応答をキャッシュしてはいけません。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
9.3.1. MKCOLステータスコード
9.3.1. MKCOL Status Codes
可能な一般的なステータスコードに加えて、以下のステータスコードは特定の適用性をMKCOLに持っています:
In addition to the general status codes possible, the following status codes have specific applicability to MKCOL:
201 (作成されます)--収集は作成されました。
201 (Created) - The collection was created.
403 (禁じられます)--これは少なくとも2つの状態の1つを示します: 1) サーバは与えられた位置でのURL名前空間、または2における)収集の作成にRequest-URIの親収集を許しません。存在していますが、メンバーを受け入れることができません。
403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its URL namespace, or 2) the parent collection of the Request-URI exists but cannot accept members.
405 (メソッドNot Allowed)--非写像しているURLの上でMKCOLを実行できるだけです。
405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL.
409 (闘争)--Request-URIで収集を1つ以上の中間的収集が作成されるまですることができません。 サーバは自動的にそれらの中間的収集を作成してはいけません。
409 (Conflict) - A collection cannot be made at the Request-URI until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
415 (サポートされないメディアType)--サーバは要求ボディータイプをサポートしません(この仕様がいずれも定義しないので、ボディーはMKCOL要求のときに法的ですが、サーバはボディータイプを考えて、いずれもサポートしないようにありそうです)。
415 (Unsupported Media Type) - The server does not support the request body type (although bodies are legal on MKCOL requests, since this specification doesn't define any, the server is likely not to support any given body type).
507 (不十分なStorage)--リソースには、このメソッドの実行の後にリソースの状態を記録できるくらいのスペースがありません。
507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of this method.
9.3.2. 例--MKCOL
9.3.2. Example - MKCOL
この例は/webdisc/xfiles/と呼ばれる収集をサーバwww.example.comに作成します。
This example creates a collection called /webdisc/xfiles/ on the server www.example.com.
Dusseault Standards Track [Page 47] RFC 4918 WebDAV June 2007
>>Request
MKCOL/webdisc/xfiles/HTTP/1.1ホスト: www.example.com
MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.example.com
>>Response
作成されたHTTP/1.1 201
HTTP/1.1 201 Created
9.4. 得てください、そして、収集に向かってください。
9.4. GET, HEAD for Collections
GETの意味論はGETが定義されるので収集に適用されると、変わりがありません、「Request-URIによって特定されるどんな情報(実体の形の)も検索してください」という[RFC2616]です。 収集に適用されると、GETは"index.html"リソースのコンテンツ、収集のコンテンツの人間読み込み可能な視点、または全体で他の何かを返すかもしれません。 したがって、収集でのGETの結果が収集の会員資格に相関関係に全く堪えないのは、可能です。
The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET, when applied to a collection, may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence, it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection.
同様に、収集リソースに適用される場合、HEADの意味論は、HEADの定義が応答メッセージ本体がなければGETであるので、変更されていません。
Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
9.5. 収集のためのポスト
9.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.
9.6. 要件を削除してください。
9.6. DELETE Requirements
DELETEは、「Request-URIによって特定されたリソースを削除する」ために[RFC2616]、セクション9.7で定義されます。 しかしながら、WebDAVはいくつかのDELETE取り扱い要件を変えます。
DELETE is defined in [RFC2616], Section 9.7, to "delete the resource identified by the Request-URI". However, WebDAV changes some DELETE handling requirements.
うまくいっているDELETE要求を処理するサーバ:
A server processing a successful DELETE request:
削除されたリソースに根づいている錠を破壊しなければなりません。
MUST destroy locks rooted on the deleted resource
Request-URIからどんなリソースまでもマッピングを取り除かなければなりません。
MUST remove the mapping from the Request-URI to any resource.
したがって、うまくいっているDELETE操作(そして他の動作がないとき)の後に、目標Request-URIへのその後のGET/HEAD/PROPFIND要求は404(Foundでない)を返さなければなりません。
Thus, after a successful DELETE operation (and in the absence of other actions), a subsequent GET/HEAD/PROPFIND request to the target Request-URI MUST return 404 (Not Found).
Dusseault Standards Track [Page 48] RFC 4918 WebDAV June 2007
9.6.1. DELETE for Collections
収集でのDELETEメソッドが行動しなければならない、「深さ:」 「無限」ヘッダーはそれで使用されました。 クライアントは収集でのDELETEと共にどんな値にもかかわらず、無限でもDepthヘッダーを提出してはいけません。
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は、Request-URIで指定された収集と内部のメンバーURLによって特定されたすべてのリソースが削除されることであるよう命令します。
DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URLs are to be deleted.
メンバーURLによって特定されたどんなリソースも削除できないなら、メンバーの先祖のすべてを削除してはいけません、URL名前空間の一貫性を維持するために。
If any resource identified by a member URL cannot be deleted, then all of the member's ancestors MUST NOT be deleted, so as to maintain URL namespace consistency.
DELETE MUSTが処理で適用されている状態で、どんなヘッダーも、削除されるためにあらゆるリソースを入れました。
Any headers included with DELETE MUST be applied in processing every resource to be deleted.
DELETEメソッドが、処理するのを完了したとき、それは一貫したURL名前空間をもたらさなければなりません。
When the DELETE method has completed processing, it MUST result in a consistent URL namespace.
誤りがメンバーリソース(Request-URIで特定されたリソース以外のリソース)を削除しながら発生するなら、応答は207であるかもしれません(マルチStatus)。 マルチStatusはどの社内資源を削除できなかったかを示すのにここで使用されます、エラーコード(クライアントが、どのリソースが失敗を引き起こしたかを理解しているのを助けるべきである)を含んでいて。 例えば、内部のリソースがロックされるなら、Multi-状態本体は状態423(ロックされます)がある応答を含むかもしれないでしょうに。
If an error occurs deleting a member resource (a resource other than the resource identified in the Request-URI), then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error code, which should help the client understand which resources caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked.
The server MAY return a 4xx status response, rather than a 207, if the request failed completely.
要求が完全に失敗したなら、サーバは207よりむしろ4xx状態応答を返すかもしれません。
424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi- Status) response for DELETE. They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally, 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code.
424 (Dependencyに失敗します) 状態はコネがDELETEのための207(マルチStatus)応答であったならSHOULD NOTをコード化します。 クライアントが、クライアントが先祖の子孫のために誤りを受けるとき、リソースの先祖を削除できなかったのを知るので、安全にそれらを省くことができます。 Content) いいえ、誤りSHOULD NOT。さらに、204、(207(マルチStatus)では、返してください。 この禁止の理由は204(Contentがない)がデフォルト成功コードであるということです。
9.6.2. Example - DELETE
9.6.2. 例--、削除
>>Request
>>要求
DELETE /container/ HTTP/1.1 Host: www.example.com
/container/ HTTP/1.1ホストを削除してください: www.example.com
Dusseault Standards Track [Page 49] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[49ページ]。
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: application/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.example.com/container/resource3</d:href> <d:status>HTTP/1.1 423 Locked</d:status> <d:error><d:lock-token-submitted/></d:error> </d:response> </d:multistatus>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><d:multistatus xmlns:dが等しい、「DAV: 「: 提出されたロックトークン/></d: 誤り></d: 応答></d: ><d: 応答><d: href>http://www.example.com/コンテナ/resource3</d: href><d: 状態>HTTP/1.1 423Locked</d: 状態><d: 誤り><d「マルチ-状態」>」
In this example, the attempt to delete http://www.example.com/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.example.com/container/ also failed. Thus, the client knows that the attempt to delete http://www.example.com/container/ must have also failed since the parent cannot be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection.
この例では、 http://www.example.com/container/resource3 を削除する試みは、それをロックして、要求でロックトークンを全く提出しなかったので、失敗しました。 その結果、また、 http://www.example.com/container/ を削除する試みは失敗しました。 したがって、クライアントは、また、 http://www.example.com/container/ を削除する試みがまた、子供が削除されていない場合親を削除できないので失敗したに違いないのを知っています。 Depthヘッダーは含まれていませんが、収集にはメソッドがあるので、無限の深さは想定されます。
9.7. PUT Requirements
9.7. 要件を置いてください。
9.7.1. PUT for Non-Collection Resources
9.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は失敗しなければなりません。
A PUT request allows a client to indicate what media type an entity body has, and whether it should change if overwritten. Thus, a client SHOULD provide a Content-Type for a new resource if any is known. If the client does not provide a Content-Type for a new resource, the server MAY create a resource with no Content-Type assigned, or it MAY attempt to assign a Content-Type.
PUT要求で、上書きされるなら、クライアントは実体本体にはどんなメディアタイプがあるか、そして、それが変化するべきであるかどうかを示すことができます。 したがって、SHOULDがもしあれば新しいリソースのためのコンテントタイプを提供するクライアントは知られています。 クライアントが新しいリソースにコンテントタイプを提供しないなら、コンテントタイプが全く割り当てられていなく、サーバがリソースを作成するかもしれませんか、またはそれは、コンテントタイプを割り当てるのを試みるかもしれません。
Dusseault Standards Track [Page 50] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[50ページ]。
Note that although a recipient ought generally to treat metadata supplied with an HTTP request as authoritative, in practice there's no guarantee that a server will accept client-supplied metadata (e.g., any request header beginning with "Content-"). Many servers do not allow configuring the Content-Type on a per-resource basis in the first place. Thus, clients can't always rely on the ability to directly influence the content type by including a Content-Type request header.
受取人がそうしますが、HTTP要求が実際には正式であるとして供給されたメタデータを扱うために、一般に、サーバがクライアントによって供給されたメタデータ(「内容」で始まる例えばどんな要求ヘッダーも)を受け入れるという保証が全くないことに注意してください。 多くのサーバで、第一に、1リソースあたり1個のベースでコンテントタイプを構成しません。 したがって、クライアントはいつもコンテントタイプ要求ヘッダーを含んでいることによって直接content typeに影響を及ぼす能力を当てにすることができるというわけではありません。
9.7.2. PUT for Collections
9.7.2. 収集のために、置かれます。
This specification does not define the behavior of the PUT method for existing collections. A PUT request to an existing collection MAY be treated as an error (405 Method Not Allowed).
この仕様は既存の収集のためのPUTメソッドの振舞いを定義しません。 既存の収集へのPUT要求は誤り(405Method Not Allowed)として扱われるかもしれません。
The MKCOL method is defined to create collections.
MKCOLメソッドは、収集を作成するために定義されます。
9.8. COPY Method
9.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メソッドはRequest-URIによって特定されたソースリソースの写しを作成します、Destinationヘッダーの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メソッドのサポートはリソースをコピーする能力を保証しません。 例えば、別々のプログラムは同じサーバに関するリソースを制御するかもしれません。その結果、同じサーバにあるように見える位置にリソースをコピーするのは可能でないかもしれません。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドは金庫ではなく、ベキ等元([RFC2616]のセクション9.1を見る)です。 このメソッドへの応答をキャッシュしてはいけません。
9.8.1. COPY for Non-collection Resources
9.8.1. 非収集リソースのためのコピー
When the source resource is not a collection, the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible. Since the environment at the destination may be different than at the source due to factors outside the scope of control of the server, such as the absence of resources required for correct operation, it may not be possible to completely duplicate the behavior of the resource at the destination. Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource.
ソースリソースが収集でないときに、COPYメソッドの結果は州と振舞いができるだけ密接にソースリソースのものに合っている目的地の新しいリソースの作成です。 目的地の環境が要素でソースより異なるかもしれないので、外では、リソースの欠如などのサーバの見える範囲が正しい操作に必要であり、目的地にリソースの振舞いを完全にコピーするのは可能でないかもしれません。 目的地リソースへのその後の変更はソースリソースを変更しないでしょう。 ソースリソースへのその後の変更は目的地リソースを変更しないでしょう。
Dusseault Standards Track [Page 51] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[51ページ]。
9.8.2. COPY for Properties
9.8.2. 特性のためのコピー
After a successful COPY invocation, all dead properties on the source resource SHOULD be duplicated on the destination resource. Live properties described in this document SHOULD be duplicated as identically behaving live properties at the destination resource, but not necessarily with the same values. Servers SHOULD NOT convert live properties into dead properties on the destination resource, because clients may then draw incorrect conclusions about the state or functionality of a resource. Note that some live properties are defined such that the absence of the property has a specific meaning (e.g., a flag with one meaning if present, and the opposite if absent), and in these cases, a successful COPY might result in the property being reported as "Not Found" in subsequent requests.
うまくいっているCOPY実施、ソースリソースSHOULDのすべての死んでいる特性の後、目的地リソースにコピーされてください。 このドキュメントSHOULDで説明された精力の特性は、同じ値で同じくらい同様に目的地リソースにおける精力の特性を反応させながらコピーされますが、必ずコピーされるというわけではありません。 サーバSHOULD NOTは目的地リソースの死んでいる特性に精力の特性を変換します、次に、クライアントがリソースの状態か機能性に関する不正確な結論に達するかもしれないので。 特性の欠如には特定の意味(例えば、1つが意味していますが、存在している旗、反対ですが、休み)があるように、いくつかの精力の特性が定義されることに注意してください。そうすれば、これらの場合では、うまくいっているCOPYはその後の要求で「見つけられない」ように報告される特性をもたらすかもしれません。
When the destination is an unmapped URL, a COPY operation creates a new resource much like a PUT operation does. Live properties that are related to resource creation (such as DAV:creationdate) should have their values set accordingly.
目的地が非写像しているURLであるときに、COPY操作はPUT操作のような多くがする新しいリソースを作成します。 リソース作成(DAV: creationdateなどの)に関連する精力の特性で、それに従って、それらの値を設定するはずです。
9.8.3. COPY for Collections
9.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". Servers MUST support the "0" and "infinity" Depth header behaviors on WebDAV-compliant resources.
まるで値の「無限」があるDepthヘッダーが含まれているかのようにDepthヘッダーのない収集でのCOPYメソッドは行動しなければなりません。 クライアントは収集のときに「0インチか「無限」」の値でCOPYの上のDepthヘッダーを提出するかもしれません。 サーバは「WebDAV対応することのリソースにおける0インチと「無限」深さヘッダーの振舞い」をサポートしなければなりません。
An infinite-depth COPY instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources are to be copied to a location relative to it, recursively through all levels of the collection hierarchy. Note that an infinite-depth COPY of /A/ into /A/B/ could lead to infinite recursion if not handled correctly.
無限の深さCOPYは、すべての内部のメンバーリソースがRequest-URIによって特定された収集リソースがDestinationヘッダーのURIによって特定された位置までコピーされることであり、収集階層構造のすべてのレベルを通してそれに比例して位置に再帰的にコピーされることであるよう命令します。 正しく扱われないなら/A/B/への/A/の無限の深さCOPYが無限の再帰に通じるかもしれないことに注意してください。
A COPY of "Depth: 0" only instructs that the collection and its properties, but not resources identified by its internal member URLs, are to be copied.
Aがコピーする、「深さ:」 0インチは、内部のメンバーURLによって特定されたリソースではなく、収集とその特性がコピーされることであるよう命令するだけです。
Any headers included with a COPY MUST be applied in processing every resource to be copied with the exception of the Destination header.
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://example.com/ and the
DestinationヘッダーはRequest-URIに目的地URIを指定するだけです。 Request-URIによって特定された収集のメンバーに適用されると、Destinationの値は現在の位置を階層構造に反映するように変更されることです。 そしてそれで、Request URIがHostヘッダーがある/a/であるなら http://example.com/ を評価してください。
Dusseault Standards Track [Page 52] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[52ページ]。
Destination is http://example.com/b/, then when http://example.com/a/c/d is processed, it must use a Destination of http://example.com/b/c/d.
目的地が http://example.com/b/ である、そして、 http://example.com/a/c/d が処理されるとき、それは http://example.com/b/c/d のDestinationを使用しなければなりません。
When the COPY method has completed processing, it MUST have created a consistent URL namespace at the destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while copying an internal collection, the server MUST NOT copy any resources identified by members of this collection (i.e., the server must skip this subtree), as this would create an inconsistent namespace. After detecting an error, the COPY operation SHOULD try to finish as much of the original copy operation as possible (i.e., the server should still attempt to copy other subtrees and their members that are not descendants of an error-causing collection).
COPYメソッドが、処理するのを完了したとき、それは目的地で一貫したURL名前空間を作成したに違いありません(名前空間の一貫性の定義に関してセクション5.1を見てください)。 しかしながら、誤りが内部の収集をコピーしている間、発生するなら、サーバはこの収集のメンバーによって特定されたどんなリソースもコピーしてはいけません(すなわち、サーバはこの下位木をスキップしなければなりません)、これが矛盾した名前空間を作成するだろうというとき。 誤りを検出した後に、COPY操作SHOULDはできるだけ多くの原本操作を終えようとします(すなわち、サーバは、他の下位木と誤りを引き起こす収集の子孫でない彼らのメンバーをコピーするのをまだ試みているべきです)。
So, for example, if an infinite-depth copy operation is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt should still be made to copy /a/c/. Similarly, after encountering an error copying a non- collection resource as part of an infinite-depth copy, the server SHOULD try to finish as much of the original copy operation as possible.
/a/は収集の/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), and the URL of the resource causing the failure MUST appear with the specific error.
COPYメソッドを実行することにおける誤りがRequest-URIで特定されたリソース以外のリソースで発生するなら、応答は207であるに違いありません(マルチStatus)、そして、失敗を引き起こすリソースのURLは特定の誤りと共に現れなければなりません。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a COPY method. These responses can be safely omitted because the client will know that the progeny of a resource could not be copied when the client receives an error for the parent. Additionally, 201 (Created)/204 (No Content) status codes SHOULD NOT be returned as values in 207 (Multi-Status) responses from COPY methods. They, too, can be safely omitted because they are the default success codes.
424(失敗したDependency)状態は返されたコネがCOPYメソッドからの207(マルチStatus)応答であったならSHOULD NOTをコード化します。 クライアントが、クライアントが親のために誤りを受けるとき、リソースの子孫をコピーできなかったのを知るので、安全にこれらの応答を省略できます。 さらに、201(作成される)/204(Contentがありません)状態はCOPYからの207における値として返された(マルチStatusの)応答がメソッドであったならSHOULD NOTをコード化します。 それらがデフォルト成功コードであるので、また、安全にそれらを省略できます。
9.8.4. COPY and Overwriting Destination Resources
9.8.4. コピーと目的地リソースを上書きすること。
If a COPY request has an Overwrite header with a value of "F", and a resource exists at the Destination URL, the server MUST fail the request.
COPY要求にはOverwriteヘッダーが「F」の値と共にあって、リソースが目的地URLに存在しているなら、サーバは要求に失敗しなければなりません。
When a server executes a COPY request and overwrites a destination resource, the exact behavior MAY depend on many factors, including WebDAV extension capabilities (see particularly [RFC3253]). For
サーバがCOPY要求を実行して、目的地リソースを上書きするとき、正確な振舞いを多くの要素に依存するかもしれません、WebDAV拡大能力(特に[RFC3253]、見る)を含んでいて。 for
Dusseault Standards Track [Page 53] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[53ページ]。
example, when an ordinary resource is overwritten, the server could delete the target resource before doing the copy, or could do an in- place overwrite to preserve live properties.
例、普通のリソースが上書きされると、サーバはコピーする前に目標リソースを削除できたか、または精力の特性を保持するためにコネ場所重ね書きをするかもしれません。
When a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY. Thus, merging the membership of the source and destination collections together in the destination is not a compliant behavior.
収集が上書きされるとき、うまくいっているCOPY要求の後の目的地収集の会員資格はCOPYの直前ソース収集と同じ会員資格であるに違いありません。 したがって、目的地でソースと目的地収集の会員資格を一緒に合併するのは、対応する振舞いではありません。
In general, if clients require the state of the destination URL to be wiped out prior to a COPY (e.g., to force live properties to be reset), then the client could send a DELETE to the destination before the COPY request to ensure this reset.
一般に、クライアントがCOPY(例えば精力の特性がリセットさせられる)の前で破壊されるために目的地URLを状態に要求するなら、クライアントはこのリセットを確実にするというCOPY要求の前にDELETEを目的地に送るかもしれません。
9.8.5. Status Codes
9.8.5. ステータスコード
In addition to the general status codes possible, the following status codes have specific applicability to COPY:
可能な一般的なステータスコードに加えて、以下のステータスコードは特定の適用性をCOPYに持っています:
201 (Created) - The source resource was successfully copied. The COPY operation resulted in the creation of a new resource.
201 (作成されます)--ソースリソースは首尾よくコピーされました。 COPY操作は新しいリソースの作成をもたらしました。
204 (No Content) - The source resource was successfully copied to a preexisting destination resource.
204 (Contentがありません)--ソースリソースは首尾よく先在の目的地リソースにコピーされました。
207 (Multi-Status) - Multiple resources were to be affected by the COPY, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi- status response. For example, if a destination resource was locked and could not be overwritten, then the destination resource URL appears with the 423 (Locked) status.
207 (マルチStatus)--複数のリソースがCOPYで影響を受けることでしたが、それらのいくつかにおける誤りは、操作が行われるのを防ぎました。 特定のエラーメッセージはソースと目的地URLで最も適切であると共にマルチ状態応答のボディーに現れます。 例えば、目的地リソースをロックして、上書きできないなら、目的地リソースURLは423(ロックされる)状態と共に現れます。
403 (Forbidden) - The operation is forbidden. A special case for COPY could be that the source and destination resources are the same resource.
403 (禁じられます)--操作は禁じられます。 COPYに、特別なケースはソースと目的地リソースが同じリソースであるということであるかもしれません。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409 (闘争)--1つ以上の中間的収集が作成されるまで、目的地でリソースを作成できません。 サーバは自動的にそれらの中間的収集を作成してはいけません。
412 (Precondition Failed) - A precondition header check failed, e.g., the Overwrite header is "F" and the destination URL is already mapped to a resource.
412 (前提条件Failed)--前提条件ヘッダーチェックは失敗して、例えば、Overwriteヘッダーは「F」であり、目的地URLは既にリソースに写像されます。
Dusseault Standards Track [Page 54] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[54ページ]。
423 (Locked) - The destination resource, or resource within the destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423 (ロックされます)--目的地リソース、または目的地収集の中のリソースがロックされました。 この応答SHOULDは'提出されたロックトークン'前提条件要素を含んでいます。
502 (Bad Gateway) - This may occur when the destination is on another server, repository, or URL namespace. Either the source namespace does not support copying to the destination namespace, or the destination namespace refuses to accept the resource. The client may wish to try GET/PUT and PROPFIND/PROPPATCH instead.
502 (悪いゲートウェイ)--目的地が別のサーバ、倉庫、またはURL名前空間にあるとき、これは起こるかもしれません。 ソース名前空間が目的地名前空間へのコピーをサポートしないか、または目的地名前空間は、リソースを受け入れるのを拒否します。 クライアントは代わりにGET/PUTとPROPFIND/PROPPATCHを試みたがっているかもしれません。
507 (Insufficient Storage) - The destination resource does not have sufficient space to record the state of the resource after the execution of this method.
507 (不十分なStorage)--目的地リソースには、このメソッドの実行の後にリソースの状態を記録できるくらいのスペースがありません。
9.8.6. Example - COPY with Overwrite
9.8.6. 例--重ね書きがあるコピー
This example shows resource http://www.example.com/~fielding/index.html being copied to the location http://www.example.com/users/f/fielding/index.html. The 204 (No Content) status code indicates that the existing resource at the destination was overwritten.
この例は、リソース http://www.example.com/~fielding/index.html が位置の http://www.example.com/users/f/fielding/index.html までコピーされるのを示します。 204(Contentがない)ステータスコードは、目的地の既存のリソースが上書きされたのを示します。
>>Request
>>要求
COPY /~fielding/index.html HTTP/1.1 Host: www.example.com Destination: http://www.example.com/users/f/fielding/index.html
コピー/~フィールディング/index.html HTTP/1.1ホスト: www.example.com Destination: http://www.example.com/users/f/fielding/index.html
>>Response
>>応答
HTTP/1.1 204 No Content
HTTP/1.1 204いいえ内容
9.8.7. Example - COPY with No Overwrite
9.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 URL is already mapped to a resource.
以下の例は、同じコピー操作が実行されますが、Overwriteヘッダーセットであるのを「F.」に示します。 目的地URLが既にリソースに写像されるので、412(前提条件Failed)の応答を返します。
>>Request
>>要求
COPY /~fielding/index.html HTTP/1.1 Host: www.example.com Destination: http://www.example.com/users/f/fielding/index.html Overwrite: F
コピー/~フィールディング/index.html HTTP/1.1ホスト: www.example.com Destination: http://www.example.com/users/f/fielding/index.html 重ね書き: F
Dusseault Standards Track [Page 55] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[55ページ]。
>>Response
>>応答
HTTP/1.1 412 Precondition Failed
HTTP/1.1 412前提条件は失敗しました。
9.8.8. Example - COPY of a Collection
9.8.8. 例--収集のコピー
>>Request
>>要求
COPY /container/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/othercontainer/ Depth: infinity
/container/ HTTP/1.1ホストをコピーしてください: www.example.com Destination: http://www.example.com/othercontainer/ の深さ: 無限
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<?xmlバージョン=、「=「utf-8インチ?>」をコード化する1インチ
<d:multistatus xmlns:d="DAV:"> <d:response> <d:href>http://www.example.com/othercontainer/R2/</d:href> <d:status>HTTP/1.1 423 Locked</d:status> <d:error><d:lock-token-submitted/></d:error> </d:response> </d:multistatus>
<d:multistatus xmlns:dが等しい、「DAV: 「><d: 応答><d: href>http://www.example.com/othercontainer/R2/</d: href><d: 状態>HTTP/1.1 423は</d: 状態><d: 誤り><d: 提出されたロックトークン/></d: 誤り></d: 応答></d: 「マルチ-状態」>をロックしました」。
The Depth header is unnecessary as the default behavior of COPY on a collection is to act as if a "Depth: infinity" header had been submitted. In this example, most of the resources, along with the collection, were copied successfully. However, the collection R2 failed because the destination R2 is locked. Because there was an error copying R2, none of R2's members were copied. However, no errors were listed for those members due to the error minimization rules.
Depthヘッダーが収集のCOPYのデフォルト動きが行動することであるので不要である、「深さ:」 「無限」ヘッダーを提出しました。 この例では、リソースの大部分は収集と共に首尾よくコピーされました。 しかしながら、目的地R2がロックされるので、収集R2は失敗しました。 R2をコピーする誤りがあったので、R2のメンバーのだれもコピーされませんでした。 しかしながら、誤りは全く誤り最小化規則のためそれらのメンバーのために記載されませんでした。
9.9. MOVE Method
9.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 in a single operation. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URLs, other than the Request-URI that identifies the source resource, to point to the new destination resource.
続かれて、非収集リソースにおけるMOVE操作は一貫性メインテナンス処理があとに続いたコピー(COPY)の論理的な同等物です。aはソースに削除します。そこでは、すべての3つの動作がただ一つの操作で実行されます。 サーバは一貫性メインテナンスステップで移動で引き起こされたアップデートを実行できます、すべてのURLをアップデートするのなどように、新しい目的地リソースを示すためにソースリソースを特定するRequest-URIを除いて。
Dusseault Standards Track [Page 56] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[56ページ]。
The Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV-compliant resources MUST support the MOVE method.
Destinationヘッダーは、すべてのMOVEメソッドに存在していなければならなくて、MOVEメソッドのCOPY部分にすべてのCOPY要件の後をつけなければなりません。 すべてのWebDAV対応することのリソースが、MOVEがメソッドであるとサポートしなければなりません。
Support for the MOVE method does not guarantee the ability to move a resource to a particular destination. For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server.
MOVEメソッドのサポートは特定の目的地へのリソースを運動能力に保証しません。 例えば、別々のプログラムは実際に異なったセットの同じサーバに関するリソースを制御するかもしれません。したがって、同じサーバに属すように見える名前空間の中でリソースを動かすのは可能でないかもしれません。
If a resource exists at the destination, the destination resource will be deleted as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header.
リソースが目的地に存在していると、目的地リソースはMOVE操作の副作用としてOverwriteヘッダーの制限を条件として削除されるでしょう。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドは金庫ではなく、ベキ等元([RFC2616]のセクション9.1を見る)です。 このメソッドへの応答をキャッシュしてはいけません。
9.9.1. MOVE for Properties
9.9.1. 特性を提議してください。
Live properties described in this document SHOULD be moved along with the resource, such that the resource has identically behaving live properties at the destination resource, but not necessarily with the same values. Note that some live properties are defined such that the absence of the property has a specific meaning (e.g., a flag with one meaning if present, and the opposite if absent), and in these cases, a successful MOVE might result in the property being reported as "Not Found" in subsequent requests. If the live properties will not work the same way at the destination, the server MAY fail the request.
このドキュメントSHOULDで説明された精力の特性は、リソースには目的地リソースにおける同様に振る舞っている精力の特性があるようにリソースと共に動かされますが、必ず同じ値で動かされるというわけではありません。 特性の欠如には特定の意味(例えば、1つが意味していますが、存在している旗、反対ですが、休み)があるように、いくつかの精力の特性が定義されることに注意してください。そうすれば、これらの場合では、うまくいっているMOVEはその後の要求で「見つけられない」ように報告される特性をもたらすかもしれません。 精力の特性が目的地で同じように働かないなら、サーバは要求に失敗するかもしれません。
MOVE is frequently used by clients to rename a file without changing its parent collection, so it's not appropriate to reset all live properties that are set at resource creation. For example, the DAV: creationdate property value SHOULD remain the same after a MOVE.
MOVEが親収集を変えないでファイルを改名するのに頻繁にクライアントによって使用されるので、リソース作成で設定されるすべての精力の特性をリセットするのは適切ではありません。 例えば、DAV: creationdate資産価値SHOULDはMOVEの後に同じままで残っています。
Dead properties MUST be moved along with the resource.
リソースと共に死んでいる特性を動かさなければなりません。
9.9.2. MOVE for Collections
9.9.2. 収集を提議してください。
A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the address specified in the Destination header, and all resources identified by its internal member URLs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy.
Aが移行する、「深さ:」 「無限」は、Request-URIによって特定された収集がDestinationヘッダーで指定されたアドレスに動かされるよう命令します、そして、内部のメンバーURLによって特定されたすべてのリソースは収集階層構造のすべてのレベルを通してそれに比例して位置に再帰的に動かされることです。
The MOVE method on a collection MUST act as if a "Depth: infinity" header was used on it. A client MUST NOT submit a Depth header on a MOVE on a collection with any value but "infinity".
収集でのMOVEメソッドが行動しなければならない、「深さ:」 「無限」ヘッダーはそれで使用されました。 クライアントは収集のときにどんな値にもかかわらず、「無限」でもMOVEの上のDepthヘッダーを提出してはいけません。
Dusseault Standards Track [Page 57] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[57ページ]。
Any headers included with MOVE MUST be applied in processing every resource to be moved with the exception of the Destination header. The behavior of the Destination header is the same as given for COPY on collections.
MOVE MUSTが処理で適用されている状態で、どんなヘッダーも、Destinationヘッダーを除いて、動かされるためにあらゆるリソースを入れました。 Destinationヘッダーの動きは収集のときにCOPYのために与えるのと同じです。
When the MOVE method has completed processing, it MUST have created a consistent URL namespace at both the source and destination (see Section 5.1 for the definition of namespace consistency). However, if an error occurs while moving an internal collection, the server MUST NOT move any resources identified by members of the failed collection (i.e., the server must skip the error-causing subtree), as this would create an inconsistent namespace. In this case, after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to move other subtrees and the resources identified by their members that are not descendants of an error-causing collection). So, for example, if an infinite-depth move is performed on collection /a/, which contains collections /a/b/ and /a/c/, and an error occurs moving /a/b/, an attempt should still be made to try moving /a/c/. Similarly, after encountering an error moving a non-collection resource as part of an infinite-depth move, the server SHOULD try to finish as much of the original move operation as possible.
MOVEメソッドが、処理するのを完了したとき、それはソースと目的地の両方で一貫したURL名前空間を作成したに違いありません(名前空間の一貫性の定義に関してセクション5.1を見てください)。 しかしながら、誤りが内部の収集が感動的である間、発生するなら、サーバは失敗した収集のメンバーによって特定されたどんなリソースも動かしてはいけません(すなわち、サーバは誤りを引き起こす下位木をスキップしなければなりません)、これが矛盾した名前空間を作成するだろうというとき。 この場合、誤りを検出した後に、移動命令SHOULDはできるだけ多くのオリジナルの移動を終えようとします(すなわち、サーバは、誤りを引き起こす収集の子孫でない彼らのメンバーによって特定された他の下位木とリソースを動かすのをまだ試みているべきです)。 /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), and the errored resource's URL MUST appear with the specific error.
誤りがRequest-URIで特定されたリソース以外のリソースで発生するなら、応答は207であるに違いありません(マルチStatus)、そして、erroredリソースのURLは特定の誤りと共に現れなければなりません。
The 424 (Failed Dependency) status code SHOULD NOT be returned in the 207 (Multi-Status) response from a MOVE method. These errors can be safely omitted because the client will know that the progeny of a resource could not be moved when the client receives an error for the parent. Additionally, 201 (Created)/204 (No Content) responses SHOULD NOT be returned as values in 207 (Multi-Status) responses from a MOVE. These responses can be safely omitted because they are the default success codes.
424(失敗したDependency)状態は返されたコネがMOVEメソッドからの207(マルチStatus)応答であったならSHOULD NOTをコード化します。 クライアントが、クライアントが親のために誤りを受けるとき、リソースの子孫を動かすことができなかったのを知るので、安全にこれらの誤りを省略できます。 Content) いいえ、応答SHOULD NOT。さらに、201(作成される)/204、(207(マルチStatus)の応答における値として、MOVEから、返してください。 それらがデフォルト成功コードであるので、安全にこれらの応答を省略できます。
9.9.3. MOVE and the Overwrite Header
9.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」に用意ができていると、操作は失敗するでしょう。
Dusseault Standards Track [Page 58] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[58ページ]。
9.9.4. Status Codes
9.9.4. ステータスコード
In addition to the general status codes possible, the following status codes have specific applicability to MOVE:
可能な一般的なステータスコードに加えて、以下のステータスコードは特定の適用性をMOVEに持っています:
201 (Created) - The source resource was successfully moved, and a new URL mapping was created at the destination.
201 (作成されます)--ソースリソースは首尾よく動かされて、新しいURLマッピングは目的地で作成されました。
204 (No Content) - The source resource was successfully moved to a URL that was already mapped.
204 (Contentがありません)--ソースリソースは首尾よく既に写像されたURLに動かされました。
207 (Multi-Status) - Multiple resources were to be affected by the MOVE, but errors on some of them prevented the operation from taking place. Specific error messages, together with the most appropriate of the source and destination URLs, appear in the body of the multi- status response. For example, if a source resource was locked and could not be moved, then the source resource URL appears with the 423 (Locked) status.
207 (マルチStatus)--複数のリソースがMOVEで影響を受けることでしたが、それらのいくつかにおける誤りは、操作が行われるのを防ぎました。 特定のエラーメッセージはソースと目的地URLで最も適切であると共にマルチ状態応答のボディーに現れます。 例えば、ソースリソースをロックして、動かすことができないなら、ソースリソースURLは423(ロックされる)状態と共に現れます。
403 (Forbidden) - Among many possible reasons for forbidding a MOVE operation, this status code is recommended for use when the source and destination resources are the same.
403 (禁じられます)--ソースと目的地リソースが同じであるときに、MOVE操作を禁じる多くの可能な理由の中では、このステータスコードは使用のために推薦されます。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. Or, the server was unable to preserve the behavior of the live properties and still move the resource to the destination (see 'preserved-live-properties' postcondition).
409 (闘争)--1つ以上の中間的収集が作成されるまで、目的地でリソースを作成できません。 サーバは自動的にそれらの中間的収集を作成してはいけません。 または、サーバは、精力の特性の動きを保持して、まだリソースを目的地に動かすことができませんでした('保存された精力の特性'postconditionを見てください)。
412 (Precondition Failed) - A condition header failed. Specific to MOVE, this could mean that the Overwrite header is "F" and the destination URL is already mapped to a resource.
412 (前提条件Failed)--状態ヘッダーは失敗しました。 MOVEに特定です、これはOverwriteヘッダーが「F」であり、目的地URLが既にリソースに写像されることを意味するかもしれません。
423 (Locked) - The source or the destination resource, the source or destination resource parent, or some resource within the source or destination collection, was locked. This response SHOULD contain the 'lock-token-submitted' precondition element.
423 (ロックされます)--ソース、目的地リソース、ソースまたは目的地リソース親、または、ソースか目的地収集の中の何らかのリソース、ロックされました。 この応答SHOULDは'提出されたロックトークン'前提条件要素を含んでいます。
502 (Bad Gateway) - This may occur when the destination is on another server and the destination server refuses to accept the resource. This could also occur when the destination is on another sub-section of the same server namespace.
502 (悪いゲートウェイ)--目的地が別のサーバにあって、目的地サーバが、リソースを受け入れるのを拒否するとき、これは起こるかもしれません。 また、目的地が同じサーバ名前空間の別の小区分にあるとき、これは起こることができました。
Dusseault Standards Track [Page 59] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[59ページ]。
9.9.5. Example - MOVE of a Non-Collection
9.9.5. 例--非収集の移動
This example shows resource http://www.example.com/~fielding/index.html being moved to the location http://www.example.com/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination URL was already mapped to a resource. In this case, since there was nothing at the destination resource, the response code is 201 (Created).
この例は、リソース http://www.example.com/~fielding/index.html が位置の http://www.example.com/users/f/fielding/index.html に動かされるのを示します。 目的地URLが既にリソースに写像されたなら、目的地リソースのコンテンツは上書きされたでしょう。 目的地リソースには何もなかったので、この場合、応答コードは201(作成される)です。
>>Request
>>要求
MOVE /~fielding/index.html HTTP/1.1 Host: www.example.com Destination: http://www.example/users/f/fielding/index.html
移動/~フィールディング/index.html HTTP/1.1ホスト: www.example.com Destination: http://www.example/users/f/fielding/index.html
>>Response
>>応答
HTTP/1.1 201 Created Location: http://www.example.com/users/f/fielding/index.html
HTTP/1.1 201は位置を作成しました: http://www.example.com/users/f/fielding/index.html
9.9.6. Example - MOVE of a Collection
9.9.6. 例--収集の移動
>>Request
>>要求
MOVE /container/ HTTP/1.1 Host: www.example.com Destination: http://www.example.com/othercontainer/ Overwrite: F If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) (<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
/container/ HTTP/1.1ホストを動かしてください: www.example.com Destination: http://www.example.com/othercontainer/ 重ね書き: F、: (<つぼ:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) (<つぼ:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?> <d:multistatus xmlns:d='DAV:'> <d:response> <d:href>http://www.example.com/othercontainer/C2/</d:href> <d:status>HTTP/1.1 423 Locked</d:status> <d:error><d:lock-token-submitted/></d:error> </d:response> </d:multistatus>
<?xmlバージョンは「=「utf-8インチ?><d:multistatus xmlns:d='DAVをコード化する1インチ: ': 提出されたロックトークン/></d: 誤り></d: 応答></d: ><d: 応答><d: href>http://www.example.com/othercontainer/C2/</d: href><d: 状態>HTTP/1.1 423Locked</d: 状態><d: 誤り><d「マルチ-状態」>'」と等しいです。
Dusseault Standards Track [Page 60] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[60ページ]。
In this example, the client has submitted a number of lock tokens with the request. A lock token will need to be submitted for every resource, both source and destination, anywhere in the scope of the method, that is locked. In this case, the proper lock token was not submitted for the destination http://www.example.com/othercontainer/C2/. This means that the resource /container/C2/ could not be moved. Because there was an error moving /container/C2/, none of /container/C2's members were moved. However, no errors were listed for those members due to the error minimization rules. User agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in an underlying transport layer.
この例では、クライアントは要求で多くのロックトークンを提出しました。 ロックトークンは、あらゆるリソース、ソースと目的地の両方のために提出する必要があって、メソッドの範囲でどこでも、それはロックされます。 この場合、適切なロックトークンを目的地 http://www.example.com/othercontainer/C2/ に提出しませんでした。これは、リソース/container/C2/を動かすことができなかったことを意味します。 /container/C2/を動かす誤りがあったので、/container/C2のメンバーのだれも動かされませんでした。 しかしながら、誤りは全く誤り最小化規則のためそれらのメンバーのために記載されませんでした。 ユーザエージェント認証は以前にHTTPプロトコルの範囲の外のメカニズムで起こりました、基本的なトランスポート層の中で。
9.10. LOCK Method
9.10. ロックメソッド
The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested.
以下のセクションはLOCKメソッドを説明します。(それは、どんなアクセス型の錠も取り出して、既存の錠をリフレッシュするのに使用されます)。 LOCKメソッドのこれらのセクションは、LOCKメソッドに特定の状態でそれらの意味論だけについて説明して、要求されている錠のアクセス型から独立しています。
Any resource that supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein.
最小限で、LOCKがメソッドであるとサポートするどんなリソースも、XML要求と応答がここに定義された書式であると、サポートしなければなりません。
This method is neither idempotent nor safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
このメソッドは、ベキ等元でなくてまた安全ではありません([RFC2616]のセクション9.1を見てください)。 このメソッドへの応答をキャッシュしてはいけません。
9.10.1. Creating a Lock on an Existing Resource
9.10.1. 既存のリソースに錠を作成します。
A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The resource identified in the Request-URI becomes the root of the lock. LOCK method requests to create a new lock MUST have an XML request body. The server MUST preserve the information provided by the client in the 'owner' element in the LOCK request. The LOCK request MAY have a Timeout header.
既存のリソースへのLOCK要求はRequest-URIによって特定されたリソースに錠を作成するでしょう、リソースが闘争錠で既にロックされないなら。 Request-URIで特定されたリソースは錠の根になります。 新しい錠を作成するというLOCKメソッド要求には、XML要求ボディーがなければなりません。 サーバはクライアントによってLOCK要求における'所有者'要素に提供された情報を保存しなければなりません。 LOCK要求には、Timeoutヘッダーがあるかもしれません。
When a new lock is created, the LOCK response:
aであるときに、新しい錠は作成されて、LOCKは反応です:
o MUST contain a body with the value of the DAV:lockdiscovery property in a prop XML element. This MUST contain the full information about the lock just granted, while information about other (shared) locks is OPTIONAL.
o DAV: lockdiscovery属性の価値が支柱XML要素にあるボディーを含まなければなりません。 これはただ与えられた錠に関する完全情報を含まなければなりませんが、他の(共有される)の錠の情報はOPTIONALです。
o MUST include the Lock-Token response header with the token associated with the new lock.
o 新しい錠に関連しているトークンでLock-トークン応答ヘッダを含まなければなりません。
Dusseault Standards Track [Page 61] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[61ページ]。
9.10.2. Refreshing Locks
9.10.2. 壮快な錠
A lock is refreshed by sending a LOCK request to the URL of a resource within the scope of the lock. This request MUST NOT have a body and it MUST specify which lock to refresh by using the 'If' header with a single lock token (only one lock may be refreshed at a time). The request MAY contain a Timeout header, which a server MAY accept to change the duration remaining on the lock to the new value. A server MUST ignore the Depth header on a LOCK refresh.
錠は、錠の範囲の中でLOCK要求をリソースのURLに送ることによって、リフレッシュされます。 この要求には、ボディーがあってはいけません、そして、それはどれがただ一つのロックトークンと共に'If'ヘッダーを使用することによってリフレッシュするためにロックされるかを指定しなければなりません(一度に、1個の錠だけをリフレッシュしてもよいです)。 要求はTimeoutヘッダーを含むかもしれません。(サーバは、錠の上に新しい値のままで残っている持続時間を変えるためにヘッダーを受け入れるかもしれません)。 サーバはLOCKの上のヘッダーがリフレッシュするDepthを無視しなければなりません。
If the resource has other (shared) locks, those locks are unaffected by a lock refresh. Additionally, those locks do not prevent the named lock from being refreshed.
リソースに他の(共有される)の錠があるなら、それらの錠は錠がリフレッシュするaで影響を受けないです。 さらに、それらの錠は、命名された錠がリフレッシュされるのを防ぎません。
The Lock-Token header is not returned in the response for a successful refresh LOCK request, but the LOCK response body MUST contain the new value for the DAV:lockdiscovery property.
Lock-トークンヘッダーはLOCK応答ボディーはDAVのための新しい値を含まなければなりません: aのための応答でうまくいった状態で返されないで、LOCK要求をリフレッシュしなさいというのにもかかわらずの、lockdiscoveryの特性ということです。
9.10.3. Depth and Locking
9.10.3. 深さとロック
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によって指定されたリソースをロックするのを意図します。
If the Depth header is set to infinity, then the resource specified in the Request-URI along with all its members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token. Similarly, if an UNLOCK is successfully executed on this token, all associated resources are unlocked. Hence, partial success is not an option for LOCK or UNLOCK. Either the entire hierarchy is locked or no resources are locked.
Depthヘッダーが無限で用意ができているなら、リソースがRequest-URIですべてのメンバーと、いっぱいな階層構造の下側に指定されて、ロックされることになっていてください。 好成績は単一のロック象徴を返さなければなりません。 同様に、UNLOCKがこの象徴の上で首尾よく実行されるなら、すべての関連リソースの錠は開いています。 したがって、部分的な成功はLOCKかUNLOCKのためのオプションではありません。 全体の階層構造がロックされるか、またはリソースは全くロックされません。
If the lock cannot be granted to all resources, the server MUST return a Multi-Status response with a 'response' element for at least one resource that prevented the lock from being granted, along with a suitable status code for that failure (e.g., 403 (Forbidden) or 423 (Locked)). Additionally, if the resource causing the failure was not the resource requested, then the server SHOULD include a 'response' element for the Request-URI as well, with a 'status' element containing 424 Failed Dependency.
すべてのリソースに錠を与えることができないなら、サーバは錠が与えられるのを防いだ少なくとも1つのリソースのために'応答'要素でMulti-状態応答を返さなければなりません、その失敗(例えば、403(禁じられる)か423(ロックされる))のための適当なステータスコードと共に。 さらに、サーバSHOULDは失敗を引き起こしたリソースが要求されたリソースでなかったならまた、Request-URIのための'応答'要素を含んでいます、'状態'要素が424Failed Dependencyを含んでいて。
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ヘッダーを全く提出しないなら要求が行動しなければならない、「深さ: 無限」を提出しました。
Dusseault Standards Track [Page 62] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[62ページ]。
9.10.4. Locking Unmapped URLs
9.10.4. Unmapped URLをロックします。
A successful LOCK method MUST result in the creation of an empty resource that is locked (and that is not a collection) when a resource did not previously exist at that URL. Later on, the lock may go away but the empty resource remains. Empty resources MUST then appear in PROPFIND responses including that URL in the response scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length
うまくいっているLOCK方法はリソースが以前にそのURLに存在しなかったときロックされる(それは収集ではありません)空のリソースの創造をもたらさなければなりません。 後で、錠は遠ざかるかもしれませんが、空のリソースは残っています。 そして、空のリソースは応答範囲にそのURLを含むPROPFIND応答に現れなければなりません。 サーバは、空のリソース、204いいえContent応答を使用するか、またはContent-長さのヘッダーがゼロ・レングスを示している200OKを使用することによって、GET要求に首尾よく応じなければなりません。
9.10.5. Lock Compatibility Table
9.10.5. ロック互換性テーブル
The table below describes the behavior that occurs when a lock request is made on a resource.
以下のテーブルはリソースでロック要求をするとき起こる振舞いについて説明します。
+--------------------------+----------------+-------------------+ | Current State | Shared Lock OK | Exclusive Lock OK | +--------------------------+----------------+-------------------+ | None | True | True | | Shared Lock | True | False | | Exclusive Lock | False | False* | +--------------------------+----------------+-------------------+
+--------------------------+----------------+-------------------+ | 現状| 共有されたLock OK| 排他的なLock OK| +--------------------------+----------------+-------------------+ | なし| 本当| 本当| | 共有された錠| 本当| 誤る| | 排他的な錠| 誤る| 誤った*| +--------------------------+----------------+-------------------+
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 that the lock must not be granted.
一番左コラムでリソースの現在のロック状態を与えます、そして、ファースト・ローにロック要求をリストアップします。 列と1つのコラムの交差点はロック要求の結果を与えます。 例えば、共有された錠がリソースで持たれて、排他的な錠が要求されるなら、テーブル項目は「誤っています」、錠を与えてはいけないのを示して。
9.10.6. LOCK Responses
9.10.6. ロック応答
In addition to the general status codes possible, the following status codes have specific applicability to LOCK:
可能な一般的なステータスコードに加えて、以下のステータスコードは特定の適用性をLOCKに持っています:
200 (OK) - The LOCK request succeeded and the value of the DAV: lockdiscovery property is included in the response body.
200 (OK)--引き継がれたLOCK要求とDAVの値: lockdiscoveryの特性は応答本体に含まれています。
201 (Created) - The LOCK request was to an unmapped URL, the request succeeded and resulted in the creation of a new resource, and the value of the DAV:lockdiscovery property is included in the response body.
201 (作成されます)--要求は、新しいリソースの創造、およびDAVの値を引き継いで、もたらしました: 非写像しているURLにはLOCK要求があって、lockdiscoveryの特性は応答本体に含まれています。
Dusseault Standards Track [Page 63] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[63ページ]。
409 (Conflict) - A resource cannot be created at the destination until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically.
409 (闘争)--1つ以上の中間的収集が作成されるまで、目的地でリソースを作成できません。 サーバは自動的にそれらの中間的収集を作成してはいけません。
423 (Locked), potentially with 'no-conflicting-lock' precondition code - There is already a lock on the resource that is not compatible with the requested lock (see lock compatibility table above).
423 (ロックされる)です、'闘争錠がありません'で潜在的にコードをあらかじめ調整しないでください--既に、錠が要求された錠と互換性がないリソースにあります(ロック互換性テーブルが上であることを見てください)。
412 (Precondition Failed), with 'lock-token-matches-request-uri' precondition code - The LOCK request was made with an If header, indicating that the client wishes to refresh the given lock. However, the Request-URI did not fall within the scope of the lock identified by the token. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
412 'ロック象徴マッチはuriを要求すること'で、コードをあらかじめ調整してください--(前提条件Failed)、Ifヘッダーと共にLOCK要求をしました、クライアントが与えられた錠をリフレッシュしたがっているのを示して。 しかしながら、Request-URIは象徴によって特定された錠の範囲の中に下がりませんでした。 錠にはRequest-URIを含んでいない範囲があるかもしれませんか、錠が見えなくなったかもしれませんか、または象徴は無効であるかもしれません。
9.10.7. Example - Simple Lock Request
9.10.7. 例--簡単なロック要求
>>Request
>>要求
LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
/workspace/webdav/proposal.doc HTTP/1.1ホストをロックしてください: example.com Timeout: 無限の2番目-4100000000コンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx Authorization: 「」 ダイジェストユーザ名="ejw"、分野=" ejw@example.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://example.org/~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://example.org/~ejw/contact.html</D: href></D: 所有者></D: lockinfo>に書いてください'と等しいこと」と等しいです。
>>Response
>>応答
HTTP/1.1 200 OK Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4> Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 200OKロック象徴: <つぼ:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>コンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:prop xmlns:D="DAV:">
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 支柱xmlns: Dが等しい、「DAV: ">"
Dusseault Standards Track [Page 64] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[64ページ]。
<D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>infinity</D:depth> <D:owner> <D:href>http://example.org/~ejw/contact.html</D:href> </D:owner> <D:timeout>Second-604800</D:timeout> <D:locktoken> <D:href >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href> </D:locktoken> <D:lockroot> <D:href >http://example.com/workspace/webdav/proposal.doc</D:href> </D:lockroot> </D:activelock> </D:lockdiscovery> </D:prop>
<D: lockdiscovery><D: activelock><D: locktype><D: /></D: locktype><D: lockscope><D: 排他的な/></D: lockscope><D: 深さ>無限</D: 深さ><D: 所有者><Dに書いてください: href>http://example.org/~ejw/接触; html</D: href></D: 所有者><D: タイムアウト>2番目-604800</D: タイムアウト><D: locktoken><D: href>つぼ: uuid: e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D: href></D: locktoken><D: lockroot><D: href>http://example.com/ワークスペース/webdav/proposal.doc</D: href></D: lockroot></D: activelock></D: lockdiscovery></D: >を支えてください。
This example shows the successful creation of an exclusive write lock on resource http://example.com/workspace/webdav/proposal.doc. The resource http://example.org/~ejw/contact.html contains contact information for the creator of the lock. The server has an activity- based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例がうまくいっている創造を示している、排他的である、リソース http://example.com/workspace/webdav/proposal.doc の上の錠を書いてください。 リソース http://example.org/~ejw/contact.html は錠の創造者への問い合わせ先を含んでいます。 サーバはこのリソースに適所にベースの活動タイムアウト方針を持っています。(それは、1週間(604800秒)後に自動的に錠を取り外します)。 一回だけ、応答、および不透明な分野がAuthorization要求ヘッダーで計算されていないことに注意してください。
9.10.8. Example - Refreshing a Write Lock
9.10.8. 例--aをリフレッシュして、錠を書いてください。
>>Request
>>要求
LOCK /workspace/webdav/proposal.doc HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
/workspace/webdav/proposal.doc HTTP/1.1ホストをロックしてください: example.com Timeout: 無限、2番目-4100000000、: (<つぼ:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) 認可: 「」 ダイジェストユーザ名="ejw"、分野=" ejw@example.com "一回だけ=…」, 「uriは"/workspace/webdav/proposal.doc"と等しく、応答は」 …と等しいです」, 「不透明なものは」 …と等しいです」
Dusseault Standards Track [Page 65] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[65ページ]。
>>Response
>>応答
HTTP/1.1 200 OK Content-Type: application/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> <D:owner> <D:href>http://example.org/~ejw/contact.html</D:href> </D:owner> <D:timeout>Second-604800</D:timeout> <D:locktoken> <D:href >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href> </D:locktoken> <D:lockroot> <D:href >http://example.com/workspace/webdav/proposal.doc</D:href> </D:lockroot> </D:activelock> </D:lockdiscovery> </D:prop>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 支柱xmlns: Dが等しい、「DAV: 「><D: lockdiscovery><D: activelock><D: locktype><D: /></D: locktype><D: lockscope><D: 排他的な/></D: lockscope><D: 深さ>無限</D: 深さ><D: より自己の><Dを書いてください: href>http://example.org/~ejw/接触」; html</D: href></D: 所有者><D: タイムアウト>2番目-604800</D: タイムアウト><D: locktoken><D: href>つぼ: uuid: e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D: href></D: locktoken><D: lockroot><D: href>http://example.com/ワークスペース/webdav/proposal.doc</D: href></D: lockroot></D: activelock></D: lockdiscovery></D: >を支えてください。
This request would refresh the lock, attempting to reset the timeout to the new value specified in the timeout header. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
タイムアウトヘッダーで指定された新しい値へのタイムアウトをリセットするのを試みて、この要求は錠をリフレッシュするでしょう。 無限のタイムアウトにもかかわらず、サーバが求められたクライアントが、要求を無視するのを選ぶのに注意してください。 この例では、一回だけ、応答、および不透明な分野はAuthorization要求ヘッダーで計算されていません。
9.10.9. Example - Multi-Resource Lock Request
9.10.9. 例--マルチリソースロック要求
>>Request
>>要求
LOCK /webdav/ HTTP/1.1 Host: example.com Timeout: Infinite, Second-4100000000 Depth: infinity Content-Type: application/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", realm="ejw@example.com", nonce="...",
/webdav/ HTTP/1.1ホストをロックしてください: example.com Timeout: 無限の2番目-4100000000の深さ: 無限コンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx Authorization: 「」 ダイジェストユーザ名="ejw"、分野=" ejw@example.com "一回だけ=…」,
Dusseault Standards Track [Page 66] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[66ページ]。
uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
「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://example.org/~ejw/contact.html</D:href> </D:owner> </D:lockinfo>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:lockinfo xmlns:Dが等しい、「DAV: 「><D: locktype><D: : href>http://example.org/~ejw/contact.html</D: href></D: 所有者></D: /></D: locktype><D: lockscope><D: 排他的な/></D: lockscope><D: 所有者><D lockinfo>に書いてください」
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: application/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://example.com/webdav/secret</D:href> <D:status>HTTP/1.1 403 Forbidden</D:status> </D:response> <D:response> <D:href>http://example.com/webdav/</D:href> <D:status>HTTP/1.1 424 Failed Dependency</D:status> </D:response> </D:multistatus>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:multistatus xmlns:Dが等しい、「DAV: 「><D: 応答><D: href>http://example.com/webdav/秘密</D: href><D: 状態>HTTP/1」; 1 : 状態の>HTTP/1.1 424の失敗した依存</D: 状態></D: 応答></D: 403の禁制の</D: 状態></D: 応答><D: 応答><D: href>http://example.com/webdav/</D: href><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://example.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the a 'response' element for the Request-URI itself has been included as required.
誤りはリソース http://example.com/webdav/secret における403(禁じられる)応答です。 このリソースをロックできなかったので、リソースのいずれもロックされませんでした。 また、Request-URI自体のためのa'応答'要素が必要に応じて含まれていることに注意してください。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、一回だけ、応答、および不透明な分野はAuthorization要求ヘッダーで計算されていません。
Dusseault Standards Track [Page 67] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[67ページ]。
9.11. UNLOCK Method
9.11. 方法をアンロックしてください。
The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock.
UNLOCK方法はLock-象徴要求ヘッダーでのロック象徴によって特定された錠を取り外します。 Request-URIは錠の範囲の中でリソースを特定しなければなりません。
Note that use of the Lock-Token header to provide the lock token is not consistent with other state-changing methods, which all require an If header with the lock token. Thus, the If header is not needed to provide the lock token. Naturally, when the If header is present, it has its normal meaning as a conditional header.
ロック象徴を提供するLock-象徴ヘッダーの使用が他の状態を変える方法とすべて、一致していないことに注意してください。(方法はロック象徴でIfヘッダーを必要とします)。 したがって、Ifヘッダーをロック象徴を提供する必要はありません。 Ifヘッダーが出席しているとき、当然、それには、条件付きのヘッダーとして正常な意味があります。
For a successful response to this method, the server MUST delete the lock entirely.
この方法へのうまくいっている応答のために、サーバは錠を完全に削除しなければなりません。
If all resources that have been locked under the submitted lock token cannot be unlocked, then the UNLOCK request MUST fail.
提出されたロック象徴の下でロックされたすべてのリソースの錠が開くことができないなら、UNLOCK要求は失敗しなければなりません。
A successful response to an UNLOCK method does not mean that the resource is necessarily unlocked. It means that the specific lock corresponding to the specified token no longer exists.
UNLOCK方法へのうまくいっている応答は、リソースの錠が必ず開いていることを意味しません。 それは、指定された象徴に対応する特定の錠がもう存在しないことを意味します。
Any DAV-compliant resource that supports the LOCK method MUST support the UNLOCK method.
LOCK方法を支持するどんなDAV対応することのリソースもUNLOCK方法を支持しなければなりません。
This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
この方法は金庫ではなく、ベキ等元([RFC2616]のセクション9.1を見る)です。 この方法への応答をキャッシュしてはいけません。
9.11.1. Status Codes
9.11.1. ステータスコード
In addition to the general status codes possible, the following status codes have specific applicability to UNLOCK:
可能な一般的なステータスコードに加えて、以下のステータスコードは特定の適用性をUNLOCKに持っています:
204 (No Content) - Normal success response (rather than 200 OK, since 200 OK would imply a response body, and an UNLOCK success response does not normally contain a body).
204 (Contentがありません)--通常の成功応答(200OKが応答本体を含意して、通常、UNLOCK成功応答がボディーを含まないで以来の200OKよりむしろ)。
400 (Bad Request) - No lock token was provided.
400 (悪いRequest)--ロック象徴を全く提供しませんでした。
403 (Forbidden) - The currently authenticated principal does not have permission to remove the lock.
403 (禁じられます)--現在認証された校長には、錠を取り外す許可がありません。
409 (Conflict), with 'lock-token-matches-request-uri' precondition - The resource was not locked, or the request was made to a Request-URI that was not within the scope of the lock.
409(闘争)、'ロック象徴マッチはuriを要求すること'で、あらかじめ調整してください--リソースはロックされませんでした、または、要求がそうでした。錠の範囲の中になかったRequest-URIに作られています。
Dusseault Standards Track [Page 68] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[68ページ]。
9.11.2. Example - UNLOCK
9.11.2. 例--アンロックしてください。
>>Request
>>要求
UNLOCK /workspace/webdav/info.doc HTTP/1.1 Host: example.com Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7> Authorization: Digest username="ejw" realm="ejw@example.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..."
/workspace/webdav/info.doc HTTP/1.1ホストをアンロックしてください: example.com Lock-象徴: <つぼ:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>認可: 「ユーザ名="ejw"分野=" ejw@example.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 "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://example.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock.
この例、ロック象徴によって特定された錠では、「つぼ:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7"はリソース http://example.com/workspace/webdav/info.doc から首尾よく取り外されます」。 この錠がちょうど1つ以上のリソースを含んでいたなら、錠は錠にすべてのリソースを含むのから取り外されます。
In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.
この例では、一回だけ、応答、および不透明な分野はAuthorization要求ヘッダーで計算されていません。
10. HTTP Headers for Distributed Authoring
10. 分配されたオーサリングのためのHTTPヘッダ
All DAV headers follow the same basic formatting rules as HTTP headers. This includes rules like line continuation and how to combine (or separate) multiple instances of the same header using commas.
すべてのDAVヘッダーがHTTPヘッダと同じ基本的な形式規則に従います。 これは線継続とコンマを使用することでどう同じヘッダーの複数の例を結合するかような(分離してください)規則を含んでいます。
WebDAV adds two new conditional headers to the set defined in HTTP: the If and Overwrite headers.
WebDAVは2個の新しい条件付きのヘッダーをHTTPで定義されたセットに追加します: IfとOverwriteヘッダー。
10.1. DAV Header
10.1. DAVヘッダー
DAV = "DAV" ":" #( compliance-class ) compliance-class = ( "1" | "2" | "3" | extend ) extend = Coded-URL | token ; token is defined in RFC 2616, Section 2.2 Coded-URL = "<" absolute-URI ">" ; No linear whitespace (LWS) allowed in Coded-URL ; absolute-URI defined in RFC 3986, Section 4.3
「DAVは"DAV"と等しい」:、」 #(承諾クラス) 承諾クラス=、(「1インチ|、「2インチ|、「3インチ| 広がってください、)、=コード化されたURLを広げてください、」| 象徴。 象徴はRFC2616で定義されて、セクション2.2Coded-URLは"<"絶対URI">"と等しいです。 Coded-URLに許容されなかったどんな直線的な空白(LWS)も。 RFC3986、セクション4.3で定義された絶対URI
Dusseault Standards Track [Page 69] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[69ページ]。
This general-header appearing in the response indicates that the resource supports the DAV schema and protocol as specified. All DAV- compliant resources MUST return the DAV header with compliance-class "1" on all OPTIONS responses. In cases where WebDAV is only supported in part of the server namespace, an OPTIONS request to non- WebDAV resources (including "/") SHOULD NOT advertise WebDAV support.
応答に現れるこの一般的なヘッダーは、リソースが指定されるとしてDAV図式とプロトコルをサポートするのを示します。 すべてのDAV対応することのリソースが「すべてのオプション応答での1インチ」を承諾クラスがあるDAVヘッダーに返さなければなりません。 「WebDAVが一部支持されるだけであるところでコネがサーバ名前空間、非WebDAVのリソースへのOPTIONS要求をケースに入れる、(」 /を含んでいる、」、)、WebDAVサポートの広告を出すべきではありません。
The value is a comma-separated list of all compliance class identifiers that the resource supports. Class identifiers may be Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can appear in any order. Identifiers that are standardized through the IETF RFC process are tokens, but other identifiers SHOULD be Coded- URLs to encourage uniqueness.
値はリソースが支持するすべての承諾クラス識別子のコンマで切り離されたリストです。 クラス識別子は、Coded-URLか象徴であるかもしれません([RFC2616]によって定義されるように)。 識別子は順不同に現れることができます。 IETF RFCの過程で標準化される識別子は奨励するCoded URLがユニークさであったなら象徴ですが、他の識別子SHOULDです。
A resource must show class 1 compliance if it shows class 2 or 3 compliance. In general, support for one compliance class does not entail support for any other, and in particular, support for compliance class 3 does not require support for compliance class 2. Please refer to Section 18 for more details on compliance classes defined in this specification.
リソースは、それがクラス2か3にコンプライアンスを示すかどうかをクラス1コンプライアンスに示さなければなりません。 一般に、1つの承諾クラスのサポートはいかなる他のサポートも伴いません、そして、特に、承諾クラス3のサポートは承諾クラス2に支持を要しません。 この仕様に基づき定義された承諾クラスに関するその他の詳細についてセクション18を参照してください。
Note that many WebDAV servers do not advertise WebDAV support in response to "OPTIONS *".
多くのWebDAVサーバが「オプション*」に対応してWebDAVサポートの広告を出さないことに注意してください。
As a request header, this header allows the client to advertise compliance with named features when the server needs that information. Clients SHOULD NOT send this header unless a standards track specification requires it. Any extension that makes use of this as a request header will need to carefully consider caching implications.
サーバがその情報を必要とするとき、要求ヘッダーとして、このヘッダーはクライアントに命名された特徴へのコンプライアンスに広告を出させます。 標準化過程仕様がそれを必要としない場合、クライアントSHOULD NOTはこのヘッダーを送ります。 要求ヘッダーとしてこれを利用するどんな拡張子も、含意をキャッシュすると慎重に考える必要があるでしょう。
10.2. Depth Header
10.2. 深さヘッダー
Depth = "Depth" ":" ("0" | "1" | "infinity")
「深さは「深さ」と等しい」:、」 (「0インチ|、「1インチ| 「無限」、)、」
The Depth request header is used with methods executed on resources that could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its internal members only ("Depth: 1"), or the resource and all its members ("Depth: infinity").
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ヘッダーを支えるどんな方法のためのデフォルトの振舞いです。 方法は、定義における異なった振舞いを定義することによって、これらのデフォルトをくつがえすかもしれません。
Dusseault Standards Track [Page 70] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[70ページ]。
Methods that support the Depth header may choose not to support all of the header's values and may define, on a case-by-case basis, the behavior of the method if a Depth header is not present. For example, the MOVE method only supports "Depth: infinity", and if a Depth header is not present, it will act as if a "Depth: infinity" header had been applied.
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階層構造への試み。コピーされるメンバーの何人かの結果と何かはそうしませんように。
By default, the Depth header does not interact with other headers. That is, each header on a request with a Depth header MUST be applied only to the Request-URI if it applies to any resource, unless specific Depth behavior is defined for that header.
デフォルトで、Depthヘッダーは他のヘッダーと対話しません。 すなわち、それがどんなリソースにも適用されるなら、Depthヘッダーによる要求での各ヘッダーをRequest-URIだけに適用しなければなりません、特定のDepthの振舞いがそのヘッダーのために定義されない場合。
If a source or destination resource within the scope of the Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header.
Depthヘッダーの範囲の中のソースか目的地リソースを方法のうまくいっている実行を防ぐほどそのような方法でロックするなら、If要求ヘッダーで要求でそのリソースのためのロック象徴を提出しなければなりません。
The Depth header only specifies the behavior of the method with regards to internal members. If a resource does not have internal members, then the Depth header MUST be ignored.
Depthヘッダーはあいさつによる方法の振舞いを内部のメンバーに指定するだけです。 リソースに内部のメンバーがいないなら、Depthヘッダーを無視しなければなりません。
10.3. Destination Header
10.3. 目的地ヘッダー
The Destination request header specifies the URI that identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters.
Destination要求ヘッダーはパラメタとして2つのURIをみなすCOPYやMOVEなどの方法のための目的地リソースを特定するURIを指定します。
Destination = "Destination" ":" Simple-ref
「目的地=「目的地」」:、」 純真な審判
If the Destination value is an absolute-URI (Section 4.3 of [RFC3986]), it may name a different server (or different port or scheme). If the source server cannot attempt a copy to the remote server, it MUST fail the request. Note that copying and moving resources to remote servers is not fully defined in this specification (e.g., specific error conditions).
Destination値が絶対URI([RFC3986]のセクション4.3)であるなら、それは異なったサーバ(または、異なったポートか計画)を命名するかもしれません。 ソースサーバがリモートサーバにコピーを試みることができないなら、それは要求に失敗しなければなりません。 リモートサーバへのコピーと感動的なリソースをある注意はこの仕様に基づき完全に(例えば、特定のエラー条件)を定義したというわけではありません。
Dusseault Standards Track [Page 71] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[71ページ]。
If the Destination value is too long or otherwise unacceptable, the server SHOULD return 400 (Bad Request), ideally with helpful information in an error body.
Destination値が長過ぎるか、またはそうでなければ、容認できないなら、サーバSHOULDは400(悪いRequest)を返します、理想的な役立つ情報が誤り本体にある状態で。
10.4. If Header
10.4. ヘッダーです。
The If request header is intended to have similar functionality to the If-Match header defined in Section 14.24 of [RFC2616]. However, the If header handles any state token as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification.
If要求ヘッダーが[RFC2616]のセクション14.24で定義されたIf-マッチヘッダーに同様の機能性を持っていることを意図します。 しかしながら、IfヘッダーはETagsと同様にどんな州の象徴も扱います。 州の象徴の典型的な例はロック象徴です、そして、ロック象徴はこの仕様に基づき定義された唯一の州の象徴です。
10.4.1. Purpose
10.4.1. 目的
The If header has two distinct purposes:
Ifヘッダーには、2つの異なった目的があります:
o The first purpose is to make a request conditional by supplying a series of state lists with conditions that match tokens and ETags to a specific resource. If this header is evaluated and all state lists fail, then the request MUST fail with a 412 (Precondition Failed) status. On the other hand, the request can succeed only if one of the described state lists succeeds. The success criteria for state lists and matching functions are defined in Sections 10.4.3 and 10.4.4.
o 最初の目的は象徴とETagsを特定のリソースに合わせる状態を一連の州のリストに供給することによって要求を条件付きにすることです。 このヘッダーが評価されて、すべての州のリストが失敗するなら、412(前提条件Failed)状態に応じて、要求は失敗しなければなりません。 他方では、説明された州のリストの1つが成功する場合にだけ、要求は成功できます。 州のリストと合っている機能の成功評価基準はセクション10.4.3と10.4で.4に定義されます。
o Additionally, the mere fact that a state token appears in an If header means that it has been "submitted" with the request. In general, this is used to indicate that the client has knowledge of that state token. The semantics for submitting a state token depend on its type (for lock tokens, please refer to Section 6).
o さらに、州の象徴がIfヘッダーに現れるという単なる事実は、それが要求で「提出されたこと」を意味します。 一般に、これは、クライアントにはその州の象徴に関する知識があるのを示すのに使用されます。 州の象徴を提出するための意味論はタイプに頼っています(ロック象徴について、セクション6を参照してください)。
Note that these two purposes need to be treated distinctly: a state token counts as being submitted independently of whether the server actually has evaluated the state list it appears in, and also independently of whether or not the condition it expressed was found to be true.
これらの2つの目的が、明瞭に扱われる必要に注意してください: わかってそれが言い表した状態が本当であることがわかったかどうかの如何にかかわらずも州の象徴はサーバが実際に州のリストを評価したかどうかの如何にかかわらず提出して、現れるように数えられます。
10.4.2. Syntax
10.4.2. 構文
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list )
「=“If"であるなら」:、」 (1*いいえ、タグリスト| 1つの*タグ付けをされたリスト)
No-tag-list = List Tagged-list = Resource-Tag 1*List
タグリストがない=リストタグ付けをされたリスト=リソースタグ1*リスト
List = "(" 1*Condition ")" Condition = ["Not"] (State-token | "[" entity-tag "]") ; entity-tag: see Section 3.11 of [RFC2616] ; No LWS allowed between "[", entity-tag and "]"
リスト=「(「1*状態」)」Conditionが[“Not"]と等しい、(州象徴|、「[「実体タグ」]」)、。 実体タグ: [RFC2616]のセクション3.11を見てください。 そして、どんなLWSも間に許容しなかった、「[「実体タグ、」、]、」
Dusseault Standards Track [Page 72] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[72ページ]。
State-token = Coded-URL
州象徴はコード化されたURLと等しいです。
Resource-Tag = "<" Simple-ref ">" ; Simple-ref: see Section 8.3 ; No LWS allowed in Resource-Tag
リソースタグ="<"純真な審判">"。 純真な審判: セクション8.3を見てください。 Resource-タグに許容されなかったLWS全く
The syntax distinguishes between untagged lists ("No-tag-list") and tagged lists ("Tagged-list"). Untagged lists apply to the resource identified by the Request-URI, while tagged lists apply to the resource identified by the preceding Resource-Tag.
構文は非タグ付けをされたリスト(「タグリストがない」)とタグ付けをされたリスト(「タグ付けをされたリスト」の)を見分けます。 UntaggedリストはRequest-URIによって特定されたリソースに適用されます、タグ付けをされたリストが前のResource-タグによって特定されたリソースに適用されますが。
A Resource-Tag applies to all subsequent Lists, up to the next Resource-Tag.
Resource-タグはすべてのその後のListsに次のResource-タグまで適用されます。
Note that the two list types cannot be mixed within an If header. This is not a functional restriction because the No-tag-list syntax is just a shorthand notation for a Tagged-list production with a Resource-Tag referring to the Request-URI.
2つのリストタイプがIfヘッダーの中に複雑であることができないことに注意してください。 タグリストがない構文がただRequest-URIについて言及するResource-タグとのTagged-リスト生産のための簡単な表記法であるので、これは機能制限ではありません。
Each List consists of one or more Conditions. Each Condition is defined in terms of an entity-tag or state-token, potentially negated by the prefix "Not".
各Listは1Conditionsから成ります。 各Conditionは接頭語“Not"によって潜在的に否定された実体タグか州象徴に関して定義されます。
Note that the If header syntax does not allow multiple instances of If headers in a single request. However, the HTTP header syntax allows extending single header values across multiple lines, by inserting a line break followed by whitespace (see [RFC2616], Section 4.2).
Ifヘッダー構文がただ一つの要求にIfヘッダーの複数の例を許容しないことに注意してください。 しかしながら、HTTPヘッダ構文で、複数の線の向こう側にただ一つのヘッダー値を広げます、空白があとに続いたラインブレイクを挿入することによって([RFC2616]を見てください、セクション4.2)。
10.4.3. List Evaluation
10.4.3. リスト評価
A Condition that consists of a single entity-tag or state-token evaluates to true if the resource matches the described state (where the individual matching functions are defined below in Section 10.4.4). Prefixing it with "Not" reverses the result of the evaluation (thus, the "Not" applies only to the subsequent entity-tag or state-token).
単一の実体タグか州象徴から成るConditionは、リソースが説明された状態(個々の合っている機能が以下でセクション10.4.4で定義されるところ)に合っているかどうか本当に評価します。 “Not"と共にそれを前に置くと、評価の結果は破棄されます(その結果、“Not"はその後の実体タグか州象徴だけに適用します)。
Each List production describes a series of conditions. The whole list evaluates to true if and only if each condition evaluates to true (that is, the list represents a logical conjunction of Conditions).
それぞれのList生産は一連の状態について説明します。 全体のリストが本当に評価する、唯一、状態が本当(すなわち、リストはConditionsのa論理的な接続詞を表す)に評価するそれぞれ。
Each No-tag-list and Tagged-list production may contain one or more Lists. They evaluate to true if and only if any of the contained lists evaluates to true (that is, if there's more than one List, that List sequence represents a logical disjunction of the Lists).
それぞれのタグリストがなくてTagged-リスト生産は1Listsを入れてあるかもしれません。 彼らが本当に評価する、唯一、リストが本当(すなわち、1Listがあれば、そのList系列はListsの論理的な分裂を表す)に評価する含有のいずれも。
Dusseault Standards Track [Page 73] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[73ページ]。
Finally, the whole If header evaluates to true if and only if at least one of the No-tag-list or Tagged-list productions evaluates to true. If the header evaluates to false, the server MUST reject the request with a 412 (Precondition Failed) status. Otherwise, execution of the request can proceed as if the header wasn't present.
最終的に、全体のIfヘッダーが本当に評価する、唯一、少なくとも創作が本当に評価するいいえタグリストかTagged-リストの1つ。 ヘッダーが評価する、誤っているのに、サーバは412(前提条件Failed)状態で要求を拒絶しなければなりません。 さもなければ、まるでヘッダーが出席していないかのように要求の実行は続くことができます。
10.4.4. Matching State Tokens and ETags
10.4.4. 合っている州の象徴とETags
When performing If header processing, the definition of a matching state token or entity tag is as follows:
Ifヘッダー処理を実行するとき、合っている州の象徴か実体タグの定義は以下の通りです:
Identifying a resource: The resource is identified by the URI along with the token, in tagged list production, or by the Request-URI in untagged list production.
リソースを特定します: リソースは象徴に伴うタグ付けをされたリスト生産におけるURIか非タグ付けをされたリスト生産におけるRequest-URIによって特定されます。
Matching entity tag: Where the entity tag matches an entity tag associated with the identified resource. Servers MUST use either the weak or the strong comparison function defined in Section 13.3.3 of [RFC2616].
合っている実体タグ: 実体タグが合っているところでは、実体タグは特定されたリソースと交際しました。 サーバは.3セクション13.3[RFC2616]で定義された弱い比較関数か強い比較関数を使用しなければなりません。
Matching state token: Where there is an exact match between the state token in the If header and any state token on the identified resource. A lock state token is considered to match if the resource is anywhere in the scope of the lock.
マッチングは象徴を述べます: Ifヘッダーでの州の象徴と特定されたリソースでのどんな州の象徴との完全な一致もあるところ。 リソースが錠の範囲で何処かでにあるなら、ロック州の象徴が合っていると考えられます。
Handling unmapped URLs: For both ETags and state tokens, treat as if the URL identified a resource that exists but does not have the specified state.
取り扱いはURLを非写像しました: ETagsと州の象徴の両方に関しては、まるでURLが存在していますが、指定された状態を持っていないリソースを特定するかのように、扱ってください。
10.4.5. If Header and Non-DAV-Aware Proxies
10.4.5. そして、ヘッダーである、非DAV意識する、プロキシ
Non-DAV-aware proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the client MUST use the "Cache-Control: no-cache" request header so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies, the "Pragma: no- cache" request header MUST be used for the same reason.
非DAV意識する、プロキシはIfヘッダーを尊敬しないでしょう、彼らがIfヘッダーを理解しないで、HTTPが、非理解されているヘッダーが無視されるのを必要とするので。 HTTP/1.1のプロキシとコミュニケートするとき、クライアントが使用しなければならない、「キャッシュ制御:」 「キャッシュがありません」は、キャッシュからプロキシが不適切に要求を修理しようとするのを防ぐためにヘッダーを要求します。 HTTP/1.0のプロキシに対処するとき「Pragma:」 同じ理由から「いいえキャッシュ」要求ヘッダーを使用しなければなりません。
Because in general clients may not be able to reliably detect non- DAV-aware intermediates, they are advised to always prevent caching using the request directives mentioned above.
クライアントが一般にDAV意識している非中間介在物を確かに検出できないかもしれないので、いつもキャッシュするのを前記のように要求指示を使用することで防ぐようにアドバイスされます。
Dusseault Standards Track [Page 74] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[74ページ]。
10.4.6. Example - No-tag Production
10.4.6. 例--タグがない生産
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> ["I am an ETag"]) (["I am another ETag"])
: (<つぼ:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>[「私はETagです」]) ([「私は別のETagです」])
The previous header would require that the resource identified in the Request-URI be locked with the specified lock token and be in the state identified by the "I am an ETag" ETag or in the state identified by the second ETag "I am another ETag".
前のヘッダーは、Request-URIで特定されたリソースが指定されたロック象徴でロックされて、「私はETagです」ETagによって特定された州か第2ETag「私は別のETagであること」によって特定された状態にあるのを必要とするでしょう。
To put the matter more plainly one can think of the previous If header as expressing the condition below:
より明らかにその物質を置くために、人は以下の状態を言い表すと前のIfヘッダーを思うことができます:
( is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND matches-etag("I am an ETag") ) OR ( matches-etag("I am another ETag") )
(ロックされる、(つぼ:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2)とマッチ-etag(「私はETagである」)OR(マッチ-etag(「私は別のETagです」))
10.4.7. Example - Using "Not" with No-tag Production
10.4.7. 例--タグがない生産がある“Not"を使用すること。
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
: (<つぼ:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2><つぼ:uuid:58f202ac-22cf-11d1-b12d-002035b29092>でない)
This If header requires that the resource must not be locked with a lock having the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 and must be locked by a lock with the lock token urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092.
このIfヘッダーが、リソースをロック象徴つぼ: uuid: 181d4fae-7d8c-11d0-a765-00a0c91e6bf2を持っている錠でロックされてはいけなくて、ロック象徴つぼがある錠でロックしなければなりません: uuid: 58f202ac-22cf-11d1-b12d-002035b29092が必要です。
10.4.8. Example - Causing a Condition to Always Evaluate to True
10.4.8. 例--いつも本当に評価する状態を引き起こすこと。
There may be cases where a client wishes to submit state tokens, but doesn't want the request to fail just because the state token isn't current anymore. One simple way to do this is to include a Condition that is known to always evaluate to true, such as in:
州の象徴がそれ以上よく見られるだけではないので、ケースがクライアントが州の象徴を提出することを願っていますが、失敗するという要求が欲しくないところにあるかもしれません。 これをする1つの簡単な方法はそれがいつも本当に評価するのが知られている以下などのConditionを含むことです。
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>) (Not <DAV:no-lock>)
: (<つぼ:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>) (<DAV: ロック>)
"DAV:no-lock" is known to never represent a current lock token. Lock tokens are assigned by the server, following the uniqueness requirements described in Section 6.5, therefore cannot use the "DAV:" scheme. Thus, by applying "Not" to a state token that is
「DAV: 錠がありません」が現在のロックトークンを決して表さないのが知られています。 したがって、トークンがサーバによって割り当てられる錠(ユニークさの要件がセクション6.5で説明した次の事柄)が使用できない、「DAV:」 計画してください。 したがって、州のトークンに“Not"を適用することによって、それはそうです。
Dusseault Standards Track [Page 75] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[75ページ]。
known not to be current, the Condition always evaluates to true. Consequently, the whole If header will always evaluate to true, and the lock token urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2 will be submitted in any case.
電流、いつもConditionになってください。知っている、本当に評価します。 その結果Ifヘッダーがいつも本当に評価する全体、および: uuid: 181d4fae-7d8c-11d0-a765-00a0c91e6bf2が提出されるいずれもケースに入れるロックトークンつぼ。
10.4.9. Example - Tagged List If Header in COPY
10.4.9. 例--コピーのヘッダーであるならリストにタグ付けをします。
>>Request
>>要求
COPY /resource1 HTTP/1.1 Host: www.example.com Destination: /resource2 If: </resource1> (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A weak ETag"]) (["strong ETag"])
コピー/resource1HTTP/1.1ホスト: www.example.com Destination: /resource2、: 「</resource1>、(<のつぼ:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2の>の[W/"Aの弱いETag、」、)([「強いETag」])
In this example, http://www.example.com/resource1 is being copied to http://www.example.com/resource2. When the method is first applied to http://www.example.com/resource1, resource1 must be in the state specified by "(<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> [W/"A weak ETag"]) (["strong ETag"])". That is, either it must be locked with a lock token of "urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2" and have a weak entity tag W/"A weak ETag" or it must have a strong entity tag "strong ETag".
この例では、 http://www.example.com/resource1 は http://www.example.com/resource2 にコピーされています。 「いつまでにメソッドが最初に http://www.example.com/resource1 に適用されて、状態でresource1を指定しなければならないか、「(<のつぼ:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2の>の[W/"Aの弱いETag、」、)、([「強いETag」])、」 弱い実体に」 W/A弱いETagにタグ付けをさせてください。そして、「ロックトークンですなわち、それをロックしなければならない、「つぼ:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2"、」 それには、強い実体タグ「強いETag」がなければなりません。
10.4.10. Example - Matching Lock Tokens with Collection Locks
10.4.10. 例--収集錠がある合っているロックトークン
DELETE /specs/rfc2518.txt HTTP/1.1 Host: www.example.com If: <http://www.example.com/specs/> (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
/specs/rfc2518.txt HTTP/1.1ホストを削除してください: www.example.com If: <http://www.example.com/specs/>。(<つぼ:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
For this example, the lock token must be compared to the identified resource, which is the 'specs' collection identified by the URL in the tagged list production. If the 'specs' collection is not locked by a lock with the specified lock token, the request MUST fail. Otherwise, this request could succeed, because the If header evaluates to true, and because the lock token for the lock affecting the affected resource has been submitted.
この例に関しては、ロックトークンを特定されたリソースにたとえなければなりません。(それは、URLによってタグ付けをされたリスト生産で特定された'仕様'収集です)。 '仕様'収集が指定されたロックトークンがある錠によってロックされないなら、要求は失敗しなければなりません。 さもなければ、この要求が成功できた、本当、影響を受けるリソースに影響する錠のためのロックトークンを提出したのでIfヘッダーは評価します。
10.4.11. Example - Matching ETags on Unmapped URLs
10.4.11. 例--Unmapped URLの合っているETags
Consider a collection "/specs" that does not contain the member "/specs/rfc2518.doc". In this case, the If header
それがする「」 収集が/仕様であると考えてください」はメンバー"/specs/rfc2518.doc"を含んでいません。 この場合Ifヘッダー
If: </specs/rfc2518.doc> (["4217"])
: </specs/rfc2518.doc>。(["4217"])
Dusseault Standards Track [Page 76] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[76ページ]。
will evaluate to false (the URI isn't mapped, thus the resource identified by the URI doesn't have an entity matching the ETag "4217").
誤り(URIは写像されません、その結果、URIによって特定されたリソースはETag「4217」に合っている実体を持っていない)に評価するでしょう。
On the other hand, an If header of
他方では、Ifヘッダー
If: </specs/rfc2518.doc> (Not ["4217"])
: </specs/rfc2518.doc>。([「4217」]でない)
will consequently evaluate to true.
その結果、本当に評価するでしょう。
Note that, as defined above in Section 10.4.4, the same considerations apply to matching state tokens.
同じ問題が上でセクション10.4.4で定義されるように合っている州のトークンに適用されることに注意してください。
10.5. Lock-Token Header
10.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メソッドで使用されます。
10.6. Overwrite Header
10.6. 重ね書きヘッダー
Overwrite = "Overwrite" ":" ("T" | "F")
「重ね書き=「重ね書き」」:、」 (「T」| 「F」)
The Overwrite request header specifies whether the server should overwrite a resource mapped to the destination URL during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the destination URL does map to a resource. If the overwrite header is not included in a COPY or MOVE request, then the resource MUST treat the request as if it has an overwrite header of value "T". While the Overwrite header appears to duplicate the functionality of using an "If-Match: *" header (see [RFC2616]), If-Match applies only to the Request-URI, and not to the Destination of a COPY or MOVE.
Overwrite要求ヘッダーは、サーバがCOPYかMOVEの間に目的地URLに写像されたリソースを上書きするべきであるかどうか指定します。 「F」の値は、目的地URLがリソースに地図をするならサーバがコピーか移動命令を実行してはいけないと述べます。 重ね書きヘッダーがCOPYかMOVE要求に含まれていないなら、まるでそれには価値「T」の重ね書きヘッダーがあるかのようにリソースは要求を扱わなければなりません。 Overwriteヘッダーが、使用の機能性をコピーするように見える、「-合ってください、:、」 *「ヘッダー([RFC2616]を見る)、If-マッチはCOPYかMOVEのDestinationではなく、Request-URIだけに適用されます。」
If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code. The server MUST do authorization checks before checking this or any conditional header.
COPYかMOVEがOverwriteヘッダーの値のため実行されないなら、メソッドは412(前提条件Failed)ステータスコードで失敗しなければなりません。 これかどんな条件付きのヘッダーもチェックする前に、サーバは許可検査をしなければなりません。
All DAV-compliant resources MUST support the Overwrite header.
すべてのDAV対応することのリソースがOverwriteヘッダーを支えなければなりません。
Dusseault Standards Track [Page 77] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[77ページ]。
10.7. Timeout Request Header
10.7. タイムアウト要求ヘッダー
TimeOut = "Timeout" ":" 1#TimeType TimeType = ("Second-" DAVTimeOutVal | "Infinite") ; No LWS allowed within TimeType DAVTimeOutVal = 1*DIGIT
「タイムアウトは「タイムアウト」と等しい」:、」 1#TimeType TimeTypeは(「2番目」のDAVTimeOutVal| 「無限」)と等しいです。 TimeType DAVTimeOutValの中に許容されなかったLWSは全く1*DIGITと等しいです。
Clients MAY include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method.
クライアントは彼らのLOCK要求でTimeout要求ヘッダーを入れるかもしれません。 しかしながら、サーバは、これらの要求を光栄に思うか、または考えるのさえ必要ではありません。 クライアントはLOCKメソッド以外のどんなメソッドでもTimeout要求ヘッダーを提出してはいけません。
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であるはずがない。
See Section 6.6 for a description of lock timeout behavior.
ロックタイムアウトの振舞いの記述に関してセクション6.6を見てください。
11. Status Code Extensions to HTTP/1.1
11. HTTP/1.1へのステータスコード拡大
The following status codes are added to those defined in HTTP/1.1 [RFC2616].
以下のステータスコードはHTTP/1.1[RFC2616]で定義されたものに加えられます。
11.1. 207 Multi-Status
11.1. 207 マルチ状態
The 207 (Multi-Status) status code provides status for multiple independent operations (see Section 13 for more information).
207(マルチStatus)ステータスコードは複数の単独操業に状態を提供します(詳しい情報に関してセクション13を見てください)。
11.2. 422 Unprocessable Entity
11.2. 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指示を含むなら、このエラー条件は起こるかもしれません。
11.3. 423 Locked
11.3. 423はロックされました。
The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
423(ロックされる)ステータスコードは、メソッドに関するソースか目的地リソースがロックされることを意味します。 この応答SHOULDは'ロックトークンは提出したこと'にもかかわらずの、'闘争錠がありません'などの適切な前提条件かpostconditionコードを含んでいます。
Dusseault Standards Track [Page 78] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[78ページ]。
11.4. 424 Failed Dependency
11.4. 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)で失敗するでしょう。
11.5. 507 Insufficient Storage
11.5. 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 that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.
507(不十分なStorage)ステータスコードは、サーバが首尾よく要求を終了するのに必要である表現を保存できないのでリソースにメソッドを実行できなかったことを意味します。 この状態が一時的であると考えられます。 このステータスコードを受け取った要求がユーザ動作の結果であったなら、それが別々のユーザ動きで要求されるまで、要求を繰り返してはいけません。
12. Use of HTTP Status Codes
12. HTTPステータスコードの使用
These HTTP codes are not redefined, but their use is somewhat extended by WebDAV methods and requirements. In general, many HTTP status codes can be used in response to any request, not just in cases described in this document. Note also that WebDAV servers are known to use 300-level redirect responses (and early interoperability tests found clients unprepared to see those responses). A 300-level response MUST NOT be used when the server has created a new resource in response to the request.
これらのHTTPコードは再定義されませんが、彼らの使用はWebDAVメソッドと要件によっていくらか広げられます。 一般に、本書では説明されたケースだけではなく、どんな要求に対応して多くのHTTPステータスコードを使用できます。 また、WebDAVサーバが再直接の300レベルの応答を使用するのが知られていることに注意してください(早めの相互運用性テストはそれらの応答を見るために用意ができていていないクライアントを設立します)。 サーバが要求に対応して新しいリソースを作成したとき、300レベルの応答を使用してはいけません。
12.1. 412 Precondition Failed
12.1. 412前提条件は失敗しました。
Any request can contain a conditional header defined in HTTP (If- Match, If-Modified-Since, etc.) or the "If" or "Overwrite" conditional headers defined in this specification. If the server evaluates a conditional header, and if that condition fails to hold, then this error code MUST be returned. On the other hand, if the client did not include a conditional header in the request, then the server MUST NOT use this status code.
どんな要求もHTTPで定義された条件付きのヘッダーを含むことができる、(-、マッチ、以来変更されたIfなど) または、この仕様に基づき定義された“If"か「重ね書き」条件付きのヘッダー。 サーバが条件付きのヘッダーを評価して、その状態が成立しないなら、このエラーコードを返さなければなりません。 他方では、クライアントが要求で条件付きのヘッダーを入れなかったなら、サーバはこのステータスコードを使用してはいけません。
12.2. 414 Request-URI Too Long
12.2. 414要求URIも長さ
This status code is used in HTTP 1.1 only for Request-URIs, not URIs in other locations.
このステータスコードは他の位置のURIではなく、Request-URIにだけHTTP1.1に使用されます。
Dusseault Standards Track [Page 79] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[79ページ]。
13. Multi-Status Response
13. マルチ状態応答
A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate. The default Multi-Status response body is a text/xml or application/xml HTTP entity with a 'multistatus' root element. Further elements contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element.
Multi-状態応答は状況における複数のリソースに関して複数のステータスコードが適切であるかもしれないところに情報を伝達します。 デフォルトMulti-状態応答本体は'「マルチ-状態」'根の要素があるテキスト/xmlかアプリケーション/xml HTTP実体です。 さらなる要素はステータスコードがメソッド実施の間に生成した200、300、400、および500のシリーズを含んでいます。 記録されていて、100シリーズ状態は'応答'XML要素でSHOULD NOTをコード化します。
Although '207' is used as the overall response status code, the recipient needs to consult the contents of the multistatus response body for further information about the success or failure of the method execution. The response MAY be used in success, partial success and also in failure situations.
'207'は総合的な応答ステータスコードとして使用されていますが、受取人は、メソッド実行の成否に関する詳細のために「マルチ-状態」応答ボディーのコンテンツに相談する必要があります。 応答は成功、部分的な成功、および失敗状況でも使用されるかもしれません。
The 'multistatus' root element holds zero or more 'response' elements in any order, each with information about an individual resource. Each 'response' element MUST have an 'href' element to identify the resource.
'「マルチ-状態」'根の要素はゼロかそれぞれ個々のリソースの情報で順不同なより多くの'応答'要素を保持します。 それぞれの'応答'要素には、リソースを特定する'href'要素がなければなりません。
A Multi-Status response uses one out of two distinct formats for representing the status:
Multi-状態応答は状態を表すのに2つの異なった形式のうちの1を使用します:
1. A 'status' element as child of the 'response' element indicates the status of the message execution for the identified resource as a whole (for instance, see Section 9.6.2). Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic rules defined in Section 10 of [RFC2616].
1. '応答'要素の子供としての'状態'要素は全体で特定されたリソースのためのメッセージ実行の状態を示します(例えば、セクション9.6.2を見てください)。 定義が特定のステータスコードクライアントの情報を提供する何らかのメソッドが応答で見るように準備されるべきです。 しかしながら、[RFC2616]のセクション10で定義されたジェネリック規則を使用して、クライアントは他のステータスコードを扱うことができなければなりません。
2. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is described in detail in Sections 9.1 and 9.2.
2. PROPFINDとPROPPATCHに関しては、'状態'の代わりに'propstat'要素を使用することで形式を広げてあります、リソースの個人財産の情報を提供して。 この形式は、PROPFINDとPROPPATCHに特定であり、セクション9.1と9.2で詳細に説明されます。
13.1. Response Headers
13.1. 応答ヘッダ
HTTP defines the Location header to indicate a preferred URL for the resource that was addressed in the Request-URI (e.g., in response to successful PUT requests or in redirect responses). However, use of this header creates ambiguity when there are URLs in the body of the response, as with Multi-Status. Thus, use of the Location header with the Multi-Status response is intentionally undefined.
HTTPは、Request-URI(例えば、うまくいっているPUT要求に対応した再直接の応答における)で扱われたリソースのために都合のよいURLを示すためにLocationヘッダーを定義します。 しかしながら、URLが応答のボディーにあるとき、このヘッダーの使用はMulti-状態のようにあいまいさを作成します。 したがって、Multi-状態応答によるLocationヘッダーの使用は故意に未定義です。
Dusseault Standards Track [Page 80] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[80ページ]。
13.2. Handling Redirected Child Resources
13.2. 取り扱いは子供リソースを向け直しました。
Redirect responses (300-303, 305, and 307) defined in HTTP 1.1 normally take a Location header to indicate the new URI for the single resource redirected from the Request-URI. Multi-Status responses contain many resource addresses, but the original definition in [RFC2518] did not have any place for the server to provide the new URI for redirected resources. This specification does define a 'location' element for this information (see Section 14.9). Servers MUST use this new element with redirect responses in Multi-Status.
通常、HTTP1.1で定義された再直接の応答(300-303、305、および307)は、Request-URIから向け直されたただ一つのリソースのために新しいURIを示すためにLocationヘッダーを連れて行きます。 マルチStatus応答は多くのリソースアドレスを含んでいますが、[RFC2518]とのオリジナルの定義には、サーバが新しいURIを向け直されたリソースに提供するどんな場所もありませんでした。 この仕様はこの情報のために'位置'要素を定義します(セクション14.9を見てください)。 サーバはMulti-状態の再直接の応答と共にこの新しい要素を使用しなければなりません。
Clients encountering redirected resources in Multi-Status MUST NOT rely on the 'location' element being present with a new URI. If the element is not present, the client MAY reissue the request to the individual redirected resource, because the response to that request can be redirected with a Location header containing the new URI.
Multi-状態で向け直されたリソースに遭遇するクライアントは新しいURIについて存在している'位置'要素を当てにしてはいけません。 要素が存在していないなら、クライアントは個々の向け直されたリソースに要求を再発行するかもしれません、Locationヘッダーが新しいURIを含んでいてその要求への応答を向け直すことができるので。
13.3. Internal Status Codes
13.3. 内部のステータスコード
Sections 9.2.1, 9.1.2, 9.6.1, 9.8.3, and 9.9.2 define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses.
セクション9.2 .1 9.1 .2 9.6 .1、9.8、.3、9.9に、.2はMulti-状態応答に使用される様々なステータスコードを定義します。 この仕様はこれらの応答に現れることができた他のステータスコードの意味を定義しません。
14. XML Element Definitions
14. XML要素定義
In this section, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). Note that all of the elements defined here may be extended according to the rules defined in Section 17. All elements defined here are in the "DAV:" namespace.
このセクションでは、それぞれのセクションの最終的な系列は、[REC-XML]で定義された書式を使用することで要素型の宣言をします。 「値」分野は、XML要素の許容できるコンテンツで存在しているところでBNF(すなわち、さらにPCDATA要素の値を制限する)を使用することでさらなる制限を指定します。 セクション17で定義された規則に従ってここで定義された要素のすべてが広げられるかもしれないことに注意してください。 中にここで定義されたすべての要素がある、「DAV:」 名前空間。
14.1. activelock XML Element
14.1. activelock XML Element
Name: activelock
以下を命名してください。 activelock
Purpose: Describes a lock on a resource.
目的: リソースで錠について説明します。
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?, lockroot)>
<!ELEMENT activelock(lockscope、locktype、深さ、所有者?、タイムアウト?、locktoken?、lockroot)>。
Dusseault Standards Track [Page 81] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[81ページ]。
14.2. allprop XML Element
14.2. allprop XML Element
Name: allprop
以下を命名してください。 allprop
Purpose: Specifies that all names and values of dead properties and the live properties defined by this document existing on the resource are to be returned.
目的: リソースに存在するこのドキュメントによって定義された死んでいる特性と精力の特性のすべての名前と値が返されることであると指定します。
<!ELEMENT allprop EMPTY >
<!ELEMENT allprop EMPTY>。
14.3. collection XML Element
14.3. 収集XML Element
Name: collection
以下を命名してください。 収集
Purpose: Identifies the associated resource as a collection. The DAV:resourcetype property of a collection resource MUST contain this element. It is normally empty but extensions may add sub- elements.
目的: 関連リソースが収集であると認識します。 DAV: 収集リソースのresourcetypeの特性はこの要素を含まなければなりません。 それは通常空ですが、拡大はサブ要素を加えるかもしれません。
<!ELEMENT collection EMPTY >
<!ELEMENT収集EMPTY>。
14.4. depth XML Element
14.4. 深さXML Element
Name: depth
以下を命名してください。 深さ
Purpose: Used for representing depth values in XML content (e.g., in lock information).
目的: XML内容(例えば、ロック情報の)の深さ値を表すのにおいて、使用されています。
Value: "0" | "1" | "infinity"
値: "0" | "1" | 「無限」
<!ELEMENT depth (#PCDATA) >
<!ELEMENTの深さ(#PCDATA) >。
14.5. error XML Element
14.5. 誤りXML Element
Name: error
以下を命名してください。 誤り
Purpose: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. In these cases, servers MAY return an XML response body with a document element of 'error', containing child elements identifying particular condition codes.
目的: 誤り応答(特に403Forbiddenと409Conflict)は、何が支障をきたしたかを示すために時々詳しい情報を必要とします。 これらの場合では、サーバは'誤り'のドキュメント要素でXML応答ボディーを返すかもしれません、特定の条件コードを特定する子供要素を含んでいて。
Description: Contains at least one XML element, and MUST NOT contain text or mixed content. Any element that is a child of the 'error' element is considered to be a precondition or postcondition code. Unrecognized elements MUST be ignored.
記述: テキストを含んではいけない、少なくとも1つのXML要素を含んで、さもなければ、内容を混ぜました。 '誤り'要素の子供であるどんな要素も前提条件かpostconditionコードであると考えられます。 認識されていない要素を無視しなければなりません。
<!ELEMENT error ANY >
<!ELEMENT誤りいずれも>。
Dusseault Standards Track [Page 82] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[82ページ]。
14.6. exclusive XML Element
14.6. 排他的なXML Element
Name: exclusive
以下を命名してください。 排他的
Purpose: Specifies an exclusive lock.
目的: 排他的な錠を指定します。
<!ELEMENT exclusive EMPTY >
<!のELEMENTの排他的なEMPTY>。
14.7. href XML Element
14.7. href XML Element
Name: href
以下を命名してください。 href
Purpose: MUST contain a URI or a relative reference.
目的: URIか相対参照を含まなければなりません。
Description: There may be limits on the value of 'href' depending on the context of its use. Refer to the specification text where 'href' is used to see what limitations apply in each case.
記述: 限界が使用の文脈による'href'の値にあるかもしれません。 'href'がどんな制限がその都度適用されるかを確認するのに使用される仕様テキストを参照してください。
Value: Simple-ref
値: 純真な審判
<!ELEMENT href (#PCDATA)>
<!ELEMENT href(#PCDATA)>。
14.8. include XML Element
14.8. XML Elementを含めてください。
Name: include
以下を命名してください。 インクルード
Purpose: Any child element represents the name of a property to be included in the PROPFIND response. All elements inside an 'include' XML element MUST define properties related to the resource, although possible property names are in no way limited to those property names defined in this document or other standards. This element MUST NOT contain text or mixed content.
目的: どんな子供要素も、PROPFIND応答に含まれるように特性の名前を表します。 '包含'XML要素におけるすべての要素がリソースに関連する特性を定義しなければなりません、可能な特性の名は本書では定義されたそれらの特性の名か他の規格に決して制限されませんが。 テキストを含んではいけない、さもなければ、この要素は内容を混ぜました。
<!ELEMENT include ANY >
<!ELEMENTはどんな>も含んでいます。
14.9. location XML Element
14.9. 位置のXML Element
Name: location
以下を命名してください。 位置
Purpose: HTTP defines the "Location" header (see [RFC2616], Section 14.30) for use with some status codes (such as 201 and the 300 series codes). When these codes are used inside a 'multistatus' element, the 'location' element can be used to provide the accompanying Location header value.
目的: HTTPは使用のために、いくつかのステータスコード(201や300のシリーズコードなどの)で「位置」ヘッダー([RFC2616]を見てください、セクション14.30)を定義します。 これらのコードが'「マルチ-状態」'要素の中で使用されるとき、付随のLocationヘッダー価値を提供するのに'位置'要素を使用できます。
Dusseault Standards Track [Page 83] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[83ページ]。
Description: Contains a single href element with the same value that would be used in a Location header.
記述: Locationヘッダーで使用される同じ値に従ったただ一つのhref要素に、含んでいます。
<!ELEMENT location (href)>
<!ELEMENT位置(href)>。
14.10. lockentry XML Element
14.10. lockentry XML Element
Name: lockentry
以下を命名してください。 lockentry
Purpose: Defines the types of locks that can be used with the resource.
目的: リソースと共に使用できる錠のタイプを定義します。
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockentry(lockscope、locktype) >。
14.11. lockinfo XML Element
14.11. lockinfo XML Element
Name: lockinfo
以下を命名してください。 lockinfo
Purpose: The 'lockinfo' XML element is used with a LOCK method to specify the type of lock the client wishes to have created.
目的: 'lockinfo'XML要素はクライアントが作成したがっていた錠のタイプを指定するLOCKメソッドで使用されます。
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT lockinfo(lockscope、locktype、所有者)? >。
14.12. lockroot XML Element
14.12. lockroot XML Element
Name: lockroot
以下を命名してください。 lockroot
Purpose: Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request.
目的: 錠の根のURLを含んでいます。(錠はリソースがLOCK要求で扱われたURLです)。
Description: The href element contains the root of the lock. The server SHOULD include this in all DAV:lockdiscovery property values and the response to LOCK requests.
記述: href要素は錠の根を含んでいます。 サーバSHOULDはすべてのDAVにこれを含んでいます: lockdiscovery特性の値とLOCK要求への応答。
<!ELEMENT lockroot (href) >
<!ELEMENT lockroot(href) >。
14.13. lockscope XML Element
14.13. lockscope XML Element
Name: lockscope
以下を命名してください。 lockscope
Purpose: Specifies whether a lock is an exclusive lock, or a shared lock.
目的: 錠が排他的な錠、または共有された錠であるかを指定します。
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT lockscope(排他的|、共有、) >。
Dusseault Standards Track [Page 84] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[84ページ]。
14.14. locktoken XML Element
14.14. locktoken XML Element
Name: locktoken
以下を命名してください。 locktoken
Purpose: The lock token associated with a lock.
目的: 錠に関連しているロックトークン。
Description: The href contains a single lock token URI, which refers to the lock.
記述: hrefはただ一つのロックトークンURIを含んでいます。(それは、錠について言及します)。
<!ELEMENT locktoken (href) >
<!ELEMENT locktoken(href) >。
14.15. locktype XML Element
14.15. locktype XML Element
Name: locktype
以下を命名してください。 locktype
Purpose: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.
目的: 錠のアクセス型を指定します。 現在のところこの仕様が1つのロックタイプしか定義しない、錠を書いてください。
<!ELEMENT locktype (write) >
<!ELEMENT locktype(書きます) >。
14.16. multistatus XML Element
14.16. multistatus XML Element
Name: multistatus
以下を命名してください。 「マルチ-状態」
Purpose: Contains multiple response messages.
目的: 複数の応答メッセージを含んでいます。
Description: The 'responsedescription' element at the top level is used to provide a general message describing the overarching nature of the response. If this value is available, an application may use it instead of presenting the individual response descriptions contained within the responses.
記述: トップレベルにおける'responsedescription'要素は、応答のアーチをかける本質について説明する一般的なメッセージを提供するのに使用されます。 この値が利用可能であるなら、応答の中に含まれた個々の応答記述を提示することの代わりにアプリケーションはそれを使用するかもしれません。
<!ELEMENT multistatus (response*, responsedescription?) >
<!ELEMENT multistatus(応答*、responsedescription)? >。
14.17. owner XML Element
14.17. 所有者XML Element
Name: owner
以下を命名してください。 所有者
Purpose: Holds client-supplied information about the creator of a lock.
目的: 船倉は錠のクリエイターの情報をクライアントと同じくらい提供しました。
Description: Allows a client to provide information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL
記述: クライアントが直接、元本(電話番号かメールURIなどの)に連絡するか、または主体を発見するのに十分な情報を提供するのを許容する、(URLなど
Dusseault Standards Track [Page 85] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[85ページ]。
of a homepage) who created a lock. The value provided MUST be treated as a dead property in terms of XML Information Item preservation. The server MUST NOT alter the value unless the owner value provided by the client is empty. For a certain amount of interoperability between different client implementations, if clients have URI-formatted contact information for the lock creator suitable for user display, then clients SHOULD put those URIs in 'href' child elements of the 'owner' element.
ホームページ) 錠を作成した。 XML情報Item保存で死んでいる特性として提供された値を扱わなければなりません。 クライアントによって提供された所有者値が空でない場合、サーバは値を変更してはいけません。 異なったクライアント実装の間のある量の相互運用性のために、クライアントがロッククリエイターへのURIでフォーマットされた問い合わせ先をユーザディスプレイに適するようにするなら、クライアントSHOULDは'所有者'要素の'href'子供要素にそれらのURIを入れます。
Extensibility: MAY be extended with child elements, mixed content, text content or attributes.
伸展性: 子供要素、複雑な内容、テキスト内容または属性で広げられるかもしれません。
<!ELEMENT owner ANY >
<!ELEMENT所有者いずれも>。
14.18. prop XML Element
14.18. 支柱XML Element
Name: prop
以下を命名してください。 支柱
Purpose: Contains properties related to a resource.
目的: リソースに関連する特性を含んでいます。
Description: A generic container for properties defined on resources. All elements inside a 'prop' XML element MUST define properties related to the resource, although possible property names are in no way limited to those property names defined in this document or other standards. This element MUST NOT contain text or mixed content.
記述: リソースで定義された特性のためのジェネリックコンテナ。 '支柱'XML要素におけるすべての要素がリソースに関連する特性を定義しなければなりません、可能な特性の名は本書では定義されたそれらの特性の名か他の規格に決して制限されませんが。 テキストを含んではいけない、さもなければ、この要素は内容を混ぜました。
<!ELEMENT prop ANY >
<!ELEMENTはどんな>も支えます。
14.19. propertyupdate XML Element
14.19. propertyupdate XML Element
Name: propertyupdate
以下を命名してください。 propertyupdate
Purpose: Contains a request to alter the properties on a resource.
目的: リソースに特性を変更するという要求を含んでいます。
Description: This XML element is a container for the information required to modify the properties on the resource.
記述: このXML要素はリソースの特性を変更するのに必要である情報のためのコンテナです。
<!ELEMENT propertyupdate (remove | set)+ >
<!ELEMENT propertyupdate(取り外してください| セットする)+>。
14.20. propfind XML Element
14.20. propfind XML Element
Name: propfind
以下を命名してください。 propfind
Dusseault Standards Track [Page 86] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[86ページ]。
Purpose: Specifies the properties to be returned from a PROPFIND method. Four special elements are specified for use with 'propfind': 'prop', 'allprop', 'include', and 'propname'. If 'prop' is used inside 'propfind', it MUST NOT contain property values.
目的: PROPFINDメソッドから返される資産を指定します。 4つの特別な要素が'propfind'との使用に指定されます: '支柱'、'allprop'は'''propnameを含んでいます'。 '支柱'が'propfind'で使用されるなら、それは特性の値を含んではいけません。
<!ELEMENT propfind ( propname | (allprop, include?) | prop ) >
<!ELEMENT propfind(propname| (allprop、インクルード?)| 支柱) >。
14.21. propname XML Element
14.21. propname XML Element
Name: propname
以下を命名してください。 propname
Purpose: Specifies that only a list of property names on the resource is to be returned.
目的: リソースに関する特性の名の唯一のリストが返されることであると指定します。
<!ELEMENT propname EMPTY >
<!ELEMENT propname EMPTY>。
14.22. propstat XML Element
14.22. propstat XML Element
Name: propstat
以下を命名してください。 propstat
Purpose: Groups together a prop and status element that is associated with a particular 'href' element.
目的: 特定の'href'要素に関連していた状態で支柱と状態要素を一緒に分類します。
Description: The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies. The optional precondition/ postcondition element and 'responsedescription' text also apply to the properties named in 'prop'.
記述: propstat XML要素は1つの支柱XML要素と1つの状態XML要素を含まなければなりません。 支柱XML要素のコンテンツは状態要素の結果が適用される特性の名前を記載するだけでよいです。 また、任意の前提条件/postcondition要素と'responsedescription'テキストは'支柱'で指定された特性に適用されます。
<!ELEMENT propstat (prop, status, error?, responsedescription?) >
<!ELEMENT propstat(支柱、状態、誤り?、responsedescription)? >。
14.23. remove XML Element
14.23. XML Elementを取り外してください。
Name: remove
以下を命名してください。 取り外してください。
Purpose: Lists the properties to be removed from a resource.
目的: リソースから取り除くために特性を記載します。
Description: Remove instructs that the properties specified in prop should be removed. Specifying the removal of a property that does not exist is not an error. All the XML elements in a 'prop' XML element inside of a 'remove' XML element MUST be empty, as only the names of properties to be removed are required.
記述: 取り外してください。支柱で指定された資産が取り外されるべきであるよう命令します。 存在しない特性の取り外しを指定するのは、誤りではありません。 '取り外してください'XML要素の'支柱'XML要素内部のすべてのXML要素が空であるに違いありません、取り除かれるべき特性の名前だけが必要であるように。
<!ELEMENT remove (prop) >
ELEMENTが取り外す<!(支柱) >。
Dusseault Standards Track [Page 87] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[87ページ]。
14.24. response XML Element
14.24. 応答XML Element
Name: response
以下を命名してください。 応答
Purpose: Holds a single response describing the effect of a method on resource and/or its properties.
目的: メソッドの効果をリソース、そして/または、所有地に説明するただ一つの応答を保持します。
Description: The 'href' element contains an HTTP URL pointing to a WebDAV resource when used in the 'response' container. A particular 'href' value MUST NOT appear more than once as the child of a 'response' XML element under a 'multistatus' XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by 'href'. There are, however, no requirements regarding ordering based on 'href' values. The optional precondition/postcondition element and 'responsedescription' text can provide additional information about this resource relative to the request or result.
記述: 'href'要素は'応答'コンテナで使用されるとWebDAVリソースを示すHTTP URLを含んでいます。 特定の'href'値は'応答'XML要素の子供として'「マルチ-状態」'XML要素の下で一度より多く見えてはいけません。 この要件が、直線的な時間への応答のためにコストを処理し続けるのに必要です。 本質的には、これは、'href'によるすべての応答を一緒に分類するために探さなければならないのを防ぎます。 しかしながら、'href'値に基づく注文に関する要件が全くありません。 任意の前提条件/postcondition要素と'responsedescription'テキストは要求か結果に比例してこのリソースに関する追加情報を提供できます。
<!ELEMENT response (href, ((href*, status)|(propstat+)), error?, responsedescription? , location?) >
<!ELEMENT応答(href、(href*、状態)|(propstat+))、誤り?、responsedescription? , 位置?) >。
14.25. responsedescription XML Element
14.25. responsedescription XML Element
Name: responsedescription
以下を命名してください。 responsedescription
Purpose: Contains information about a status response within a Multi-Status.
目的: Multi-状態の中に状態応答の情報を含んでいます。
Description: Provides information suitable to be presented to a user.
記述: ユーザに提示されるのにおいて適当な情報を提供します。
<!ELEMENT responsedescription (#PCDATA) >
<!ELEMENT responsedescription(#PCDATA) >。
14.26. set XML Element
14.26. XML Elementを設定してください。
Name: set
以下を命名してください。 セットします。
Purpose: Lists the property values to be set for a resource.
目的: 特性がリソースに設定されるために評価するリスト。
Description: The 'set' element MUST contain only a 'prop' element. The elements contained by the 'prop' element inside the 'set' element MUST specify the name and value of properties that are set on the resource identified by Request-URI. If a property already exists, then its value is replaced. Language tagging information appearing in the scope of the 'prop' element (in the "xml:lang"
記述: 'セット'要素は'支柱'要素だけを含まなければなりません。 'セット'要素の中に'支柱'要素によって含まれた要素はRequest-URIによって特定されたリソースに設定される属性の名前と価値を指定しなければなりません。 特性が既に存在しているなら、値を取り替えます。 中、'支柱'要素の範囲に現れる言語タグ付け情報、(「xml: lang」
Dusseault Standards Track [Page 88] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[88ページ]。
attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND.
属性存在しているなら 特性と共に持続して保存しなければならなくて、次に回収可能な使用PROPFINDは保存するに違いありませんか?
<!ELEMENT set (prop) >
ELEMENTが設定する<!(支柱) >。
14.27. shared XML Element
14.27. 共有されたXML Element
Name: shared
以下を命名してください。 共有されます。
Purpose: Specifies a shared lock.
目的: 共有された錠を指定します。
<!ELEMENT shared EMPTY >
<!ELEMENTはEMPTY>を共有しました。
14.28. status XML Element
14.28. 状態XML Element
Name: status
以下を命名してください。 状態
Purpose: Holds a single HTTP status-line.
目的: 1HTTP状況表示行を保持します。
Value: status-line (defined in Section 6.1 of [RFC2616])
値: 状況表示行([RFC2616]のセクション6.1では、定義されます)
<!ELEMENT status (#PCDATA) >
<!ELEMENT状態(#PCDATA) >。
14.29. timeout XML Element
14.29. タイムアウトXML Element
Name: timeout
以下を命名してください。 タイムアウト
Purpose: The number of seconds remaining before a lock expires.
目的: 錠の前に残っている秒数は期限が切れます。
Value: TimeType (defined in Section 10.7)
値: TimeType(セクション10.7では、定義されます)
<!ELEMENT timeout (#PCDATA) >
<!ELEMENTタイムアウト(#PCDATA) >。
14.30. write XML Element
14.30. XML Elementに書いてください。
Name: write
以下を命名してください。 書いてください。
Purpose: Specifies a write lock.
目的: 指定、aは錠を書きます。
<!ELEMENT write EMPTY >
ELEMENTがEMPTY>に書く<!
Dusseault Standards Track [Page 89] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[89ページ]。
15. DAV Properties
15. 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要素の値を制限する)を使用することでさらなる制限を指定します。
A protected property is one that cannot be changed with a PROPPATCH request. There may be other requests that would result in a change to a protected property (as when a LOCK request affects the value of DAV:lockdiscovery). Note that a given property could be protected on one type of resource, but not protected on another type of resource.
保護された特性はPROPPATCH要求に従って変えることができないものです。 保護された特性(LOCK要求がDAV: lockdiscoveryの値に影響する時としての)への変化をもたらす他の要求があるかもしれません。 与えられた特性はリソースの1つのタイプの上に保護されましたが、別のタイプに関するリソースに保護できなかったことに注意してください。
A computed property is one with a value defined in terms of a computation (based on the content and other properties of that resource, or even of some other resource). A computed property is always a protected property.
計算された特性は計算(そのリソース、またはある他のリソースさえの内容と他の特性に基づいている)で値が定義されている1です。 いつも計算された特性は保護された特性です。
COPY and MOVE behavior refers to local COPY and MOVE operations.
COPYとMOVEの振舞いは地方のCOPYとMOVE操作について言及します。
For properties defined based on HTTP GET response headers (DAV:get*), the header value could include LWS as defined in [RFC2616], Section 4.2. Server implementors SHOULD strip LWS from these values before using as WebDAV property values.
HTTP GET応答ヘッダ(DAV: *を手に入れてください)に基づいて定義された特性には、ヘッダー値は[RFC2616](セクション4.2)で定義されるようにLWSを含むかもしれません。 WebDAVとして特性の値を使用する前に、サーバ作成者SHOULDはこれらの値からLWSを剥取ります。
15.1. creationdate Property
15.1. creationdate Property
Name: creationdate
以下を命名してください。 creationdate
Purpose: Records the time and date the resource was created.
目的: リソースが作成された日時を記録します。
Value: date-time (defined in [RFC3339], see the ABNF in Section 5.6.)
値: 日付-時間([RFC3339]で定義されていて、セクション5.6でABNFを見てください。)
Protected: MAY be protected. Some servers allow DAV:creationdate to be changed to reflect the time the document was created if that is more meaningful to the user (rather than the time it was uploaded). Thus, clients SHOULD NOT use this property in synchronization logic (use DAV:getetag instead).
保護される: 保護されるかもしれません。 いくつかのサーバで、DAV: creationdateは、ユーザ(それがアップロードされた時よりむしろ)には、それが、より重要であるならドキュメントが作成されたとき反射するために変化します。 したがって、クライアントSHOULD NOTは同期論理にこの特性を使用します(代わりにDAV: getetagを使用してください)。
COPY/MOVE behavior: This property value SHOULD be kept during a MOVE operation, but is normally re-initialized when a resource is created with a COPY. It should not be set in a COPY.
COPY/MOVEの振舞い: この資産価値SHOULDはMOVE操作の間保たれますが、リソースがCOPYと共に作成されるとき、通常、再初期化されます。 COPYにそれを設定するべきではありません。
Dusseault Standards Track [Page 90] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[90ページ]。
Description: The DAV:creationdate property SHOULD be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created. Servers that are incapable of persistently recording the creation date SHOULD instead leave it undefined (i.e. report "Not Found").
記述: DAV: creationdateの特性のSHOULD、すべてのDAV対応することのリソースで定義されてください。 リソースが作成されたとき、存在しているなら、それは現在のタイムスタンプを含んでいます。 未定義の状態でSHOULDが代わりに残す作成日付を持続して記録できないサーバ(すなわち、「見つけられない」というレポート)。
<!ELEMENT creationdate (#PCDATA) >
<!ELEMENT creationdate(#PCDATA) >。
15.2. displayname Property
15.2. displayname Property
Name: displayname
以下を命名してください。 displayname
Purpose: Provides a name for the resource that is suitable for presentation to a user.
目的: ユーザにとって、プレゼンテーションに適したリソースに名前を提供します。
Value: Any text.
値: どんなテキスト。
Protected: SHOULD NOT be protected. Note that servers implementing [RFC2518] might have made this a protected property as this is a new requirement.
保護される: SHOULD NOT、保護されてください。 [RFC2518]を実装するサーバがこれが新しい要件であるのでこれを保護された特性にしたかもしれないことに注意してください。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
COPY/MOVEの振舞い: この資産価値SHOULD、COPYとMOVE操作では、保存されてください。
Description: Contains a description of the resource that is suitable for presentation to a user. This property is defined on the resource, and hence SHOULD have the same value independent of the Request-URI used to retrieve it (thus, computing this property based on the Request-URI is deprecated). While generic clients might display the property value to end users, client UI designers must understand that the method for identifying resources is still the URL. Changes to DAV:displayname do not issue moves or copies to the server, but simply change a piece of meta-data on the individual resource. Two resources can have the same DAV: displayname value even within the same collection.
記述: ユーザにとって、プレゼンテーションに適したリソースの記述を含んでいます。 この特性はリソースで定義されます、そして、したがって、SHOULDには、それを検索するのに使用されるRequest-URIの如何にかかわらず同じ値があります(その結果、Request-URIに基づくこの特性を計算するのは推奨しないです)。 ジェネリッククライアントはエンドユーザに資産価値を表示するかもしれませんが、クライアントUIデザイナーは、それでも、リソースを特定するためのメソッドがURLであることを理解しなければなりません。 DAV: displaynameへの変化は移動かコピーをサーバに発行しませんが、単に個々のリソースに関する1つのメタデータを変えてください。 2つのリソースが同じDAVを持つことができます: 同じ収集の中のdisplayname値さえ。
<!ELEMENT displayname (#PCDATA) >
<!ELEMENT displayname(#PCDATA) >。
15.3. getcontentlanguage Property
15.3. getcontentlanguage Property
Name: getcontentlanguage
以下を命名してください。 getcontentlanguage
Purpose: Contains the Content-Language header value (from Section 14.12 of [RFC2616]) as it would be returned by a GET without accept headers.
目的: それがGETによって返されるようにContent-言語ヘッダー価値([RFC2616]のセクション14.12からの)を含んでいる、ヘッダーを受け入れてください。
Value: language-tag (language-tag is defined in Section 3.10 of [RFC2616])
値: 言語タグ(言語タグは[RFC2616]のセクション3.10で定義されます)
Dusseault Standards Track [Page 91] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[91ページ]。
Protected: SHOULD NOT be protected, so that clients can reset the language. Note that servers implementing [RFC2518] might have made this a protected property as this is a new requirement.
保護される: SHOULD NOTが保護されて、したがって、そのクライアントは言語をリセットできます。 [RFC2518]を実装するサーバがこれが新しい要件であるのでこれを保護された特性にしたかもしれないことに注意してください。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
COPY/MOVEの振舞い: この資産価値SHOULD、COPYとMOVE操作では、保存されてください。
Description: The DAV:getcontentlanguage property MUST be defined on any DAV-compliant resource that returns the Content-Language header on a GET.
記述: DAV: GETの上のContent-言語ヘッダーを返すどんなDAV対応することのリソースでもgetcontentlanguageの特性を定義しなければなりません。
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlanguage(#PCDATA) >。
15.4. getcontentlength Property
15.4. getcontentlength Property
Name: getcontentlength
以下を命名してください。 getcontentlength
Purpose: Contains the Content-Length header returned by a GET without accept headers.
目的: 含有、Content-長さはヘッダーがa GETで戻ったヘッダーを受け入れます。
Value: See Section 14.13 of [RFC2616].
値: [RFC2616]のセクション14.13を見てください。
Protected: This property is computed, therefore protected.
保護される: この特性は、計算されて、したがって、保護されます。
Description: The DAV:getcontentlength property MUST be defined on any DAV-compliant resource that returns the Content-Length header in response to a GET.
記述: DAV: GETに対応してContent-長さのヘッダーを返すどんなDAV対応することのリソースでもgetcontentlengthの特性を定義しなければなりません。
COPY/MOVE behavior: This property value is dependent on the size of the destination resource, not the value of the property on the source resource.
COPY/MOVEの振舞い: この資産価値はソースリソースの属性の価値ではなく、目的地リソースのサイズに依存しています。
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontentlength(#PCDATA) >。
15.5. getcontenttype Property
15.5. getcontenttype Property
Name: getcontenttype
以下を命名してください。 getcontenttype
Purpose: Contains the Content-Type header value (from Section 14.17 of [RFC2616]) as it would be returned by a GET without accept headers.
目的: それがGETによって返されるようにコンテントタイプヘッダー価値([RFC2616]のセクション14.17からの)を含んでいる、ヘッダーを受け入れてください。
Value: media-type (defined in Section 3.7 of [RFC2616])
値: メディアタイプ([RFC2616]のセクション3.7では、定義されます)
Protected: Potentially protected if the server prefers to assign content types on its own (see also discussion in Section 9.7.1).
保護される: サーバが、それ自身のものにcontent typeを割り当てるのを好むなら(また、セクション9.7.1における議論を見てください)、潜在的に保護されています。
Dusseault Standards Track [Page 92] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[92ページ]。
COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations.
COPY/MOVEの振舞い: この資産価値SHOULD、COPYとMOVE操作では、保存されてください。
Description: This property MUST be defined on any DAV-compliant resource that returns the Content-Type header in response to a GET.
記述: GETに対応してコンテントタイプヘッダーを返すどんなDAV対応することのリソースでもこの特性を定義しなければなりません。
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getcontenttype(#PCDATA) >。
15.6. getetag Property
15.6. getetag Property
Name: getetag
以下を命名してください。 getetag
Purpose: Contains the ETag header value (from Section 14.19 of [RFC2616]) as it would be returned by a GET without accept headers.
目的: それがGETによって返されるようにETagヘッダー価値([RFC2616]のセクション14.19からの)を含んでいる、ヘッダーを受け入れてください。
Value: entity-tag (defined in Section 3.11 of [RFC2616])
値: 実体タグ([RFC2616]のセクション3.11では、定義されます)
Protected: MUST be protected because this value is created and controlled by the server.
保護される: この値がサーバによって作成されて、制御されるので、保護しなければなりません。
COPY/MOVE behavior: This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. Also note the considerations in Section 8.8.
COPY/MOVEの振舞い: この資産価値はソースリソースの属性の価値ではなく、目的地リソースの最終的な状態に依存しています。 また、セクション8.8の問題に注意してください。
Description: The getetag property MUST be defined on any DAV- compliant resource that returns the Etag header. Refer to Section 3.11 of RFC 2616 for a complete definition of the semantics of an ETag, and to Section 8.6 for a discussion of ETags in WebDAV.
記述: Etagヘッダーを返すどんなDAV対応することのリソースでもgetetagの特性を定義しなければなりません。 ETagの意味論の完全な定義と、WebDAVでのETagsの議論のためのセクション8.6をRFC2616のセクション3.11を参照してください。
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getetag(#PCDATA) >。
15.7. getlastmodified Property
15.7. getlastmodified Property
Name: getlastmodified
以下を命名してください。 getlastmodifiedしました。
Purpose: Contains the Last-Modified header value (from Section 14.29 of [RFC2616]) as it would be returned by a GET method without accept headers.
目的: GETメソッドでそれを返すように最終更新日ヘッダー価値([RFC2616]のセクション14.29からの)を含んでいる、ヘッダーを受け入れてください。
Value: rfc1123-date (defined in Section 3.3.1 of [RFC2616])
値: rfc1123-日付(.1セクション3.3[RFC2616]では、定義されます)
Protected: SHOULD be protected because some clients may rely on the value for appropriate caching behavior, or on the value of the Last-Modified header to which this property is linked.
保護される: SHOULD、何人かのクライアントが適切なキャッシュの振舞いか、この特性が繋がっている最終更新日ヘッダーの値の上の値を当てにするかもしれないので、保護されてください。
Dusseault Standards Track [Page 93] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[93ページ]。
COPY/MOVE behavior: This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this can be preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Note that since [RFC2616] requires clients to use ETags where provided, a server implementing ETags can count on clients using a much better mechanism than modification dates for offline synchronization or cache control. Also note the considerations in Section 8.8.
COPY/MOVEの振舞い: この資産価値はソースリソースの属性の価値ではなく、目的地リソースの最後に変更された期日に依存しています。 いくつかのサーバ実装がファイルシステム日付を使用するというメモはDAVのために値を変更しました: 値をgetlastmodifiedしました、そして、HTTP最終更新日値のSHOULDが変化さえするとき、MOVEにこれを保存できます。 [RFC2616]が、クライアントが提供されているところでETagsを使用するのを必要とするのでETagsを実装するサーバがオフライン同期かキャッシュ制御の変更日付よりはるかに良いメカニズムを使用することでクライアントを頼りにすることができることに注意してください。 また、セクション8.8の問題に注意してください。
Description: The last-modified date on a resource SHOULD only reflect changes in the body (the GET responses) of the resource. A change in a property only SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body. The DAV: getlastmodified property MUST be defined on any DAV-compliant resource that returns the Last-Modified header in response to a GET.
記述: SHOULDが反映するだけであるリソースに関する最後変更された期日はリソースのボディー(GET応答)で変化します。 クライアントが最後変更された期日にいつ既存のボディーを上書きするかを知るために当てにするかもしれないのでSHOULD NOTだけが最後変更された期日に変えさせる資産における変化。 DAV: GETに対応して最終更新日ヘッダーを返すどんなDAV対応することのリソースでもgetlastmodified特性を定義しなければなりません。
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT getlastmodified(#PCDATA) >。
15.8. lockdiscovery Property
15.8. lockdiscovery Property
Name: lockdiscovery
以下を命名してください。 lockdiscovery
Purpose: Describes the active locks on a resource
目的: リソースでアクティブな錠について説明します。
Protected: MUST be protected. Clients change the list of locks through LOCK and UNLOCK, not through PROPPATCH.
保護される: 保護しなければなりません。 クライアントはPROPPATCHを通して変えるのではなく、LOCKとUNLOCKを通して錠のリストを変えます。
COPY/MOVE behavior: The value of this property depends on the lock state of the destination, not on the locks of the source resource. Recall that locks are not moved in a MOVE operation.
COPY/MOVEの振舞い: この属性の価値はソースリソースの錠ではなく、目的地のロック状態に依存します。 錠がMOVE操作で動かされていないと思い出してください。
Description: Returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. Owner information MAY be omitted if it is considered sensitive. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there are one or more locks, an 'activelock' element appears for each lock on the resource. This property is NOT lockable with respect to write locks (Section 7).
記述: タイムアウト、および関連ロックトークンに残りながら、だれが錠を持つかに関するリスト、彼がどんなタイプの錠を持っているか、そして、タイムアウトタイプ、および時間を返します。 それが敏感であると考えられるなら、所有者情報は省略されるかもしれません。 錠が全くありませんが、サーバが錠を支えると、特性は、存在していますが、'activelock'要素を全く含まないでしょう。 1個以上の錠があれば、'activelock'要素はリソースの各錠の弁護に出廷します。 この特性がロックできない、錠(セクション7)を書いてください。
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT lockdiscovery(activelock)*>。
Dusseault Standards Track [Page 94] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[94ページ]。
15.8.1. Example - Retrieving DAV:lockdiscovery
15.8.1. 例--DAV: lockdiscoveryを検索すること。
>>Request
>>要求
PROPFIND /container/ HTTP/1.1 Host: www.example.com Content-Length: xxxx Content-Type: application/xml; charset="utf-8"
PROPFIND/コンテナ/HTTP/1.1ホスト: www.example.com Content-長さ: xxxxコンテントタイプ: アプリケーション/xml。 charset=「utf8インチ」
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D='DAV:'> <D:prop><D:lockdiscovery/></D:prop> </D:propfind>
<?xmlバージョンは「1インチのコード化は「utf-8インチ?><D:propfind xmlns:D='DAVと等しいです: '><D: ><D: lockdiscovery/></Dを支えてください: ></D: propfind>を支えてください'」と等しいです。
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D='DAV:'> <D:response> <D:href>http://www.example.com/container/</D:href> <D:propstat> <D:prop> <D:lockdiscovery> <D:activelock> <D:locktype><D:write/></D:locktype> <D:lockscope><D:exclusive/></D:lockscope> <D:depth>0</D:depth> <D:owner>Jane Smith</D:owner> <D:timeout>Infinite</D:timeout> <D:locktoken> <D:href >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href> </D:locktoken> <D:lockroot> <D:href>http://www.example.com/container/</D:href> </D:lockroot> </D:activelock> </D:lockdiscovery> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
<?xmlバージョン=「1インチコード化=「utf-8インチ?><D:multistatus xmlns:Dは'DAV:'><D: 応答><Dと等しいです: href>http://www.example'」; com/container/</D: href><D: propstat><D: 支柱><D: lockdiscovery><D: activelock><D: locktype><D: /></D: locktype><D: lockscope><D: 排他的な/></D: lockscope><にD: 深さ>0</Dを書いてください:; 深さ><D: 所有者>ジェーンスミス</D: 所有者><D: タイムアウト>Infinite</D: タイムアウト><D: locktoken><D: href>つぼ: uuid: f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D: href></D: locktoken><D: lockroot><D: href>http://www; example.com/container/</D: href></D: lockroot></D: activelock></D: lockdiscovery></D: ><D: 状態>HTTP/1.1 200OK</D: 状態></D: propstat></D: 応答></D: 「マルチ-状態」>を支えてください。
Dusseault Standards Track [Page 95] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[95ページ]。
This resource has a single exclusive write lock on it, with an infinite timeout.
このリソースでシングルは排他的になります。それに無限のタイムアウトで錠を書いてください。
15.9. resourcetype Property
15.9. resourcetype Property
Name: resourcetype
以下を命名してください。 resourcetype
Purpose: Specifies the nature of the resource.
目的: リソースの本質を指定します。
Protected: SHOULD be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), not by PROPPATCH.
保護される: SHOULD、保護されてください。 一般に、リソースタイプはPROPPATCHで決められるのではなく、リソース(MKCOL対PUT)を作成する操作で決められます。
COPY/MOVE behavior: Generally a COPY/MOVE of a resource results in the same type of resource at the destination.
COPY/MOVEの振舞い: 一般にリソースのCOPY/MOVEは目的地で同じタイプに関するリソースをもたらします。
Description: MUST be defined on all DAV-compliant resources. Each child element identifies a specific type the resource belongs to, such as 'collection', which is the only resource type defined by this specification (see Section 14.3). If the element contains the 'collection' child element plus additional unrecognized elements, it should generally be treated as a collection. If the element contains no recognized child elements, it should be treated as a non-collection resource. The default value is empty. This element MUST NOT contain text or mixed content. Any custom child element is considered to be an identifier for a resource type.
記述: すべてのDAV対応することのリソースで定義しなければなりません。 それぞれの子供要素はリソースがものである特定のタイプを特定します、'収集'などのように(セクション14.3を見てください)。(それは、タイプがこの仕様で定義した唯一のリソースです)。 要素が'収集'子供要素と追加認識されていない要素を含んでいるなら、一般に、それは収集として扱われるべきです。 要素が認識された子供要素を全く含んでいないなら、それは非収集リソースとして扱われるべきです。 デフォルト値は空です。 テキストを含んではいけない、さもなければ、この要素は内容を混ぜました。 どんなカスタム子供要素もリソースタイプへの識別子であると考えられます。
Example: (fictional example to show extensibility)
例: (伸展性を示している作り事の例)
<x:resourcetype xmlns:x="DAV:"> <x:collection/> <f:search-results xmlns:f="http://www.example.com/ns"/> </x:resourcetype>
<x:resourcetype xmlns:xが等しい、「DAV: 「><x: 収集/><f: 検索結果xmlns: fは" http://www.example.com/ns "/></x: resourcetype>と等しいです」。
15.10. supportedlock Property
15.10. supportedlock Property
Name: supportedlock
以下を命名してください。 supportedlock
Purpose: To provide a listing of the lock capabilities supported by the resource.
目的: リソースによってサポートされたロック能力のリストを提供するために。
Protected: MUST be protected. Servers, not clients, determine what lock mechanisms are supported.
保護される: 保護しなければなりません。 クライアントではなく、サーバが、どんなロックメカニズムがサポートされるかを決定します。
Dusseault Standards Track [Page 96] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[96ページ]。
COPY/MOVE behavior: This property value is dependent on the kind of locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at the destination.
COPY/MOVEの振舞い: この資産価値はソースリソースにおける属性の価値ではなく、目的地で支えられた錠の種類に依存しています。 目的地へのCOPYに試みられるサーバは、目的地にこの特性を設定するのを試みるべきではありません。
Description: Returns a listing of the combinations of scope and access types that may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls, so a server is not required to provide information the client is not authorized to see. This property is NOT lockable with respect to write locks (Section 7).
記述: リソースに関するロック要求で指定されるかもしれない範囲とアクセス型の組み合わせのリストを返します。 サーバはクライアントが見るのに権限を与えられないという情報を提供するのに必要でないように実際の内容がアクセス制御から制御されることに注意してください。 この特性がロックできない、錠(セクション7)を書いてください。
<!ELEMENT supportedlock (lockentry)* >
<!ELEMENT supportedlock(lockentry)*>。
15.10.1. Example - Retrieving DAV:supportedlock
15.10.1. 例--DAV: supportedlockを検索すること。
>>Request
>>要求
PROPFIND /container/ HTTP/1.1 Host: www.example.com Content-Length: xxxx Content-Type: application/xml; charset="utf-8"
PROPFIND/コンテナ/HTTP/1.1ホスト: www.example.com Content-長さ: xxxxコンテントタイプ: アプリケーション/xml。 charset=「utf8インチ」
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:prop><D:supportedlock/></D:prop> </D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV: 「><D: ><D: supportedlock/></Dを支えてください: ></D: propfind>を支えてください」
>>Response
>>応答
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.example.com/container/</D:href> <D:propstat> <D:prop> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope>
com/container/</D: href><D: propstat><D: ><D: supportedlock><D: lockentry><D: lockscope><D: 排他的な/></D: lockscope><D: locktype><Dを支えてください: : 共有された/></D: /></D: locktype></D: lockentry><D: lockentry><D: lockscope><D lockscope @に書いてください?br />
Dusseault Standards Track [Page 97] RFC 4918 WebDAV June 2007
<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>
16. 前提条件/Postcondition XML Elements
16. Precondition/Postcondition XML Elements
セクション8.7で導入するように、多くの状態応答のボディーにエラー条件に関するその他の情報を含むことができます。 このセクションは、誤りボディーメカニズムの使用のときに要件を作って、多くの前提条件とpostconditionコードを紹介します。
As introduced in Section 8.7, extra information on error conditions can be included in the body of many status responses. This section makes requirements on the use of the error body mechanism and introduces a number of precondition and postcondition codes.
メソッドの「前提条件」はその実行されるべきメソッドに、正しいに違いないサーバの事情について説明します。 メソッドの"postcondition"はそのメソッドが完成した後に正しいに違いないサーバの事情について説明します。
A "precondition" of a method describes the state of the server that must be true for that method to be performed. A "postcondition" of a method describes the state of the server that must be true after that method has been completed.
Each precondition and postcondition has a unique XML element associated with it. In a 207 Multi-Status response, the XML element MUST appear inside an 'error' element in the appropriate 'propstat or 'response' element depending on whether the condition applies to one or more properties or to the resource as a whole. In all other error responses where this specification's 'error' body is used, the precondition/postcondition XML element MUST be returned as the child of a top-level 'error' element in the response body, unless otherwise negotiated by the request, along with an appropriate response status. The most common response status codes are 403 (Forbidden) if the request should not be repeated because it will always fail, and 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. The 'error' element MAY contain child elements with specific error information and MAY be extended with any custom child elements.
各前提条件とpostconditionには、それに関連しているユニークなXML要素があります。 207Multi-状態応答では、XML要素は適切な'propstatか状態が1つ以上の特性、または、全体でリソースに適用されるかどうかに依存する'応答'要素'の'誤り'要素の中に現れなければなりません。 他のすべての誤り応答では、この仕様の'誤り'ボディーが使用されているところに、トップレベル'誤り'要素の子供として応答本体で前提条件/postcondition XML要素を返さなければなりません、別の方法で要求で交渉されない場合、適切な応答状態と共に。 ユーザが対立を解決して、要求を再提出できるかもしれないと予想されるなら要求がいつも失敗するので繰り返されるのと409(闘争)でないなら、最も一般的な応答ステータスコードは403(禁じられる)です。 '誤り'要素は、特定のエラー情報で子供要素を含んでいて、どんなカスタム子供要素でも敷衍されるかもしれません。
This mechanism does not take the place of using a correct numeric status code as defined here or in HTTP, because the client must always be able to take a reasonable course of action based only on the numeric code. However, it does remove the need to define new numeric codes. The new machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions, so naturally, any group defining a new condition code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups.
このメカニズムはここかHTTPで定義されるように正しい数値ステータスコードを使用する代わりをしません、クライアントがいつも数字コードだけに基づく合理的な行動を取ることができなければならないので。 しかしながら、それは新しい数字コードを定義する必要性を取り除きます。 このために使用される新しい機械可読コードが前提条件とpostconditionsとして分類されたXML要素であるので、当然、新しい条件コードを定義するどんなグループもそれら自身の名前空間を使用できます。 いつものように、「DAV:」 名前空間は使用のためにIETF貸し切りのWebDAVワーキンググループによって予約されます。
Dusseault Standards Track [Page 98] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[98ページ]。
A server supporting this specification SHOULD use the XML error whenever a precondition or postcondition defined in this document is violated. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank. However, a server MAY instead use a custom condition code and other supporting text, because even when clients do not automatically recognize condition codes, they can be quite useful in interoperability testing and debugging.
本書では定義された前提条件かpostconditionが違反されるときはいつも、この仕様SHOULD使用がXML誤りであるとサポートするサーバ。 本書では指定されなかったエラー条件のために、サーバは、単に適切な数値状態を選んで、応答本体を空白の状態でおくかもしれません。 しかしながら、サーバは代わりにカスタム条件コードと他のサポートテキストを使用するかもしれません、クライアントが自動的に条件コードを認めないときさえ、それらが相互運用性テストとデバッグでかなり役に立つ場合があるので。
Example - Response with precondition code
例--前提条件コードによる応答
>>Response
>>応答
HTTP/1.1 423 Locked Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
HTTP/1.1 423はコンテントタイプをロックしました: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:lock-token-submitted> <D:href>/workspace/webdav/</D:href> </D:lock-token-submitted> </D:error>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 誤りxmlns: Dが等しい、「DAV: 「><D: ロックトークンで提出された><D: href>/workspace/webdav/</D: href></D: ロックトークンで提出された></D: 誤り>」
In this example, a client unaware of a depth-infinity lock on the parent collection "/workspace/webdav/" attempted to modify the collection member "/workspace/webdav/proposal.doc".
この例では、親収集"/workspace/webdav/"の深さ無限錠に気づかないクライアントは、収集メンバー"/workspace/webdav/proposal.doc"を変更するのを試みました。
Some other useful preconditions and postconditions have been defined in other specifications extending WebDAV, such as [RFC3744] (see particularly Section 7.1.1), [RFC3253], and [RFC3648].
ある他の役に立つ前提条件とpostconditionsはWebDAVを広げる他の仕様に基づき定義されました、[RFC3744](特にセクション7.1.1を見る)や、[RFC3253]や、[RFC3648]などのように。
All these elements are in the "DAV:" namespace. If not specified otherwise, the content for each condition's XML element is defined to be empty.
これらのすべての要素がある、「DAV:」 名前空間。 別の方法で指定されないなら、各状態のXML要素のための内容は、空になるように定義されます。
Name: lock-token-matches-request-uri
以下を命名してください。 ロックトークンマッチはuriを要求します。
Use with: 409 Conflict
以下がある使用 409 闘争
Purpose: (precondition) -- A request may include a Lock-Token header to identify a lock for the UNLOCK method. However, if the Request-URI does not fall within the scope of the lock identified by the token, the server SHOULD use this error. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.
目的: (前提条件) -- 要求は、UNLOCKメソッドのために錠を特定するためにLock-トークンヘッダーを含むかもしれません。 しかしながら、Request-URIがトークンによって特定された錠の範囲の中に下がらないなら、サーバSHOULDはこの誤りを使用します。 錠にはRequest-URIを含んでいない範囲があるかもしれませんか、錠が見えなくなったかもしれませんか、またはトークンは無効であるかもしれません。
Dusseault Standards Track [Page 99] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[99ページ]。
Name: lock-token-submitted (precondition)
以下を命名してください。 ロックトークンは提出されました。(前提条件)
Use with: 423 Locked
以下がある使用 423はロックされました。
Purpose: The request could not succeed because a lock token should have been submitted. This element, if present, MUST contain at least one URL of a locked resource that prevented the request. In cases of MOVE, COPY, and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource made the request fail -- but the server is only responsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all.
目的: 要求は、ロックトークンを提出するべきであったので、成功できませんでした。 存在しているなら、この要素は要求を防いだロックされたリソースの少なくとも1つのURLを含まなければなりません。 収集錠がかかわるMOVE、COPY、およびDELETEの場合では、クライアントが、どれがリソースをロックしたかが要求に失敗されたのを見つけるのが、難しい場合がありますが、サーバは単にそのようなリソースのロックされた1つを返すのに原因となります。 サーバはそれらを皆、知っているなら要求が成功するのを防いだあらゆるロックされたリソースを返すかもしれません。
<!ELEMENT lock-token-submitted (href+) >
提出された<!ELEMENTロックトークン(href+) >。
Name: no-conflicting-lock (precondition)
以下を命名してください。 闘争錠がありません。(前提条件)
Use with: Typically 423 Locked
以下がある使用 通常、423はロックされました。
Purpose: A LOCK request failed due the presence of an already existing conflicting lock. Note that a lock can be in conflict although the resource to which the request was directed is only indirectly locked. In this case, the precondition code can be used to inform the client about the resource that is the root of the conflicting lock, avoiding a separate lookup of the "lockdiscovery" property.
目的: LOCK要求は既に既存の闘争の存在がロックする支払われるべきものに失敗しました。 要求が向けられたリソースが間接的にロックされるだけですが、錠が闘争中であることができることに注意してください。 この場合、闘争錠の根であるリソースに関してクライアントに知らせるのに前提条件コードを使用できます、"lockdiscovery"の特性の別々のルックアップを避けて。
<!ELEMENT no-conflicting-lock (href)* >
<!ELEMENT闘争していないロック(href)*>。
Name: no-external-entities
以下を命名してください。 外部実体がありません。
Use with: 403 Forbidden
以下がある使用 禁じられた403
Purpose: (precondition) -- If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error.
目的: (前提条件) -- 要求本体が外部実体を含んでいるのでサーバがクライアント要求を拒絶するなら、サーバSHOULDはこの誤りを使用します。
Name: preserved-live-properties
以下を命名してください。 保存された精力の特性
Use with: 409 Conflict
以下がある使用 409 闘争
Purpose: (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server
目的: (postcondition) -- サーバがそうでなければ、有効なMOVEを受けたか、COPYは同じ振舞いが目的地にある精力の特性を要求しますが、維持できません。 多分、サーバ
Dusseault Standards Track [Page 100] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[100ページ]。
only supports some live properties in some parts of the repository, or simply has an internal error.
倉庫の数個の一部のいくつかの精力の特性を支えるか、または単に内部エラーを持っているだけです。
Name: propfind-finite-depth
以下を命名してください。 propfindの有限深さ
Use with: 403 Forbidden
以下がある使用 禁じられた403
Purpose: (precondition) -- This server does not allow infinite-depth PROPFIND requests on collections.
目的: (前提条件) -- このサーバは収集に関する無限の深さPROPFIND要求を許しません。
Name: cannot-modify-protected-property
以下を命名してください。 保護された特性を変更できません。
Use with: 403 Forbidden
以下がある使用 禁じられた403
Purpose: (precondition) -- The client attempted to set a protected property in a PROPPATCH (such as DAV:getetag). See also [RFC3253], Section 3.12.
目的: (前提条件) -- クライアントは、PROPPATCH(DAV: getetagなどの)に保護された特性をはめ込むのを試みました。 また、[RFC3253]、セクション3.12を見てください。
17. XML Extensibility in DAV
17. DAVのXML伸展性
The XML namespace extension ([REC-XML-NAMES]) is used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the "DAV:" namespace SHOULD NOT be used in the request or response body unless that XML element is explicitly defined in an IETF RFC reviewed by a WebDAV working group.
XML名前空間拡張子([REC-XML-NAMES])は、新しいXML要素が他の要素名と衝突することへの恐怖なしで加えられるのを許容するのにこの仕様で使用されます。 WebDAV要求と応答本体を任意のXML要素で広げることができますが、中でメッセージ受取人、XML要素でどれを無視できるか、「DAV:」 名前空間SHOULD NOT、そのXML要素がWebDAVワーキンググループによって見直されたIETF RFCで明らかに定義されない場合、要求か応答本体で使用されてください。
For WebDAV to be both extensible and backwards-compatible, both clients and servers need to know how to behave when unexpected or unrecognized command extensions are received. For XML processing, this means that clients and servers MUST process received XML documents as if unexpected elements and attributes (and all children of unrecognized elements) were not there. An unexpected element or attribute includes one that may be used in another context but is not expected here. Ignoring such items for purposes of processing can of course be consistent with logging all information or presenting for debugging.
WebDAVは広げることができて、かつ後方に互換性があるように、クライアントとサーバの両方が、予期していなかったか認識されていないコマンド拡大が受け取られているとき、振る舞う方法を知る必要があります。 XML処理のために、まるで予期していなかった要素と属性(そして、認識されていない要素のすべての子供)がないかのようにクライアントとサーバが処理しなければならないこの手段はXMLドキュメントを受け取りました。 予期していなかった要素か属性が別の文脈で使用されるかもしれませんが、ここで期待されないものを含んでいます。 処理の目的のためにそのような項目を無視するのはもちろんデバッグのためのすべての情報を登録するか、提示と一致している場合があります。
This restriction also applies to the processing, by clients, of DAV property values where unexpected XML elements SHOULD be ignored unless the property's schema declares otherwise.
また、この制限は処理に適用されます、クライアントでDAVでは、特性はどこの予期していなかったXML要素SHOULDを評価するか。特性の図式が別の方法で宣言しない場合、無視されます。
This restriction does not apply to setting dead DAV properties on the server where the server MUST record all XML elements.
この制限はサーバがすべてのXML要素を記録しなければならないサーバの死んでいるDAVの特性を設定するのに適用されません。
Dusseault Standards Track [Page 101] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[101ページ]。
Additionally, this restriction does not apply to the use of XML where XML happens to be the content type of the entity body, for example, when used as the body of a PUT.
さらに、PUTのボディーとして使用される場合、この制限は、例えば、実体本体のcontent typeであることをXMLが起こるXMLの使用に適用しません。
Processing instructions in XML SHOULD be ignored by recipients. Thus, specifications extending WebDAV SHOULD NOT use processing instructions to define normative behavior.
XML SHOULDでの指示を処理して、受取人によって無視されてください。 したがって、WebDAV SHOULDを広げる仕様は、標準の振舞いを定義するのに処理命令を使用しません。
XML DTD fragments are included for all the XML elements defined in this specification. However, correct XML will not be valid according to any DTD due to namespace usage and extension rules. In particular:
XML DTD断片はこの仕様に基づき定義されたすべてのXML要素のために含まれています。 しかしながら、どんなDTDに応じても、正しいXMLは名前空間用法と拡大規則で有効にならないでしょう。 特に:
o Elements (from this specification) are in the "DAV:" namespace,
o 要素(この仕様からの)がある、「DAV:」 名前空間
o Element ordering is irrelevant unless otherwise stated,
o 別の方法で述べられない場合、要素注文は無関係です。
o Extension attributes MAY be added,
o 拡大属性は加えられるかもしれません。
o For element type definitions of "ANY", the normative text definition for that element defines what can be in it and what that means.
o 「いずれ」の要素型定義のために、その要素のための標準のテキスト定義は、何がそれにあることができるか、そして、それが何を意味するかを定義します。
o For element type definitions of "#PCDATA", extension elements MUST NOT be added.
o 「」 #PCDATAの要素型定義」において、拡大要素を加えてはいけません。
o For other element type definitions, including "EMPTY", extension elements MAY be added.
o 他の要素型定義において、「空になってください」を含んでいて、拡大要素は加えられるかもしれません。
Note that this means that elements containing elements cannot be extended to contain text, and vice versa.
これが、テキストを含むように要素を含む要素について敷衍できないことを意味することに注意してください、そして、逆もまた同様です。
With DTD validation relaxed by the rules above, the constraints described by the DTD fragments are normative (see for example Appendix A). A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD.
規則によって伸びやかなDTD合法化が上であることで、DTD断片によって説明された規制は規範的です(例えばAppendix Aを見てください)。 どんな一生懸命コード化されたかダイナミックに宣言しているDTDに従っても、XMLボディーがあるWebDAVメッセージの受取人はXMLドキュメントを有効にしてはいけません。
Note that this section describes backwards-compatible extensibility rules. There might also be times when an extension is designed not to be backwards-compatible, for example, defining an extension that reuses an XML element defined in this document but omitting one of the child elements required by the DTDs in this specification.
このセクションが後方にコンパチブル伸展性規則について説明することに注意してください。 また、拡大が例えば、本書では定義されたXML要素を再利用する拡大を定義しながら後方に互換性がないように設計される回があるかもしれませんが、子供要素の1つを省略するのがDTDがこの仕様で必要です。
Dusseault Standards Track [Page 102] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[102ページ]。
18. DAV Compliance Classes
18. DAV承諾クラス
A DAV-compliant resource can advertise several classes of compliance. A client can discover the compliance classes of a resource by executing OPTIONS on the resource and examining the "DAV" header which is returned. Note particularly that resources, rather than servers, are spoken of as being compliant. That is because theoretically some resources on a server could support different feature sets. For example, a server could have a sub-repository where an advanced feature like versioning was supported, even if that feature was not supported on all sub-repositories.
DAV対応することのリソースは数人のクラスのコンプライアンスの広告を出すことができます。 クライアントは、リソースでOPTIONSを実行して、返される"DAV"ヘッダーを調べることによって、リソースの承諾クラスを発見できます。 リソースが言いなりになるとしてサーバよりむしろ話されることに特に注意してください。 それは理論的にサーバに関するいくつかのリソースが異なった特徴セットを支えるかもしれないからです。 例えば、サーバはversioningするような高度な特徴がサポートされたサブ倉庫を持っているかもしれません、その特徴がすべてのサブ倉庫の上でサポートされなかったとしても。
Since this document describes extensions to the HTTP/1.1 protocol, minimally all DAV-compliant resources, clients, and proxies MUST be compliant with [RFC2616].
このドキュメントがHTTP/1.1プロトコルに拡大について説明するので、最少量でDAV対応することのリソース、クライアント、およびプロキシは[RFC2616]と共に言いなりになっているに違いありません。
A resource that is class 2 or class 3 compliant must also be class 1 compliant.
また、クラス2かクラス3対応であるリソースもクラス1対応するに違いありません。
18.1. Class 1
18.1. クラス1
A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document.
クラス1対応することのリソースはこのドキュメントのすべてのセクションのすべての“MUST"必要条件を満たさなければなりません。
Class 1 compliant resources MUST return, at minimum, the value "1" in the DAV header on all responses to the OPTIONS method.
クラスの1の対応するリソースは「オプションメソッドへのすべての応答でのDAVヘッダーの1インチ」で最小限、値で戻らなければなりません。
18.2. Class 2
18.2. クラス2
A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the DAV:supportedlock property, the DAV: lockdiscovery property, the Time-Out response header and the Lock- Token request header. A class 2 compliant resource SHOULD also support the Timeout request header and the 'owner' XML element.
クラスの2の対応するリソースは、すべてのクラス1必要条件を満たして、LOCKメソッド、DAV: supportedlockの特性、DAVをサポートしなければなりません: lockdiscoveryの特性、外のTime応答ヘッダ、およびLockトークンはヘッダーを要求します。 またSHOULDがTimeout要求ヘッダーと'所有者'XML要素を支えるクラス2対応することのリソース。
Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.
クラスの2の対応するリソースは戻らなければなりません、最小限で、値、「1インチと「オプションメソッドへのすべての応答でのDAVヘッダーの2インチ。」
18.3. Class 3
18.3. クラス3
A resource can explicitly advertise its support for the revisions to [RFC2518] made in this document. Class 1 MUST be supported as well. Class 2 MAY be supported. Advertising class 3 support in addition to class 1 and 2 means that the server supports all the requirements in this specification. Advertising class 3 and class 1 support, but not class 2, means that the server supports all the requirements in this specification except possibly those that involve locking support.
リソースは明らかに本書では作られた[RFC2518]に改正のサポートの広告を出すことができます。 また、クラス1をサポートしなければなりません。 クラス2はサポートされるかもしれません。 クラス1と2に加えた広告クラス3サポートは、サーバがこの仕様によるすべての要件をサポートすることを意味します。 クラス2ではなく、広告クラス3とクラス1サポートが、サーバがことによるとサポートをロックすることを伴うもの以外のこの仕様によるすべての要件をサポートすることを意味します。
Dusseault Standards Track [Page 103] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[103ページ]。
Example:
例:
DAV: 1, 3
DAV: 1, 3
19. Internationalization Considerations
19. 国際化問題
In the realm of internationalization, this specification complies with the IETF Character Set Policy [RFC2277]. In this specification, human-readable fields can be found either in the value of a property, or in an error message returned in a response entity body. In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [RFC3629] and UTF-16 [RFC2781] encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header (defined in [RFC3023]), as well as XML charset declarations.
国際化の分野では、この仕様がIETF文字コードPolicy[RFC2277]に従います。 この仕様では、属性の価値、または応答実体本体で返されたエラーメッセージで人間読み込み可能な分野を見つけることができます。 どちらの場合も、人間読み込み可能な内容は、XMLを使用することでコード化されて、XMLプロセッサが最小限でコード化された要素をXMLに読み込むのを必要とします、ISOの10646の多言語飛行機のUTF-8[RFC3629]とUTF-16[RFC2781]encodingsを使用して。XMLは文字集合タグ付けとコード化のための明示の条項を持っています。 この仕様によるXMLの例はコンテントタイプヘッダー([RFC3023]では、定義される)のcharsetパラメタの使用を示します、XML charset宣言と同様に。
XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. The "xml:lang" attribute appears on an XML element to identify the language of its content and attributes. See [REC-XML] for definitions of values and scoping.
また、XMLは特定のXML要素のコンテンツの言語を指定するのに言語タグ付け能力を提供します。 「xml: lang」属性はその内容と属性の言語を特定するXML要素の上に現れます。 値と見ることの定義に関して[REC-XML]を見てください。
WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. Implementors of WebDAV applications are strongly encouraged to read "XML Media Types" [RFC3023] for instruction on which MIME media type to use for XML transport, and on use of the charset parameter of the Content-Type header.
WebDAVアプリケーションは文字集合タグ付け、文字集合コード化、および言語タグ付けにXML仕様の機能性をサポートしなければなりません。 WebDAVアプリケーションの作成者がMIMEメディアがXMLに輸送を使用するためにタイプされる指示と、コンテントタイプヘッダーのcharsetパラメタの使用の上の「XMLメディアタイプ」[RFC3023]を読むよう強く奨励されます。
Names used within this specification fall into four categories: names of protocol elements such as methods and headers, names of XML elements, names of properties, and names of conditions. Naming of protocol elements follows the precedent of HTTP, using English names encoded in US-ASCII for methods and headers. Since these protocol elements are not visible to users, and are simply long token identifiers, they do not need to support multiple languages. Similarly, the names of XML elements used in this specification are not visible to the user and hence do not need to support multiple languages.
この仕様の中で中古の名前は4つのカテゴリになります: メソッドやヘッダーなどのプロトコル要素の名前、XML要素の名前、特性の名前、および状態の名前。 メソッドとヘッダーに米国-ASCIIでコード化されたイギリスの名前を使用して、プロトコル要素の命名はHTTPの先例に従います。 これらのプロトコル要素がユーザにとって目に見えないで、単に長いトークン識別子であるので、それらは複数の言語をサポートする必要はありません。 同様に、この仕様で使用されるXML要素の名前は、ユーザにとって目に見えないで、したがって、複数の言語をサポートする必要はありません。
WebDAV property names are qualified XML names (pairs of XML namespace name and local name). Although some applications (e.g., a generic property viewer) will display property names directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name and namespace to a human-readable field when displaying the property name
WebDAV特性の名は適切なXML名(組のXML名前空間名と地方名)です。 いくつかのアプリケーション(例えば、ジェネリック特性のビューアー)が直接彼らのユーザに特性の名を表示するでしょうが、特性の名を表示するとき、主用途が固定セットの特性を使用して、特性の名と名前空間から人間読み込み可能な分野までマッピングを提供すると予想されます。
Dusseault Standards Track [Page 104] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[104ページ]。
to a user. It is only in the case where the set of properties is not known ahead of time that an application need display a property name to a user. We recommend that applications provide human-readable property names wherever feasible.
ユーザに。 特性のセットが早めに知られていない場合だけでは、アプリケーションは特性の名をユーザに表示しなければなりません。 私たちは、アプリケーションが人間読み込み可能な特性の名をどこでも、可能であるところに提供することを勧めます。
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が現場情報を必要としないので、この仕様はこの情報の伝達にどんなメカニズムも指定しません。
20. Security Considerations
20. セキュリティ問題
This section is provided to detail issues concerning security implications of which WebDAV applications need to be aware.
WebDAVアプリケーションが意識している必要があるセキュリティ含意に関してこのセクションを詳細問題に提供します。
All of the security considerations of HTTP/1.1 (discussed in [RFC2616]) and XML (discussed in [RFC3023]) also apply to WebDAV. In addition, the security risks inherent in remote authoring require stronger authentication technology, introduce several new privacy concerns, and may increase the hazards from poor server design. These issues are detailed below.
また、HTTP/1.1([RFC2616]では、議論する)とXML([RFC3023]では、議論する)のセキュリティ問題のすべてがWebDAVに適用されます。 さらに、リモートオーサリングに固有のセキュリティリスクは、より強い認証技術を必要として、いくつかの新しいプライバシーの問題を紹介して、貧しいサーバデザインから危険を増強するかもしれません。 これらの問題は以下で詳細です。
20.1. Authentication of Clients
20.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 a Basic authentication challenge in a WWW-Authenticate header unless the connection is secure. An example of a secure connection would be a Transport Layer Security (TLS) connection employing a strong cipher suite and server authentication.
パスワードは、不安定なチャンネルの上に明確なことがパスワードが傍受されるかもしれないのでリソースのアクセシビリティと保全を保護するための不十分な手段であることを送りました。 HTTP/1.1のためのBasic認証がパスワードの本質的には明確なテキスト伝送を実行するので、接続が安全でない場合、WebDAVクライアントをサーバに認証するのにBasic認証を使用してはいけません。 aはヘッダーをWWW認証します。その上、WebDAVサーバがBasic認証挑戦を送ってはいけない、接続が安全でない場合。 安全な接続に関する例は堅固な暗号スイートとサーバ証明を使うTransport Layer Security(TLS)接続でしょう。
Dusseault Standards Track [Page 105] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[105ページ]。
WebDAV applications MUST support the Digest authentication scheme [RFC2617]. Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication that is useful in a wide range of scenarios.
WebDAVアプリケーションは、Digest認証が体系[RFC2617]であるとサポートしなければなりません。 Digest認証が、コミュニケーションへの双方が共有秘密キー、パスワードを知っていることを確かめるので、その秘密を送る必要はなくて、明確なDigest認証はさまざまなシナリオで役に立つ認証のレベルを提供している間、Basic認証の固有である警備上の問題を避けます。
20.2. Denial of Service
20.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はシステムのリソースのあらゆる部分でサービス不能攻撃を可能にします。
o The underlying storage can be attacked by PUTting extremely large files.
o PUTtingは基本的なストレージを攻撃できます。非常に大きいファイル。
o Asking for recursive operations on large collections can attack processing time.
o 大きい収集のときに再帰的な操作を求めるのは攻撃処理時間がそうすることができます。
o Making multiple pipelined requests on multiple connections can attack network connections.
o 複数の接続に関する複数のpipelined要求をすると、ネットワーク接続を攻撃できます。
WebDAV servers need to be aware of the possibility of a denial-of- service attack at all levels. The proper response to such an attack MAY be to simply drop the connection. Or, if the server is able to make a response, the server MAY use a 400-level status request such as 400 (Bad Request) and indicate why the request was refused (a 500- level status response would indicate that the problem is with the server, whereas unintentional DoS attacks are something the client is capable of remedying).
WebDAVサーバは、否定の可能性を意識している必要があります。-サービスでは、レベルを全く攻撃してください。 そのような攻撃への適切な応答は単に接続を下げることであるかもしれません。 または、サーバが応答をすることができるなら、サーバは、400(悪いRequest)などの400レベルの状態要求を使用して、要求がなぜ拒否されたかを(500の平らな状態応答は、問題がサーバであるのを示すでしょうが、意図的でないDoS攻撃はクライアントが治すことができる何かです)示すかもしれません。
20.3. Security through Obscurity
20.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サーバのユーザがそれらのリソース名の相対的な不鮮明によるよりむしろリソースへの求められていないアクセスを防ぐのにアクセス制御方法を使用するよう奨励されます。
20.4. Privacy Issues Connected to Locks
20.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 DAV: lockdiscovery property on the resource, and can be used by other
また、ロック要求を提出するとき、ユーザエージェントは錠(人がロボットよりむしろ錠を取り出しているそれらのケースのための)を取り出す人のために問い合わせ先を与える'所有者'XML分野を提出するかもしれません。 この問い合わせ先はDAVに保存されます: リソースで特性をlockdiscoveryして、もう一方は使用できます。
Dusseault Standards Track [Page 106] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[106ページ]。
collaborators to begin negotiation over access to the resource. However, in many cases, this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the DAV:lockdiscovery property as appropriate. Furthermore, user agents SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.
リソースへのアクセスの上で交渉を始める共同制作者。 しかしながら、多くの場合、この問い合わせ先を非常に個人的である場合があり、広く広めるべきではありません。 SHOULDが制限するサーバは適宜DAV: lockdiscoveryの特性へのアクセスを読みます。 その上、ユーザエージェントSHOULDは問い合わせ先を全く送るかどうかと、問い合わせ先を送るかどうかのコントロールを提供します、まさにどんな情報を送るかのコントロール。
20.5. Privacy Issues Connected to Properties
20.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.
特性の値がドキュメントの作者などの情報を保持するのに通常使用されるので、プライバシーの問題がリソースの特性のデータへの広範囲のアクセスに由来しながら起こることができた可能性があります。 特性で個人情報の不注意なリリースの危険を減少させるために、サーバは、そんなに別々の制御機構がリソース本体へのアクセスを読み込むアクセスを開発して、リソースの特性へのアクセスを読むよう奨励されます。 これで、アクセスをリソースのコンテンツにひどく制限しないで、ユーザはそれらの特性のデータの普及を制御できます。
20.6. Implications of XML Entities
20.6. XML実体の含意
XML supports a facility known as "external entities", defined in Section 4.2.2 of [REC-XML], which instructs an XML processor to retrieve and include additional XML. An external XML entity can be used to append or modify the document type declaration (DTD) associated with an XML document. An external XML entity can also be used to include XML within the content of an XML document. For non- validating XML, such as the XML used in this specification, including an external XML entity is not required by XML. However, XML does state that an XML processor may, at its discretion, include the external XML entity.
XMLは追加XMLを検索して、含むようにXMLプロセッサを命令する.2セクション4.2[REC-XML]で定義された「外部実体」として知られている施設をサポートします。 XMLドキュメントに関連しているドキュメント型の宣言(DTD)を追加するか、または変更するのに外部のXML実体を使用できます。 また、XMLドキュメントの中身の中にXMLを含むのに外部のXML実体を使用できます。 この仕様で使用されるXMLなどの非有効にしているXMLに関しては、外部のXML実体を含んでいるのはXMLによって必要とされません。 しかしながら、XMLは、XMLプロセッサが自己判断で外部のXML実体を含むかもしれないと述べます。
External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case, significantly modifying its semantics or exposing the XML processor to the security risks discussed in [RFC3023]. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy. If a server chooses not to handle external XML entities, it SHOULD respond to requests containing external entities with the 'no-external-entities' condition code.
外部のXML実体は、どんな固有の信頼できることも持たないで、どんなHTTP GET要求に風土病であるすべての攻撃も受けることがあります。 その上、外部のXML実体がDTDを変更して、したがって、XMLドキュメントの最終形態に影響するのは、可能です、最悪の場合には、[RFC3023]で議論したセキュリティ危険に意味論をかなり変更するか、またはXMLプロセッサを暴露して。 したがって、implementersは外部のXML実体が信頼できないとして扱われるべきであるのを意識しているに違いありません。 サーバが、そうしないのを選ぶなら、外部のXML実体を扱ってください、それ。'外部実体がありません'条件コードがある外部実体を含んでいて、SHOULDは要求に応じます。
There is also the scalability risk that would accompany a widely deployed application that made use of external XML entities. In this situation, it is possible that there would be significant numbers of requests for one external XML entity, potentially overloading any
また、外部のXML実体を利用した広く配布しているアプリケーションに伴うスケーラビリティリスクがあります。 この状況で、1つの外部のXML実体を求める重要な数の要求があるのは、可能です、潜在的にいずれも積みすぎて
Dusseault Standards Track [Page 107] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[107ページ]。
server that fields requests for the resource containing the external XML entity.
外部のXML実体を含むリソースに関する要求をさばくサーバ。
Furthermore, there's also a risk based on the evaluation of "internal entities" as defined in Section 4.2.2 of [REC-XML]. A small, carefully crafted request using nested internal entities may require enormous amounts of memory and/or processing time to process. Server implementers should be aware of this risk and configure their XML parsers so that requests like these can be detected and rejected as early as possible.
その上、また、.2セクション4.2[REC-XML]で定義されるように「内部の実体」の評価に基づくリスクがあります。 入れ子にされた内部の実体を使用する小さくて、慎重に作られた要求は、処理するために莫大な量のメモリ、そして/または、処理時間を必要とするかもしれません。 サーバimplementersは、できるだけ早くこれらのような要求を検出して、拒絶できるようにこのリスクを意識していて、それらのXMLパーサを構成するはずです。
20.7. Risks Connected with Lock Tokens
20.7. ロックトークンに関連づけられた危険
This specification encourages the use of "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens (Section 6.5), in order to guarantee their uniqueness across space and time. Version 1 UUIDs (defined in Section 4) MAY contain a "node" field that "consists of an IEEE 802 MAC address, usually the host address. For systems with multiple IEEE addresses, any available one can be used". Since a WebDAV server will issue many locks over its lifetime, the implication is that it may also be publicly exposing its IEEE 802 address.
この仕様は「一般にユニークな識別子(UUID)つぼの名前空間」([RFC4122])のロックトークン(セクション6.5)の使用を奨励します、スペースと時間の向こう側にそれらのユニークさを保証するために。 バージョン1UUIDs(セクション4では、定義される)は「IEEE802MACアドレス、通常ホスト・アドレスから成る」「ノード」分野を含むかもしれません。 「複数のIEEEアドレスがあるシステムのために、どんな利用可能な1つも使用できます。」 WebDAVサーバが一生のうちに多くの錠を支給するので、含意はまた、IEEEが802アドレスであると公的に暴露しているかもしれないということです。
There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address:
IEEE802アドレスの暴露に関連しているいくつかのリスクがあります。 IEEE802を使用して、以下を扱ってください。
o It is possible to track the movement of hardware from subnet to subnet.
o ハードウェアのサブネットからサブネットまでの動きを追跡するのは可能です。
o It may be possible to identify the manufacturer of the hardware running a WebDAV server.
o WebDAVサーバを実行するハードウェアのメーカーを特定するのは可能であるかもしれません。
o It may be possible to determine the number of each type of computer running WebDAV.
o WebDAVを実行するそれぞれのタイプのコンピュータの数を測定するのは可能であるかもしれません。
This risk only applies to host-address-based UUID versions. Section 4 of [RFC4122] describes several other mechanisms for generating UUIDs that do not involve the host address and therefore do not suffer from this risk.
この危険はホストアドレスベースのUUIDバージョンに適用されるだけです。 [RFC4122]のセクション4は、ホスト・アドレスにかかわらないで、またしたがってこのリスクが欠点でないUUIDsを生成するために他の数個のメカニズムについて説明します。
20.8. Hosting Malicious Content
20.8. 悪意がある内容をホスティングします。
HTTP has the ability to host programs that are executed on client machines. These programs can take many forms including Web scripts, executables, plug-in modules, and macros in documents. WebDAV does not change any of the security concerns around these programs, yet often WebDAV is used in contexts where a wide range of users can publish documents on a server. The server might not have a close
HTTPはクライアントマシンの上で実行されるホストプログラムに能力を持っています。 これらのプログラムはドキュメントにウェブスクリプト、executables、プラグイン・モジュール、およびマクロを含む多くの形を取ることができます。 WebDAVはこれらのプログラムの周りで安全上の配慮のいずれも変えません、しかし、しばしば、WebDAVがさまざまなユーザがサーバのドキュメントを発表できる文脈で使用されます。サーバには、閉鎖がないかもしれません。
Dusseault Standards Track [Page 108] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[108ページ]。
trust relationship with the author that is publishing the document. Servers that allow clients to publish arbitrary content can usefully implement precautions to check that content published to the server is not harmful to other clients. Servers could do this by techniques such as restricting the types of content that is allowed to be published and running virus and malware detection software on published content. Servers can also mitigate the risk by having appropriate access restriction and authentication of users that are allowed to publish content to the server.
ドキュメントを発表している作者を関係に委託してください。 クライアントが任意の内容を発表できるサーバは、他のクライアントには、サーバに発表された内容が有害でないことをチェックするために有効に注意を実装することができます。 サーバは発行された内容で発行されるのが許容されていて、ウイルスを述べている内容とマルウェア検出ソフトウェアのタイプを制限などなどのテクニックでこれをするかもしれません。 また、サーバは、内容をサーバに発表できるユーザの適切なアクセス制限と認証を持っていることによって、危険を緩和できます。
21. IANA Considerations
21. IANA問題
21.1. New URI Schemes
21.1. 新しいURI体系
This specification defines two URI schemes:
この仕様は2つのURI体系を定義します:
1. the "opaquelocktoken" scheme defined in Appendix C, and
そして1. "opaquelocktoken"体系がAppendixでCを定義した。
2. the "DAV" URI scheme, which historically was used in [RFC2518] to disambiguate WebDAV property and XML element names and which continues to be used for that purpose in this specification and others extending WebDAV. Creation of identifiers in the "DAV:" namespace is controlled by the IETF.
2. "DAV"URI体系。(その体系は、WebDAVの特性とXML要素名のあいまいさを除くのに[RFC2518]で歴史的に使用されて、WebDAVを広げながらそのためにこの仕様と他のもので使用され続けています)。 中の識別子の作成、「DAV:」 名前空間はIETFによって制御されます。
Note that defining new URI schemes for XML namespaces is now discouraged. "DAV:" was defined before standard best practices emerged.
XML名前空間の新しいURI体系を定義するのが現在お勧めできないことに注意してください。 「DAV:」 一般的な最も良い習慣が現れる前に定義されました。
21.2. XML Namespaces
21.2. XML名前空間
XML namespaces disambiguate WebDAV property names and XML elements. Any WebDAV user or application can define a new namespace in order to create custom properties or extend WebDAV XML syntax. IANA does not need to manage such namespaces, property names, or element names.
XML名前空間はWebDAV特性の名とXML要素のあいまいさを除きます。 どんなWebDAVユーザやアプリケーションも、カスタム特性を作成するか、またはWebDAV XML構文を広げるために新しい名前空間を定義できます。 IANAはそのような名前空間、特性の名、または要素名を管理する必要はありません。
21.3. Message Header Fields
21.3. メッセージヘッダーフィールド
The message header fields below should be added to the permanent registry (see [RFC3864]).
以下のメッセージヘッダーフィールドは永久的な登録に加えられるべきです([RFC3864]を見てください)。
21.3.1. DAV
21.3.1. DAV
Header field name: DAV
ヘッダーフィールド名: DAV
Applicable protocol: http
適切なプロトコル: http
Status: standard
状態: 規格
Dusseault Standards Track [Page 109] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[109ページ]。
Author/Change controller: IETF
コントローラを書くか、または変えてください: IETF
Specification document: this specification (Section 10.1)
仕様ドキュメント: この仕様(セクション10.1)
21.3.2. Depth
21.3.2. 深さ
Header field name: Depth
ヘッダーフィールド名: 深さ
Applicable protocol: http
適切なプロトコル: http
Status: standard
状態: 規格
Author/Change controller: IETF
コントローラを書くか、または変えてください: IETF
Specification document: this specification (Section 10.2)
仕様ドキュメント: この仕様(セクション10.2)
21.3.3. Destination
21.3.3. 目的地
Header field name: Destination
ヘッダーフィールド名: 目的地
Applicable protocol: http
適切なプロトコル: http
Status: standard
状態: 規格
Author/Change controller: IETF
コントローラを書くか、または変えてください: IETF
Specification document: this specification (Section 10.3)
仕様ドキュメント: この仕様(セクション10.3)
21.3.4. If
21.3.4. if
Header field name: If
ヘッダーフィールド名: if
Applicable protocol: http
適切なプロトコル: http
Status: standard
状態: 規格
Author/Change controller: IETF
コントローラを書くか、または変えてください: IETF
Specification document: this specification (Section 10.4)
仕様ドキュメント: この仕様(セクション10.4)
21.3.5. Lock-Token
21.3.5. ロックトークン
Header field name: Lock-Token
ヘッダーフィールド名: ロックトークン
Applicable protocol: http
適切なプロトコル: http
Status: standard
状態: 規格
Dusseault Standards Track [Page 110] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[110ページ]。
Author/Change controller: IETF
コントローラを書くか、または変えてください: IETF
Specification document: this specification (Section 10.5)
仕様ドキュメント: この仕様(セクション10.5)
21.3.6. Overwrite
21.3.6. 重ね書き
Header field name: Overwrite
ヘッダーフィールド名: 重ね書き
Applicable protocol: http
適切なプロトコル: http
Status: standard
状態: 規格
Author/Change controller: IETF
コントローラを書くか、または変えてください: IETF
Specification document: this specification (Section 10.6)
仕様ドキュメント: この仕様(セクション10.6)
21.3.7. Timeout
21.3.7. タイムアウト
Header field name: Timeout
ヘッダーフィールド名: タイムアウト
Applicable protocol: http
適切なプロトコル: http
Status: standard
状態: 規格
Author/Change controller: IETF
コントローラを書くか、または変えてください: IETF
Specification document: this specification (Section 10.7)
仕様ドキュメント: この仕様(セクション10.7)
21.4. HTTP Status Codes
21.4. HTTPステータスコード
This specification defines the HTTP status codes
この仕様はHTTPステータスコードを定義します。
o 207 Multi-Status (Section 11.1)
o 207 マルチ状態(セクション11.1)
o 422 Unprocessable Entity (Section 11.2),
o 422は実体(セクション11.2)をUnprocessableします。
o 423 Locked (Section 11.3),
o 423は(セクション11.3)をロックしました。
o 424 Failed Dependency (Section 11.4) and
o そして424が依存に失敗した、(セクション11.4)。
o 507 Insufficient Storage (Section 11.5),
o 507 不十分なストレージ(セクション11.5)
to be updated in the registry at <http://www.iana.org/assignments/http-status-codes>.
<http://www.iana.org/課題/httpステータスコード>での登録でアップデートするために。
Note: the HTTP status code 102 (Processing) has been removed in this specification; its IANA registration should continue to reference RFC 2518.
以下に注意してください。 この仕様でHTTPステータスコード102(処理)を取り除きました。 IANA登録はRFC2518を参照に続けるべきです。
Dusseault Standards Track [Page 111] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[111ページ]。
22. Acknowledgements
22. 承認
A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work.
無感動な無視から重要なレビューと背峰にピアスをするとき、これなどの仕様は繁栄します。 作者は感謝して以下の人々の貢献を承諾します。(人々の洞察は私たちの仕事のあらゆる段階でとても貴重でした)。
Contributors to RFC 2518
RFC2518の貢献者
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; he both helped the formation of the working group and patiently coached the authors along the way. In so many ways he has set high standards that we have toiled to meet. The contributions of Judith Slein were also invaluable; by clarifying the requirements and in patiently reviewing version after version, she both improved this specification and expanded our minds on document management.
このリストからの2は特記に値します。 ラリーMasinterによる貢献は非常に貴重です。 彼は、ワーキンググループの構成を助けて、道に沿って我慢強く作者をコーチしました。 とても多くの方法で、彼は、私たちが疲れさせた高い規格に会うように設定しました。 また、ジュディスSleinの貢献も非常に貴重でした。 要件をはっきりさせて、我慢強く次々とバージョンを見直す際に、彼女は、この仕様を改良して、私たちの心を文書管理に広げました。
We would also like to thank John Turner for developing the XML DTD.
また、XML DTDを開発して頂いて、ジョン・ターナーに感謝申し上げます。
The authors of RFC 2518 were Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter, and D. Jensen. Although their names had to be removed due to IETF author count restrictions, they can take credit for the majority of the design of WebDAV.
RFC2518の作者は、ヤロンGolandと、ジム・ホワイトヘッドと、A.Faiziと、スティーブ・カーターと、D.ジェンセンでした。 IETF作者カウント制限のためそれらの名前を取り除かなければなりませんでしたが、それらはWebDAVのデザインの大部分を自分の手柄にすることができます。
Additional Acknowledgements for This Specification
この仕様のための追加承認
Significant contributors of text for this specification are listed as contributors in the section below. We must also gratefully acknowledge Geoff Clemm, Joel Soderberg, and Dan Brotsky for hashing out specific text on the list or in meetings. Joe Hildebrand and Cullen Jennings helped close many issues. Barry Lind described an additional security consideration and Cullen Jennings provided text
この仕様のためのテキストの重要な貢献者は貢献者として下のセクションで記載されています。 また、私たちは、リストかミーティングにおける特定のテキストをとことん話し合って解決させるために感謝してジェフ・クレム、ジョエル・セーデルベリ、およびダンBrotskyを承認しなければなりません。 ジョー・ヒルデブラントとCullenジョニングスは近くで多くの問題を助けました。 バリー・リンドは追加担保の考慮について説明しました、そして、Cullenジョニングスはテキストを提供しました。
Dusseault Standards Track [Page 112] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[112ページ]。
for that consideration. Jason Crawford tracked issue status for this document for a period of years, followed by Elias Sinderson.
その考慮のために。 ジェイソン・クロフォードはしばらく、このドキュメントのためにエリアスSindersonによって続かれた何年も問題状態を追跡しました。
23. Contributors to This Specification
23. この仕様への貢献者
Julian Reschke <green/>bytes GmbH Hafenweg 16, 48155 Muenster, Germany EMail: julian.reschke@greenbytes.de
Muenster、GmbH Hafenweg16、48155ドイツがメールするジュリアンReschke<緑色/>バイト: julian.reschke@greenbytes.de
Elias Sinderson University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: elias@cse.ucsc.edu
エリアスSindersonカリフォルニア大学、サンタクルスの1156のHigh通り、サンタクルス、カリフォルニア 95064はメールされます: elias@cse.ucsc.edu
Jim Whitehead University of California, Santa Cruz 1156 High Street, Santa Cruz, CA 95064 EMail: ejw@soe.ucsc.edu
ジムホワイトヘッドカリフォルニア大学、サンタクルスの1156のHigh通り、サンタクルス、カリフォルニア 95064はメールされます: ejw@soe.ucsc.edu
24. Authors of RFC 2518
24. RFC2518の作者
Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: yarong@microsoft.com
レッドモンド、ワシントン98052-6399がメールされるY.Y.Golandマイクロソフト社1マイクロソフト方法: yarong@microsoft.com
E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 EMail: ejw@ics.uci.edu
E.J.ホワイトヘッド、Jr.部 情報とコンピュータサイエンスでは、カリフォルニア大学アーバイン校アーバイン、カリフォルニア92697-3425はメールされます: ejw@ics.uci.edu
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043 EMail: asad@netscape.com
A.Faizi Netscape685の東Middlefield Roadマウンテンビュー、カリフォルニア 94043はメールされます: asad@netscape.com
Dusseault Standards Track [Page 113] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[113ページ]。
S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: srcarter@novell.com
S.R.カーターノベル1555N.技術道S ORM F111オレーム、M/ユタ84097-2399はメールされます: srcarter@novell.com
D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: dcjensen@novell.com
D.ジェンセンノベル1555N.技術道S ORM F111オレーム、M/ユタ84097-2399はメールされます: dcjensen@novell.com
25. References
25. 参照
25.1. Normative References
25.1. 引用規格
[REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816/>.
T.、パオリ、J.、Sperberg-マックィーン、C.、Maler、E.、およびF.Yergeau、「拡張マークアップ言語(XML)1.0(第4版)」を[REC-XML]は、いななかせます、W3C REC-xml-20060816、2006年8月、<http://www.w3.org/TR/2006/REC-xml-20060816/>。
[REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/ REC-xml-infoset-20040204/>.
[REC-XML-INFOSET] カウァンとJ.とR.トビン、「XML一組の情報(第2版)」、W3C REC-xml-infoset-20040204、2004年2月、<http://www.w3.org/TR/2004/ REC-xml-infoset-20040204/>。
[REC-XML-NAMES] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", W3C REC- xml-names-20060816, August 2006, <http:// www.w3.org/TR/2006/REC-xml-names-20060816/>.
[REC-XML-NAMES]は、T.、オランダ人、D.、Layman、A.、およびR.トビン、「XML1.0(第2版)の名前空間」をいななかせます、W3C REC- xml名20060816、2006年8月、<REC-xml http://www.w3.org/TR/2006/名20060816/>。
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
Dusseault Standards Track [Page 114] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[114ページ]。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]Klyneエド(G.、C.ニューマン)は「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、2002年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122] リーチ、P.、食事、M.、およびR.ザルツ、「一般にユニークな識別子(UUID)つぼの名前空間」、RFC4122、2005年7月。
25.2. Informative References
25.2. 有益な参照
[RFC2291] Slein, J., Vitali, F., Whitehead, E., and D. Durand, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web", RFC 2291, February 1998.
[RFC2291] Slein、J.、ヴィターリ、F.、ホワイトヘッド、E.、およびD.ジュランド、「分配されたオーサリングとVersioningのための要件はWWWのために議定書を作ります」、RFC2291、1998年2月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518] Goland、Y.、ホワイトヘッド、E.、Faizi、A.、カーター、S.、およびD.ジェンセン、「分配されたオーサリングのためのHTTP拡大--、WEBDAV、」、RFC2518(1999年2月)
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781]ホフマン、2000年2月のP.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253] クレム、G.、Amsden、J.、エリソン、T.、Kaler、C.、およびJ.ホワイトヘッド、「WebDAV(ウェブの分配されたオーサリングとVersioning)へのVersioning拡張子」、RFC3253(2002年3月)。
[RFC3648] Whitehead, J. and J. Reschke, Ed., "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol", RFC 3648, December 2003.
[RFC3648] ホワイトヘッドとJ.とJ.Reschke、エド、「ウェブの分配されたオーサリングとVersioning(WebDAV)の規則正しい収集プロトコル」、RFC3648、12月2003日
Dusseault Standards Track [Page 115] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[115ページ]。
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.
[RFC3744] クレム、G.、Reschke、J.、Sedlar、E.、およびJ.ホワイトヘッド、「ウェブの分配されたオーサリングとVersioning(WebDAV)アクセスコントロールは議定書を作ります」、RFC3744、2004年5月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]KlyneとG.とノッティンガム、M.とJ.ムガール人、「メッセージヘッダーフィールドのための登録手順」BCP90、2004年9月のRFC3864。
Dusseault Standards Track [Page 116] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[116ページ]。
Appendix A. Notes on Processing XML Elements
処理XML Elementsに関する付録A.注
A.1. Notes on Empty XML Elements
A.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要素が意味的に同じです。
A.2. Notes on Illegal XML Processing
A.2。 不法なXML処理に関する注
XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of whitespace, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements.
XMLは法的に見えるデータを提出するのを簡単にするフレキシブルなデータの形式ですが、事実上、ありません。 「あなたが受け入れるものでフレキシブルであって、あなたが送るもので厳しくいてください」の哲学はまだ適用されていますが、不適当にそれは適用してはいけません。 XMLは空白の問題、要素注文、新しい要素を挿入するのなどに対処するのにおいて非常にフレキシブルです。 この柔軟性は特に要素の意味の領域で拡大を必要としません。
There is no kindness in accepting illegal combinations of XML elements. At best, it will cause an unwanted result and at worst it can cause real damage.
XML要素の不法な組み合わせを受け入れるのにおいて親切が全くありません。 せいぜい、求められていない結果を引き起こすでしょう、そして、最悪の場合はそれは本当の損害をもたらすことができます。
A.3. Example - XML Syntax Error
A.3。 例--XML構文エラー
The following request body for a PROPFIND method is illegal.
PROPFINDメソッドのための以下の要求本体は不法です。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:"> <D:allprop/> <D:propname/> </D:propfind>
<?xmlバージョンが等しい、「=をコード化する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)で応じなければなりません。
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指示を実行していて。 これはそれを増強するより相互運用性をむしろ減少させます。
Dusseault Standards Track [Page 117] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[117ページ]。
A.4. Example - Unexpected XML Element
A.4。 例--予期していなかったXML要素
The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element.
propfind要素に一緒に現れるのが明らかに禁止された2つの要素を含んだので、前の例は不法でした。 しかしながら、XMLが広げることができる言語であるので、人は、新しい要素がpropfindとの使用のために定義されると想像できます。 前の例のように、下をPROPFINDの要求ボディーであり、満期の支柱要素を理解していないサーバによるa400(悪いRequest)で拒絶しなければなりません。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E="http://www.example.com/standards/props/"> <E:expired-props/> </D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV:」、」 xmlns: Eが等しい、「 http://www.example.com/standards/props/ 、「><E: 満期の支柱/></D: propfind>」
To understand why a 400 (Bad Request) is returned, let us look at the request body as the server unfamiliar with expired-props sees it.
400(悪いRequest)がなぜ返します、満期の支柱になじみがなくサーバとしての要求本体を見ようということであるかを理解しているのがそれを見ます。
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E="http://www.example.com/standards/props/"> </D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV:」、」 xmlns: Eが等しい、「 http://www.example.com/standards/props/ 、「></D: propfind>」
As the server does not understand the 'expired-props' element, according to the WebDAV-specific XML processing rules specified in Section 17, it must process the request as if the element were not there. Thus, the server sees an empty propfind, which by the definition of the propfind element is illegal.
セクション17で指定されたWebDAV特有のXML処理規則に従ってサーバが'満期の支柱'要素を理解していないとき、まるで要素がないかのようにそれは要求を処理しなければなりません。 したがって、サーバは空のpropfindを見ます。(propfind要素の定義で、propfindは不法です)。
Please note that had the extension been additive, it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND:
拡大が付加的であったなら、それは必ず、400(悪いRequest)をもたらしたというわけではないでしょうに。 例えば、PROPFINDのために以下の要求本体を想像してください:
<?xml version="1.0" encoding="utf-8" ?> <D:propfind xmlns:D="DAV:" xmlns:E="http://www.example.com/standards/props/"> <D:propname/> <E:leave-out>*boss*</E:leave-out> </D:propfind>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:propfind xmlns:Dが等しい、「DAV:」、」 xmlns: Eが等しい、「 http://www.example.com/standards/props/ 、「><D: propname/><E: >*ボス*</Eを省いてください: ></D: propfind>を置いてください」
The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with 'leave-out', the only result would be that the 'leave-out' element would be ignored and a propname would be executed.
前の例は、要素外からいなくなるのを架空の含んでいます。 目的は名前が提出されたパターンに合っているどんな特性の復帰も防ぐことです。 '外から、いなくなること'になじみのないサーバに前の例を提出するなら、唯一の結果は'外から、いなくなり'要素が無視されて、propnameが実行されるだろうということでしょうに。
Dusseault Standards Track [Page 118] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[118ページ]。
Appendix B. Notes on HTTP Client Compatibility
HTTPクライアントの互換性に関する付録B.注
WebDAV was designed to be, and has been found to be, backward- compatible with HTTP 1.1. The PUT and DELETE methods are defined in HTTP and thus may be used by HTTP clients as well as WebDAV-aware clients, but the responses to PUT and DELETE have been extended in this specification in ways that only a WebDAV client would be entirely prepared for. Some theoretical concerns were raised about whether those responses would cause interoperability problems with HTTP-only clients, and this section addresses those concerns.
WebDAVは、設計されて、後方にHTTP1.1と互換性があった状態であるように見つけられました。 PUTとDELETEメソッドは、HTTPで定義されて、その結果、WebDAV意識しているクライアントと同様にHTTPクライアントが使用されるかもしれませんが、この仕様でWebDAVクライアントだけが完全に用意ができている方法でPUTとDELETEへの応答を広げてあります。 それらの応答がHTTPだけクライアントに関する相互運用性問題を引き起こして、このセクションがそれらの関心を扱うか否かに関係なく、いくつかの理論上の関心がほとんど高められました。
Since any HTTP client ought to handle unrecognized 400-level and 500- level status codes as errors, the following new status codes should not present any issues: 422, 423, and 507 (424 is also a new status code but it appears only in the body of a Multistatus response.) So, for example, if an HTTP client attempted to PUT or DELETE a locked resource, the 423 Locked response ought to result in a generic error presented to the user.
どんなHTTPクライアントも認識されていない400レベルを扱うべきであり、500が誤りとしてステータスコードを平らにするので、以下の新しいステータスコードはどんな問題も提示するべきではありません: 422、423、および507(また、424は新しいステータスコードですが、それはMultistatus応答のボディーだけに現れます。) そのように、例えば、HTTPクライアントがPUTかDELETEにロックされたリソースを試みたなら、423Locked応答はユーザに提示されたジェネリック誤りをもたらすべきです。
The 207 Multistatus response is interesting because an HTTP client issuing a DELETE request to a collection might interpret a 207 response as a success, even though it does not realize the resource is a collection and cannot understand that the DELETE operation might have been a complete or partial failure. That interpretation isn't entirely justified, because a 200-level response indicates that the server "received, understood, and accepted" the request, not that the request resulted in complete success.
DELETE要求を収集に出すHTTPクライアントが成功として207応答を解釈するかもしれないので、207Multistatus応答はおもしろいです、リソースが収集であるとわからないで、DELETE操作が完全であるか部分的な失敗であったかもしれないのを理解できませんが。 その解釈は完全に正当化されません、200レベルの応答が、サーバが要求を「受けて、理解して、受け入れたこと」を示すので要求は完全な成功をもたらしたというわけではありません。
One option is that a server could treat a DELETE of a collection as an atomic operation, and use either 204 No Content in case of success, or some appropriate error response (400 or 500 level) for an error. This approach would indeed maximize backward compatibility. However, since interoperability tests and working group discussions have not turned up any instances of HTTP clients issuing a DELETE request against a WebDAV collection, this concern is more theoretical than practical. Thus, servers are likely to be completely successful at interoperating with HTTP clients even if they treat any collection DELETE request as a WebDAV request and send a 207 Multi-Status response.
1つのオプションはサーバが誤りに、原子操作として収集のDELETEを扱って、成功の場合の204ノーContentか何らかの適切な誤り応答(400か500レベル)のどちらかを使用するかもしれないということです。 本当に、このアプローチは後方の互換性を最大にするでしょう。 しかしながら、相互運用性テストとワーキンググループ議論がWebDAV収集に対してDELETE要求を出すHTTPクライアントのどんなインスタンスも捜しあてていないので、この関心は実用的であるというよりも理論上です。 したがって、サーバは彼らがDELETEが要求するどんな収集もWebDAV要求として扱い、207Multi-状態応答を送ってもHTTPクライアントと共に共同利用するところに完全にうまくいく傾向があります。
In general, server implementations are encouraged to use the detailed responses and other mechanisms defined in this document rather than make changes for theoretical interoperability concerns.
一般に、サーバ実装がきめ細かい対応を使用するよう奨励されて、他のメカニズムは変更を行うよりむしろ理論上の相互運用性関心をこのドキュメントで定義しました。
Dusseault Standards Track [Page 119] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[119ページ]。
Appendix C. The 'opaquelocktoken' Scheme and URIs
'opaquelocktoken'が計画する付録C.とURI
The 'opaquelocktoken' URI scheme was defined in [RFC2518] (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time.
'opaquelocktoken'URI体系は、ロックトークンとして使用されて、時間中にすべてのリソースの向こう側に特有であることを意図するUUIDsからシンタクス上正しい、そして、生成しやすいURIを作成するために[RFC2518](そして、IANAが登録される)で定義されました。
An opaquelocktoken URI is constructed by concatenating the 'opaquelocktoken' scheme with a UUID, along with an optional extension. Servers can create new UUIDs for each new lock token. If a server wishes to reuse UUIDs, the server MUST add an extension, and the algorithm generating the extension MUST guarantee that the same extension will never be used twice with the associated UUID.
opaquelocktoken URIは、任意の拡大に伴うUUIDと共に'opaquelocktoken'体系を連結することによって、構成されます。 サーバはそれぞれの新しいロックトークンのために新しいUUIDsを作成できます。 サーバがUUIDsを再利用したいなら、サーバは関連UUIDと共に使用されていた状態で拡大が保証しなければならない同じ拡大が決してない拡大、アルゴリズムのおよび生成することを二度加えなければなりません。
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; UUID is defined in Section 3 of [RFC4122]. Note that LWS ; is not allowed between elements of ; this production.
OpaqueLockToken-URI=は「以下をopaquelocktokenします」。 UUID[拡大]。 UUIDは[RFC4122]のセクション3で定義されます。 そのLWSに注意してください。 要素の間に許容されていない、。 この生産。
Extension = path ; path is defined in Section 3.3 of [RFC3986]
拡大は経路と等しいです。 経路はセクション3.3で定義されます。[RFC3986]
Appendix D. Lock-null Resources
付録D.ロックヌルリソース
The original WebDAV model for locking unmapped URLs created "lock- null resources". This model was over-complicated and some interoperability and implementation problems were discovered. The new WebDAV model for locking unmapped URLs (see Section 7.3) creates "locked empty resources". Lock-null resources are deprecated. This section discusses the original model briefly because clients MUST be able to handle either model.
ロックがURLを非写像したので、オリジナルのWebDAVモデルは「ロックのヌルリソース」を作成しました。 このモデルは過剰複雑でした、そして、何らかの相互運用性と実装問題は発見されました。 ロックがURLを非写像したので(セクション7.3を見てください)、新しいWebDAVモデルは「ロックされた空のリソース」を作成します。 ロックヌルリソースは推奨しないです。 クライアントがどちらのモデルも扱うことができなければならないので、このセクションは簡潔に原型について論じます。
In the original "lock-null resource" model, which is no longer recommended for implementation:
オリジナルの「ロックヌルリソース」モデルで:(モデルは実装のためにもう推薦されません)。
o A lock-null resource sometimes appeared as "Not Found". The server responds with a 404 or 405 to any method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
o ロックヌルリソースは「見つけられません」のように時々見えました。 サーバは404か405でPUT、MKCOL、OPTIONS、PROPFIND、LOCK、UNLOCK以外のどんなメソッドにも反応します。
o A lock-null resource does however show up as a member of its parent collection.
o しかしながら、ロックヌルリソースは親収集のメンバーとして現れます。
o The server removes the lock-null resource entirely (its URI becomes unmapped) if its lock goes away before it is converted to a regular resource. Recall that locks go away not only when they expire or are unlocked, but are also removed if a resource is renamed or moved, or if any parent collection is renamed or moved.
o それが通常のリソースに変換される前に錠が遠ざかるなら、サーバはロックヌルリソースを完全(URIは非写像されるようになる)に取り除きます。 錠が期限が切れない場合にだけ遠ざかるか、またはアンロックされますが、また、何か親収集がリソースが改名されるか、動かされる、改名されるか、または動かされるなら取り外されたと思い出してください。
Dusseault Standards Track [Page 120] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[120ページ]。
o The server converts the lock-null resource into a regular resource if a PUT request to the URL is successful.
o URLへのPUT要求がうまくいくなら、サーバはロックヌルリソースを通常のリソースに変換します。
o The server converts the lock-null resource into a collection if a MKCOL request to the URL is successful (though interoperability experience showed that not all servers followed this requirement).
o URLへのMKCOL要求がうまくいくなら(相互運用性経験は、すべてのサーバがこの要件に続いたというわけではないのを示しましたが)、サーバはロックヌルリソースを収集に変換します。
o Property values were defined for DAV:lockdiscovery and DAV: supportedlock properties but not necessarily for other properties like DAV:getcontenttype.
o 特性の値はDAV: lockdiscoveryとDAVのために定義されました: 特性にもかかわらず、必ずDAVのような他の特性でないsupportedlock: getcontenttype。
Clients can easily interoperate both with servers that support the old model "lock-null resources" and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET.
クライアントは、古いモデル「ロックヌルリソース」をサポートするサーバと「ロックされた空のリソース」のお勧めのモデルと共にLOCKの後にMKCOLかGETではなく、非写像しているURLにPUTを試みるだけで容易に共同利用できます。
D.1. Guidance for Clients Using LOCK to Create Resources
D.1。 リソースを作成するのに錠を使用しているクライアントのための指導
A WebDAV client implemented to this specification might find servers that create lock-null resources (implemented before this specification using [RFC2518]) as well as servers that create locked empty resources. The response to the LOCK request will not indicate what kind of resource was created. There are a few techniques that help the client deal with either type.
この仕様に実装されたWebDAVクライアントはロックされた空のリソースを作成するサーバと同様にロックヌルリソースを作成する(この仕様の前に[RFC2518]を使用することで実装されます)サーバを見つけるかもしれません。 LOCK要求への応答は、どういうリソースが作成されたかを示さないでしょう。 クライアントがタイプに対処するのを助けるいくつかのテクニックがあります。
If the client wishes to avoid accidentally creating either lock- null or empty locked resources, an "If-Match: *" header can be included with LOCK requests to prevent the server from creating a new resource.
クライアントが、偶然作成するのを避けたいならヌルの、または、空のロックされたリソースをロックしてください、「-合ってください、:、」 *「サーバが新しいリソースを作成するのを防ぐというLOCK要求でヘッダーを含むことができます。」
If a LOCK request creates a resource and the client subsequently wants to overwrite that resource using a COPY or MOVE request, the client should include an "Overwrite: T" header.
LOCK要求がリソースを作成して、クライアントが次にCOPYかMOVE要求、クライアントを使用すると含まれるべきであるそのリソースを上書きしたがっている、「上書きしてください」 「T」ヘッダー。
If a LOCK request creates a resource and the client then decides to get rid of that resource, a DELETE request is supposed to fail on a lock-null resource and UNLOCK should be used instead. But with a locked empty resource, UNLOCK doesn't make the resource disappear. Therefore, the client might have to try both requests and ignore an error in one of the two requests.
LOCK要求がリソースを作成して、次に、クライアントが、そのリソースを取り除くと決めるなら、DELETE要求はロックヌルリソースで失敗するべきです、そして、UNLOCKは代わりに使用されるべきです。 しかし、ロックされた空のリソースで、UNLOCKはリソースを見えなくならせません。 したがって、クライアントは、2つの要求の1つで両方の要求を試みて、誤りを無視しなければならないかもしれません。
Appendix E. Guidance for Clients Desiring to Authenticate
認証するクライアントの望みのための付録E.指導
Many WebDAV clients that have already been implemented have account settings (similar to the way email clients store IMAP account settings). Thus, the WebDAV client would be able to authenticate with its first couple requests to the server, provided it had a way to get the authentication challenge from the server with realm name,
既に実装された多くのWebDAVクライアントがアカウント設定(メールクライアントがIMAPアカウント設定を保存する方法と同様の)を持っています。 したがって、WebDAVクライアントは最初のカップルと共にサーバに要求を認証できるでしょう、それにサーバから認証挑戦を得る方法が分野名と共にあったなら
Dusseault Standards Track [Page 121] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[121ページ]。
nonce, and other challenge information. Note that the results of some requests might vary according to whether or not the client is authenticated -- a PROPFIND might return more visible resources if the client is authenticated, yet not fail if the client is anonymous.
一回だけの、そして、他の挑戦情報。 クライアントが認証されるかどうかに従っていくつかの要求の結果が異なるかもしれないことに注意してください--クライアントが匿名であるなら、PROPFINDはクライアントが認証されるなら、より目に見えるリソースを返しますが、失敗しないかもしれません。
There are a number of ways the client might be able to trigger the server to provide an authentication challenge. This appendix describes a couple approaches that seem particularly likely to work.
クライアントが認証挑戦を提供するためにサーバの引き金となることができるかもしれない多くの方法があります。 この付録は特に働きそうである2、3のアプローチについて説明します。
The first approach is to perform a request that ought to require authentication. However, it's possible that a server might handle any request even without authentication, so to be entirely safe, the client could add a conditional header to ensure that even if the request passes permissions checks, it's not actually handled by the server. An example of following this approach would be to use a PUT request with an "If-Match" header with a made-up ETag value. This approach might fail to result in an authentication challenge if the server does not test authorization before testing conditionals as is required (see Section 8.5), or if the server does not need to test authorization.
最初のアプローチは認証を必要とするべきである要求を実行することです。 要求が許容チェックを通過しても、それは実際にサーバによって扱われません。しかしながら、それが完全に安全であるなら、サーバが認証がなくてもどんな要求も扱うかもしれないのでクライアントがこのアプローチに続く例がPUT要求を使用することであることを保証するために条件付きのヘッダーを加えるかもしれないのが可能である、「-合ってください、」 ヘッダー、作り上げているETag値で。 サーバが承認をテストする必要はなくて、そのままでconditionalsをテストするのが必要になる(セクション8.5を見てください)前にサーバが承認をテストしないなら、このアプローチは認証挑戦をもたらさないかもしれません。
Example - forcing auth challenge with write request
例--authが挑戦する強制は要求を書きます。
>>Request
>>要求
PUT /forceauth.txt HTTP/1.1 Host: www.example.com If-Match: "xxx" Content-Type: text/plain Content-Length: 0
forceauth.txt HTTP/1.1が接待する/を置いてください: www.example.com If-マッチ: "xxx"コンテントタイプ: テキスト/明瞭なContent-長さ: 0
The second approach is to use an Authorization header (defined in [RFC2617]), which is likely to be rejected by the server but which will then prompt a proper authentication challenge. For example, the client could start with a PROPFIND request containing an Authorization header containing a made-up Basic userid:password string or with actual plausible credentials. This approach relies on the server responding with a "401 Unauthorized" along with a challenge if it receives an Authorization header with an unrecognized username, invalid password, or if it doesn't even handle Basic authentication. This seems likely to work because of the requirements of RFC 2617:
2番目のアプローチはAuthorizationヘッダー([RFC2617]では、定義される)を使用することです。(サーバによって拒絶されそうですが、次に、ヘッダーは適切な認証挑戦をうながすでしょう)。 例えば、クライアントは作り上げているBasicユーザID: パスワードストリングを含むAuthorizationヘッダーを含んでいるPROPFIND要求か実際のもっともらしい資格証明書から始めることができました。 このアプローチがaで反応するサーバを当てにする、「401、権限のなさ、」 認識されていないユーザ名、無効のパスワードでAuthorizationヘッダーを受ける、Basic認証を扱わないでも、aと共に、挑戦してください。 これはRFC2617の要件のために働きそうです:
Dusseault Standards Track [Page 122] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[122ページ]。
"If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource."
「発生源サーバが受け入れたくないなら、資格証明書は要求と共に発信して、それはSHOULDリターンa401(権限のない)応答です。」 「応答が含まなければならない、aが要求されたリソースに適切な少なくとも1つの(ことによると新しい)の挑戦を含むヘッダーフィールドをWWW認証する、」
There's a slight problem with implementing that recommendation in some cases, because some servers do not even have challenge information for certain resources. Thus, when there's no way to authenticate to a resource or the resource is entirely publicly available over all accepted methods, the server MAY ignore the Authorization header, and the client will presumably try again later.
いくつかの場合、その推薦を実装するくだらない問題があります、いくつかのサーバには、あるリソースのための挑戦情報がしさえしないので。 あるとき、したがって、ずっとリソースかリソースに認証するノーはすべての受け入れられたメソッドの上で公的に完全に利用可能です、そして、サーバはAuthorizationヘッダーを無視するかもしれません、そして、おそらく、クライアントは後で再び試みるでしょう。
Example - forcing auth challenge with Authorization header
例--Authorizationヘッダーによるauth挑戦を強制すること。
>>Request
>>要求
PROPFIND /docs/ HTTP/1.1 Host: www.example.com Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Content-type: application/xml; charset="utf-8" Content-Length: xxxx
PROPFIND/docs/HTTP/1.1ホスト: www.example.com Authorization: 基本のQWxhZGRpbjpvcGVuIHNlc2FtZQ=文書内容: アプリケーション/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
[body omitted]
[省略されたボディー]
Appendix F. Summary of Changes from RFC 2518
RFC2518からの変化の付録F.概要
This section lists major changes between this document and RFC 2518, starting with those that are likely to result in implementation changes. Servers will advertise support for all changes in this specification by returning the compliance class "3" in the DAV response header (see Sections 10.1 and 18.3).
このセクションはこのドキュメントとRFC2518の間の大きな変化を記載します、実装変化をもたらしそうなものから始めて。 サーバは、「DAV応答ヘッダ(セクション10.1と18.3を見る)の3インチ」を承諾クラスに返すことによって、この仕様に基づくすべての変化のサポートの広告を出すでしょう。
F.1. Changes for Both Client and Server Implementations
F.1。 クライアントとサーバ実装の両方のための変化
Collections and Namespace Operations
収集と名前空間操作
o The semantics of PROPFIND 'allprop' (Section 9.1) have been relaxed so that servers return results including, at a minimum, the live properties defined in this specification, but not necessarily return other live properties. The 'allprop' directive therefore means something more like "return all properties that are supposed to be returned when 'allprop' is requested" -- a set of properties that may include custom properties and properties defined in other specifications if those other specifications so require. Related to this, 'allprop' requests can now be extended with the 'include' syntax to include specific named properties,
o PROPFIND'allprop'(セクション9.1)の意味論がリラックスして、サーバは、最小限でこの仕様に基づき定義された精力の特性を含む結果を返しますが、必ず他の精力の資産を返すというわけではありません。 したがって、'allprop'指示は、何か「いつが返されるべきであるすべての資産を返してください'というallpropのようなものより多いものは'要求されています」--1セットのカスタム特性を含むかもしれない特性とそれらの他の仕様がそう必要であるなら他の仕様に基づき定義された特性を意味します。 これに関係づけられて、今特定の命名された性質を含むように'包含'構文で'allprop'要求を広げることができます。
Dusseault Standards Track [Page 123] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[123ページ]。
thereby avoiding additional requests due to changed 'allprop' semantics.
その結果、変えられた'allprop'意味論による追加要求を避けます。
o Servers are now allowed to reject PROPFIND requests with Depth: Infinity. Clients that used this will need to be able to do a series of Depth:1 requests instead.
o サーバは現在、DepthとのPROPFIND要求を拒絶できます: 無限。 これを使用したクライアントは、代わりにDepth: 1要求のシリーズができる必要があるでしょう。
o Multi-Status response bodies now can transport the value of HTTP's Location response header in the new 'location' element. Clients may use this to avoid additional roundtrips to the server when there is a 'response' element with a 3xx status (see Section 14.24).
o マルチStatus応答ボディーは現在、新しい'位置'要素のHTTPのLocation応答ヘッダの値を輸送できます。 クライアントは、3xx状態がある'応答'要素があるとき(セクション14.24を見てください)、追加往復旅行をサーバとして避けるのにこれを使用するかもしれません。
o The definition of COPY has been relaxed so that it doesn't require servers to first delete the target resources anymore (this was a known incompatibility with [RFC3253]). See Section 9.8.
o COPYの定義がリラックスして、それ以上最初に目標リソースを削除するのがサーバを必要としません(これは[RFC3253]がある知られている不一致でした)。 セクション9.8を見てください。
Headers and Marshalling
ヘッダーと整理
o The Destination and If request headers now allow absolute paths in addition to full URIs (see Section 8.3). This may be useful for clients operating through a reverse proxy that does rewrite the Host request header, but not WebDAV-specific headers.
o DestinationとIfは、ヘッダーが現在完全なURIに加えた絶対パスを許容するよう(セクション8.3を見てください)要求します。 これはWebDAV特有のヘッダーではなく、Host要求ヘッダーを書き直すリバースプロキシを通して働いているクライアントの役に立つかもしれません。
o This specification adopts the error marshalling extensions and the "precondition/postcondition" terminology defined in [RFC3253] (see Section 16). Related to that, it adds the "error" XML element inside multistatus response bodies (see Section 14.5, however note that it uses a format different from the one recommended in RFC 3253).
o この仕様は[RFC3253]で定義された拡大を整理する誤りと「前提条件/postcondition」用語を採用します(セクション16を見てください)。 それに関係づけられて、それは「マルチ-状態」応答ボディーの中で「誤り」XML要素を加えます(しかしながら、セクション14.5を見てください、そして、RFC3253のお勧めのものと異なった形式を使用することに注意してください)。
o Senders and recipients are now required to support the UTF-16 character encoding in XML message bodies (see Section 19).
o 送付者と受取人は現在、XMLメッセージボディーでUTF-16文字符号化をサポートしなければなりません(セクション19を見てください)。
o Clients are now required to send the Depth header on PROPFIND requests, although servers are still encouraged to support clients that don't.
o クライアントは現在DepthヘッダーをPROPFIND要求に送らなければなりません、サーバがそうしないクライアントをサポートするようまだ奨励されていますが。
Locking
ロックします。
o RFC 2518's concept of "lock-null resources" (LNRs) has been replaced by a simplified approach, the "locked empty resources" (see Section 7.3). There are some aspects of lock-null resources clients cannot rely on anymore, namely, the ability to use them to create a locked collection or the fact that they disappear upon UNLOCK when no PUT or MKCOL request was issued. Note that servers are still allowed to implement LNRs as per RFC 2518.
o RFC2518の「ロックヌルリソース」(LNRs)の概念を簡単なアプローチ、「ロックされた空のリソース」に取り替えました(セクション7.3を見てください)。 すなわち、ロックヌルリソースクライアントの局面がそれ以上当てにすることができないいくつか、ロックされた収集を作成するのに彼らを使用する能力またはどんなPUTもMKCOL要求も出されなかったとき、彼らがUNLOCKで見えなくなるという事実があります。 サーバがRFC2518に従ってまだLNRsを実装することができることに注意してください。
Dusseault Standards Track [Page 124] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[124ページ]。
o There is no implicit refresh of locks anymore. Locks are only refreshed upon explicit request (see Section 9.10.2).
o ノーは暗黙です。そこ、それ以上錠をリフレッシュしてください。 錠は明白な要求のときにリフレッシュされるだけです(セクション9.10.2を見てください)。
o Clarified that the DAV:owner value supplied in the LOCK request must be preserved by the server just like a dead property (Section 14.17). Also added the DAV:lockroot element (Section 14.12), which allows clients to discover the root of lock.
o はっきりさせられて、DAV:LOCK要求で供給された所有者価値がサーバによって守られなければならないのが死んでいる特性(セクション14.17)はただ、好きです。 また、DAV: lockroot要素(セクション14.12)を加えました。(クライアントは、それで錠の根を発見できます)。
F.2. Changes for Server Implementations
F.2。 サーバ実装のための変化
Collections and Namespace Operations
収集と名前空間操作
o Due to interoperability problems, allowable formats for contents of 'href' elements in multistatus responses have been limited (see Section 8.3).
o 相互運用性問題のため、「マルチ-状態」応答における'href'要素のコンテンツのための許容できる形式は制限されました(セクション8.3を見てください)。
o Due to lack of implementation, support for the 'propertybehavior' request body for COPY and MOVE has been removed. Instead, requirements for property preservation have been clarified (see Sections 9.8 and 9.9).
o 実装の不足のため、COPYとMOVEのための'propertybehavior'要求本体のサポートを取り除きました。 代わりに、特性の保存のための要件ははっきりさせられました(セクション9.8と9.9を見てください)。
Properties
特性
o Strengthened server requirements for storage of property values, in particular persistence of language information (xml:lang), whitespace, and XML namespace information (see Section 4.3).
o 言語情報(xml: lang)、空白、およびXML名前空間情報(セクション4.3を見る)の特定の固執における、特性の値のストレージのための強まっているサーバ要件。
o Clarified requirements on which properties should be writable by the client; in particular, setting "DAV:displayname" should be supported by servers (see Section 15).
o 特性がクライアントが書き込み可能であるべき要件をはっきりさせます。 特に、「DAV: displayname」を設定するのはサーバによって支持されるべきです(セクション15を見てください)。
o Only 'rfc1123-date' productions are legal as values for DAV: getlastmodified (see Section 15.7).
o 'rfc1123-日付'創作だけがDAVのための値として法的です: getlastmodifiedしました(セクション15.7を見ます)。
Headers and Marshalling
ヘッダーと整理
o Servers are now required to do authorization checks before processing conditional headers (see Section 8.5).
o サーバが、現在、条件付きのヘッダーを処理する前に許可検査をするのに必要です(セクション8.5を見てください)。
Locking
ロックします。
o Strengthened requirement to check identity of lock creator when accessing locked resources (see Section 6.4). Clients should be aware that lock tokens returned to other principals can only be used to break a lock, if at all.
o アクセスするときロック創造者のアイデンティティをチェックするという強まっている要件はリソースをロックしました(セクション6.4を見てください)。 クライアントはせいぜい錠を壊すのに他の校長に返されたロック象徴を使用できるだけであるのを意識しているべきです。
Dusseault Standards Track [Page 125] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[125ページ]。
o Section 8.10.4 of [RFC2518] incorrectly required servers to return a 409 status where a 207 status was really appropriate. This has been corrected (Section 9.10).
o 207状態が本当に適切であった409状態を返す.4の[RFC2518]不当に必要なセクション8.10サーバ。 これを修正してあります(セクション9.10)。
F.3. Other Changes
F.3。 他の変化
The definition of collection state has been fixed so it doesn't vary anymore depending on the Request-URI (see Section 5.2).
収集状態の定義が修理されたので、それ以上Request-URIによって、それは異なりません(セクション5.2を見てください)。
The DAV:source property introduced in Section 4.6 of [RFC2518] was removed due to lack of implementation experience.
DAV: [RFC2518]のセクション4.6で紹介されたソース資産は実現経験の不足のため取り外されました。
The DAV header now allows non-IETF extensions through URIs in addition to compliance class tokens. It also can now be used in requests, although this specification does not define any associated semantics for the compliance classes defined in here (see Section 10.1).
DAVヘッダーは現在、承諾クラス象徴に加えて非IETF拡張子のURIに通ることを許します。 また、現在要求でそれを使用できます、この仕様はここで定義された承諾クラスのために少しの関連意味論も定義しませんが(セクション10.1を見てください)。
In RFC 2518, the definition of the Depth header (Section 9.2) required that, by default, request headers would be applied to each resource in scope. Based on implementation experience, the default has now been reversed (see Section 10.2).
RFC2518では、Depthヘッダー(セクション9.2)の定義はそれを必要として、デフォルトで、要求ヘッダーは範囲の各リソースに適用されるでしょう。 実現経験に基づいて、デフォルトは現在、逆にされました(セクション10.2を見てください)。
The definitions of HTTP status code 102 ([RFC2518], Section 10.1) and the Status-URI response header (Section 9.7) have been removed due to lack of implementation.
実現の不足のためHTTPステータスコード102([RFC2518]、セクション10.1)とStatus-URI応答ヘッダ(セクション9.7)の定義を取り除きました。
The TimeType format used in the Timeout request header and the "timeout" XML element used to be extensible. Now, only the two formats defined by this specification are allowed (see Section 10.7).
よくTimeout要求ヘッダーと「タイムアウト」XML要素で使用されるTimeType形式は以前は広げることができる状態でした。 現在、この仕様で定義された2つの書式だけが許容されています(セクション10.7を見てください)。
Author's Address
作者のアドレス
Lisa Dusseault (editor) CommerceNet 2064 Edgewood Dr. Palo Alto, CA 94303 US
リサDusseault(エディタ)CommerceNet2064Edgewoodパロアルト博士、カリフォルニア94303米国
EMail: ldusseault@commerce.net
メール: ldusseault@commerce.net
Dusseault Standards Track [Page 126] RFC 4918 WebDAV June 2007
Dusseault規格はWebDAV2007年6月にRFC4918を追跡します[126ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Dusseault Standards Track [Page 127]
Dusseault標準化過程[127ページ]
一覧
スポンサーリンク