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 つの異なる形式のいずれかを使用します:

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