From 3518481e9190f19bbf81741704f45cb3c1761758 Mon Sep 17 00:00:00 2001 From: SphinxKnight Date: Fri, 17 Sep 2021 20:08:55 +0200 Subject: Prepare HTTP section for Markdown conversion (#2453) * Remove summary classes * Remove hidden blocks * Remove id when not in headings * Remove notranslate * remove unecessary ltr dir * Remove spans from automatic translation tool copy/paste * Remove unhandled pe brush for plain text * make consistent notes * make consistent warning + rm rfc class * fix one-offs and images + spans * fix dls and subsequent oneoff errors * fix sups --- files/fr/web/http/compression/index.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'files/fr/web/http/compression') diff --git a/files/fr/web/http/compression/index.html b/files/fr/web/http/compression/index.html index ec4fa26888..49b4794212 100644 --- a/files/fr/web/http/compression/index.html +++ b/files/fr/web/http/compression/index.html @@ -35,20 +35,20 @@ translation_of: Web/HTTP/Compression

Les algorithmes de compression avec pertes sont généralement plus performants que les algorithmes de compression sans perte.

-

Puisque certains types de fichiers gèrent nativement la compression, il est souvent inutile de les compresser une seconde fois. En réalité, cela s'avère souvent contre-productif de par la taille induite par les données additionnelles nécessaires (lors de la compression, un dictionnaire de données est généré) le fichier en sortie est alors plus gros que celui avant compression. Veillez à ne pas utiliser les techniques suivantes pour les fichiers au format compressé.

+

Note : Puisque certains types de fichiers gèrent nativement la compression, il est souvent inutile de les compresser une seconde fois. En réalité, cela s'avère souvent contre-productif de par la taille induite par les données additionnelles nécessaires (lors de la compression, un dictionnaire de données est généré) le fichier en sortie est alors plus gros que celui avant compression. Veillez à ne pas utiliser les techniques suivantes pour les fichiers au format compressé.

Compression de bout en bout

La compression de bout en bout constitue la compression permettant le plus de gain de performances pour le Web. La compression de bout en bout est définie par la compression du corps du message qui est effectuée par le serveur et ne sera modifié qu'une fois arrivé à destination par le client. Les étapes lors du transport laissent la charge utile inchangée.

-

Séquence du serveur au client mettant en œuvre la compression de bout en bout

+

Séquence du serveur au client mettant en œuvre la compression de bout en bout

L'ensemble des navigateurs récents supportent la compression de bout en bout et le seul élément à échanger entre le serveur et le client est l'algorithme de compression à utiliser. Ces algorithmes sont optimisés pour le transport du texte. Dans les années 90, les technologies de compression ont évoluées rapidement, il existe donc de nombreuses possibilités en termes d'algorithmes. Les algorithmes qu'il convient de considérer à l'heure actuelle sont : gzip, le plus utilisé et br le nouveau venu.

Pour sélectionner l'algorithme à utiliser, le navigateur et le serveur s'appuient sur la négociation du contenu. Le navigateur envoie un en-tête {{HTTPHeader("Accept-Encoding")}} contenant les algorithmes qu'il prend en charge par ordre de préférence, le serveur en sélectionne un pour compresser le corps de la réponse et inclut l'algorithme utilisé dans l'en-tête {{HTTPHeader("Content-Encoding")}} pour informer le navigateur de l’algorithme sélectionné. La négociation de contenu s'appuyant sur l'encodage des données le serveur doit envoyer un en-tête {{HTTPHeader("Vary")}} contenant au moins {{HTTPHeader("Accept-Encoding")}} en plus de l'en-tête de la réponse. Les caches seront ainsi en mesure de gérer les différentes représentations de la ressource.

-

Séquence de négociation de contenu échangeant les algorithmes de compression et les en-têtes associés

+

Séquence de négociation de contenu échangeant les algorithmes de compression et les en-têtes associés

La compression permettant un gain de performance significatif, il est conseillé de l'activer pour l'ensemble des fichiers à l'exception des fichiers audios et vidéos au format compressé.

@@ -58,11 +58,11 @@ translation_of: Web/HTTP/Compression

La compression saut par saut, bien que similaire à la compression de bout en bout se distingue fondamentalement par son fonctionnement : la compression n'a pas lieu au niveau du serveur mais entre des éléments du réseau situés entre le serveur et le navigateur, chaque bond pouvant utiliser un mécanisme de compression différent.

-

Compression saut par saut entre le serveur et le client

+

Compression saut par saut entre le serveur et le client

HTTP permet de mettre en œuvre cette technique à l'aide d'un élément de négociation de contenu. Le nœud transmettant la donnée diffuse son utilisation de l'en-tête {{HTTPHeader("TE")}}, le noeud suivant choisit la méthode de compression appropriée et transmet son choix via {{HTTPHeader("Transfer-Encoding")}}.

-

Diagramme de séquence détaillant les échanges d'en-têtes en compression saut par saut

+

Diagramme de séquence détaillant les échanges d'en-têtes en compression saut par saut

En pratique la compression saut par saut est transparente pour le serveur et le client et elle demeure rarement utilisée. Les en-têtes {HTTPHeader("TE")}} and {{HTTPHeader("Transfer-Encoding")}} sont le plus souvent utilisé pour transmettre des réponses par morceaux ce qui permet la transmission de ressource avant d'en avoir déterminé la taille.

-- cgit v1.2.3-54-g00ecf