HTTPQUERY
日本語

Accept-Encoding

使い方

HTTP の Accept-Encoding リクエストヘッダーはコンテンツネゴシエーションの一部であり、クライアントがサポートするエンコーディング方式を指定します。サーバーは利用可能な方式の 1 つを選び、HTTP レスポンスに Content-Encoding ヘッダーを含めることでその選択をクライアントに伝えます。

注意

クライアントとサーバーが同じエンコーディング方式をサポートしている場合でも、送信前に元のリソースに一切手を加えないことがあります。これは、そのリソースについて identity の値も受け入れ可能な状況で起こります。よくある例は、データがすでに圧縮されており、さらに圧縮アルゴリズムを適用してもサイズが縮まらない場合です。JPEG のような事前に圧縮された画像ファイルでこれが起こります。もう 1 つの状況は、サーバーが高負荷で、送信前にデータを処理するために必要なリソースを割けない場合です。

複数のエンコーディングは、別々の HTTP Accept-Encoding ヘッダーを使うか、カンマ区切りのリストで指定します。優先度や優先順位を示すために q 値も含めます。

SEO への影響

Google のクローラーとフェッチャーは gzip、deflate、Brotli（br）のコンテンツエンコーディングをサポートします。各 Google のユーザーエージェントは、すべてのリクエストの Accept-Encoding ヘッダーでサポートするエンコーディングを通知し、通常は Accept-Encoding: gzip, deflate, br となります。Googlebot に圧縮したレスポンスを配信することで、帯域とクロール時間を削減できます。Bingbot は Accept-Encoding: gzip, deflate を送ります。

gzip

gzip ディレクティブは、クライアントが GNU zip 圧縮をサポートすることを示します。これは Web で最も広くサポートされているエンコーディングです。

deflate

deflate ディレクティブは、クライアントが zlib 圧縮をサポートすることを示します。名前に反して、これは生の DEFLATE 圧縮データを zlib でラップしたものを使います。

br

br ディレクティブは、クライアントが Brotli 圧縮をサポートすることを示します。Brotli はテキストベースのコンテンツにおいて、通常 gzip よりも高い圧縮率を実現します。

zstd

zstd ディレクティブは、クライアントが Zstandard 圧縮をサポートすることを示します。Zstandard は高い圧縮率と高速な展開速度を両立します。

identity

identity ディレクティブは、エンコーディングを適用しないことを示します。identity;q=0 で明示的に除外されない限り、この値は常に受け入れ可能とみなされます。

*（ワイルドカード）

ワイルドカード * は、ヘッダーにまだ列挙されていない任意のエンコーディングに一致します。Accept-Encoding ヘッダーが存在しない場合、サーバーは * が指定されたものとしてリクエストを扱います。

;q=（品質値）

;q= パラメーターは各エンコーディングに 0 から 1 の間の重みを割り当てます。1 が最高の優先度で、0 は「受け入れ不可」を意味します。省略した場合の既定の品質値は 1 です。サーバーはこれらの重みを使って優先するエンコーディングを選択します。

例

次の例では、クライアントが複数のエンコーディング方式のいずれかを使うようサーバーに要求します。1 つ目のバリエーションでは、各選択肢に等しい優先度が与えられています。2 つ目のバリエーションでは、q 値のディレクティブを使ってエンコーディングの優先度に重みを割り当てています。サーバーは適用したエンコーディングを、処理した順に並べて返します。

リクエスト（バリエーション #1）

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *

リクエスト（バリエーション #2）

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br;q=1.0, identity;q=0.5, *;q=0.25

レスポンス

HTTP/1.1 200 OK
Content-Encoding: gzip, br

トラブルシューティング

Accept-Encoding があるのに圧縮が適用されない。一部のリバースプロキシは、転送前にリクエストから Accept-Encoding を取り除きます。nginx では proxy_set_header Accept-Encoding $http_accept_encoding で元の値を保持できます。curl -H “Accept-Encoding: gzip” -I で確認してください。

想定外のエンコーディングが選ばれる。品質値（q 値）が優先順位を制御します。Accept-Encoding: gzip;q=0.5, br;q=1.0 のリクエストは Brotli を優先します。q 値を省略すると等しい重みが割り当てられ、サーバーが自由に選択します。

CORS プリフライトに Accept-Encoding がない。Accept-Encoding ヘッダーは CORS のセーフリストに含まれており、プリフライトを引き起こしません。クロスオリジンのリクエストで圧縮が効かなくなった場合は、サーバーが Origin ヘッダーに関わらず圧縮を適用しているか確認してください。

CDN が非圧縮のレスポンスを配信する。一部の CDN は、オリジンが適切な Content-Type で非圧縮のレスポンスを送った場合にのみ圧縮します。CDN が圧縮版と非圧縮版のバリアントを別々にキャッシュできるよう、オリジンが Vary: Accept-Encoding を返していることを確認してください。

identity エンコーディングが拒否される。Accept-Encoding: identity;q=0 を送ることは、クライアントが非圧縮のレスポンスを受け入れられないとサーバーに伝えることになります。サポートされるエンコーディングが 1 つも利用できない場合、サーバーは 406 Not Acceptable を返します。列挙したすべてのエンコーディングが必ず利用できると保証されない限り、identity を q=0 に設定するのは避けてください。