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 &lt;RFC2518&gt;.
         </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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

MIN関数 最小値を求める

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る