为什么gzip最小长度指令不被尊重?

如果我理解正确的话,最好不要小的资源,因为它们实际上可能变得更大,同时仍然在CPU上性能受到影响。 所以使用gzip_min_length指令是一个明显的解决scheme。 但是,在运行REST API的服务器上尝试此操作时,我正在处理这似乎不起作用。 当我收到一个空的json响应或非常小的响应时,Content-Encoding头仍然存在并读取“gzip”。

HTTP响应头

我的问题是为什么这个设置没有得到NginX的尊重,我能做些什么来解决它?

API是build立在stream明微框架上的。

我已经附加了我在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 

在上面确认我的注意事项后,这看起来似乎对应于NGINX gzip模块文档中的注释 :“长度仅由”Content-Length“响应头字段确定。

gzip_min_length 1000; ,我的JSON响应正在被gzip,即使他们只有100字节。

我改变了我的应用程序添加Content-Length: 100头,NGINX发送JSON响应,而不使用gzip编码。

如果我将配置更改为gzip_min_length 80; 具有相同的100字节的内容长度,那么NGINX按预期应用gzip编码。

小故事:您需要应用NGINX的Content-Length头来正确处理gzip_min_length检查。