web-dev-qa-db-ja.com

無効なContent-Encodingヘッダーを指定するリクエストの適切なHTTPステータスコード？

クライアントがHTTPリクエストを送信し、サーバーでデコードできないContent-Encodingヘッダーを指定すると、どのステータスコードが返されますか？

例

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

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

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

補遺：もちろん、rfc2616を徹底的にチェックしました。答えがそこにある場合、私はいくつかの新しい矯正アイウェアを必要とするかもしれませんが、それがそうであるとは思いません。

更新：

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

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

httphttp-headershttp-status-codes
28
rdlowrey

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

RFC 2616から：

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

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

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

新しいホットネス RFC 7231 は、それについてさえ明白です：

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

415（サポートされていないメディアタイプ）ステータスコードは、
ペイロードが原因で、元のサーバーがリクエストの処理を拒否しています
は、ターゲットリソースのこのメソッドでサポートされていない形式です。
フォーマットの問題は、要求の指示が原因である可能性があります
Content-TypeまたはContent-Encoding、または
直接データ。

46
cHao

彼らは、誰が億万長者になりたいのかという最後の質問をするべきです！

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

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

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

  • 422 Unprocessable Entityは、リクエストが整形式であるが、意味的に何らかの理由で正しくない場合に返される応答を表します。これは適切に思えますが、これはHTTPのWebDAV拡張であり、標準ではありません。

上記を踏まえて、私は個人的に400 Bad Requestを選択します。他のHTTPエキスパートがより良い候補者を持っている場合でも、代わりに彼らの意見を聞きます。 ;）

[〜＃〜] update [〜＃〜]：以前ウィキペディアのページからHTTPステータスを参照していました。そこにある情報は正確であるように見えますが、それも完全ではありません。 W3C の仕様を見ると、HTTP 406に関する多くの情報が得られ、結局、406が適切なコードであると考えるようになりました。

10.4.7 406受け入れ不可

リクエストで識別されたリソースは、リクエストで送信されたAcceptヘッダーに応じて許容できないコンテンツ特性を持つレスポンスエンティティのみを生成できます。

HEADリクエストでない限り、レスポンスには、ユーザーまたはユーザーエージェントが最も適切なものを選択できる、利用可能なエンティティの特性と場所のリストを含むエンティティが含まれる必要があります（SHOULD）。エンティティ形式は、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パックページです。よろしいですか？
  • クライアント：Welllll ...私は本当にDEFLATEを望んでいませんでしたが、それを大丈夫にデコードできるので、それを採用します。

（または）

  • クライアント：私はユーザーと一緒にそれをクリアする必要があると思います。つかまっている。
11
GordonM