La compression Gzip ne prend pas effet - - Centre de documentation Alibaba Cloud

Description du problème

Le serveur d'origine d'un nom de domaine accéléré par Alibaba Cloud CDNDCDN est un serveur NGINX sur lequel la fonctionnalité de compression Gzip est activée. Lorsqu'un client demande une ressource directement au serveur d'origine, la compression Gzip fonctionne correctement. En revanche, lorsque la requête d'un client est redirigée depuis un point de présence (POP) vers le serveur d'origine, la compression Gzip ne s'applique pas. Les détails sont présentés ci-dessous :

Si la compression et la décompression Gzip fonctionnent comme prévu, le serveur NGINX renvoie le contenu compressé afin de réduire la consommation de bande passante et d'accélérer le temps de réponse. Toutefois, après l'utilisation de Alibaba Cloud CDNDCDN, les requêtes sont redirigées depuis les POPs vers le serveur d'origine et les clients reçoivent le contenu non compressé. Dans ce cas de figure, la fonctionnalité de compression Gzip sur le serveur d'origine ne prend pas effet. Voici plus de détails :

Si Alibaba Cloud CDNDCDN n'est pas utilisé et que les en-têtes de requête contiennent Accept-Encoding: gzip, deflate, l'en-tête de réponse correspondant est Content-Encoding: gzip. Le contenu est alors compressé.
Si Alibaba Cloud CDNDCDN est utilisé et que les en-têtes de requête contiennent Accept-Encoding: gzip, deflate, l'en-tête de réponse est Content-Length et l'en-tête Content-Encoding: gzip n'est pas renvoyé.

Cause

La configuration liée à Gzip sur le serveur d'origine NGINX est invalide, et la compression Gzip n'est pas activée pour les requêtes redirigées vers le serveur d'origine. Voici les détails :

Lorsqu'une requête est redirigée d'un POP vers le serveur d'origine, l'en-tête Via est ajouté à la requête pour indiquer qu'elle provient d'un proxy. Dans cet exemple, Alibaba Cloud CDNDCDN agit en tant que proxy. Cependant, le module ngx_http_gzip_module de NGINX inclut un élément de configuration gzip_proxied, qui contrôle l'activation de la compression Gzip pour les requêtes proxy. L'une des conditions préalables pour que cet élément de configuration prenne effet est la présence de l'en-tête Via dans les en-têtes de requête. Par conséquent, l'élément de configuration gzip_proxied détermine si la compression Gzip doit être activée pour les requêtes adressées au serveur d'origine.

Solution

Si vous rencontrez le même problème que celui décrit dans la section Description du problème, suivez les étapes ci-dessous pour mettre à jour le fichier de configuration de NGINX. Si vous ne parvenez pas à identifier le problème, consultez la section Références.

Localisez les blocs liés à Gzip dans les fichiers de configuration de NGINX. La configuration Gzip peut être définie dans les blocs http, server et location, qui correspondent à différents fichiers de configuration. Dans cet exemple, Gzip est configuré dans le bloc http du fichier nginx.conf.
Vérifiez si l'élément de configuration gzip_proxied existe. S'il existe, modifiez-le selon la configuration suivante. S'il n'existe pas, ajoutez la configuration ci-dessous. Pour plus d'informations sur l'élément de configuration gzip_proxied, consultez la documentation NGINX.

Remarque
Si l'élément de configuration gzip_proxied n'existe pas, la valeur de la configuration suivante est off par défaut.
```
gzip_proxied  any
```
Remarque
any indique que la compression Gzip est activée pour toutes les requêtes proxy.
Après avoir enregistré la configuration précédente, exécutez les commandes suivantes dans l'ordre pour valider la configuration de NGINX et recharger les fichiers de configuration.
```
nginx -t
nginx -s reload
```
Activez Alibaba Cloud CDNDCDN. Une fois les requêtes redirigées vers le serveur d'origine NGINX, vérifiez si la réponse contient l'en-tête Content-Encoding: gzip. Si c'est le cas, le contenu est compressé.

Références

Vous pouvez suivre les étapes ci-dessous pour vérifier si vous rencontrez le même problème que celui décrit dans la section Problème :

Ouvrez une interface de ligne de commande (CLI) qui prend en charge la commande curl.
Exécutez la commande curl suivante pour accéder au serveur d'origine en incluant l'en-tête Accept-Encoding: gzip, deflate.
```
curl -voa 'http://[$Domain]/[$Resource]' -x [$Original_Server_IP]:80 -H 'Accept-Encoding: gzip, deflate'
```
Remarque
- [$Domain] : votre nom de domaine.
- [$Resource] : l'URL d'une ressource demandée, telle qu'une image ou une opération API.
- [$Original_Server_IP] : l'adresse IP publique du serveur d'origine NGINX.
Le système renvoie une réponse similaire au contenu suivant. Vérifiez si l'en-tête Content-Encoding: gzip est renvoyé.
Reportez-vous à la commande suivante et ajoutez un en-tête Via basé sur la commande de l'étape 2 pour simuler une requête provenant d'un proxy.
```
curl -voa 'http://[$Domain]/[$Resource]' -x [$Original_Server_IP]:80 -H 'Accept-Encoding: gzip, deflate' -H 'Via:xxx'
```
Remarque
Vous pouvez utiliser n'importe quelle valeur pour l'en-tête Via, cela n'affecte pas le résultat du test. Dans cet exemple, xxx est utilisé.

Le système renvoie une réponse similaire au contenu suivant. Vérifiez si l'en-tête Content-Length est renvoyé à la place de l'en-tête Content-Encoding: gzip.