web-dev-qa-db-ja.com

gzipの最小長ディレクティブが尊重されないのはなぜですか？

私が正しく理解している場合は、CPUのパフォーマンスに影響を与えながら、実際には大きくなる可能性があるため、小さなリソースをgzipで圧縮しない方がよいでしょう。したがって、gzip_min_lengthディレクティブを使用することは、そのための明白な解決策です。ただし、REST APIを実行しているサーバーでこれを試してみると、これに取り組んでいるようには見えません。空のjson応答、または非常に小さい応答を受け取った場合、 Content-Encodingヘッダーはまだ存在し、「gzip」を読み取っています。

HTTP応答ヘッダー

私の質問は、なぜこの設定がNginXによって尊重されていないのか、そしてそれを修正するために何ができるのかということです。

APIは Lumen マイクロフレームワークに基づいて構築されています。

Nginx.confで使用しているGzip設定を添付しました：

  # Compression

  # Enable Gzip compressed.
  gzip on;

  # Enable compression both for HTTP/1.0 and HTTP/1.1.
  gzip_http_version  1.1;

  # Compression level (1-9).
  # 5 is a perfect compromise between size and cpu usage, offering about
  # 75% reduction for most ascii files (almost identical to level 9).
  gzip_comp_level    5;

  # Don't compress anything that's already small and unlikely to shrink much
  # if at all (the default is 20 bytes, which is bad as that usually leads to
  # larger files after gzipping).
  gzip_min_length    1000;

  # Compress data even for clients that are connecting to us via proxies,
  # identified by the "Via" header (required for CloudFront).
  gzip_proxied       any;

  # Tell proxies to cache both the gzipped and regular version of a resource
  # whenever the client's Accept-Encoding capabilities header varies;
  # Avoids the issue where a non-gzip capable client (which is extremely rare
  # today) would display gibberish if their proxy gave them the gzipped version.
  gzip_vary          on;

  # Compress all output labeled with one of the following MIME-types.
  gzip_types
    application/atom+xml
    application/javascript
    application/json
    application/rss+xml
    application/vnd.ms-fontobject
    application/x-font-ttf
    application/x-web-app-manifest+json
    application/xhtml+xml
    application/xml
    font/opentype
    image/svg+xml
    image/x-icon
    text/css
    text/plain
    text/x-component;
  # text/html is always compressed by HttpGzipModule
nginxservergziphttpresponselumen
12
Jon

上記の私のメモを確認すると、これは NGINX gzipモジュールのドキュメント のメモに対応しているようです。「長さは「Content-Length」応答ヘッダーフィールドからのみ決定されます。」

gzip_min_length 1000;を使用すると、JSON応答が100バイトしかない場合でも、gzipで圧縮されていました。

アプリケーションを変更してContent-Length: 100ヘッダーを追加すると、NGINXはgzipエンコーディングを使用せずにJSON応答を送信します。

同じ100バイトのContent-Lengthで構成をgzip_min_length 80;に変更すると、NGINXは期待どおりにgzipエンコーディングを適用します。

短編小説：Content-Lengthチェックを適切に処理するには、NGINXのgzip_min_lengthヘッダーを適用する必要があります。

13
Chad Barth