Pourquoi la directive de longueur minimale de gzip n'est-elle pas respectée?

Question

Si je comprends bien, il est préférable de ne pas compresser les petites ressources car elles pourraient grossir tout en ayant un impact sur les performances du processeur. L'utilisation de la directive gzip_min_length est donc une solution évidente. Cependant, lorsque j'essaie ceci sur un serveur qui exécute une API REST, je travaille sur cela ne semble pas fonctionner. Lorsque je reçois une réponse json vide, ou une toute petite, l'en-tête Content-Encoding est toujours présent et lit "gzip".

HTTP Response headers

Ma question est pourquoi ce paramètre n'est pas respecté par Nginx et que puis-je faire pour y remédier?

L'API est construite sur le microframework Lumen.

Je joins le réglage Gzip J'utilise dans mon 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 

Answer 1

Confirmant ma note ci-dessus, cela ne semble correspondre à la note dans la NGINX gzip module documentation indiquant « La longueur est déterminée uniquement à partir du champ d'en-tête de réponse "Content-Length". "

Avec gzip_min_length 1000;, mes réponses JSON étaient gzipées, même si elles n'étaient que de 100 octets.

J'ai modifié mon application pour ajouter l'en-tête Content-Length: 100 et NGINX envoie la réponse JSON sans utiliser le codage gzip.

Si je change la configuration en gzip_min_length 80; avec la même longueur de contenu de 100 octets, NGINX applique le codage gzip comme prévu.

Petite nouvelle: vous devez appliquer l'en-tête Content-Length pour que NGINX gère correctement la vérification gzip_min_length.