2015-10-21 9 views
6

Se ho capito bene, è meglio non gzip di piccole risorse in quanto potrebbero diventare più grandi pur avendo un impatto sulle prestazioni della CPU. Quindi usare la direttiva gzip_min_length è una soluzione ovvia a questo. Tuttavia, quando provarlo su un server che esegue un'API REST su cui sto lavorando non sembra funzionare. Quando ricevo una risposta JSON vuota, o molto piccola, l'intestazione Content-Encoding è ancora presente e sta leggendo "gzip".Perché la direttiva sulla lunghezza minima gzip non viene rispettata?

HTTP Response headers

La mia domanda è: perché questa impostazione non viene rispettato da Nginx e che cosa posso fare per risolvere il problema?

L'API è costruita sulla microframmatura Lumen.

Ho allegato l'impostazione Gzip sto usando nella mia nginx.conf:

# 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

Sei sicuro che sia la compressione nginx e non la tua applicazione? –

+0

Sì, abbastanza sicuro ... :-) – Vercoutere

+0

Ho appena eseguito lo stesso comportamento e presumo che sia dovuto alla nota nella [documentazione del modulo gzip NGINX] (http://nginx.org/en/docs/http /ngx_http_gzip_module.html#gzip_min_length) affermando "La lunghezza è determinata solo dal campo di intestazione della risposta" Content-Length "." – cebarth

risposta

7

Confermando la mia nota di cui sopra, questo non sembra corrispondere alla nota nella NGINX gzip module documentation affermando "La lunghezza è determinata soltanto dal campo di intestazione della risposta "Content-Length". "

Con gzip_min_length 1000;, le mie risposte JSON venivano convertite in gzip, anche se erano solo 100 byte.

Ho modificato la mia applicazione per aggiungere l'intestazione Content-Length: 100 e NGINX invia la risposta JSON senza utilizzare la codifica gzip.

Se cambio la configurazione in gzip_min_length 80; con lo stesso Content-Length da 100 byte, NGINX applica la codifica gzip come previsto.

Breve storia: è necessario applicare l'intestazione Content-Length per NGINX per gestire correttamente il controllo gzip_min_length.

Problemi correlati