33

クライアントが HTTP リクエストを送信し、サーバーがデコードできない Content-Encoding ヘッダーを指定した場合、どのステータス コードを返す必要がありますか?

例

クライアントは JSON データを REST リソースに POST し、gzip コーディングを使用してエンティティ本体をエンコードします。ただし、サーバースクールの gzip クラスに失敗したため、サーバーは DEFLATE コーディングしかデコードできません。

どの HTTP 応答コードを返す必要がありますか? 415 Unsupported Media Typeと言いますが、問題はエンティティの Content-Type ではありません。それ以外の場合はサポートされているエンティティ本体のエンコーディングです。

415 のうち、どちらがより適切ですか? 400? おそらくカスタム応答コードですか？

補遺:もちろん、rfc2616 を徹底的にチェックしました。答えがあれば、新しい矯正眼鏡が必要になるかもしれませんが、そうではないと思います.

アップデート：

これは、クライアントに受け入れられない可能性のある応答を送信することとは関係ありません。問題は、クライアントがサーバーに、サーバーが理解できないエンコーディングで有効なメディアタイプである場合とそうでない場合があるものを送信していることです（Content-Encodingクライアントがリクエストメッセージにパッケージ化したヘッダーに従って）。

これはエッジ ケースであり、ブラウザーのユーザー エージェントを処理する場合には発生しませんが、エンティティ ボディを受け入れてリソースを作成/変更する REST API で発生する可能性があります。

4

2 に答える 2

55

私がそれを読んで415 Unsupported Media Typeいるように、最も適切なように聞こえます。

RFC 2616 から:

10.4.16 415 サポートされていないメディア タイプです

リクエストのエンティティが、リクエストされたメソッドのリクエストされたリソースでサポートされていない形式であるため、サーバーはリクエストの処理を拒否しています。

ええ、テキスト部分には「エンコーディング」ではなく「メディア タイプ」と書かれていますが、実際の説明にはその区別についての言及は含まれていません。

新しいホットネスであるRFC 7231は、それについても明示しています。

6.5.13. 415 サポートされていないメディア タイプです

415 (サポートされていないメディア タイプ) ステータス コードは、ペイロード がターゲット リソースのこのメソッドでサポートされていない形式である
ため、オリジン サーバーが要求の処理を拒否していることを示します。形式の問題は、リクエストで示されている Content-Type または Content-Encodingが原因であるか、 データを直接検査した結果である可能性があります。



于 2012-07-13T21:18:55.310 に答える
11

彼らは、誰がミリオネアになりたいかについての最後の質問をする必要があります！

クライアントが提供した情報がサーバーで処理できない形式であるため、ブラウザーはサーバーがサービスを提供できないことを要求しました。ただし、これは、クライアントが提供したデータをサポートしていないことに対するサーバーの責任ではなく、サーバーのAcccept- *ヘッダーをリッスンせず、不適切なエンコーディングでデータを提供したことに対するクライアントの責任です。それはそれをクライアントエラー（400シリーズのエラーコード）にします。

  • 私の最初の本能は400BadRequestが、この場合の適切な応答です。
  • 405メソッドは許可されていません。HTTP動詞が許可されていないことを示しているため、正しくありません。
  • 406 Not Acceptableは約束があるように見えますが、サーバーが送信したAccept-*要求ヘッダーを満たすデータをクライアントに提供できないことを示しています。これはあなたのケースに合うとは思えません。
  • 412前提条件の失敗はかなり漠然と定義されています。それは適切かもしれませんが、私はそれには賭けません。
  • 415サポートされていないメディアタイプは、拒否されているデータタイプではなく、エンコード形式であるため、正しくありません。

その後、非標準の応答コードの領域に入ります。

  • 422 Unprocessable Entityは、要求が整形式であるが、何らかの意味で意味的に正しくない場合に返される必要がある応答を記述します。これは適切に思えますが、HTTPのWebDAV拡張機能であり、標準ではありません。

上記を考えると、私は個人的に400BadRequestを選びます。他のHTTPエキスパートにもっと良い候補があれば、代わりに彼らの話を聞きます。;）

更新：私は以前、ウィキペディアのページからHTTPステータスを参照していました。そこにある情報は正確であるように見えますが、それも完全ではありません。W3Cの仕様を見ると、HTTP 406に関するより多くの情報が得られ、結局のところ406が正しいコードである可能性があると私は思います。

10.4.7406受け入れられない

リクエストによって識別されたリソースは、リクエストで送信されたacceptヘッダーに従って受け入れられないコンテンツ特性を持つ応答エンティティのみを生成できます。

HEADリクエストでない限り、応答には、ユーザーまたはユーザーエージェントが最も適切なものを選択できる利用可能なエンティティの特性と場所のリストを含むエンティティを含める必要があります。エンティティ形式は、Content-Typeヘッダーフィールドで指定されたメディアタイプによって指定されます。ユーザーエージェントのフォーマットと機能に応じて、最も適切な選択肢の選択が自動的に実行される場合があります。ただし、この仕様では、このような自動選択の標準は定義されていません。

  Note: HTTP/1.1 servers are allowed to return responses which are
  not acceptable according to the accept headers sent in the
  request. In some cases, this may even be preferable to sending a
  406 response. User agents are encouraged to inspect the headers of
  an incoming response to determine if it is acceptable.

応答が受け入れられない可能性がある場合、ユーザーエージェントは一時的にそれ以上のデータの受信を停止し、ユーザーにさらなるアクションの決定を問い合わせる必要があります。

Content-Typeヘッダーについては明示的に言及していますが、「エンティティの特性」については言及しています。これは、GZIPとDEFLATEの圧縮などをカバーしていると読むことができます。

注目に値することの1つは、データをそのまま送信し、ヘッダーと一緒にデータがどの形式でどのエンコーディングを使用しているかをクライアントに通知し、クライアントが整理できるようにすることが適切である可能性があることです。 。したがって、クライアントがGZIP圧縮を受け入れることを示すヘッダーを送信したが、サーバーがDEFLATEを使用して応答を生成することしかできない場合、それをヘッダーと一緒に送信すると、DEFLATEは問題ないはずです（コンテキストによって異なります）。

  • クライアント：GZIPPEDページをください。
  • サーバー：申し訳ありませんが、できません。私はあなたのためにそれをDEFLATEパックすることができます。これがDEFLATEパックのページです。大丈夫ですか？
  • クライアント：Wellll ... DEFLATEは本当に必要ではありませんでしたが、デコードしても問題ないので、それを使用します。

（また）

  • クライアント：ユーザーと一緒にそれをクリアする必要があると思います。持続する。
于 2012-07-12T21:57:21.173 に答える