2015-10-21 15 views
6

Wenn ich es richtig verstehe, ist es besser, kleine Ressourcen nicht zu gzipen, da sie vielleicht größer werden, während die CPU noch einen Leistungseinbruch hat. Die gzip_min_length-Direktive ist also eine naheliegende Lösung. Wenn ich dies auf einem Server versuche, der eine REST-API ausführt, an der ich arbeite, scheint dies jedoch nicht zu funktionieren. Wenn ich eine leere JSON-Antwort oder eine sehr kleine Antwort erhalte, ist der Content-Encoding-Header immer noch vorhanden und liest "gzip".Warum wird die gzip-Richtlinie zur Mindestlänge nicht eingehalten?

HTTP Response headers

Meine Frage ist, warum diese Einstellung nicht von Nginx respektiert wird und was kann ich tun, um es zu beheben?

Die API basiert auf dem Lumen Mikrorahmen.

Ich habe die gzip-Einstellung angebracht ich in meinem nginx.conf mit:

# 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

Sind Sie sicher, dass es Nginx-Komprimierung ist und nicht Ihre Anwendung? –

+0

Ja, ziemlich sicher ... :-) – Vercoutere

+0

Ich bin gerade auf dasselbe Verhalten gestoßen und nehme an, dass es an der Notiz in der [NGINX gzip Moduldokumentation] liegt (http://nginx.org/en/docs/http /ngx_http_gzip_module.html#gzip_min_length) mit der Angabe "Die Länge wird nur aus dem Header-Feld" Content-Length "bestimmt." – cebarth

Antwort

7

meine Anmerkung oben bestätigen, dies im NGINX gzip module documentation auf die Note zu entsprechen scheint „Die Länge wird unter Angabe bestimmt nur aus dem Antwortkopfzeilenfeld "Content-Length". "

Mit gzip_min_length 1000; wurden meine JSON-Antworten gezippt, auch wenn sie nur 100 Byte waren.

Ich habe meine Anwendung geändert, um die Content-Length: 100 Header hinzufügen und NGINX sendet die JSON-Antwort ohne Verwendung der GZIP-Codierung.

Wenn ich die Konfiguration zu gzip_min_length 80; mit der gleichen 100-Byte-Content-Length ändern, dann wendet NGINX die gzip-Codierung wie erwartet an.

Kurzgeschichte: Sie müssen die Content-Length Header für NGINX anwenden, um die gzip_min_length Überprüfung richtig zu behandeln.