2015-10-21 21 views
6

Nếu tôi hiểu chính xác thì tốt hơn là không nên gzip tài nguyên nhỏ vì chúng thực sự có thể lớn hơn trong khi vẫn có hiệu suất đạt trên CPU. Vì vậy, sử dụng chỉ thị gzip_min_length là một giải pháp rõ ràng cho điều đó. Tuy nhiên, khi cố gắng này trên một máy chủ chạy một API REST tôi đang làm việc trên điều này dường như không hoạt động. Khi tôi nhận được phản hồi json trống hoặc một phần rất nhỏ, tiêu đề Mã hóa nội dung vẫn còn hiện diện và đọc "gzip".Tại sao chỉ thị độ dài tối thiểu của gzip không được tôn trọng?

HTTP Response headers

Câu hỏi của tôi là lý do tại sao thiết lập này không được tôn trọng bởi Nginx và những gì tôi có thể làm gì để khắc phục nó?

API được xây dựng trên Lumen vi phim.

Tôi có kèm theo các thiết lập Gzip Tôi đang sử dụng trong nginx.conf tôi:

# 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

Bạn có chắc là nén nginx chứ không phải ứng dụng của bạn? –

+0

Vâng, khá chắc chắn ... :-) – Vercoutere

+0

Tôi vừa chạy vào cùng một hành vi và cho rằng đó là do ghi chú trong [tài liệu mô-đun gzip NGINX] (http://nginx.org/en/docs/http /ngx_http_gzip_module.html#gzip_min_length) cho biết "Độ dài được xác định chỉ từ trường tiêu đề phản hồi" Nội dung dài "." – cebarth

Trả lời

7

Xác nhận lưu ý của tôi ở trên, điều này dường như tương ứng với các ghi chú trong NGINX gzip module documentation nêu rõ "Chiều dài được xác định duy nhất từ trường tiêu đề phản hồi "Nội dung dài". "

Với gzip_min_length 1000;, câu trả lời JSON của tôi đã được gzip'ed, ngay cả khi chúng chỉ có 100 byte.

Tôi đã thay đổi ứng dụng của mình để thêm tiêu đề Content-Length: 100 và NGINX gửi phản hồi JSON mà không sử dụng mã hóa gzip.

Nếu tôi thay đổi cấu hình thành gzip_min_length 80; với cùng độ dài nội dung 100 byte, thì NGINX áp dụng mã hóa gzip như mong đợi.

Câu chuyện ngắn: bạn cần áp dụng tiêu đề Content-Length cho NGINX để xử lý kiểm tra gzip_min_length đúng cách.

Các vấn đề liên quan