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

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

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 を使用して新しいリソースを作成するなどの特定のユースケースにも適用されることに注意してください。

に最終更新