3. Using the Accept-Encoding Header Field in Responses (レスポンスでの Accept-Encoding ヘッダーフィールドの使用)

[RFC7231] 第 5.3.4 節は, "Accept-Encoding" をリクエストヘッダーフィールドのみとして定義している.

本仕様はその定義を拡張し, "Accept-Encoding" をレスポンスヘッダーフィールドとしても許可する. レスポンスに存在する場合, 関連するリクエストでリソースが受け入れ可能だった Content Codings を示す. フィールド値が "identity" のみを含む場合, Content Coding はサポートされなかったことを意味する.

この情報は関連リクエストに固有であることに注意すること. サポートされる符号化の集合は, 同一サーバー上の他のリソースでは異なる可能性があり, 時間とともに変化したり, リクエストの他の側面 (リクエストメソッドなど) に依存する可能性がある.

[RFC7231] 第 6.5.13 節は, ステータスコード 415 (Unsupported Media Type) を, メディアタイプと Content Coding の両方に関する問題に適用されるものとして定義している.

サポートされない Content Coding によりリクエストが失敗したサーバーは, 415 ステータスで応答し, そのレスポンスに "Accept-Encoding" ヘッダーフィールドを含めるべきである. これによりクライアントは, Content Coding に関する問題とメディアタイプに関する問題を区別できる. メディアタイプに関する問題との混同を避けるため, Content Coding に関係ない理由で 415 を返すサーバーは, "Accept-Encoding" ヘッダーフィールドを MUST NOT で含めてはならない.

レスポンスでの "Accept-Encoding" の最も一般的な用途は, クライアントによる Content Coding の楽観的使用に対する 415 (Unsupported Media Type) となることが期待される. ただし, 将来の対話を最適化するため, Content Coding がサポートされていることをクライアントに示すためにもこのヘッダーフィールドを使える. 例えば, リクエストペイロードが十分大きく圧縮符号化の利用が妥当だったのにクライアントが行わなかった場合, リソースは 2xx レスポンスにそれを含めてもよい.