メインコンテンツまでスキップ

RFC 4918 - HTTPの拡張: Web分散オーサリングとバージョン管理（WebDAV）

  • ステータス: Proposed Standard
  • 発行日: June 2007
  • ストリーム: IETF
  • 廃止: RFC2518
  • エラッタ: エラッタなし

概要 (Abstract)​

Web分散オーサリングとバージョン管理 (WebDAV, Web Distributed Authoring and Versioning) は、リソースプロパティ (Resource Properties) の管理、リソースコレクション (Resource Collections) の作成と管理、URL名前空間操作 (URL Namespace Manipulation)、およびリソースロック (Resource Locking、衝突回避用) のための、HTTP/1.1に付属する一連のメソッド (Methods)、ヘッダー (Headers)、およびコンテンツタイプ (Content-Types) で構成されます。

RFC 2518は1999年2月に発行されました。本仕様はRFC 2518を廃止し、相互運用性の経験に基づいた軽微な改訂を行っています。

本メモのステータス (Status of This Memo)​

本文書は、インターネットコミュニティのためのインターネット標準化過程プロトコルを規定し、改善のための議論と提案を求めます。本プロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1) の最新版を参照してください。本メモの配布は無制限です。

Copyright (C) The IETF Trust (2007).

目次 (Contents)​

主要セクション​

付録 (Appendices)​

WebDAVの中核概念​

主要機能​

WebDAVは、HTTP/1.1プロトコルを以下の中核機能で拡張します:

  1. プロパティ (Properties): Webリソースのメタデータを追加、変更、クエリ
  2. コレクション (Collections): リソースの階層構造を作成・管理
  3. ロック (Locking): 同時編集の競合を防止、排他ロックと共有ロックをサポート
  4. 名前空間操作 (Namespace Operations): Webリソースのコピーと移動

新しいHTTPメソッド​

  • PROPFIND: リソースのプロパティを取得します
  • PROPPATCH: リソースのプロパティを変更します
  • MKCOL: コレクションを作成します (ディレクトリの作成に類似)
  • COPY: リソースまたはコレクションをコピーします
  • MOVE: リソースまたはコレクションを移動または名前変更します
  • LOCK: 競合を防ぐためにリソースをロックします
  • UNLOCK: リソースのロックを解除します

新しいHTTPステータスコード​

  • 207 Multi-Status: バッチ操作のためのマルチステータスレスポンス
  • 422 Unprocessable Entity: リクエストは整形されていたが、意味的なエラーが含まれていた
  • 423 Locked: リソースがロックされています
  • 424 Failed Dependency: 前のリクエストの失敗により、リクエストが失敗しました
  • 507 Insufficient Storage: リクエストを完了するためのストレージが不足しています

使用例​

  • 協調編集 (Collaborative Editing): 複数のユーザーがWebコンテンツを同時に編集
  • コンテンツ管理システム (CMS): Webサイトコンテンツのリモート管理
  • ファイル共有 (File Sharing): HTTPプロトコル経由でのファイルのアップロードとダウンロード
  • クラウドストレージ (Cloud Storage): HTTPベースのファイルストレージサービスの実装

1. Introduction (序論)​

本文書は、クライアントがリモートでWebコンテンツのオーサリング操作を実行できるようにする、HTTP/1.1プロトコルの拡張について説明します。この拡張は、以下の操作を提供する、一貫したメソッド (Methods)、ヘッダー (Headers)、リクエストエンティティボディ形式 (Request Entity Body Formats)、およびレスポンスエンティティボディ形式 (Response Entity Body Formats) のセットを提供します:

プロパティ (Properties): Webページに関する情報（著者、作成日など）を作成、削除、クエリする機能。

コレクション (Collections): ドキュメントのセットを作成し、階層的なメンバーシップリスト（ファイルシステムのディレクトリリストのようなもの）を取得する機能。

ロック (Locking): 複数の人が同時にドキュメントを操作することを防ぐ機能。これにより、「更新の損失問題 (Lost Update Problem)」を防ぎます。この問題は、最初のある著者が変更を書き込み、次に別の著者が他の著者の変更をマージせずに変更を書き込むことで、変更が失われることを指します。

名前空間操作 (Namespace Operations): サーバーにWebリソースをコピーおよび移動するように指示する機能。これらの操作は、URLからリソースへのマッピングを変更します。

これらの操作の要件と根拠は、関連文書である「World Wide Web分散オーサリングおよびバージョン管理プロトコルの要件 (Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web)」[RFC2291] に記載されています。

本文書は、[RFC2291] で提案されているバージョン管理操作を規定していません。その作業は、別の文書「WebDAVのバージョン管理拡張 (Versioning Extensions to WebDAV)」[RFC3253] で行われました。

以下のセクションでは、さまざまなWebDAV抽象概念について詳細に説明します: リソースプロパティ (Resource Properties, 第4節)、リソースのコレクション (Collections of Resources, 第5節)、一般的なロック (Locks, 第6節)、および特に書き込みロック (Write Locks, 第7節)。

これらの抽象概念は、WebDAV固有のHTTPメソッド (第9節) と、WebDAVメソッドで使用される追加のHTTPヘッダー (第10節) によって操作されます。WebDAVにおけるHTTPリクエストとレスポンスの処理に関する一般的な考慮事項は、第8節に記載されています。

HTTP/1.1が提供するステータスコードは、WebDAVメソッドで発生するほとんどのエラー状態を記述するのに十分ですが、既存のカテゴリにうまく当てはまらないエラーもあります。本仕様は、WebDAVメソッド用に開発された追加のステータスコード (第11節) を定義し、WebDAVで使用される既存のHTTPステータスコード (第12節) について説明します。一部のWebDAVメソッドは多数のリソースに対して操作する可能性があるため、マルチステータスレスポンス (Multi-Status Response, 第13節) が導入され、複数のリソースのステータス情報を返すようになりました。最後に、このバージョンのWebDAVは、エラーレスポンスボディに事前条件と事後条件 (Precondition/Postcondition, 第16節) XML要素を導入しています。

WebDAVは、プロパティ名と一部の値にXML ([REC-XML]) を使用し、また複雑なリクエストとレスポンスをマーシャリングするためにXMLを使用します。本仕様には、マーシャリングで使用されるすべてのプロパティ (第15節) およびすべての他のXML要素 (第14節) のDTDとテキスト定義が含まれています。WebDAVには、後方互換性のある方法でWebDAV XMLマーシャリングを拡張するためのいくつかの特別なルール (第17節) が含まれています。

本仕様の最後には、リソースが本仕様に準拠することの意味 (第18節)、国際化サポート (第19節)、およびセキュリティ (第20節) に関するセクションがあります。

2. Notational Conventions (表記規則)​

本文書はHTTP/1.1プロトコルの拡張セットを記述しているため、プロトコル要素を記述するために使用される拡張BNF (Augmented BNF) は、暗黙の線形空白 (Implied Linear Whitespace) に関するルールを含め、[RFC2616] のセクション2.1で説明されているものと完全に同じです。この拡張BNFは [RFC2616] のセクション2.2で提供される基本的な生成規則を使用するため、これらの規則は本文書にも適用されます。これは他のRFCで使用される標準BNF構文ではないことに注意してください。

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、[RFC2119] に記載されているように解釈されるものとします。

日本語対照:

  • MUST (しなければならない): 絶対要件
  • MUST NOT (してはならない): 絶対禁止
  • REQUIRED (必須である): 絶対要件
  • SHALL (しなければならない): 強制要件
  • SHALL NOT (してはならない): 強制禁止
  • SHOULD (すべきである): 強く推奨されるが必須ではない
  • SHOULD NOT (すべきでない): 強く推奨されないが禁止ではない
  • RECOMMENDED (推奨される): 推奨される実践
  • MAY (してもよい): 許可されるが任意
  • OPTIONAL (任意である): 完全に任意

なお、自然言語では、「DAV:」XML名前空間の「creationdate」プロパティのようなプロパティは、簡潔にするために「DAV:creationdate」と呼ばれることがあります。

3. Terminology (用語)​

本セクションでは、WebDAV仕様で使用される主要な用語を定義します。

URI/URL​

URI (Uniform Resource Identifier, 統一資源識別子) および URL (Uniform Resource Locator, 統一資源位置指定子)。これらの用語（およびそれらの違い）は [RFC3986] で定義されています。

URI/URL Mapping (URI/URLマッピング)​

絶対URIとリソースの間の関係。リソースはネットワーク経由で取得できないアイテムと取得できるアイテムの両方を表すことができるため、リソースは0個、1個、または複数のURIマッピングを持つことが可能です。リソースを「http」スキームURIにマッピングすると、そのURIを使用してリソースにHTTPプロトコルリクエストを送信できるようになります。

Path Segment (パスセグメント)​

非公式には、URI内のスラッシュ（「/」）間に見られる文字。正式には、[RFC3986] のセクション3.3で定義されています。

Collection (コレクション)​

非公式には、子リソースへの参照のコンテナとしても機能するリソース。正式には、パスセグメントとリソース間のマッピングのセットを含み、セクション5で定義された要件を満たすリソース。

Internal Member (of a Collection) (コレクションの内部メンバー)​

非公式には、コレクションの子リソース。正式には、コレクションに含まれるパスセグメントマッピングによって参照されるリソース。

Internal Member URL (of a Collection) (コレクションの内部メンバーURL)​

内部メンバーのURL。コレクションのURL（末尾のスラッシュを含む）に、内部メンバーを識別するパスセグメントを加えたもので構成されます。

Member (of a Collection) (コレクションのメンバー)​

非公式には、コレクションの「子孫」。正式には、コレクションの内部メンバー、または再帰的に内部メンバーのメンバー。

Member URL (of a Collection) (コレクションのメンバーURL)​

コレクション自体の内部メンバーURLであるか、またはそのコレクションのメンバーの内部メンバーURLであるURL。

Property (プロパティ)​

リソースに関する記述情報を含む名前/値のペア。

Live Property (ライブプロパティ)​

そのセマンティクスと構文がサーバーによって強制されるプロパティ。たとえば、ライブプロパティ DAV:getcontentlength は、GETリクエストによって返されるエンティティの長さである値が、サーバーによって自動的に計算されます。

Dead Property (デッドプロパティ)​

そのセマンティクスと構文がサーバーによって強制されないプロパティ。サーバーはデッドプロパティの値を記録するだけです。クライアントは、デッドプロパティの構文とセマンティクスの一貫性を維持する責任があります。

Principal (プリンシパル)​

ネットワークリソースへのアクセスを開始する、個別の人間または計算アクター。

State Token (状態トークン)​

リソースの状態を表すURI。ロックトークン (Lock Token) は、本仕様で定義されている唯一の状態トークンです。

4. Data Model for Resource Properties (リソースプロパティのデータモデル)​

4.1 The Resource Property Model (リソースプロパティモデル)​

Properties (プロパティ) は, リソースの状態を記述するデータの断片です。プロパティはデータに関するデータです。

プロパティは, リソースの効率的な発見と管理を提供するために, 分散オーサリング環境で使用されます。たとえば, 'subject' プロパティは, すべてのリソースを主題別にインデックス化することを可能にし, 'author' プロパティは, どの著者がどのドキュメントを書いたかを発見することを可能にします。

DAV プロパティモデルは名前/値のペアで構成されます。プロパティの名前は, プロパティの構文とセマンティクスを識別し, その構文とセマンティクスを参照するアドレスを提供します。

プロパティには "live (ライブ)" と "dead (デッド)" の2つのカテゴリがあります。ライブプロパティは, その構文とセマンティクスがサーバーによって強制されます。ライブプロパティには次のケースが含まれます: a) プロパティの値がサーバーによって保護および維持される場合, b) プロパティの値がクライアントによって維持されるが, サーバーが送信された値に対して構文チェックを実行する場合。特定のライブプロパティのすべてのインスタンスは, そのプロパティ名に関連付けられた定義に準拠しなければなりません。デッドプロパティは, その構文とセマンティクスがクライアントによって強制されます; サーバーは単にプロパティの値を逐語的に記録します。

4.2 Properties and HTTP Headers (プロパティと HTTP ヘッダー)​

プロパティは, 限定的な意味で HTTP メッセージヘッダーにすでに存在しています。しかし, 分散オーサリング環境では, リソースの状態を記述するために比較的多数のプロパティが必要であり, それらすべてを HTTP ヘッダーを通じて設定/返すことは非効率的です。したがって, プリンシパルが関心のあるプロパティのセットを識別し, それらのプロパティのみを設定または取得できるようにするメカニズムが必要です。

4.3 Property Values (プロパティ値)​

プロパティの値は常に整形式の XML フラグメントです。

XML が選択されたのは, それが豊富なスキーマ定義をサポートする柔軟で自己記述的な構造化データ形式であり, 複数の文字セットをサポートしているためです。XML の自己記述的な性質により, 要素を追加することで任意のプロパティの値を拡張できます。クライアントは拡張に遭遇しても壊れません。元のスキーマで指定されたデータを引き続き持ち, 理解できない要素を無視しなければならないためです。

XML の複数文字セットのサポートにより, 人間が読める任意のプロパティをユーザーに馴染みのある文字セットでエンコードおよび読み取ることができます。XML の複数の人間の言語のサポートは, "xml:lang" 属性を使用して, 同じ文字セットが複数の人間の言語で使用される場合を処理します。xml:lang スコープは再帰的であるため, プロパティ名要素を含む任意の要素の xml:lang 属性は, より局所的にスコープされた属性によって上書きされない限り, プロパティ値に適用されることに注意してください。プロパティは1つの言語で1つの値のみを持つ (または言語が未定義のままである可能性がある) ことに注意してください; プロパティは異なる言語で複数の値を持つことも, 複数の言語で単一の値を持つこともできません。

プロパティは常に, "property name element (プロパティ名要素)" と呼ばれるプロパティ名で構成される XML 要素で表されます。最も単純な例は空のプロパティであり, これは存在しないプロパティとは異なります:

<R:title xmlns:R="http://www.example.com/ns/"><R:title>

プロパティの値はプロパティ名要素の内部に表示されます。値は, テキストのみおよび混合コンテンツを含む, あらゆる種類の整形式 XML コンテンツである可能性があります。サーバーは, デッドプロパティの保存と送信において, 次の XML Information Items (情報項目) ([REC-XML-INFOSET] の用語を使用) を保持しなければなりません:

プロパティ名 Element Information Item (要素情報項目) 自体について:

  • [namespace name]
  • [local name]
  • [attributes] "xml:lang" という名前またはスコープ内のそのような属性
  • [children] 型が element または character

プロパティ値内のすべての Element Information Items (要素情報項目) について:

  • [namespace name]
  • [local name]
  • [attributes]
  • [children] 型が element または character

プロパティ値内の Attribute Information Items (属性情報項目) について:

  • [namespace name]
  • [local name]
  • [normalized value]

プロパティ値内の Character Information Items (文字情報項目) について:

  • [character code]

プレフィックスは一部の XML ボキャブラリ (例えば XPath と XML Schema) で使用されるため, サーバーは値内の任意の Information Item (情報項目) について次を保持すべきです:

  • [prefix]

上記にリストされていない XML Infoset 属性はサーバーによって保持される可能性がありますが, クライアントはそれらが保持されることに依存してはなりません。上記の規則は, 特に定義されていない限り, デフォルトでライブプロパティにも適用されます。

サーバーは XML 属性 xml:space を存在する場合無視しなければならず, 空白処理を変更するためにそれを使用してはなりません。プロパティ値内の空白は重要です。

4.3.1 例 - 混合コンテンツを持つプロパティ​

クライアントによって次のように作成されたデッドプロパティ 'author' を考えてみましょう:

<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 -->
    &lt;x:uri type='email'
           added='2005-11-26'>mailto:[email protected]&lt;x:uri>
    &lt;x:uri type='web'
           added='2005-11-27'>http://www.example.com&lt;x:uri>
    &lt;x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
      Jane has been working way &lt;h:em>too&lt;h:em> long on the
      long-awaited revision of <![CDATA[&lt;RFC2518>]]>.
    &lt;x:notes>
  &lt;x:author>
&lt;D:prop>

このプロパティが要求されると, サーバーは次を返す可能性があります:

&lt;D:prop xmlns:D='DAV:'>&lt;author
        xml:lang='en'
        xmlns:x='http://example.com/ns'
        xmlns='http://example.com/ns'
        xmlns:h='http://www.w3.org/1999/xhtml'>
    &lt;x:name>Jane Doe&lt;x:name>
    &lt;x:uri   added="2005-11-26" type="email"
      >mailto:[email protected]&lt;x:uri>
    &lt;x:uri   added="2005-11-27" type="web"
      >http://www.example.com&lt;x:uri>
    &lt;x:notes>
      Jane has been working way &lt;h:em>too&lt;h:em> long on the
      long-awaited revision of &lt;RFC2518&gt;.
    &lt;x:notes>
  &lt;/author>
&lt;D:prop>

この例で注意すべき点:

  • プロパティ名自体の [prefix] は重要ではないため保持されませんでしたが, 他のすべての [prefix] 値は保持されました,
  • 属性値は一重引用符ではなく二重引用符で書き換えられています (引用符のスタイルは重要ではありません), そして属性の順序は保持されていません,
  • xml:lang 属性はプロパティ名要素自体に返されました (プロパティが設定されたときにスコープ内にありましたが, レスポンス内の正確な位置はスコープ内にある限り重要とは見なされません),
  • タグ間の空白はすべての場所で保持されています (属性間の空白はそうではありません),
  • CDATA カプセル化は文字エスケープに置き換えられました (逆も合法です),
  • コメント項目は削除されました (処理命令項目も削除されます)。

実装ノート: クライアントが XML コンテンツを文字単位で保持する必要がある編集シナリオなどのケースがあります (属性の順序や引用符のスタイルなど)。この場合, クライアントは XML 解析で特別な意味を持つすべての文字をエスケープすることにより, テキストのみのプロパティ値を使用することを検討すべきです。

4.4 Property Names (プロパティ名)​

Property name (プロパティ名) は, プロパティの構文とセマンティクスに関する情報を提供するスキーマに関連付けられた普遍的に一意の識別子です。

プロパティの名前は普遍的に一意であるため, クライアントは, 同じサーバー上および異なるサーバー間の複数のリソースにわたって, 特定のプロパティの一貫した動作に依存できます。ただし, そのプロパティが問題のリソース上で "ライブ" であり, ライブプロパティの実装がその定義に忠実である場合に限ります。

XML namespace (名前空間) メカニズム (URIs ([RFC3986]) に基づく) は, 名前空間の衝突を防ぎ, さまざまな程度の管理制御を提供するため, プロパティの命名に使用されます。

プロパティ名前空間はフラットです; つまり, プロパティの階層は明示的に認識されません。したがって, プロパティ A とプロパティ A/B がリソース上に存在する場合, 2つのプロパティ間の関係は認識されません。階層プロパティに関連する問題に対処する別の仕様が最終的に作成されることが期待されています。

最後に, 単一のリソース上で同じプロパティを2回定義することはできません。これはリソースのプロパティ名前空間で衝突を引き起こすためです。

4.5 Source Resources and Output Resources (ソースリソースと出力リソース)​

一部の HTTP リソースはサーバーによって動的に生成されます。これらのリソースについては, そのリソースがどのように生成されるかを制御するソースコードがどこかに存在すると推定されます。ソースファイルと出力 HTTP リソースの関係は, 1対1, 1対多, 多対1, または多対多である可能性があります。HTTP には, リソースが動的であるかどうかを判断する, ましてやそのソースファイルがどこに存在するか, またはそれらをどのように作成するかを判断するメカニズムはありません。この問題は有用に解決されるでしょうが, 相互運用可能な WebDAV 実装は, 静的リソースのみを扱うことによって, 実際にはこの問題を解決せずに広く展開されています。したがって, ソース対出力の問題は本仕様では解決されておらず, 別のドキュメントに延期されています。

5. Collections of Web Resources (Web リソースのコレクション)​

このセクションでは, Web リソースの一種であるコレクションの説明を提供し, HTTP URL 名前空間および HTTP メソッドとの相互作用について説明します。コレクションリソースの目的は, サーバーの名前空間内でコレクションのようなオブジェクト (例えばファイルシステムディレクトリ) をモデル化することです。

すべての DAV 準拠リソースは, ここで指定された HTTP URL 名前空間モデルをサポートしなければなりません。

5.1 HTTP URL Namespace Model (HTTP URL 名前空間モデル)​

HTTP URL 名前空間は階層的な名前空間であり, 階層は "/" 文字で区切られます。

HTTP URL 名前空間が次の条件を満たす場合, 一貫性があると言われます: HTTP 階層内のすべての URL に対して, その URL を内部メンバー URL として含むコレクションが存在します。検討中の名前空間のルートまたはトップレベルコレクションは, 前のルールから除外されます。検討中の名前空間のトップレベルコレクションは, 必ずしも絶対パス '/' によって識別されるコレクションではありません -- 1つ以上のパスセグメントによって識別される可能性があります (例えば, /servlets/webdav/...)

HTTP/1.1 も WebDAV も, HTTP URL 名前空間全体が一貫していることを要求していません -- WebDAV 互換リソースには親コレクションがない場合があります。ただし, 特定の WebDAV メソッドは, 名前空間の不整合を引き起こす結果を生成することが禁止されています。

[RFC2616] と [RFC3986] で暗黙的に示されているように, コレクションリソースを含む任意のリソースは, 複数の URI によって識別される可能性があります。たとえば, リソースは複数の HTTP URL によって識別される可能性があります。

5.2 Collection Resources (コレクションリソース)​

Collection resources (コレクションリソース) は, コンテナとしても機能するという点で他のリソースとは異なります。一部の HTTP メソッドはコレクションにのみ適用されますが, 一部はコレクションによって定義されたコンテナ内の一部またはすべてのリソースに適用されます。メソッドのスコープが明確でない場合, クライアントは適用する深さを指定できます。深さは, ゼロレベル (コレクションのみ), 1レベル (コレクションと直接含まれるリソース), または無限レベル (コレクションと再帰的に含まれるすべてのリソース) のいずれかです。

コレクションの状態は, 少なくともパスセグメントとリソース間のマッピングのセット, およびコレクション自体のプロパティのセットで構成されます。このドキュメントでは, B にマップするパスセグメントマッピングが存在し, それが A に含まれている場合, リソース B はコレクションリソース A に含まれていると言います。コレクションは, 特定のパスセグメントに対して最大1つのマッピングを含まなければなりません。つまり, 同じパスセグメントを複数のリソースにマップすることは違法です。

コレクションで定義されたプロパティは, 非コレクションリソースのプロパティとまったく同じように動作します。コレクションは, GET によって返されるエンティティボディなどの追加の状態を持つ可能性があります。

それぞれ URL "U" と "V" で識別されるすべての WebDAV 準拠リソース A と B について, "V" が "U/SEGMENT" に等しい場合, A は "SEGMENT" から B へのマッピングを含むコレクションでなければなりません。したがって, URL http://example.com/bar/blah を持つリソース B が WebDAV 準拠であり, URL http://example.com/bar/ を持つリソース A が WebDAV 準拠である場合, リソース A はコレクションでなければならず, "blah" から B への正確に1つのマッピングを含まなければなりません。

通常, マッピングは単一のセグメントとリソースで構成されますが, 一般的に, マッピングはセグメントのセットとリソースで構成されます。これにより, サーバーはセグメントのセットを同等として扱うことができます (つまり, すべてのセグメントが同じリソースにマップされるか, どのセグメントもリソースにマップされません)。たとえば, セグメントに対して大文字小文字の折りたたみを実行するサーバーは, セグメント "ab", "Ab", "aB", および "AB" を同等として扱います。クライアントは, これらのセグメントのいずれかを使用してリソースを識別できます。PROPFIND 結果はこれらの同等のセグメントの1つを選択してマッピングを識別するため, マッピングごとに1つの PROPFIND 応答要素があり, マッピング内のセグメントごとに1つではないことに注意してください。

コレクションリソースは, HTTP URL 名前空間階層内の非 WebDAV 準拠リソースへのマッピングを持つ可能性がありますが, 必須ではありません。たとえば, URL http://example.com/bar/blah を持つリソース X が WebDAV 準拠でなく, URL http://example.com/bar/ を持つリソース A が WebDAV コレクションを識別する場合, A は "blah" から X へのマッピングを持つ場合と持たない場合があります。

WebDAV 準拠リソースが HTTP URL 名前空間階層内に WebDAV 準拠の内部メンバーを持たない場合, WebDAV 準拠リソースはコレクションである必要はありません。

コレクションが末尾のスラッシュなしの名前で参照される場合, サーバーは末尾のスラッシュが存在するかのようにリクエストを処理する可能性があるという長年の慣例があります。この場合, "/" で終わる URL を指す Content-Location ヘッダーを応答で返すべきです。たとえば, クライアントが http://example.com/blah (末尾のスラッシュなし) でメソッドを呼び出す場合, サーバーは http://example.com/blah/ (末尾のスラッシュ) で操作が呼び出されたかのように応答し, 値 http://example.com/blah/ の Content-Location ヘッダーを返すべきです。サーバーがコレクションを参照する URL を生成する場所では, サーバーは末尾のスラッシュを含めるべきです。一般に, クライアントはコレクション名の末尾のスラッシュ形式を使用すべきです。クライアントが末尾のスラッシュ形式を使用しない場合, クライアントはリダイレクト応答を見る準備をする必要があります。クライアントは, リソースがコレクションであるかどうかを確認するために, URL よりも DAV:resourcetype プロパティの方が信頼できることがわかります。

クライアントは, WebDAV リソースが非 WebDAV リソース内に含まれるケースをサポートできなければなりません。たとえば, http://example.com/servlet/dav/collection からの OPTIONS 応答が WebDAV サポートを示している場合, クライアントは http://example.com/servlet/dav/ またはその親が必ずしも WebDAV コレクションであるとは仮定できません。

マップされた URL がその親コレクションのメンバーとして表示されない典型的なシナリオは, サーバーが非 WebDAV リソースへのリンクまたはリダイレクトを許可する場合です。たとえば, "/col/link" は "/col/" のメンバーとして表示されない可能性がありますが, サーバーは "/col/link" への GET リクエストに対して 302 ステータスで応答します; したがって, URL "/col/link" は確かにマップされます。同様に, 動的に生成されたページは "/col/index.html" からの URL マッピングを持つ可能性があるため, このリソースは GET リクエストに対して 200 OK で応答する可能性がありますが, "/col/" のメンバーとしては表示されません。

WebDAV 準拠リソースへのマッピングでさえ, 親コレクションに表示されない場合があります。この場合の例は, 各 WebDAV 準拠リソースに対して複数のエイリアス URL をサポートするサーバーです。サーバーは大文字小文字を区別しない URL を実装する可能性があるため, "/col/a" と "/col/A" は同じリソースを識別しますが, "/col" のメンバーをリストする際には "a" または "A" のいずれかのみが報告されます。サーバーがセグメントのセットを同等として扱う場合, サーバーは PROPFIND 応答で一貫して選択された, マッピングごとに1つの優先セグメントのみを公開しなければなりません。

6. Locking (ロック)​

リソースをロックする機能は、そのリソースへのアクセスをシリアライズするメカニズムを提供します。ロックを使用することで、オーサリングクライアントは、編集中に他のプリンシパルがリソースを変更しないという合理的な保証を提供できます。このようにして、クライアントは「更新の損失 (Lost Update)」問題を防ぐことができます。

本仕様では、ロックがクライアント指定の2つのパラメータに基づいて変化することを許可しています：関与するプリンシパルの数（排他ロック vs. 共有ロック）と、付与されるアクセスの種類。本文書では、1つのアクセスタイプのロックのみを定義しています：書き込み (Write)。ただし、構文は拡張可能であり、他のアクセスタイプのロックの最終的な仕様を許可します。

6.1 Lock Model (ロックモデル)​

本セクションでは、WebDAVロックの非規範的な説明を提供します。

ロックはロックトークン (Lock Token) によって識別されます。ロックトークンはURLであり、HTTP経由で送信できます。1つのロックトークンは1つのロックのみに関連付けられます。

ロックは排他的 (Exclusive) または共有 (Shared) にすることができます。ロックのタイプは、サーバーがロックされたリソースに対するリクエストをどのように処理するかを決定します：

排他ロック (Exclusive Lock)：

  • ロックを作成したプリンシパルのみがリソースを変更できます
  • 他のプリンシパルが競合するロックを取得することを防ぎます

共有ロック (Shared Lock)：

  • 複数のプリンシパルが共有ロックを保持できます
  • 共有ロックを保持しているすべてのプリンシパルがリソースを変更できます
  • ロックを保持していないプリンシパルがリソースを変更することを防ぎます

ロックは異なるスコープを持つことができます：

  • 直接ロック (Direct Lock)：ロックはリソースに直接適用されます
  • 深度ロック (Depth Lock)：ロックはリソースとそのすべてのメンバーに適用されます

コレクションの場合、深度 (Depth) を指定できます：

  • Depth: 0：コレクション自体のみをロックします
  • Depth: infinity：コレクションとそのすべてのメンバーをロックします（再帰的）

6.2 Exclusive vs. Shared Locks (排他ロックと共有ロック)​

最も一般的なロックタイプは排他ロック (Exclusive Lock) です。排他ロックの目的は、特定のプリンシパルの編集ポリシーを強制することです。排他ロックの一般的な使用方法は、長時間のオーサリングセッション中に、異なるプリンシパルがリソースを変更するのを防ぐことです。

共有ロック (Shared Lock) は、プリンシパルのグループが同時にリソースを変更する必要がある協調オーサリングをサポートするように設計されています。共有ロックの主要な特性は、複数のプリンシパルが共有ロックを保持できることですが、排他ロックは他のすべてのロックを排除します。

ロック互換性テーブル：

現在の状態共有ロックリクエスト排他ロックリクエスト
なし✅ 可能✅ 可能
共有ロック✅ 可能❌ 不可能
排他ロック❌ 不可能❌ 不可能

6.3 Required Support (必須サポート)​

サーバーは排他書き込みロック (Exclusive Write Lock) をサポートしなければなりません (MUST)。

サーバーは共有書き込みロック (Shared Write Lock) をサポートしてもよい (MAY) です。サーバーが共有書き込みロックをサポートしていない場合、クライアントが共有書き込みロックを要求したときに、サーバーはエラーを返さなければなりません (MUST)。

6.4 Lock Creator and Privileges (ロック作成者と権限)​

ロックは、ロックを作成したプリンシパルに関連付けられます。適切なロックトークンを持つプリンシパルのみがリソースのロックを解除できます。これにより、ロック作成者がロックのライフサイクルを制御できることが保証されます。

ロックを作成するプリンシパルは、リソースにロックを作成する権限を持っている必要があります。具体的な権限要件は、サーバーのアクセス制御ポリシーによって決定されます。

6.5 Lock Tokens (ロックトークン)​

ロックトークン (Lock Token) は、ロックを一意に識別するURLです。ロックトークンは通常、opaquelocktoken: URIスキームを使用します（付録Cを参照）。

ロックトークンの特性：

  • グローバル一意性：各ロックトークンはグローバルに一意です
  • 予測不可能性：ロックトークンは、不正なアクセスを防ぐために予測不可能であるべきです
  • URL形式：ロックトークンは有効なURLです

ロックトークンの例：

opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

クライアントは次の方法でロックトークンを送信します：

  • If ヘッダーにロックトークンを含める
  • Lock-Token ヘッダーにロックトークンを含める（UNLOCKメソッドのみ）

6.6 Lock Timeout (ロックタイムアウト)​

ロックには有限のライフタイムがあります。サーバーは各ロックにタイムアウト値を割り当て、タイムアウト後にロックは自動的に期限切れになります。

タイムアウトの特性：

  • クライアントは Timeout リクエストヘッダーでタイムアウト値を提案できます
  • サーバーはクライアントの提案を無視して、独自のタイムアウト値を割り当てることができます
  • サーバーはロックレスポンスで実際のタイムアウト値を返さなければなりません (MUST)
  • クライアントはロックをリフレッシュすることでロックのライフタイムを延長できます

タイムアウト形式：

Timeout: Second-4100
Timeout: Infinite

ベストプラクティス：

  • サーバーはクライアントがロックをリフレッシュできるようにすべきです (SHOULD)
  • クライアントは長期ロックを定期的にリフレッシュすべきです (SHOULD)
  • クライアントは編集が完了したらリソースのロックを解除すべきです (SHOULD)

6.7 Lock Capability Discovery (ロック機能の発見)​

リソースをロックしようとする前に、クライアントはOPTIONSメソッドを使用してサーバーのロック機能を発見できます。レスポンスの DAV ヘッダーは、ロックサポートを含むサーバーのWebDAV準拠クラスを示します。

6.8 Active Lock Discovery (アクティブロックの発見)​

クライアントは、PROPFINDメソッドを使用して DAV:lockdiscovery プロパティを取得することで、リソース上のアクティブなロックを発見できます。このプロパティには、ロックタイプ、スコープ、深度、オーナー、タイムアウト、ロックトークンなど、リソース上のすべてのアクティブなロックに関する情報が含まれています。

7. Write Lock (書き込みロック)​

本セクションでは、本仕様で定義されている唯一のロックタイプである書き込みロック (Write Lock) について説明します。書き込みロックは、ロック所有者にリソースを変更する権利を付与するロックです。ロック所有者は、ロックを作成したプリンシパルです。

7.1 Write Locks and Properties (書き込みロックとプロパティ)​

書き込みロックを持たないユーザーはリソースのコンテンツを変更できませんが、リソースのデッドプロパティを変更してもよい (MAY) です。これにより、例えば、プリンシパルが書き込みアクセス権を必要とせずに、ロックされたリソースにコメントを追加できます。

ライブプロパティは通常、サーバーによって強制されるセマンティクスを持っています。したがって、サーバーは、リソースがロックされているときにライブプロパティへの変更を許可するかどうか、およびどのように許可するかについて裁量権を持っています。例えば、サーバーは、リソースがロックされている場合でもライブプロパティの変更を許可してもよい (MAY) です。

7.2 Avoiding Lost Updates (更新の損失を回避する)​

書き込みロックの目的は、更新の損失 (Lost Updates) を防ぐことです。更新の損失は、複数のプリンシパルが調整なしにリソースを変更しようとし、その結果、1つ以上のプリンシパルの変更が後続の更新によって上書きされるときに発生します。

書き込みロックはシリアライゼーションメカニズムを提供します：ロックホルダーのみがロックされたリソースを変更できます。これにより、変更が同時ではなく順次発生することが保証され、更新の損失問題を防ぎます。

更新損失シナリオの例（ロックなし）：

  1. ユーザーAがリソースのバージョン1を取得
  2. ユーザーBがリソースのバージョン1を取得
  3. ユーザーAが変更して保存 → バージョン2を作成
  4. ユーザーBが（バージョン1に基づいて）変更して保存 → バージョン3を作成し、Aの変更を上書き

書き込みロックを使用：

  1. ユーザーAがリソースをロック
  2. ユーザーBが変更を試みる → 423 Lockedエラーを受信
  3. ユーザーAが変更してロック解除
  4. ユーザーBがロックして変更可能

7.3 Write Locks and Unmapped URLs (書き込みロックと未マップURL)​

未マップURLへの成功したLOCKリクエストは、ロックされた空のリソースを作成します。このメカニズムにより、クライアントはリソースコンテンツを作成する前にURLを予約できます。

ロックされた空のリソースが作成されるとき：

  • リソースにはコンテンツがありません（長さゼロのエンティティ）
  • リソースは指定されたロックでロックされます
  • 後続のPUTまたはMKCOLでリソースにコンテンツを追加できます
  • ロックトークンをPUTまたはMKCOLリクエストと共に送信する必要があります

この「ロックヌルリソース (Lock-null Resource)」メカニズムは、付録Dで詳しく説明されています。

7.4 Write Locks and Collections (書き込みロックとコレクション)​

コレクションへの書き込みロックは、コレクションリソース自体をロックし、コレクションのメンバーシップへの変更（内部メンバーの追加または削除）を防ぎます。

深度無限のロックがコレクションに適用される場合：

  • コレクション自体がロックされます
  • すべての内部メンバーがロックされます
  • すべての子孫リソースが再帰的にロックされます
  • コレクションに追加された新しいメンバーは自動的にロックされます

ロックの継承：新しいリソースがロックされたコレクション（深度無限）に追加されると、新しいリソースは親コレクションからロックを継承します。

7.5 Write Locks and the If Request Header (書き込みロックとIfリクエストヘッダー)​

クライアントは If リクエストヘッダーを使用してロックトークンを送信します。このヘッダーは、ロックトークンの存在に基づいてメソッドの条件付き実行を可能にします。

If ヘッダー構文は以下をサポートします：

  • 単一のロックトークン
  • 複数のロックトークン（複数のロック用）
  • タグ付きリスト（特定のURLとトークンを関連付ける）
  • NOT条件（ロックの不在を要求）

7.5.1 Example - Write Lock and COPY (例 - 書き込みロックとCOPY)​

COPY /source HTTP/1.1
Host: example.com
Destination: http://example.com/destination
If: `http://example.com/destination` (&lt;opaquelocktoken:token123>)

このリクエストは、クライアントが /destination のロックトークンを保持している場合にのみ、/source を /destination にコピーします。

7.5.2 Example - Deleting a Member of a Locked Collection (例 - ロックされたコレクションのメンバーの削除)​

DELETE /folder/file.txt HTTP/1.1
Host: example.com
If: `http://example.com/folder/` (&lt;opaquelocktoken:folder-token>)

ロックされたコレクションのメンバーを削除するには、クライアントはコレクションのロックトークンを送信する必要があります。

7.6 Write Locks and COPY/MOVE (書き込みロックとCOPY/MOVE)​

COPYメソッドは、宛先に新しいリソースを作成します。ソースがロックされていても、新しいリソースは自動的にロックされません。ロックはコピーされません。

MOVEメソッドは、意味的にはCOPYに続いてDELETEと同等です。リソースが移動されると、ソースのロックは削除されます。宛先は自動的にロックされません。

COPYまたはMOVEの宛先がロックされている場合、クライアントは宛先を上書きするために適切なロックトークンを送信する必要があります。

7.7 Refreshing Write Locks (書き込みロックのリフレッシュ)​

ロックには有限のライフタイムがあります。ロックの早期期限切れを防ぐために、クライアントは次の方法でロックをリフレッシュできます：

  • If ヘッダーに同じロックトークンを含める
  • リクエストボディなし（または空の lockinfo 要素）

サーバーは新しいタイムアウト値で応答します。ロックのリフレッシュにより、ロックが期限切れにならない長期編集セッションが可能になります。

ロックリフレッシュの例：

LOCK /resource HTTP/1.1
Host: example.com
If: (&lt;opaquelocktoken:token123>)
Timeout: Second-3600

サーバーはロックのタイムアウトを延長し、新しい有効期限を返します。

8. General Request and Response Handling (一般的なリクエストとレスポンスの処理)​

8.1 Precedence in Error Handling (エラー処理の優先順位)​

サーバーは他のエラーよりも優先して認証エラーを返さなければなりません。これにより, 保護されたリソースに関する情報の漏洩を回避します (たとえば, クライアントがリソースへの匿名リクエストに対する 423 Locked レスポンスを見ることで隠されたリソースが存在することを発見する場合)。

8.2 Use of XML (XML の使用)​

HTTP/1.1 では, メソッドパラメータ情報は HTTP ヘッダーで排他的にエンコードされていました。HTTP/1.1 とは異なり, WebDAV はメソッドパラメータ情報を XML ([REC-XML]) リクエストエンティティボディまたは HTTP ヘッダーのいずれかでエンコードします。メソッドパラメータをエンコードするために XML を使用する動機は, 既存の構造に追加の XML 要素を追加して拡張性を提供する機能, および ISO 10646 文字セットで情報をエンコードする XML の機能による国際化サポートでした。

メソッドパラメータのエンコードに加えて, WebDAV では XML を使用してメソッドからのレスポンスをエンコードし, メソッド出力および入力に XML の拡張性と国際化の利点を提供します。

リクエストまたはレスポンスボディに XML が使用される場合, Content-Type タイプは application/xml であるべきです。実装はリクエストおよびレスポンスボディで text/xml と application/xml の両方を受け入れなければなりません。text/xml の使用は非推奨です。

すべての DAV 準拠クライアントおよびリソースは, [REC-XML] および [REC-XML-NAMES] に準拠した XML パーサーを使用しなければなりません。リクエストまたはレスポンスで使用されるすべての XML は, 少なくとも整形式であり, 名前空間を正しく使用しなければなりません。サーバーが整形式でない XML を受信した場合, サーバーは 400 (Bad Request) でリクエスト全体を拒否しなければなりません。クライアントがレスポンスで整形式でない XML を受信した場合, クライアントは実行されたメソッドの結果について何も仮定してはならず, サーバーを誤動作として扱うべきです。

信頼できないソースから送信された XML を処理すると, プライバシー, セキュリティ, サービス品質に関連するリスクが発生する可能性があることに注意してください (第 20 節を参照)。サーバーは疑わしいリクエストを拒否できます (それらが整形式の XML で構成されている場合でも), たとえば 400 (Bad Request) ステータスコードと問題を説明するオプションのレスポンスボディで。

8.3 URL Handling (URL 処理)​

URL はリクエストとレスポンスの多くの場所に表示されます。[RFC2518] との相互運用性の経験により, Multi-Status レスポンスを解析する多くのクライアントが [RFC3986] の第 5 節で定義された完全な参照解決を完全に実装していないことが示されました。したがって, 特にサーバーはレスポンスで URL を処理する際に注意する必要があり, クライアントがすべての URL を解釈できるように十分なコンテキストを持つようにする必要があります。このセクションのルールは, Multi-Status レスポンスの 'href' 要素内のリソース URL だけでなく, Destination および If ヘッダーリソース URL にも適用されます。

送信者には 2 つのアプローチの選択肢があります: Request-URI に対して解決される相対参照を使用するか, 完全な URI を使用するかです。サーバーは Multi-Status レスポンス内のすべての 'href' 値が同じ形式を使用することを確保しなければなりません。

WebDAV はその拡張で 1 つの形式の相対参照, つまり絶対パスのみを使用します。

Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )

absolute-URI, path-absolute, query の生成規則は [RFC3986] の第 4.3, 3.3, 3.4 節で定義されています。

Simple-ref 生成規則内で, 送信者は次のことをしてはなりません:

  • ドットセグメント ("." または "..") を使用する, または
  • Request-URI と一致しないプレフィックスを持つ ([RFC2616] の第 3.2.3 節で定義された比較ルールを使用)。

コレクションの識別子は '/' 文字で終わるべきです。

8.3.1 例 - 正しい URL 処理​

内部メンバー URL http://example.com/sample/a%20test を持つコレクション http://example.com/sample/ と以下の PROPFIND リクエストを考えてみましょう:

リクエスト:

PROPFIND /sample/ HTTP/1.1
Host: example.com
Depth: 1

この場合, サーバーは次のいずれかを含む 2 つの 'href' 要素を返すべきです

  • http://example.com/sample/ と http://example.com/sample/a%20test, または
  • /sample/ と /sample/a%20test

サーバーがメンバーリソースを内部的に 'a test' として格納している場合でも, URI 参照内で使用する場合はパーセントエンコードする必要があることに注意してください ([RFC3986] の第 2.1 節を参照)。また, 合法的な URI でも, & 文字などの XML 文字データ内でエスケープする必要がある文字が含まれている可能性があることに注意してください。

8.4 Required Bodies in Requests (リクエストの必須ボディ)​

これらの新しいメソッドの一部はボディを定義していません。サーバーはボディが期待されていない場合でも, すべてのリクエストのボディを検査しなければなりません。リクエストボディが存在するがサーバーによって無視される場合, サーバーは 415 (Unsupported Media Type) でリクエストを拒否しなければなりません。これは (拡張を使用しようとしていた可能性のある) クライアントに, クライアントが意図したようにボディを処理できなかったことを通知します。

8.5 HTTP Headers for Use in WebDAV (WebDAV で使用する HTTP ヘッダー)​

HTTP は WebDAV リクエストとレスポンスで使用できる多くのヘッダーを定義しています。これらのすべてがすべての状況で適切というわけではなく, いくつかの相互作用は未定義の場合があります。HTTP 1.1 は可能であればすべてのレスポンスに Date ヘッダーを要求することに注意してください ([RFC2616] の第 14.18 節を参照)。

サーバーは HTTP 条件ヘッダーをチェックする前に認証チェックを行わなければなりません。

8.6 ETag​

HTTP 1.1 はキャッシュ制御のために変更日ではなく ETags の使用を推奨しており, オーサリングで ETags を優先する理由はさらに強力です。分散オーサリング環境では ETag の正しい使用がさらに重要です。ETag はロックとともに更新の喪失問題を回避するために必要だからです。たとえば, ロックがタイムアウトし, クライアントが偶然オフラインになっているか, 長いアップロードの最中である場合, クライアントはロックの更新に失敗する可能性があります。クライアントがロックの更新に失敗した場合, その間に変更が行われていない限り, リソースは再ロックできる可能性があり, ユーザーは編集を続けることができます。クライアントがこのケースを区別できるようにするには ETag が必要です。そうでない場合, クライアントはユーザーに変更されたかどうかを伝えることさえできずに, サーバー上のリソースを上書きするかどうかをユーザーに尋ねることを余儀なくされます。タイムスタンプはこの問題を ETag ほどうまく解決しません。

強い ETag は弱い ETag よりもオーサリングのユースケースではるかに有用です ([RFC2616] の第 13.3.3 節を参照)。意味的等価性は有用な概念である可能性がありますが, それはドキュメントタイプとアプリケーションタイプに依存し, 相互運用性には本仕様および HTTP の範囲外の何らかの合意または標準が必要になる場合があります。また, 弱い ETag には HTTP で特定の制限があることにも注意してください。たとえば, これらは If-Match ヘッダーで使用できません。

PUT レスポンスの ETag の意味は, このドキュメントでも RFC 2616 でも明確に定義されていないことに注意してください (つまり, ETag がリソースが PUT リクエストのボディとバイト単位で等価であることを意味するのか, またはサーバーが保存時にドキュメントの形式または内容にわずかな変更を加えた可能性があるのか)。これは HTTP の問題であり, 純粋に WebDAV の問題ではありません。

ETag が変更された場合, クライアントはユーザーにプロンプトを表示するか, 変更されたコンテンツを破棄することを余儀なくされる可能性があるため, WebDAV サーバーは変更されていないボディと場所を持つリソースの ETag (または Last-Modified 時間) を変更すべきではありません。ETag はリソースのボディまたはコンテンツの状態を表します。プロパティが変更されたかどうかを判断する同様の方法はありません。

8.7 Including Error Response Bodies (エラーレスポンスボディの含有)​

WebDAV へのバージョン管理拡張の仕様がエラーレスポンスのボディにより具体的な情報を含めるメカニズムを導入するまで ([RFC3253] の第 1.6 節), HTTP と WebDAV はほとんどのエラーレスポンスのボディを機械解析可能な情報に使用していませんでした。エラーボディメカニズムは, ボディを取る可能性があるがまだ定義されたボディを持たない任意のエラーレスポンスで使用するのに適しています。このメカニズムは, ステータスコードが多くのことを意味する可能性がある場合 (たとえば, 400 Bad Request は必要なヘッダーが欠落している, ヘッダーが正しくフォーマットされていないなど) に特に適切です。このエラーボディメカニズムは第 16 節でカバーされています。

8.8 Impact of Namespace Operations on Cache Validators (キャッシュバリデータへの名前空間操作の影響)​

HTTP レスポンスヘッダー "Etag" と "Last-Modified" ([RFC2616] の第 14.19 および 14.29 節を参照) は URL ごと (リソースごとではない) に定義され, クライアントによってキャッシングに使用されることに注意してください。したがって, サーバーは URL 名前空間に影響を与える操作 (COPY, MOVE, DELETE, PUT, MKCOL など) を実行する際にそれらのセマンティクスを保持することを確保しなければなりません。特に:

  • 任意の URL について, "Last-Modified" 値は GET で返される表現が変更されるたびに増加しなければなりません (タイムスタンプ解像度の制限内で)。
  • 任意の URL について, "ETag" 値は GET によって返される異なる表現に再利用してはなりません。

実際には, これはサーバーが

  • より選択的に行うことができない限り, 名前空間操作の宛先名前空間内のすべてのリソースの "Last-Modified" タイムスタンプを増加させる必要がある可能性があり,
  • 同様に, これらのリソースの "ETag" 値を再割り当てする必要がある可能性があります (サーバーがサーバーによって管理される URL 名前空間全体で一意になるようにエンティティタグを割り当てる方法でない限り)。

これらの考慮事項は, 以前にマップされていたが, その後削除された URL で PUT を使用して新しいリソースを作成するなどの特定のユースケースにも適用されることに注意してください。

9. HTTP Methods for Distributed Authoring (分散オーサリングのためのHTTPメソッド)​

本章では、WebDAVによって定義されたHTTPメソッドと既存のHTTPメソッドの拡張について説明します。

WebDAVメソッド概要​

メソッド目的対象
PROPFINDリソースプロパティの取得リソースまたはコレクション
PROPPATCHリソースプロパティの変更リソース
MKCOLコレクションの作成未マップURL
COPYリソースのコピーソースと宛先
MOVEリソースの移動/名前変更ソースと宛先
LOCKリソースのロックリソースまたはコレクション
UNLOCKリソースのロック解除ロックされたリソース

9.1 PROPFIND メソッド​

PROPFINDは、Request-URIで識別されるリソースに定義されたプロパティを取得します。

リクエストタイプ：

  • propname: すべてのプロパティ名を取得
  • allprop: すべてのプロパティを取得
  • prop: 特定のプロパティを取得
  • allprop + include: すべてのプロパティと追加のプロパティを取得

リクエスト例：

PROPFIND /file HTTP/1.1
Host: example.com
Depth: 0

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:">
  &lt;D:prop>
    &lt;D:displayname/>
    &lt;D:getcontentlength/>
  &lt;D:prop>
&lt;D:propfind>

レスポンス: プロパティ値を含む207 Multi-Status

Depthヘッダー：

  • Depth: 0 - 対象リソースのみ
  • Depth: 1 - 対象と直接メンバー
  • Depth: infinity - 対象とすべての子孫

9.2 PROPPATCH メソッド​

PROPPATCHはリソースのプロパティを変更します。

操作：

  • set: プロパティの作成または更新
  • remove: プロパティの削除

例：

PROPPATCH /file HTTP/1.1
Host: example.com

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propertyupdate xmlns:D="DAV:">
  &lt;D:set>
    &lt;D:prop>&lt;D:displayname>新しい名前&lt;D:displayname>&lt;D:prop>
  &lt;D:set>
  &lt;D:remove>
    &lt;D:prop>&lt;D:author/>&lt;D:prop>
  &lt;D:remove>
&lt;D:propertyupdate>

原子性: すべての操作はまとめて成功または失敗しなければなりません (MUST)。

9.3 MKCOL メソッド​

MKCOLは、Request-URIに新しいコレクションリソースを作成します。

例：

MKCOL /new-collection/ HTTP/1.1
Host: example.com

要件：

  • Request-URIは未マップURLでなければなりません (MUST)
  • 親コレクションが存在しなければなりません (MUST)
  • リクエストボディは空であるべきです (SHOULD)

ステータスコード：

  • 201 Created - コレクションが正常に作成された
  • 403 Forbidden - URLにリソースが既に存在する
  • 409 Conflict - 親コレクションが存在しない

9.4 コレクションに対するGET、HEAD​

コレクションに適用されると、GETとHEADは以下を返すことができます (MAY)：

  • HTMLディレクトリリスト
  • コレクションメンバーリスト
  • 空のボディ

動作は実装固有です。

9.5 コレクションに対するPOST​

コレクションに対するPOSTは、メンバーを追加するために使用されます。サーバーが新しいメンバーのURLを決定します。

9.6 DELETE メソッド​

DELETEは、Request-URIで識別されるリソースを削除します。

コレクションの場合：

  • コレクションとすべてのメンバーを再帰的に削除
  • Depth: infinityヘッダーが省略された場合、動作はDepth: infinityと同等

部分失敗: いずれかのメンバーの削除が失敗した場合、操作全体が失敗します（原子性が必要）。

9.7 PUT メソッド​

PUTはリソースを作成または更新します。

書き込みロックとの相互作用：

  • ターゲットがロックされている場合、クライアントはIfヘッダーで適切なロックトークンを送信しなければなりません (MUST)
  • 未マップURLでLOCKが使用された場合、ロックヌルリソースを作成

9.8 COPY メソッド​

COPYは、ソースリソースの複製を宛先に作成します。

ヘッダー：

  • Destination: ターゲットURL（必須）
  • Depth: 0またはinfinity（デフォルト：infinity）
  • Overwrite: T（true）またはF（false）（デフォルト：T）

例：

COPY /source HTTP/1.1
Host: example.com
Destination: http://example.com/dest
Overwrite: F

動作：

  • リソースコンテンツとデッドプロパティをコピー
  • ライブプロパティはその定義に従って処理
  • コレクションのコピーは再帰的（Depth: infinity）
  • ロックはコピーされない

ステータスコード：

  • 201 Created - 宛先が作成された
  • 204 No Content - 宛先が上書きされた
  • 207 Multi-Status - 部分的成功
  • 412 Precondition Failed - Overwrite: Fで宛先が存在

9.9 MOVE メソッド​

MOVEは論理的にCOPY + DELETEと同等です。

例：

MOVE /old-location HTTP/1.1
Host: example.com
Destination: http://example.com/new-location

動作：

  • リソースを宛先に移動
  • リソースを参照するすべてのURLを更新
  • プロパティは保持される
  • ソースのロックは削除される
  • 移動後、宛先はロックされない

原子性: MOVE操作は原子的でなければなりません (MUST)。

9.10 LOCK メソッド​

LOCKはリソースにロックを取得します。

ロックタイプ：

  • 排他書き込みロック: 1つのプリンシパルのみが保持可能
  • 共有書き込みロック: 複数のプリンシパルが保持可能

例：

LOCK /resource HTTP/1.1
Host: example.com
Timeout: Second-3600

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:lockinfo xmlns:D="DAV:">
  &lt;D:lockscope>&lt;D:exclusive/>&lt;D:lockscope>
  &lt;D:locktype>&lt;D:write/>&lt;D:locktype>
  &lt;D:owner>
    &lt;D:href>http://example.com/user&lt;D:href>
  &lt;D:owner>
&lt;D:lockinfo>

レスポンス: ロックトークンを含むlockdiscoveryプロパティを持つ200 OK。

ロックリフレッシュ: Ifヘッダーにロックトークンを含め、ボディなしでLOCKを送信。

9.11 UNLOCK メソッド​

UNLOCKは、ロックトークンで識別されるロックを削除します。

例：

UNLOCK /resource HTTP/1.1
Host: example.com
Lock-Token: &lt;opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>

要件：

  • Lock-Tokenヘッダーにロックトークンを含める必要があります (MUST)
  • ロック作成者または特権プリンシパルのみがロック解除可能

ステータスコード：

  • 204 No Content - ロックが正常に削除された
  • 409 Conflict - リソースがロックされていなかった
  • 423 Locked - 異なるトークンでロックされている

完全なメソッド仕様、エラー処理、詳細な例については、RFC 4918のセクション9.1-9.11を参照してください。

10. HTTP Headers for Distributed Authoring (分散オーサリングのためのHTTPヘッダー)​

WebDAVは、分散オーサリング機能をサポートするために、いくつかの新しいHTTPヘッダーを定義し、既存のヘッダーを拡張しています。

10.1 DAVヘッダー​

目的: WebDAV準拠クラスとサポートされる機能を示します。

構文:

DAV = "DAV" ":" #(compliance-class)
compliance-class = ("1" | "2" | "3" | extend)

例:

DAV: 1, 2, 3

準拠クラス:

  • クラス1: 基本WebDAVサポート (PROPFIND, PROPPATCH, COPY, MOVE, MKCOLなど)
  • クラス2: クラス1 + ロックサポート (LOCK, UNLOCK)
  • クラス3: クラス1 + 順序付きコレクション

使用: OPTIONSレスポンスで返さなければなりません (MUST)。他のレスポンスでも返すことができます (MAY)。

10.2 Depthヘッダー​

目的: コレクションに適用されるメソッドの操作深度を指定します。

構文:

Depth = "Depth" ":" ("0" | "1" | "infinity")

値:

  • 0: 対象リソースのみ
  • 1: 対象と直接の子
  • infinity: 対象とすべての子孫を再帰的に

例:

PROPFIND /collection/ HTTP/1.1
Depth: 1

デフォルト動作:

  • PROPFIND: 省略時はinfinity
  • LOCK: 省略時はinfinity
  • COPY/MOVE: 省略時はinfinity

10.3 Destinationヘッダー​

目的: COPYおよびMOVE操作の宛先URIを指定します。

構文:

Destination = "Destination" ":" Simple-ref

例:

COPY /source HTTP/1.1
Host: example.com
Destination: http://example.com/dest

要件: 絶対URIでなければなりません (MUST)。

10.4 Ifヘッダー​

目的: 状態トークン (ETagまたはロックトークン) に基づく条件付き実行を提供します。

例:

1. 単純なロックトークン送信:

PUT /resource HTTP/1.1
If: (&lt;opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>)

2. 複数条件 (OR):

DELETE /resource HTTP/1.1
If: (&lt;locktoken1>) (&lt;locktoken2>)

3. 複数条件 (AND):

MOVE /resource HTTP/1.1
If: (&lt;locktoken>) (["etag123"])

4. NOT条件:

PUT /resource HTTP/1.1
If: (Not &lt;DAV:no-lock>)

評価:

  • () 内のリストはAND結合
  • 複数のリストはOR結合
  • Not は条件を否定
  • 評価失敗時は412 Precondition Failedを返す

10.5 Lock-Tokenヘッダー​

目的: UNLOCK操作のためのロックトークンを提供します。

構文:

Lock-Token = "Lock-Token" ":" Coded-URL

例:

UNLOCK /resource HTTP/1.1
Lock-Token: &lt;opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>

要件: UNLOCKメソッドで使用しなければなりません (MUST)。

10.6 Overwriteヘッダー​

目的: COPY/MOVEで宛先リソースを上書きするかを指定します。

構文:

Overwrite = "Overwrite" ":" ("T" | "F")

値:

  • T (True): 宛先が存在する場合に上書き (デフォルト)
  • F (False): 宛先が存在する場合は失敗 (412を返す)

例:

COPY /source HTTP/1.1
Destination: http://example.com/dest
Overwrite: F

デフォルト: 省略時はT。

10.7 Timeoutヘッダー​

目的: 要求されるロックタイムアウト期間を指定します。

構文:

Timeout = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite")

例:

LOCK /resource HTTP/1.1
Timeout: Second-3600

LOCK /resource HTTP/1.1
Timeout: Infinite, Second-3600

セマンティクス:

  • Second-n: n秒間のロックを要求
  • Infinite: タイムアウトなしのロックを要求
  • 複数の値は優先順位を示す
  • サーバーがクライアントのリストから選択または独自の値を使用

ヘッダー概要表​

ヘッダーメソッド必須デフォルト値
DAVOPTIONSMUST-1, 2, 3, extend
DepthPROPFIND, LOCK, COPY, MOVEMAYinfinity0, 1, infinity
DestinationCOPY, MOVEMUST-絶対URI
If全てMAY-状態トークン、ETag
Lock-TokenUNLOCKMUST-ロックトークンURI
OverwriteCOPY, MOVEMAYTT, F
TimeoutLOCKMAYサーバー決定Second-n, Infinite

注記: ABNF構文を含む完全なヘッダー仕様については、RFC 4918のセクション10を参照してください。

12. Use of HTTP Status Codes (HTTP ステータスコードの使用)​

これらの HTTP ステータスコードは再定義されていませんが, その使用は WebDAV メソッドと要件によってある程度拡張されています。一般的に, 多くの HTTP ステータスコードは, この文書に記載されているケースだけでなく, 任意のリクエストに対する応答として使用できます。また, WebDAV サーバーは 300 レベルのリダイレクト応答を使用することが知られており (初期の相互運用性テストでは, クライアントがこれらの応答を受け取る準備ができていないことが判明しました), サーバーがリクエストに応答して新しいリソースを作成した場合, 300 レベルの応答を使用してはなりません。

12.1. 412 Precondition Failed (412 事前条件の失敗)​

任意のリクエストには, HTTP で定義された条件付きヘッダー (If-Match, If-Modified-Since など) または本仕様で定義された "If" または "Overwrite" 条件付きヘッダーを含めることができます。サーバーが条件付きヘッダーを評価し, その条件が成立しない場合, このエラーコードを返さなければなりません。一方, クライアントがリクエストに条件付きヘッダーを含めなかった場合, サーバーはこのステータスコードを使用してはなりません。

12.2. 414 Request-URI Too Long (414 リクエスト URI が長すぎます)​

このステータスコードは, HTTP 1.1 では Request-URI にのみ使用され, 他の場所の URI には使用されません。

13. Multi-Status Response (マルチステータス応答)​

Multi-Status 応答は, 複数のステータスコードが適切である可能性がある状況で, 複数のリソースに関する情報を伝達します。デフォルトの Multi-Status 応答ボディは, 'multistatus' ルート要素を持つ text/xml または application/xml HTTP エンティティです。追加の要素には, メソッド呼び出し中に生成された 200, 300, 400, および 500 シリーズのステータスコードが含まれます。100 シリーズのステータスコードは 'response' XML 要素に記録すべきではありません。

'207' が全体的な応答ステータスコードとして使用されますが, 受信者はメソッド実行の成功または失敗に関する詳細情報を得るために multistatus 応答ボディの内容を参照する必要があります。応答は, 成功, 部分的成功, および失敗の状況でも使用できます。

'multistatus' ルート要素は, 任意の順序で 0 個以上の 'response' 要素を保持し, それぞれに個別のリソースに関する情報が含まれます。各 'response' 要素は, リソースを識別するための 'href' 要素を持たなければなりません。

Multi-Status 応答は, ステータスを表すために 2 つの異なる形式のいずれかを使用します:

  1. 'response' 要素の子要素としての 'status' 要素は, 識別されたリソース全体のメッセージ実行のステータスを示します (例えば, セクション 9.6.2 を参照)。一部のメソッド定義は, クライアントが応答で見る準備をしておくべき特定のステータスコードに関する情報を提供します。ただし, クライアントは [RFC2616] のセクション 10 で定義された一般的な規則を使用して, 他のステータスコードを処理できなければなりません。

  2. PROPFIND および PROPPATCH の場合, 'status' の代わりに 'propstat' 要素を使用して形式が拡張され, リソースの個々のプロパティに関する情報を提供します。この形式は PROPFIND および PROPPATCH に固有であり, セクション 9.1 および 9.2 で詳細に説明されています。

13.1. Response Headers (応答ヘッダー)​

HTTP は, Request-URI でアドレス指定されたリソースの優先 URL を示すために Location ヘッダーを定義しています (例えば, 成功した PUT リクエストへの応答またはリダイレクト応答)。ただし, Multi-Status のように応答ボディに URL がある場合, このヘッダーの使用は曖昧さを生じます。したがって, Multi-Status 応答での Location ヘッダーの使用は意図的に未定義です。

13.2. Handling Redirected Child Resources (リダイレクトされた子リソースの処理)​

HTTP 1.1 で定義されたリダイレクト応答 (300-303, 305, および 307) は, 通常 Location ヘッダーを使用して Request-URI からリダイレクトされた単一のリソースの新しい URI を示します。Multi-Status 応答には多くのリソースアドレスが含まれますが, [RFC2518] の元の定義では, サーバーがリダイレクトされたリソースの新しい URI を提供する場所がありませんでした。この仕様では, この情報のための 'location' 要素を定義しています (セクション 14.9 を参照)。サーバーは, Multi-Status のリダイレクト応答でこの新しい要素を使用しなければなりません。

Multi-Status でリダイレクトされたリソースに遭遇したクライアントは, 'location' 要素が新しい URI とともに存在することに依存してはなりません。要素が存在しない場合, クライアントは個々のリダイレクトされたリソースにリクエストを再発行できます。そのリクエストへの応答は, 新しい URI を含む Location ヘッダーでリダイレクトできるためです。

13.3. Internal Status Codes (内部ステータスコード)​

セクション 9.2.1, 9.1.2, 9.6.1, 9.8.3, および 9.9.2 は, Multi-Status 応答で使用されるさまざまなステータスコードを定義しています。この仕様は, これらの応答に表示される可能性のある他のステータスコードの意味を定義していません。

16. Precondition/Postcondition XML Elements (事前/事後条件 XML 要素)​

セクション 8.7 で紹介されたように, エラー条件に関する追加情報は, 多くのステータス応答のボディに含めることができます。このセクションでは, エラーボディメカニズムの使用に関する要件を設定し, 多数の事前条件および事後条件コードを導入します。

メソッドの "事前条件 (precondition)" は, そのメソッドを実行するために真でなければならないサーバーの状態を記述します。メソッドの "事後条件 (postcondition)" は, そのメソッドが完了した後に真でなければならないサーバーの状態を記述します。

各事前条件および事後条件には, それに関連付けられた一意の XML 要素があります。207 Multi-Status 応答では, XML 要素は, 条件が 1 つ以上のプロパティに適用されるか, リソース全体に適用されるかに応じて, 適切な 'propstat または 'response' 要素内の 'error' 要素内に表示されなければなりません。この仕様の 'error' ボディが使用される他のすべてのエラー応答では, リクエストによって別途ネゴシエートされない限り, 事前条件/事後条件 XML 要素は, 適切な応答ステータスとともに, 応答ボディ内のトップレベルの 'error' 要素の子として返されなければなりません。最も一般的な応答ステータスコードは, リクエストが常に失敗するため繰り返すべきでない場合は 403 (Forbidden), ユーザーが競合を解決してリクエストを再送信できると予想される場合は 409 (Conflict) です。'error' 要素は特定のエラー情報を含む子要素を含むことができ, 任意のカスタム子要素で拡張できます。

このメカニズムは, ここまたは HTTP で定義されている正しい数値ステータスコードを使用することに代わるものではありません。クライアントは常に数値コードのみに基づいて妥当な行動方針を取ることができなければならないからです。ただし, 新しい数値コードを定義する必要はなくなります。この目的で使用される新しい機械可読コードは, 事前条件および事後条件として分類される XML 要素であるため, 当然, 新しい条件コードを定義するグループは独自の名前空間を使用できます。いつものように, "DAV:" 名前空間は IETF 認可の WebDAV ワーキンググループによる使用のために予約されています。

この仕様をサポートするサーバーは, このドキュメントで定義されている事前条件または事後条件が違反されるたびに XML エラーを使用すべきです。このドキュメントで指定されていないエラー条件の場合, サーバーは適切な数値ステータスを選択し, 応答ボディを空白のままにすることができます。ただし, クライアントが条件コードを自動的に認識しない場合でも, 相互運用性テストやデバッグに非常に役立つため, サーバーは代わりにカスタム条件コードやその他のサポートテキストを使用できます。

例 - 事前条件コード付き応答:

HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:error xmlns:D="DAV:">
  &lt;D:lock-token-submitted>
    &lt;D:href>/workspace/webdav/&lt;D:href>
  &lt;D:lock-token-submitted>
&lt;D:error>

この例では, 親コレクション "/workspace/webdav/" の深さ無限ロックを認識していないクライアントが, コレクションメンバー "/workspace/webdav/proposal.doc" を変更しようとしました。

その他の有用な事前条件および事後条件は, [RFC3744] (特にセクション 7.1.1 を参照), [RFC3253], および [RFC3648] など, WebDAV を拡張する他の仕様で定義されています。

これらのすべての要素は "DAV:" 名前空間にあります。特に指定されていない限り, 各条件の XML 要素の内容は空と定義されています。

lock-token-matches-request-uri​

名前 (Name): lock-token-matches-request-uri

使用 (Use with): 409 Conflict

目的 (Purpose): (事前条件) -- リクエストには, UNLOCK メソッドのロックを識別するための Lock-Token ヘッダーが含まれる場合があります。ただし, Request-URI がトークンによって識別されるロックのスコープ内にない場合, サーバーはこのエラーを使用すべきです。ロックに Request-URI を含まないスコープがある場合, ロックが消失した場合, またはトークンが無効な場合があります。

lock-token-submitted​

名前 (Name): lock-token-submitted (事前条件)

使用 (Use with): 423 Locked

目的 (Purpose): ロックトークンを送信する必要があったため, リクエストは成功しませんでした。この要素が存在する場合, リクエストを妨げたロックされたリソースの URL を少なくとも 1 つ含まなければなりません。コレクションロックが関与する MOVE, COPY, および DELETE の場合, どのロックされたリソースがリクエストを失敗させたかをクライアントが見つけるのは困難な場合がありますが, サーバーはそのようなロックされたリソースを 1 つだけ返す責任があります。サーバーがすべてを知っている場合, リクエストの成功を妨げたすべてのロックされたリソースを返すことができます。

&lt;!ELEMENT lock-token-submitted (href+) >

no-conflicting-lock​

名前 (Name): no-conflicting-lock (事前条件)

使用 (Use with): 通常 423 Locked

目的 (Purpose): すでに存在する競合するロックの存在により, LOCK リクエストが失敗しました。リクエストが向けられたリソースが間接的にのみロックされている場合でも, ロックは競合する可能性があることに注意してください。この場合, 事前条件コードを使用して, "lockdiscovery" プロパティの個別のルックアップを回避し, 競合するロックのルートであるリソースについてクライアントに通知できます。

&lt;!ELEMENT no-conflicting-lock (href)* >

no-external-entities​

名前 (Name): no-external-entities

使用 (Use with): 403 Forbidden

目的 (Purpose): (事前条件) -- リクエストボディに外部エンティティが含まれているためにサーバーがクライアントリクエストを拒否する場合, サーバーはこのエラーを使用すべきです。

preserved-live-properties​

名前 (Name): preserved-live-properties

使用 (Use with): 409 Conflict

目的 (Purpose): (事後条件) -- サーバーは他の点では有効な MOVE または COPY リクエストを受信しましたが, 宛先で同じ動作を持つライブプロパティを維持できません。サーバーがリポジトリの一部のパートでのみ一部のライブプロパティをサポートしている場合, または単に内部エラーがある場合があります。

propfind-finite-depth​

名前 (Name): propfind-finite-depth

使用 (Use with): 403 Forbidden

目的 (Purpose): (事前条件) -- このサーバーは, コレクションに対する無限深度の PROPFIND リクエストを許可しません。

cannot-modify-protected-property​

名前 (Name): cannot-modify-protected-property

使用 (Use with): 403 Forbidden

目的 (Purpose): (事前条件) -- クライアントは PROPPATCH で保護されたプロパティ (DAV:getetag など) を設定しようとしました。[RFC3253] のセクション 3.12 も参照してください。

17. XML Extensibility in DAV (DAV における XML 拡張性)​

この仕様では, 他の要素名との衝突を恐れることなく新しい XML 要素を追加できるようにするために, XML 名前空間拡張 ([REC-XML-NAMES]) が使用されています。WebDAV リクエストおよびレスポンスボディは任意の XML 要素で拡張でき, メッセージ受信者はそれらを無視できますが, "DAV:" 名前空間の XML 要素は, その XML 要素が WebDAV ワーキンググループによってレビューされた IETF RFC で明示的に定義されていない限り, リクエストまたはレスポンスボディで使用すべきではありません。

WebDAV が拡張可能かつ下位互換性を持つためには, クライアントとサーバーの両方が予期しないまたは認識されないコマンド拡張を受信したときにどのように動作するかを知る必要があります。XML 処理の場合, これはクライアントとサーバーが受信した XML ドキュメントを, 予期しない要素と属性 (および認識されない要素のすべての子) が存在しないかのように処理しなければならないことを意味します。予期しない要素または属性には, 別のコンテキストで使用される可能性があるが, ここでは予期されていないものが含まれます。処理の目的でそのような項目を無視することは, もちろんすべての情報をログに記録することやデバッグのために提示することと一致する可能性があります。

この制限は, プロパティのスキーマが別途宣言していない限り予期しない XML 要素を無視すべき, クライアントによる DAV プロパティ値の処理にも適用されます。

この制限は, サーバーがすべての XML 要素を記録しなければならない, サーバー上での死んだ DAV プロパティの設定には適用されません。

さらに, この制限は, XML がエンティティボディのコンテンツタイプである XML の使用には適用されません。たとえば, PUT のボディとして使用される場合などです。

XML の処理命令は受信者によって無視されるべきです。したがって, WebDAV を拡張する仕様は, 規範的な動作を定義するために処理命令を使用すべきではありません。

この仕様で定義されているすべての XML 要素に対して XML DTD フラグメントが含まれています。ただし, 名前空間の使用と拡張ルールにより, 正しい XML は DTD に従って有効ではありません。特に:

  • 要素 (この仕様から) は "DAV:" 名前空間にあります,
  • 特に明記されていない限り, 要素の順序は無関係です,
  • 拡張属性を追加できます,
  • "ANY" の要素型定義の場合, その要素の規範的なテキスト定義が, そこに何を含めることができ, それが何を意味するかを定義します。
  • "#PCDATA" の要素型定義の場合, 拡張要素を追加してはなりません。
  • "EMPTY" を含む他の要素型定義の場合, 拡張要素を追加できます。

これは, 要素を含む要素はテキストを含むように拡張できず, その逆も同様であることを意味することに注意してください。

上記のルールによって DTD 検証が緩和された状態では, DTD フラグメントによって記述される制約は規範的です (たとえば, 付録 A を参照)。XML ボディを持つ WebDAV メッセージの受信者は, ハードコードされたまたは動的に宣言された DTD に従って XML ドキュメントを検証してはなりません。

このセクションでは下位互換性のある拡張性ルールについて説明していることに注意してください。拡張が下位互換性を持たないように設計される場合もあります。たとえば, この仕様の DTD で必要な子要素の 1 つを省略して, このドキュメントで定義された XML 要素を再利用する拡張を定義する場合などです。

18. DAV Compliance Classes (DAV コンプライアンスクラス)​

DAV 準拠リソースは, いくつかのコンプライアンスクラスを宣伝できます。クライアントは, リソースで OPTIONS を実行し, 返される "DAV" ヘッダーを調べることで, リソースのコンプライアンスクラスを発見できます。特に, 準拠しているとして語られるのはサーバーではなくリソースであることに注意してください。これは, 理論的にはサーバー上の一部のリソースが異なる機能セットをサポートできるためです。たとえば, サーバーには, すべてのサブリポジトリでその機能がサポートされていなくても, バージョン管理などの高度な機能がサポートされているサブリポジトリがある可能性があります。

このドキュメントは HTTP/1.1 プロトコルの拡張について説明しているため, 最低限すべての DAV 準拠リソース, クライアント, およびプロキシは [RFC2616] に準拠しなければなりません。

クラス 2 またはクラス 3 に準拠するリソースは, クラス 1 にも準拠しなければなりません。

18.1. Class 1 (クラス 1)​

クラス 1 準拠リソースは, このドキュメントのすべてのセクションのすべての "しなければならない" 要件を満たさなければなりません。

クラス 1 準拠リソースは, OPTIONS メソッドへのすべての応答の DAV ヘッダーで, 最低限値 "1" を返さなければなりません。

18.2. Class 2 (クラス 2)​

クラス 2 準拠リソースは, すべてのクラス 1 要件を満たし, LOCK メソッド, DAV:supportedlock プロパティ, DAV:lockdiscovery プロパティ, Time-Out レスポンスヘッダー, および Lock-Token リクエストヘッダーをサポートしなければなりません。クラス 2 準拠リソースは, Timeout リクエストヘッダーと 'owner' XML 要素もサポートすべきです。

クラス 2 準拠リソースは, OPTIONS メソッドへのすべての応答の DAV ヘッダーで, 最低限値 "1" と "2" を返さなければなりません。

18.3. Class 3 (クラス 3)​

リソースは, このドキュメントで行われた [RFC2518] への改訂のサポートを明示的に宣伝できます。クラス 1 もサポートされなければなりません。クラス 2 はサポートされる場合があります。クラス 1 および 2 に加えてクラス 3 サポートを宣伝することは, サーバーがこの仕様のすべての要件をサポートすることを意味します。クラス 3 とクラス 1 のサポートを宣伝するが, クラス 2 のサポートを宣伝しないことは, サーバーがロックサポートに関係する要件を除いて, この仕様のすべての要件をサポートすることを意味します。

例:

DAV: 1, 3

19. Internationalization Considerations (国際化に関する考慮事項)​

国際化の領域において、本仕様は IETF 文字セットポリシー [RFC2277] に準拠しています。本仕様では、人間が読める形式のフィールドは、プロパティの値、またはレスポンスエンティティボディで返されるエラーメッセージのいずれかに含まれます。いずれの場合も、人間が読める形式のコンテンツは XML を使用してエンコードされます。XML には文字セットのタグ付けとエンコードに関する明示的な規定があり、XML プロセッサが少なくとも ISO 10646 多言語プレーンの UTF-8 [RFC3629] および UTF-16 [RFC2781] エンコードを使用してエンコードされた XML 要素を読み取ることを要求しています。本仕様の XML 例では、Content-Type ヘッダーの charset パラメータ ([RFC3023] で定義) と XML charset 宣言の使用を示しています。

XML は、特定の XML 要素のコンテンツの言語を指定するための言語タグ付け機能も提供します。"xml:lang" 属性は XML 要素に表示され、そのコンテンツと属性の言語を識別します。値とスコープの定義については、[REC-XML] を参照してください。

WebDAV アプリケーションは、XML 仕様の文字セットタグ付け、文字セットエンコーディング、および言語タグ付け機能をサポートしなければなりません (MUST)。WebDAV アプリケーションの実装者は、XML トランスポートに使用する MIME メディアタイプと Content-Type ヘッダーの charset パラメータの使用に関する説明について、"XML Media Types" [RFC3023] を読むことを強く推奨します。

本仕様内で使用される名前は、4つのカテゴリに分類されます: メソッドやヘッダーなどのプロトコル要素の名前、XML 要素の名前、プロパティの名前、および条件の名前です。プロトコル要素の命名は HTTP の先例に従い、メソッドとヘッダーに US-ASCII でエンコードされた英語名を使用します。これらのプロトコル要素はユーザーには表示されず、単に長いトークン識別子であるため、複数の言語をサポートする必要はありません。同様に、本仕様で使用される XML 要素の名前はユーザーには表示されないため、複数の言語をサポートする必要はありません。

WebDAV プロパティ名は修飾された XML 名 (XML 名前空間名とローカル名のペア) です。一部のアプリケーション (例: 汎用プロパティビューア) はプロパティ名を直接ユーザーに表示しますが、典型的なアプリケーションは固定されたプロパティセットを使用し、プロパティ名をユーザーに表示する際にプロパティ名と名前空間から人間が読める形式のフィールドへのマッピングを提供することが期待されます。プロパティのセットが事前に分からない場合にのみ、アプリケーションはユーザーにプロパティ名を表示する必要があります。可能な限り、アプリケーションが人間が読める形式のプロパティ名を提供することを推奨します。

エラー報告については、HTTP/1.1 ステータスコードの慣例に従い、各ステータスコードにコードの短い英語の説明 (例: 423 (Locked)) を含めます。不適切に作成されたユーザーエージェントがこのメッセージをユーザーに表示する可能性はありますが、国際化されたアプリケーションはこのメッセージを無視し、ユーザーの言語と文字セットで適切なメッセージを表示します。

クライアントとサーバーの相互運用にはロケール情報は必要ないため、本仕様ではこの情報の送信メカニズムを指定していません。

20. Security Considerations (セキュリティに関する考慮事項)​

このセクションでは、WebDAV アプリケーションが認識する必要があるセキュリティへの影響に関する問題について詳しく説明します。

HTTP/1.1 のすべてのセキュリティ上の考慮事項 ([RFC2616] で議論) と XML のすべてのセキュリティ上の考慮事項 ([RFC3023] で議論) も WebDAV に適用されます。さらに、リモートオーサリングに固有のセキュリティリスクには、より強力な認証技術が必要であり、いくつかの新しいプライバシーの懸念が導入され、不適切なサーバー設計による危険が増す可能性があります。これらの問題を以下に詳しく説明します。

20.1. Authentication of Clients (クライアントの認証)​

オーサリングを重視するため、WebDAV サーバーは、ネットワークリソースへのアクセスだけでなく、リソースの整合性も保護するために認証技術を使用する必要があります。さらに、ロック機能の導入には、認証のサポートが必要です。

パスワードが傍受される可能性があるため、安全でないチャネルを介して平文で送信されるパスワードは、リソースのアクセス可能性と整合性を保護するための不十分な手段です。HTTP/1.1 の基本認証は本質的にパスワードの平文送信を実行するため、接続が安全でない限り、基本認証を使用して WebDAV クライアントをサーバーに認証してはなりません (MUST NOT)。さらに、接続が安全でない限り、WebDAV サーバーは WWW-Authenticate ヘッダーで基本認証チャレンジを送信してはなりません (MUST NOT)。安全な接続の例としては、強力な暗号スイートとサーバー認証を使用するトランスポート層セキュリティ (TLS) 接続があります。

WebDAV アプリケーションはダイジェスト認証スキーム [RFC2617] をサポートしなければなりません (MUST)。ダイジェスト認証は、その秘密を平文で送信することなく、通信の両当事者が共有秘密 (パスワード) を知っていることを検証するため、基本認証に固有のセキュリティ問題を回避しながら、幅広いシナリオで役立つレベルの認証を提供します。

20.2. Denial of Service (サービス拒否)​

サービス拒否攻撃は、WebDAV サーバーにとって特に懸念される問題です。WebDAV と HTTP を組み合わせることで、システムリソースのあらゆる部分に対してサービス拒否攻撃が可能になります。

  • 非常に大きなファイルを PUT することで、基盤となるストレージが攻撃される可能性があります。
  • 大規模なコレクションに対して再帰的な操作を要求することで、処理時間が攻撃される可能性があります。
  • 複数の接続で複数のパイプライン化されたリクエストを行うことで、ネットワーク接続が攻撃される可能性があります。

WebDAV サーバーは、すべてのレベルでサービス拒否攻撃の可能性を認識する必要があります。このような攻撃に対する適切な応答は、単に接続をドロップすることかもしれません (MAY)。または、サーバーが応答できる場合、サーバーは 400 (Bad Request) などの 400 レベルのステータスリクエストを使用し、リクエストが拒否された理由を示すことができます (MAY) (500 レベルのステータス応答は問題がサーバーにあることを示しますが、意図しない DoS 攻撃はクライアントが修正できるものです)。

20.3. Security through Obscurity (隠蔽によるセキュリティ)​

WebDAV は、PROPFIND メソッドを通じて、コレクションのメンバーリソースをリストするメカニズムを提供します。これにより、ネットワークリソースの名前を発見することの困難性のみに依存するセキュリティまたはプライバシー技術の有効性が大幅に低下します。WebDAV サーバーのユーザーは、リソース名の相対的な隠蔽性に依存するのではなく、アクセス制御技術を使用してリソースへの望ましくないアクセスを防ぐことが推奨されます。

20.4. Privacy Issues Connected to Locks (ロックに関連するプライバシーの問題)​

ロックリクエストを送信するとき、ユーザーエージェントは、ロックを取得している人の連絡先情報を提供する 'owner' XML フィールドも送信することができます (人間がロックを取得している場合、ロボットではない場合)。この連絡先情報は、リソースの DAV:lockdiscovery プロパティに保存され、他の協力者がリソースへのアクセスについて交渉を開始するために使用できます。ただし、多くの場合、この連絡先情報は非常にプライベートである可能性があり、広く配布すべきではありません。サーバーは、適切に DAV:lockdiscovery プロパティへの読み取りアクセスを制限すべきです (SHOULD)。さらに、ユーザーエージェントは、連絡先情報を送信するかどうか、および連絡先情報が送信される場合、正確にどの情報が送信されるかについての制御を提供すべきです (SHOULD)。

20.5. Privacy Issues Connected to Properties (プロパティに関連するプライバシーの問題)​

プロパティ値は通常、ドキュメントの作成者などの情報を保持するために使用されるため、リソースのプロパティデータへの広範なアクセスから生じるプライバシーの懸念が生じる可能性があります。プロパティを介した私的情報の不注意な漏洩のリスクを減らすために、サーバーは、リソース本体への読み取りアクセスとリソースのプロパティへの読み取りアクセスを分離するアクセス制御メカニズムを開発することが推奨されます。これにより、ユーザーは、リソースのコンテンツへのアクセスを過度に制限することなく、プロパティデータの配布を制御できます。

20.6. Implications of XML Entities (XML エンティティの影響)​

XML は、[REC-XML] のセクション 4.2.2 で定義されている "外部エンティティ" として知られる機能をサポートしており、XML プロセッサに追加の XML を取得して含めるように指示します。外部 XML エンティティは、XML ドキュメントに関連付けられたドキュメントタイプ宣言 (DTD) を追加または変更するために使用できます。外部 XML エンティティは、XML ドキュメントのコンテンツ内に XML を含めるためにも使用できます。本仕様で使用される XML のような非検証 XML の場合、外部 XML エンティティを含めることは XML では必須ではありません。ただし、XML は、XML プロセッサが独自の裁量で外部 XML エンティティを含めることができると述べています。

外部 XML エンティティには固有の信頼性がなく、あらゆる HTTP GET リクエストに蔓延しているすべての攻撃の影響を受けます。さらに、外部 XML エンティティが DTD を変更する可能性があり、したがって XML ドキュメントの最終形式に影響を与え、最悪の場合、そのセマンティクスを大幅に変更したり、XML プロセッサを [RFC3023] で議論されているセキュリティリスクにさらしたりする可能性があります。したがって、実装者は、外部 XML エンティティを信頼できないものとして扱う必要があることを認識する必要があります。サーバーが外部 XML エンティティを処理しないことを選択した場合、外部エンティティを含むリクエストに 'no-external-entities' 条件コードで応答すべきです (SHOULD)。

外部 XML エンティティを使用する広く展開されたアプリケーションに伴うスケーラビリティリスクもあります。この状況では、1 つの外部 XML エンティティに対する大量のリクエストが発生する可能性があり、外部 XML エンティティを含むリソースに対するリクエストを処理するサーバーが過負荷になる可能性があります。

さらに、[REC-XML] のセクション 4.2.2 で定義されている "内部エンティティ" の評価に基づくリスクもあります。ネストされた内部エンティティを使用して慎重に作成された小さなリクエストは、処理に膨大な量のメモリおよび/または処理時間を必要とする場合があります。サーバー実装者はこのリスクを認識し、このようなリクエストを可能な限り早期に検出して拒否できるように XML パーサーを構成する必要があります。

20.7. Risks Connected with Lock Tokens (ロックトークンに関連するリスク)​

本仕様は、空間と時間にわたってその一意性を保証するために、ロックトークン (セクション 6.5) に "通用一意識別子 (UUID) URN 名前空間" ([RFC4122]) の使用を推奨しています。バージョン 1 UUID (セクション 4 で定義) には、"IEEE 802 MAC アドレス (通常はホストアドレス) で構成される" "node" フィールドが含まれる場合があります (MAY)。複数の IEEE アドレスを持つシステムの場合、利用可能な任意のアドレスを使用できます"。WebDAV サーバーはその存続期間中に多くのロックを発行するため、IEEE 802 アドレスも公開される可能性があります。

IEEE 802 アドレスの公開に関連するいくつかのリスクがあります。IEEE 802 アドレスを使用すると:

  • サブネットからサブネットへのハードウェアの移動を追跡することが可能です。
  • WebDAV サーバーを実行しているハードウェアの製造元を特定できる可能性があります。
  • WebDAV を実行している各タイプのコンピューターの数を決定できる可能性があります。

このリスクは、ホストアドレスベースの UUID バージョンにのみ適用されます。[RFC4122] のセクション 4 では、ホストアドレスを含まないため、このリスクの影響を受けない UUID を生成するためのいくつかの他のメカニズムが説明されています。

20.8. Hosting Malicious Content (悪意のあるコンテンツのホスティング)​

HTTP には、クライアントマシンで実行されるプログラムをホストする機能があります。これらのプログラムは、Web スクリプト、実行可能ファイル、プラグインモジュール、ドキュメント内のマクロなど、さまざまな形式をとることができます。WebDAV は、これらのプログラムに関するセキュリティ上の懸念を変更しませんが、WebDAV は多くの場合、幅広いユーザーがサーバー上にドキュメントを公開できるコンテキストで使用されます。サーバーは、ドキュメントを公開している作成者と緊密な信頼関係を持っていない可能性があります。クライアントが任意のコンテンツを公開できるようにするサーバーは、サーバーに公開されたコンテンツが他のクライアントに有害でないことを確認するための予防措置を有効に実装できます。サーバーは、公開が許可されているコンテンツのタイプを制限したり、公開されたコンテンツでウイルスおよびマルウェア検出ソフトウェアを実行したりするなどの技術によってこれを行うことができます。サーバーは、サーバーにコンテンツを公開することが許可されているユーザーの適切なアクセス制限と認証を行うことで、リスクを軽減することもできます。

21. IANA Considerations (IANA に関する考慮事項)​

21.1. New URI Schemes (新しい URI スキーム)​

本仕様は 2 つの URI スキームを定義します:

  1. 附録 C で定義されている "opaquelocktoken" スキーム、および

  2. "DAV" URI スキーム。これは歴史的に [RFC2518] で WebDAV プロパティと XML 要素名を明確に区別するために使用され、本仕様およびその他の WebDAV を拡張する仕様でその目的のために引き続き使用されています。"DAV:" 名前空間内の識別子の作成は IETF によって制御されています。

XML 名前空間に新しい URI スキームを定義することは現在推奨されていないことに注意してください。"DAV:" は標準的なベストプラクティスが確立される前に定義されました。

21.2. XML Namespaces (XML 名前空間)​

XML 名前空間は WebDAV プロパティ名と XML 要素を明確に区別します。任意の WebDAV ユーザーまたはアプリケーションは、カスタムプロパティを作成したり WebDAV XML 構文を拡張したりするために新しい名前空間を定義できます。IANA はそのような名前空間、プロパティ名、または要素名を管理する必要はありません。

21.3. Message Header Fields (メッセージヘッダーフィールド)​

以下のメッセージヘッダーフィールドは永続レジストリに追加されるべきです ([RFC3864] を参照)。

21.3.1. DAV​

Header field name (ヘッダーフィールド名): DAV

Applicable protocol (適用可能なプロトコル): http

Status (ステータス): standard

Author/Change controller (作成者/変更管理者): IETF

Specification document (仕様文書): this specification (Section 10.1)

21.3.2. Depth​

Header field name (ヘッダーフィールド名): Depth

Applicable protocol (適用可能なプロトコル): http

Status (ステータス): standard

Author/Change controller (作成者/変更管理者): IETF

Specification document (仕様文書): this specification (Section 10.2)

21.3.3. Destination​

Header field name (ヘッダーフィールド名): Destination

Applicable protocol (適用可能なプロトコル): http

Status (ステータス): standard

Author/Change controller (作成者/変更管理者): IETF

Specification document (仕様文書): this specification (Section 10.3)

21.3.4. If​

Header field name (ヘッダーフィールド名): If

Applicable protocol (適用可能なプロトコル): http

Status (ステータス): standard

Author/Change controller (作成者/変更管理者): IETF

Specification document (仕様文書): this specification (Section 10.4)

21.3.5. Lock-Token​

Header field name (ヘッダーフィールド名): Lock-Token

Applicable protocol (適用可能なプロトコル): http

Status (ステータス): standard

Author/Change controller (作成者/変更管理者): IETF

Specification document (仕様文書): this specification (Section 10.5)

21.3.6. Overwrite​

Header field name (ヘッダーフィールド名): Overwrite

Applicable protocol (適用可能なプロトコル): http

Status (ステータス): standard

Author/Change controller (作成者/変更管理者): IETF

Specification document (仕様文書): this specification (Section 10.6)

21.3.7. Timeout​

Header field name (ヘッダーフィールド名): Timeout

Applicable protocol (適用可能なプロトコル): http

Status (ステータス): standard

Author/Change controller (作成者/変更管理者): IETF

Specification document (仕様文書): this specification (Section 10.7)

21.4. HTTP Status Codes (HTTP ステータスコード)​

本仕様は以下の HTTP ステータスコードを定義します

  • 207 Multi-Status (Section 11.1)
  • 422 Unprocessable Entity (Section 11.2),
  • 423 Locked (Section 11.3),
  • 424 Failed Dependency (Section 11.4) および
  • 507 Insufficient Storage (Section 11.5),

これらは http://www.iana.org/assignments/http-status-codes のレジストリで更新される必要があります。

注意: HTTP ステータスコード 102 (Processing) は本仕様から削除されました。その IANA 登録は引き続き RFC 2518 を参照すべきです。

22. Acknowledgements (謝辞)​

このような仕様は、鋭い批判的レビューによって繁栄し、無関心な放置によって衰退します。著者は、私たちの作業のあらゆる段階で非常に価値のある洞察を提供してくれた以下の人々の貢献に心から感謝します。

RFC 2518 への貢献者​

Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, および Lauren Wood。

このリストから 2 人が特別な言及に値します。Larry Masinter の貢献は非常に貴重でした。彼はワーキンググループの形成を支援し、途中で著者たちを辛抱強く指導しました。彼は私たちが達成しようと努力してきた高い基準を多くの方法で設定しました。Judith Slein の貢献も非常に貴重でした。要件を明確にし、バージョンごとに辛抱強くレビューすることで、彼女はこの仕様を改善し、ドキュメント管理に関する私たちの考えを広げました。

また、XML DTD を開発してくれた John Turner にも感謝します。

RFC 2518 の著者は Yaron Goland、Jim Whitehead、A. Faizi、Steve Carter、および D. Jensen でした。IETF の著者数制限により彼らの名前を削除する必要がありましたが、彼らは WebDAV の設計の大部分について功績を認められます。

本仕様に対する追加の謝辞​

本仕様のテキストの重要な貢献者は、以下のセクションに貢献者として記載されています。また、リストや会議で特定のテキストを練り上げてくれた Geoff Clemm、Joel Soderberg、Dan Brotsky にも心から感謝します。Joe Hildebrand と Cullen Jennings は多くの問題の解決を支援しました。Barry Lind は追加のセキュリティ上の考慮事項を説明し、Cullen Jennings はその考慮事項のテキストを提供しました。Jason Crawford は数年間この文書の問題ステータスを追跡し、その後 Elias Sinderson が続けました。

附録 A. Notes on Processing XML Elements (XML要素の処理に関する注意事項)​

A.1. Notes on Empty XML Elements (空のXML要素に関する注意事項)​

XMLは、XML要素がコンテンツを持たないことを示すための2つのメカニズムをサポートしています。1つ目は、&lt;A>&lt;/A> という形式のXML要素を宣言することです。2つ目は、&lt;A/> という形式のXML要素を宣言することです。この2つのXML要素は意味的に同一です。

A.2. Notes on Illegal XML Processing (不正なXML処理に関する注意事項)​

XMLは柔軟なデータ形式であり、合法に見えるが実際にはそうではないデータを簡単に送信できます。「受け入れる際には柔軟に、送信する際には厳密に」という哲学は依然として適用されますが、不適切に適用してはなりません。XMLは、空白、要素の順序、新しい要素の挿入などの問題を扱う際に非常に柔軟です。この柔軟性は、特に要素の意味の領域において、拡張を必要としません。

不正なXML要素の組み合わせを受け入れることには何の親切もありません。最善の場合でも望ましくない結果をもたらし、最悪の場合には実際の損害を引き起こす可能性があります。

A.3. Example - XML Syntax Error (例 - XML構文エラー)​

以下のPROPFINDメソッドのリクエストボディは不正です。

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:">
 &lt;D:allprop/>
 &lt;D:propname/>
&lt;D:propfind>

propfind要素の定義は、allprop要素またはpropname要素のいずれかのみを許可しており、両方は許可していません。したがって、上記はエラーであり、400 (Bad Request) で応答する必要があります。

しかし、サーバーが「親切」になりたいと考え、allprop要素を真の要素として選択し、それに応答することにしたと想像してください。propnameを実行するつもりで帯域幅が制限された回線で実行しているクライアントは、サーバーがコマンドをallpropとして扱った場合、大きな驚きを受けるでしょう。

さらに、サーバーが寛容でこのリクエストに返信することにした場合、結果はサーバーごとにランダムに変化し、一部のサーバーはallpropディレクティブを実行し、他のサーバーはpropnameディレクティブを実行します。これは相互運用性を高めるのではなく、低下させます。

A.4. Example - Unexpected XML Element (例 - 予期しないXML要素)​

前の例は、propfind要素内に一緒に表示することが明示的に禁止されている2つの要素が含まれていたため、不正でした。ただし、XMLは拡張可能な言語であるため、propfindで使用するために新しい要素が定義されることを想像できます。以下はPROPFINDのリクエストボディであり、前の例と同様に、expired-props要素を理解しないサーバーによって400 (Bad Request) で拒否される必要があります。

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
 &lt;E:expired-props/>
&lt;D:propfind>

なぜ400 (Bad Request) が返されるかを理解するために、expired-propsに不慣れなサーバーがリクエストボディをどのように見るかを見てみましょう。

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
&lt;D:propfind>

サーバーは'expired-props'要素を理解しないため、セクション17で指定されたWebDAV固有のXML処理規則に従って、要素が存在しないかのようにリクエストを処理する必要があります。したがって、サーバーは空のpropfindを見ることになり、propfind要素の定義によれば不正です。

拡張が付加的であった場合、必ずしも400 (Bad Request) にはならなかったことに注意してください。たとえば、以下のPROPFINDのリクエストボディを想像してください:

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
 &lt;D:propname/>
 &lt;E:leave-out>*boss*&lt;E:leave-out>
&lt;D:propfind>

前の例には、架空の要素leave-outが含まれています。その目的は、名前が送信されたパターンに一致するプロパティの返却を防ぐことです。前の例が'leave-out'に不慣れなサーバーに送信された場合、唯一の結果は'leave-out'要素が無視され、propnameが実行されることです。

附録 B. Notes on HTTP Client Compatibility (HTTPクライアント互換性に関する注意事項)​

WebDAV は HTTP 1.1 との下位互換性を持つように設計されており、実際に下位互換性があることが確認されています。PUT および DELETE メソッドは HTTP で定義されているため、HTTP クライアントと WebDAV 対応クライアントの両方で使用できますが、PUT および DELETE への応答は本仕様で拡張されており、WebDAV クライアントのみが完全に準備できる方法で拡張されています。これらの応答が HTTP のみのクライアントとの相互運用性の問題を引き起こすかどうかについて、いくつかの理論的な懸念が提起されており、このセクションではこれらの懸念に対処します。

HTTP クライアントは認識できない 400 レベルおよび 500 レベルのステータスコードをエラーとして処理するべきであるため、次の新しいステータスコードは問題を引き起こすべきではありません: 422、423、および 507 (424 も新しいステータスコードですが、Multistatus 応答の本文にのみ表示されます)。したがって、たとえば、HTTP クライアントがロックされたリソースに対して PUT または DELETE を試行した場合、423 Locked 応答はユーザーに一般的なエラーを表示する結果になるはずです。

207 Multistatus 応答は興味深いものです。なぜなら、コレクションに DELETE リクエストを発行する HTTP クライアントは、リソースがコレクションであることに気付かず、DELETE 操作が完全または部分的な失敗である可能性があることを理解できないにもかかわらず、207 応答を成功として解釈する可能性があるからです。その解釈は完全には正当化されません。なぜなら、200 レベルの応答は、サーバーがリクエストを「受信、理解、受け入れた」ことを示すものであり、リクエストが完全に成功したことを示すものではないからです。

1 つのオプションは、サーバーがコレクションの DELETE をアトミック操作として扱い、成功の場合は 204 No Content を使用するか、エラーの場合は適切なエラー応答 (400 または 500 レベル) を使用することです。このアプローチは確かに下位互換性を最大化します。ただし、相互運用性テストおよびワーキンググループの議論では、HTTP クライアントが WebDAV コレクションに対して DELETE リクエストを発行するインスタンスは見つかっていないため、この懸念は実用的というよりも理論的です。したがって、サーバーがコレクション DELETE リクエストを WebDAV リクエストとして扱い、207 Multi-Status 応答を送信する場合でも、HTTP クライアントとの相互運用に完全に成功する可能性が高いです。

一般的に、サーバー実装は、理論的な相互運用性の懸念のために変更を加えるのではなく、このドキュメントで定義されている詳細な応答およびその他のメカニズムを使用することが推奨されます。

附録 C. The 'opaquelocktoken' Scheme and URIs ('opaquelocktoken'スキームとURI)​

'opaquelocktoken' URI スキームは、UUID から構文的に正しく、簡単に生成できる URI を作成するために [RFC2518] で定義され (IANA によって登録され)、ロックトークンとして使用され、すべての時間にわたってすべてのリソース間で一意であることを意図しています。

opaquelocktoken URI は、'opaquelocktoken' スキームと UUID を連結し、オプションの拡張を追加することによって構築されます。サーバーは、新しいロックトークンごとに新しい UUID を作成できます。サーバーが UUID を再利用したい場合、サーバーは拡張を追加しなければならず (MUST)、拡張を生成するアルゴリズムは、同じ拡張が関連する UUID で 2 回使用されないことを保証しなければなりません (MUST)。

OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
  ; UUID は [RFC4122] のセクション 3 で定義されています。LWS は
  ; この生成の要素間で
  ; 許可されないことに注意してください。

Extension = path
  ; path は [RFC3986] のセクション 3.3 で定義されています

附録 D. Lock-null Resources (ロックnullリソース)​

マップされていない URL をロックするための元の WebDAV モデルは、"ロックnullリソース" を作成しました。このモデルは過度に複雑であり、いくつかの相互運用性と実装の問題が発見されました。マップされていない URL をロックするための新しい WebDAV モデル (セクション 7.3 を参照) は、"ロックされた空のリソース" を作成します。ロックnullリソースは非推奨です。クライアントはどちらのモデルも処理できなければならない (MUST) ため、このセクションでは元のモデルについて簡単に説明します。

元の "ロックnullリソース" モデルでは、実装が推奨されなくなりました:

  • ロックnullリソースは時々 "Not Found" として表示されます。サーバーは、PUT、MKCOL、OPTIONS、PROPFIND、LOCK、UNLOCK を除くすべてのメソッドに対して 404 または 405 で応答します。

  • ただし、ロックnullリソースは親コレクションのメンバーとして表示されます。

  • サーバーは、ロックが通常のリソースに変換される前に消失した場合、ロックnullリソースを完全に削除します (その URI はマップされなくなります)。ロックは、期限切れまたはロック解除されたときだけでなく、リソースの名前が変更または移動された場合、または親コレクションの名前が変更または移動された場合にも削除されることを思い出してください。

  • URL への PUT リクエストが成功した場合、サーバーはロックnullリソースを通常のリソースに変換します。

  • URL への MKCOL リクエストが成功した場合、サーバーはロックnullリソースをコレクションに変換します (ただし、相互運用性の経験により、すべてのサーバーがこの要件に従っているわけではないことが示されました)。

  • DAV:lockdiscovery および DAV:supportedlock プロパティのプロパティ値は定義されていましたが、DAV:getcontenttype のような他のプロパティには必ずしも定義されていませんでした。

クライアントは、マップされていない URL への LOCK 後に PUT のみを試行し、MKCOL または GET を試行しないことで、古いモデルの "ロックnullリソース" をサポートするサーバーと推奨モデルの "ロックされた空のリソース" の両方と簡単に相互運用できます。

D.1. Guidance for Clients Using LOCK to Create Resources (LOCK を使用してリソースを作成するクライアントのガイダンス)​

この仕様に実装された WebDAV クライアントは、ロックnullリソースを作成するサーバー (この仕様の前に [RFC2518] を使用して実装されたもの) と、ロックされた空のリソースを作成するサーバーの両方を見つける可能性があります。LOCK リクエストへの応答は、どの種類のリソースが作成されたかを示しません。クライアントがいずれかのタイプを処理するのに役立ついくつかのテクニックがあります。

  • クライアントがロックnullまたは空のロックされたリソースを誤って作成することを避けたい場合、サーバーが新しいリソースを作成するのを防ぐために、"If-Match: *" ヘッダーを LOCK リクエストに含めることができます。

  • LOCK リクエストがリソースを作成し、クライアントがその後 COPY または MOVE リクエストを使用してそのリソースを上書きしたい場合、クライアントは "Overwrite: T" ヘッダーを含める必要があります。

  • LOCK リクエストがリソースを作成し、クライアントがそのリソースを削除することにした場合、DELETE リクエストはロックnullリソースで失敗するはずで、代わりに UNLOCK を使用する必要があります。しかし、ロックされた空のリソースの場合、UNLOCK はリソースを消滅させません。したがって、クライアントは両方のリクエストを試行し、2 つのリクエストのいずれかでエラーを無視する必要がある場合があります。

附録 F. Summary of Changes from RFC 2518 (RFC 2518 からの変更の概要)​

この附録は、RFC 2518 からの変更の概要を提供します。

F.1. Changes for Both Client and Server Implementations (クライアントとサーバー実装の両方の変更)​

明確化:

  • どの HTTP 機能をサポートする必要があるかについての明確化を追加しました。
  • ETag をいつ返す必要があるかについての明確化を追加しました。
  • ルートコレクションは削除できないことを明確にしました。
  • クライアントが任意の順序でプロパティを含む PROPFIND 応答を処理できる必要があることを明確にしました。
  • PROPFIND Depth infinity リクエストの要件を明確にしました。
  • Timeout リクエストヘッダーの使用に関する明確化を追加しました。
  • 時間値の処理に関する明確化を追加しました。

処理の明確化:

  • WebDAV の If ヘッダーの代わりに HTTP の If ヘッダーを使用できる場合を明確にしました。
  • WebDAV クライアントが WebDAV サーバーとやり取りする際に 401 応答を処理できる必要があることを明確にしました。

強化されたガイダンス:

  • DAV ヘッダーの使用に関するガイダンスを追加しました。
  • HTTP 条件ヘッダーの処理に関するガイダンスを追加しました。
  • 過剰な数のリソースを持つコレクションに対する PROPFIND リクエストの処理に関するガイダンスを追加しました。
  • PROPFIND 応答の例を追加し、フォーマット要件を明確にしました。
  • COPY リクエストの例を追加し、Overwrite ヘッダーの処理を明確にしました。

新機能:

  • 102 (Processing) ステータスコードがこの仕様から削除されました。広く実装されておらず、RFC 2518 に移動されました。

F.2. Changes for Client Implementations (クライアント実装の変更)​

新しいガイダンス:

  • XML 拡張性に関する附録を追加しました。
  • クライアントの認証に関する附録を追加しました。
  • XML エンティティの影響に関するセキュリティ考慮事項を追加しました。

処理の変更:

  • クライアントは、応答で無効な要素の順序を受け取ったときに失敗する必要がなくなりました。

F.3. Changes for Server Implementations (サーバー実装の変更)​

ロックnullリソース:

  • サーバーがサポートするロックnullリソースは、ロックされた空のリソースに置き換えられて非推奨になりました。
  • サーバーは、下位互換性のためにロックnullリソースを引き続きサポートできます。

プロパティの変更:

  • 多数のプロパティ定義をより一貫性があり明確にするために変更しました。
  • DAV:getlastmodified が必要な場所で DAV:getetag プロパティを必須にしました。
  • コレクションに対する DAV:getcontenttype 要件を削除しました。

エラー報告:

  • 応答本文でより良いエラー報告を行うために、前提条件/事後条件 XML 要素を追加しました。
  • 前提条件と事後条件の使用に関するガイダンスを追加しました。

COPY/MOVE の動作:

  • プロパティに関する COPY/MOVE の動作を明確にしました。
  • ロックに関する COPY/MOVE の動作を明確にしました。
  • Depth ヘッダーに関する COPY/MOVE の動作を明確にしました。

ロック処理:

  • LOCK リクエストのロック所有者フィールドが認証されていないことを明確にしました。
  • ロックがいつタイムアウトする必要があり、いつ延長できるかを明確にしました。
  • LockInfo 要素の明確化を追加しました。
  • DAV:supportedlock スキーマを修正しました。

その他のサーバー変更:

  • サーバーがいつ 404 と 405 応答を使用する必要があるかを明確にしました。
  • DELETE コレクションの動作とエラー報告を明確にしました。
  • PROPPATCH トランザクション要件を明確にしました。
  • OPTIONS メソッドは応答に "DAV" ヘッダーを含める必要があります。

F.4. Clarifications to XML Processing (XML 処理の明確化)​

検証:

  • XML 処理と検証の要件レベルを明確にしました。
  • XML 処理ルールは WebDAV 定義要素にのみ適用されることを明確にしました。
  • 未知の XML 要素の処理に関するガイダンスを追加しました。

名前空間の処理:

  • プロパティと XML 要素での名前空間の使用を明確にしました。
  • プロパティ名は常に修飾されることを明確にしました。

DTD の変更:

  • DTD が仕様から削除されました。規範的ではなく、時々不正確または不完全でした。

F.5. Clarifications to Protocol Details (プロトコルの詳細の明確化)​

ステータスコードの明確化:

  • 各 WebDAV ステータスコードをいつ使用する必要があるか、または使用すべきかを明確にしました。
  • WebDAV ステータスコードと HTTP ステータスコードの相互作用を明確にしました。

ヘッダーの明確化:

  • さまざまなメソッドでの Depth ヘッダーの使用を明確にしました。
  • If ヘッダーの構文と処理を明確にしました。
  • Overwrite ヘッダーの使用を明確にしました。

応答形式:

  • Multi-Status 応答のフォーマット要件をより明確にしました。
  • すべての使用で href の処理を一貫させました。

エラー処理:

  • 前提条件/事後条件要素を使用して、仕様全体でエラー処理を強化しました。
  • 認証失敗の処理に関する具体的なガイダンスを追加しました。