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

1 files changed, 19 insertions, 19 deletions

diff --git a/files/fr/web/http/caching/index.html b/files/fr/web/http/caching/index.html
index f398127120..adcab8ef8d 100644
--- a/files/fr/web/http/caching/index.html
+++ b/files/fr/web/http/caching/index.html
@@ -10,7 +10,7 @@ original_slug: Web/HTTP/Cache
 ---
 <div>{{HTTPSidebar}}</div>
 
-<p class="summary">Les performances des sites et applications web peuvent être significativement améliorées en réutilisant les ressources déjà collectées précédemment. Les caches web réduisent la latence et le trafic du réseau, et ainsi diminuent le temps nécessaire à l'affichage de la représentation d'une ressource. En utilisant la mise en cache HTTP, les sites web deviennent plus réactifs.</p>
+<p>Les performances des sites et applications web peuvent être significativement améliorées en réutilisant les ressources déjà collectées précédemment. Les caches web réduisent la latence et le trafic du réseau, et ainsi diminuent le temps nécessaire à l'affichage de la représentation d'une ressource. En utilisant la mise en cache HTTP, les sites web deviennent plus réactifs.</p>
 
 <h2 id="Différents_types_de_caches">Différents types de caches</h2>
 
@@ -18,7 +18,7 @@ original_slug: Web/HTTP/Cache
 
 <p>Il y a différents types de caches, qui peuvent être groupés en deux principales catégories : les caches privés et les caches partagés. Un <em>cache partagé</em> est un cache qui stocke les réponses pour qu’elles soient réutilisées par plus d’un utilisateur. Un <em>cache privé</em> est dédié à un seul utilisateur. Cette page aborde principalement les caches de navigateur et de proxy, mais il existe aussi des caches de passerelle, de CDN, les caches de proxy inversés et les répartiteurs de charge qui sont déployés sur les serveurs web pour une meilleure fiabilité, une meilleure performance et une meilleure évolutivité des sites et applications web.</p>
 
-<p><img alt="Ce que permet un cache, avantages et inconvénients des caches privés ou partagés." lang="fr-FR" src="https://mdn.mozillademos.org/files/16128/HTTPCacheType-fr.png" style="height: 573px; width: 910px;"></p>
+<p><img alt="Ce que permet un cache, avantages et inconvénients des caches privés ou partagés." src="http_cache_type.png"></p>
 
 <h3 id="Caches_de_navigateur_privés">Caches de navigateur privés</h3>
 
@@ -42,29 +42,29 @@ original_slug: Web/HTTP/Cache
 
 <p>Une entrée de cache peut aussi consister en de multiples réponses stockées différenciées par une clé secondaire, si la requête fait l’objet de négociation de contenu. Pour plus de détails, voir les informations à propos de l’en-tête {{HTTPHeader("Vary")}} <a href="#Varying_responses">ci-dessous</a>.</p>
 
-<h2 id="Contrôle_de_la_mise_en_cache"><span class="tlid-translation translation"><span title="">Contrôle de la mise en cache</span></span></h2>
+<h2 id="Contrôle_de_la_mise_en_cache">Contrôle de la mise en cache</h2>
 
-<h3 id="L'en-tête_Cache-control"><span class="tlid-translation translation"><span title="">L'en-tête Cache-control</span></span></h3>
+<h3 id="L'en-tête_Cache-control">L'en-tête Cache-control</h3>
 
-<p><span class="tlid-translation translation">Le</span> {{HTTPHeader("Cache-Control")}} HTTP/1.1 <span class="tlid-translation translation"><span title="">Le champ d'en-tête général est utilisé pour spécifier les directives pour les mécanismes de cache dans les requêtes et les réponses.</span> <span title="">Utilisez cet en-tête pour définir vos stratégies de mise en cache avec la variété de directives fournie</span></span>s.</p>
+<p>Le {{HTTPHeader("Cache-Control")}} HTTP/1.1 Le champ d'en-tête général est utilisé pour spécifier les directives pour les mécanismes de cache dans les requêtes et les réponses. Utilisez cet en-tête pour définir vos stratégies de mise en cache avec la variété de directives fournies.</p>
 
 <h4 id="Pas_du_tout_de_cache_mémoire">Pas du tout de cache mémoire</h4>
 
-<p><span class="tlid-translation translation"><span title="">Le cache ne doit rien stocker concernant la demande du client ou la réponse du serveur.</span> <span title="">Une demande est envoyée au serveur et une réponse complète est téléchargée à chaque fois.</span></span></p>
+<p>Le cache ne doit rien stocker concernant la demande du client ou la réponse du serveur. Une demande est envoyée au serveur et une réponse complète est téléchargée à chaque fois.</p>
 
 <pre>Cache-Control: no-store
 Cache-Control: no-cache, no-store, must-revalidate
 </pre>
 
-<h4 id="Pas_de_cache"><span class="tlid-translation translation"><span title="">Pas de cache</span></span></h4>
+<h4 id="Pas_de_cache">Pas de cache</h4>
 
-<p><span class="tlid-translation translation"><span title="">Un cache enverra la demande au serveur d'origine pour validation avant de publier une copie en cache</span></span>.</p>
+<p>Un cache enverra la demande au serveur d'origine pour validation avant de publier une copie en cache.</p>
 
 <pre>Cache-Control: no-cache</pre>
 
-<h4 id="Caches_privées_et_publiques"><span class="tlid-translation translation"><span title="">Caches privées et publiques</span></span></h4>
+<h4 id="Caches_privées_et_publiques">Caches privées et publiques</h4>
 
-<p><span class="tlid-translation translation"><span title="">La directive "public" indique que la réponse peut être mise en cache par n'importe quel cache.</span> <span title="">Cela peut être utile si les pages avec une authentification HTTP ou des codes d’état de réponse qui ne sont pas normalement mis en cache doivent maintenant être mis en cache.</span> <span title="">En revanche, "privé" indique que la réponse est destinée à un seul utilisateur et ne doit pas être stockée par un cache partagé.</span> <span title="">Un cache de navigateur privé peut stocker la réponse dans ce cas.</span></span></p>
+<p>La directive "public" indique que la réponse peut être mise en cache par n'importe quel cache. Cela peut être utile si les pages avec une authentification HTTP ou des codes d’état de réponse qui ne sont pas normalement mis en cache doivent maintenant être mis en cache. En revanche, "privé" indique que la réponse est destinée à un seul utilisateur et ne doit pas être stockée par un cache partagé. Un cache de navigateur privé peut stocker la réponse dans ce cas.</p>
 
 <pre>Cache-Control: private
 Cache-Control: public
@@ -72,21 +72,21 @@ Cache-Control: public
 
 <h4 id="Expiration">Expiration</h4>
 
-<p><span class="tlid-translation translation"><span title="">La directive la plus importante ici est "max-age = &lt;secondes&gt;", qui correspond au temps maximum pendant lequel une ressource est considérée comme nouvelle.</span> <span title="">Contrairement à {{HTTPHeader ("Expires")}}, cette directive est relative à l'heure de la demande.</span> <span title="">Pour les fichiers de l'application qui ne changeront pas, vous pouvez généralement ajouter une mise en cache agressive.</span> <span title="">Cela inclut les fichiers statiques tels que les images, les fichiers CSS et les fichiers JavaScript, par exemple.</span></span></p>
+<p>La directive la plus importante ici est "max-age = &lt;secondes&gt;", qui correspond au temps maximum pendant lequel une ressource est considérée comme nouvelle. Contrairement à {{HTTPHeader ("Expires")}}, cette directive est relative à l'heure de la demande. Pour les fichiers de l'application qui ne changeront pas, vous pouvez généralement ajouter une mise en cache agressive. Cela inclut les fichiers statiques tels que les images, les fichiers CSS et les fichiers JavaScript, par exemple.</p>
 
-<p><span class="tlid-translation translation"><span title="">Pour plus de détails, voir aussi la section</span></span> <a href="#Freshness">Freshness</a> <span class="tlid-translation translation"><span title="">ci-dessous.</span></span>.</p>
+<p>Pour plus de détails, voir aussi la section <a href="#Freshness">Freshness</a> ci-dessous..</p>
 
 <pre>Cache-Control: max-age=31536000</pre>
 
 <h4 id="Validation">Validation</h4>
 
-<p><span class="tlid-translation translation"><span title="">Lors de l'utilisation de la directive "must-revalidate", le cache doit vérifier l'état des ressources obsolètes avant de l'utiliser, et celles qui ont expiré ne doivent pas être utilisées.</span> <span title="">Pour plus de détails, voir la section</span></span> <a href="#Cache_validation">Validation</a> <span class="tlid-translation translation"><span title="">ci-dessous</span></span>.</p>
+<p>Lors de l'utilisation de la directive "must-revalidate", le cache doit vérifier l'état des ressources obsolètes avant de l'utiliser, et celles qui ont expiré ne doivent pas être utilisées. Pour plus de détails, voir la section <a href="#Cache_validation">Validation</a> ci-dessous.</p>
 
 <pre>Cache-Control: must-revalidate</pre>
 
-<h3 id="L'en-têtePragma"><span class="tlid-translation translation"><span title="">L'en-tête</span></span><code>Pragma</code></h3>
+<h3 id="L'en-têtePragma">L'en-tête<code>Pragma</code></h3>
 
-<p><span class="tlid-translation translation"><span title="">{{HTTPHeader ("Pragma")}} est un en-tête HTTP / 1.0. Il n'est pas spécifié pour les réponses HTTP et ne constitue donc pas un remplacement fiable pour l'en-tête général HTTP / 1.1 Cache-Control, bien qu'il se comporte de la même manière que Cache</span><span title="">-Control: no-cache, si le champ d'en-tête Cache-Control est omis dans une requête.</span> <span title="">Utilisez Pragma uniquement pour une compatibilité ascendante avec les clients HTTP / 1.0</span></span>.</p>
+<p>{{HTTPHeader ("Pragma")}} est un en-tête HTTP / 1.0. Il n'est pas spécifié pour les réponses HTTP et ne constitue donc pas un remplacement fiable pour l'en-tête général HTTP / 1.1 Cache-Control, bien qu'il se comporte de la même manière que Cache-Control: no-cache, si le champ d'en-tête Cache-Control est omis dans une requête. Utilisez Pragma uniquement pour une compatibilité ascendante avec les clients HTTP / 1.0.</p>
 
 <h2 id="Fraîcheur_(Freshness)">Fraîcheur (Freshness)</h2>
 
@@ -94,7 +94,7 @@ Cache-Control: public
 
 <p>Ici un exemple de ce processus avec un cache de proxy partagé :</p>
 
-<p><img alt="Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale." src="https://mdn.mozillademos.org/files/13771/HTTPStaleness.png" style="height: 910px; width: 822px;"></p>
+<p><img alt="Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale." src="http_staleness.png"></p>
 
 <p>Le calcul de la durée de vie de la fraîcheur est basé sur plusieurs en-têtes. Si une en-tête "<code>Cache-control: max-age=N</code>" est spécifiée, alors la durée de vie est égale à N. Si cette en-tête est absente (ce qui est souvent le cas),  on vérifie si une en-tête {{HTTPHeader("Expires")}} est présente. Si ce <code>Expires</code> existe, alors sa valeur moins la valeur de l'en-tête {{HTTPHeader("Date")}} détermine la durée de vie de la fraîcheur. Finalement, si aucune en-tête n'est présente, on en cherche une {{HTTPHeader("Last-Modified")}} et si elle est présente, alors la durée de vie de la fraîcheur du cache est égale à la valeur de l'en-tête <code>Date</code> moins la valeur de l'en-tête <code>Last-modified</code> divisée par 10.</p>
 
@@ -109,11 +109,11 @@ Cache-Control: public
 
 <p>Plus nous utilisons les ressources en cache, mieux se porteront la "responsivité" et les performances d'un site Web.  Pour optimiser ceci, les bonnes pratiques recommandent de fixer les temps d'expiration aussi loin que possible dans le futur.  C'est possible avec des ressources mises à jour régulièrement ou trés souvent mais ça devient problématique pour les ressources mises à jour trés rarement.  Ce sont les ressources qui bénéficieraient au mieux de la mise en cache mais cela les rend difficiles à mettre à jour. C'est typique des ressources techniques incluses ou liées depuis chaque page web :  les fichiers JavaScript et CSS ne changent pas fréquemment mais quand ils changent, vous voulez qu'ils soient mis à jour au plus vite.</p>
 
-<p>Les développeurs Web ont inventé une technique que Steve Sounders a appelée <em>revving</em><sup><a href="https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/">[1]</a></sup>. Les fichiers rarement mis à jour sont nommés d'une maniére spécifique : dans leur URL, habituellement dans le nom de fichier, est ajouté un numéro de révision (ou version). Comme ceci, chaque nouvelle révision / version de la ressource est considérée comme une ressource elle-même, qui ne change jamais et qui peut avoir un temps d'expiration trés éloigné dans le futur. En général un an ou plus. Dans le but d'avoir les nouvelles versions, tous les liens doivent être changés. C'est l'inconvénient de cette méthode : une complexité additionnelle habituellement prise en charge par la chaîne d'outils de développeurs Web.  Quand les ressources qui ne sont pas mises à jour fréquemment changent, elles induisent un changement supplémentaire aux ressources régulièrement rafraîchies. Quand elles sont lues, les nouvelles versions des autres sont lues aussi.</p>
+<p>Les développeurs Web ont inventé une technique que Steve Sounders a appelée <em>revving</em> (<a href="https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/">source</a>). Les fichiers rarement mis à jour sont nommés d'une maniére spécifique : dans leur URL, habituellement dans le nom de fichier, est ajouté un numéro de révision (ou version). Comme ceci, chaque nouvelle révision / version de la ressource est considérée comme une ressource elle-même, qui ne change jamais et qui peut avoir un temps d'expiration trés éloigné dans le futur. En général un an ou plus. Dans le but d'avoir les nouvelles versions, tous les liens doivent être changés. C'est l'inconvénient de cette méthode : une complexité additionnelle habituellement prise en charge par la chaîne d'outils de développeurs Web.  Quand les ressources qui ne sont pas mises à jour fréquemment changent, elles induisent un changement supplémentaire aux ressources régulièrement rafraîchies. Quand elles sont lues, les nouvelles versions des autres sont lues aussi.</p>
 
 <p>Cette technique a un avantage de plus : mettre à jour deux ressources en cache en même temps ne fera pas qu'une version périmée d'une des ressources sera utilisée avec la nouvelle version de l'autre. C'est trés important quand les sites ont des feuilles de style CSS ou des scripts JS qui ont des dépendances mutuelles c'est-à-dire qui dépendent l'un de l'autre parce qu'ils se réfèrent aux mêmes éléments HTML.</p>
 
-<p><img alt="" src="https://mdn.mozillademos.org/files/13779/HTTPRevved.png"></p>
+<p><img alt="How the revved cache mechanism works." src="http_revved_fix_typo.png"></p>
 
 <p>La version de révision ajoutée à la ressource révisée n'a pas à être sous une forme classique de chaîne de version comme  1.1.3, ou une suite monotone de chiffres. Cela peut être n'importe quoi qui prévienne une collision : un hash ou une date.</p>
 
@@ -137,7 +137,7 @@ Cache-Control: public
 
 <p>Quand un cache reçoit une requête qui peut être satisfaite par une réponse en cache qui a un champ d'en-tête  <code>Vary</code> il ne devra pas utiliser cette réponse à moins que tous les champs d'en-tête cités dans l'en-tête <code>Vary</code> ne soient communs aux deux : la requête originale (en cache) et la nouvelle requête.</p>
 
-<p><img alt="The Vary header leads cache to use more HTTP headers as key for the cache." src="https://mdn.mozillademos.org/files/13769/HTTPVary.png" style="height: 817px; width: 752px;"></p>
+<p><img alt="The Vary header leads cache to use more HTTP headers as key for the cache." src="http_vary.png"></p>
 
 <p>Cela peut être trés utile pour servir du contenu dynamique par exemple. Quand on se sert de l'en-tête  <code>Vary: User-Agent</code>, les serveurs de cache devront considérer l'agent utilisateur pour décider de servir la page du cache. Si vous servez du contenu varié aux utilisateurs de mobiles, cela vous aidera à éviter qu'un cache puisse servir, par erreur, une version "Desktop" de votre site. En plus, cela aidera Google et d'autres moteurs de recherche  à découvrir la version mobile d'une page et peut aussi les avertir qu'aucun "masquage" (<a href="https://en.wikipedia.org/wiki/Cloaking">Cloaking</a>) n'est à craindre.</p>