如果我理解正确,最好不要使用gzip小资源,因为它们实际上可能会变得更大,同时仍会在CPU上出现性能损失。 所以使用gzip_min_length指令是一个明显的解决方案。 但是,在运行REST API的服务器上尝试此操作时,我正在努力解决此问题似乎无法正常工作。 当我收到空的json响应或非常小的响应时,Content-Encoding标头仍然存在并且正在读取" gzip"。
我的问题是为什么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
答案 0 :(得分:12)
确认上面的注释,这似乎与NGINX gzip module documentation中的注释对应"长度仅由“Content-Length”响应头字段确定。"
使用gzip_min_length 80;
,我的JSON响应正在进行gzip,即使它们只有100个字节。
我更改了我的应用程序以添加Content-Length
标头,NGINX在不使用gzip编码的情况下发送JSON响应。
如果我使用相同的100字节Content-Length将配置更改为gzip_min_length
,则NGINX会按预期应用gzip编码。
短篇小说:您需要应用NGINX的getline
标题来正确处理cout
检查。