Accept-Encoding
Utilisation
L’en-tête de requête HTTP Accept-Encoding fait partie du processus de négociation de contenu et indique quelles méthodes d’encodage sont prises en charge par le client. Le serveur choisit l’une des méthodes disponibles, puis informe le client de son choix en incluant l’en-tête Content-Encoding dans la réponse HTTP.
Remarque
Dans certains cas, même lorsque le client et le serveur prennent en charge les mêmes méthodes d’encodage, la ressource d’origine n’est aucunement transformée avant l’envoi. Cela se produit lorsque la valeur identity de la ressource est également acceptable. Un exemple courant est celui de données déjà compressées, pour lesquelles appliquer un algorithme de compression supplémentaire ne réduira pas davantage la taille. C’est le cas des fichiers image pré-compressés, comme le JPEG. Une autre situation est celle d’un serveur fortement chargé, incapable de libérer les ressources nécessaires pour transformer les données avant transmission.
Plusieurs encodages se déclarent au moyen d’en-têtes HTTP Accept-Encoding distincts, ou bien à l’aide d’une liste séparée par des virgules. Le facteur q est également inclus pour indiquer une préférence ou une priorité.
Impact SEO
Les robots d’exploration et les récupérateurs de Google prennent en charge les encodages de contenu gzip, deflate et Brotli (br). Chaque user agent de Google annonce les encodages pris en charge dans l’en-tête Accept-Encoding de chaque requête, généralement sous la forme Accept-Encoding: gzip, deflate, br. Servir des réponses compressées à Googlebot réduit la bande passante et le temps d’exploration. Bingbot envoie Accept-Encoding: gzip, deflate.
gzip
La directive gzip indique que le client prend en charge la compression GNU zip. Il s’agit de l’encodage le plus largement pris en charge sur le Web.
deflate
La directive deflate indique que le client prend en charge la compression zlib. Malgré son nom, elle utilise une enveloppe zlib autour des données compressées DEFLATE brutes.
br
La directive br indique que le client prend en charge la compression Brotli. Pour les contenus textuels, Brotli atteint généralement de meilleurs taux de compression que gzip.
zstd
La directive zstd indique que le client prend en charge la compression Zstandard. Zstandard offre des taux de compression élevés avec des vitesses de décompression rapides.
identity
La directive identity indique qu’aucun encodage n’est appliqué. Cette valeur est toujours considérée comme acceptable, sauf exclusion explicite au moyen de identity;q=0.
* (joker)
Le joker * correspond à tout encodage non déjà listé dans l’en-tête. En l’absence d’en-tête Accept-Encoding, le serveur traite la requête comme si * avait été spécifié.
;q= (valeurs de qualité)
Le paramètre ;q= attribue à chaque encodage un poids compris entre 0 et 1, où 1 représente la priorité la plus élevée et 0 signifie « non acceptable ». Lorsqu’il est omis, la valeur de qualité par défaut est 1. Le serveur utilise ces poids pour sélectionner l’encodage préféré.
Exemple
Dans cet exemple, le client demande au serveur d’utiliser l’une de plusieurs méthodes d’encodage. Dans la première variante, chacune des options reçoit la même priorité. Dans la seconde variante, la directive de valeur q sert à pondérer la priorité des encodages. Le serveur répond avec la liste des encodages appliqués, ordonnée selon leur ordre de traitement.
Requête (variante #1)
GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *Requête (variante #2)
GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br;q=1.0, identity;q=0.5, *;q=0.25Réponse
HTTP/1.1 200 OK
Content-Encoding: gzip, brDépannage
Compression non appliquée malgré Accept-Encoding. Certains proxys inverses retirent Accept-Encoding de la requête avant de la transmettre. Dans nginx, proxy_set_header Accept-Encoding $http_accept_encoding préserve la valeur d’origine. Vérifiez avec curl -H “Accept-Encoding: gzip” -I.
Encodage sélectionné inattendu. Les valeurs de qualité (facteurs q) déterminent l’ordre de préférence. Une requête avec Accept-Encoding: gzip;q=0.5, br;q=1.0 privilégie Brotli. Omettre les valeurs q attribue un poids identique à chacune, et le serveur choisit librement.
Préflight CORS sans Accept-Encoding. L’en-tête Accept-Encoding figure sur la liste sûre de CORS et ne déclenche pas de préflight. Si la compression cesse de fonctionner sur les requêtes cross-origin, vérifiez que le serveur applique la compression indépendamment de l’en-tête Origin.
CDN servant des réponses non compressées. Certains CDN ne compressent que lorsque le serveur d’origine envoie une réponse non compressée accompagnée d’un Content-Type approprié. Vérifiez que l’origine répond avec Vary: Accept-Encoding afin que le CDN mette en cache séparément les variantes compressées et non compressées.
Encodage identity refusé. Envoyer Accept-Encoding: identity;q=0 indique au serveur que le client ne peut pas accepter de réponses non compressées. Si aucun encodage pris en charge n’est disponible, le serveur renvoie 406 Not Acceptable. Évitez de fixer identity à q=0 à moins que tous les encodages listés ne soient garantis disponibles.