4

HTTP クライアントが無効な HTTP 要求を行った場合に、人間が読み取れるエラー メッセージ (例: content-type: text/plain) を含む HTTP 応答を生成することが許容されるかどうかを管理する HTTP 仕様のドキュメントを見つけることができませんでした。また、accept ヘッダーを使用して、受け入れ可能な応答コンテンツ タイプを制限する要求ヘッダーを指定しました。

"http://myhost/validpath?illegalRequestParameter=rubbish" に対して無効な GET 要求を発行し、"Accept: application/xml" または "Accept: application/vnd.ms-excel" という要求ヘッダーを含む REST Web サービス クライアントを想像してください。 .

サーバーは、4XX シリーズの HTTP ステータス コード (この場合は「400 Bad Request」) で応答します。しかし、サービスはどのようにしてエラーの原因に関する情報をクライアントに伝えることができるのでしょうか?

次のオプションが表示されます。

  1. HTTP 応答コンテンツに平文のエラー メッセージを作成します。応答ヘッダー「Content-type: text/plain」を設定し、応答コンテンツに説明的なエラー メッセージを含めます。ただし、これは HTTP クライアントの「受け入れ」制限に違反します。

  2. HTTP 応答コンテンツを含めないでください。これは明らかに有効ですが、「クライアント エラー」が発生したことを知っているだけで、その理由を知る方法がない (クライアント ログ ファイルで理由を報告する) クライアントにとってはあまり役に立ちません。

  3. エラー メッセージを強制的に「許容可能な」MIME タイプに変換してみてください。これが可能なことはめったにありません。エラー メッセージが有効なアプリケーション/xml 型として構築できたとしても、Web サービスの契約 (XML スキーマの準拠など)​​ に違反する可能性があります。

私の質問は次のとおりです。上記の状況は、既存の HTTP 仕様/標準によって管理されていますか?

参考文献:

  1. HTTP ステータス コードの定義: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
  2. HTTP ヘッダー フィールドの定義http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
4

1 に答える 1

0

Accept ヘッダーが「application/xml」の場合は、エラー メッセージを xml として返す必要があります。それはクライアントを壊しますが、それは問題ではありません.とにかく、クライアントは要求した情報を取得していません. 少なくとも、クライアントはエラー メッセージを解析できます...

于 2012-10-13T01:54:28.047 に答える