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

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

En-têtes de réponse HTTP

Ma question est la suivante: pourquoi NginX ne respecte-t-il pas ce paramètre et que puis-je faire pour y remédier?

L’API est construite sur le microframe de Lumen .

J’ai attaché le paramètre Gzip que 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 

Confirmant ma note ci-dessus, cela semble correspondre à la note de la documentation du module NGINX gzip 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 100 octets.

J’ai modifié mon application pour append l’en Content-Length: 100 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 histoire: vous devez appliquer l’en Content-Length tête Content-Length pour que NGINX gère correctement la vérification gzip_min_length .