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つの優先セグメントのみを公開しなければなりません。