L'en-tête HTTP Accept-Encoding permet de définir quel sera l'encodage du contenu. Il s'agit généralement de l'algorithme de compression utilisé par le serveur. Le client peut alors décoder le corps de la requête correctement. Utilisant la négociation de contenu (content negotiation), le serveur choisit l'une des propositions d'encodage que le client supporte. Le serveur l'utilise et le notifie au client à l'aide de l'en-tête Content-Encoding de la réponse.
 
Même si le client et le serveur supportent deux algorithmes de compressions communs, le serveur peut choisir de ne pas compresser le corps de la réponse si l'encodage entity (aucune compression) est accepté par le client. Deux exemples de cas communs peuvent conduire à la non-compression du corps de la réponse:
 
  • Les données sont déjà compressées et la compression ne réduira pas la taille des données transmises. Cela peut être le cas de certains formats d'images qui sont déjà compressés;
  • Le serveur est en surcharge et ne peut plus allouer suffisamment de temps de calcul nécessaire pour compresser les données. Microsoft recommande de ne pas utiliser la compression si le serveur utilise plus de 80% de la puissance de calcul.

Dès lors que l’usage d’identity, signifiant l’absence de compression, n’est pas explicitement interdite, que ce soit par identity;q=0 ou *;q=0 (sans l’usage d’une autre valeur pour identity), le serveur ne doit jamais renvoyer une erreur 406 Not Acceptable.

Notes:
  • Un dépot IANA garde à jour une liste complète des encodage de contenu.

  • Deux autres encodages, bzip etbzip2, sont parfois utilisés, bien que non-standard. Ils implémentent l’algorithme utilisé par les deux programmes UNIX respectifs. À noter que le premier n’est plus maintenu suite à des problème de license.

 

Header type Request header
Forbidden header name yes

Syntaxe

Accept-Encoding: encoding_method;q=value
encoding_method
La valeur de encoding_method peut être: gzip, compress, deflate, br, identity ou *.
value
La valeur de q (qvalue) correspond à la priorité d'utilisation des méthodes d'encodage. Il doit être un nombre compris entre 0 et 1, il peut s'agir d'un nombre à virgule (pas plus de 3 chiffres après la virgule). 1 étant la valeur la plus importante, 0 la moins importante.

Il est possible de préciser plusieurs méthodes d'encodage, elles doivent être séparée par une virgule.

La valeur q est facultative, il est possible de l'omettre dans l'en-tête.

Directives

gzip
Un format de compression utilisant Lempel-Ziv coding (LZ77), avec un CRC (Contrôle de Redondance Cyclique) de 32-bit.
compress
Un format de compression utilisant l'algorithme Lempel-Ziv-Welch (LZW).
deflate
Un format de compression utilisant la structure zlib, avec l'algorithme de compression deflate.
br
Un format de compression utilisant l'algorithme Brotli.
identity
Indique la fonction identité (c'est-à-dire pas de compression ou de modification). Cette valeur est toujours considérée comme acceptable, mais si l'en-tête ne le précise pas.
*
Correspond à tous les systèmes d'encodage de contenu qui n'ont pas été listés dans l'en-tête. C'est la valeur par défaut de l'ent-ête s'il n'est pas présent. Cela ne signifie pas que tous les algorithmes sont supportés; seulement qu'aucune préférence n'est exprimée.
;q= (qvalues weighting)
La valeur indique l'ordre de préférence des méthodes de compression à utiliser. Ce champ utilise les quality values aussi appelée weight ou poids.

Exemples

Accept-Encoding: gzip

Accept-Encoding: gzip, compress, br

Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1

Spécifications

Spécification Titre
RFC 7231, section 5.3.4: Accept-Encoding Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context

Compatibilité

No compatibility data found. Please contribute data for "http/headers/accept-encoding" (depth: 1) to the MDN compatibility data repository.

Voir aussi

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : SphinxKnight, guillaumefenollar, Athorcis, PlayeurZero
 Dernière mise à jour par : SphinxKnight,