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/authentication/index.html | 2 +- .../index.html | 8 +- .../web/http/basics_of_http/data_uris/index.html | 2 +- .../basics_of_http/evolution_of_http/index.html | 2 +- .../identifying_resources_on_the_web/index.html | 14 +-- .../web/http/basics_of_http/mime_types/index.html | 4 +- .../http/basics_of_http/resource_urls/index.html | 2 +- .../index.html | 28 +++--- files/fr/web/http/caching/index.html | 38 ++++---- files/fr/web/http/compression/index.html | 10 +-- files/fr/web/http/conditional_requests/index.html | 3 +- files/fr/web/http/content_negotiation/index.html | 14 +-- files/fr/web/http/cookies/index.html | 28 +++--- .../corsalloworiginnotmatchingorigin/index.html | 6 +- .../http/cors/errors/corsdidnotsucceed/index.html | 2 +- .../cors/errors/corsmissingalloworigin/index.html | 12 +-- files/fr/web/http/cors/errors/index.html | 10 +-- files/fr/web/http/cors/index.html | 100 ++++++++++----------- files/fr/web/http/csp/index.html | 2 +- files/fr/web/http/feature_policy/index.html | 4 +- .../fr/web/http/headers/accept-charset/index.html | 22 ++--- .../fr/web/http/headers/accept-encoding/index.html | 16 ++-- files/fr/web/http/headers/accept/index.html | 2 +- .../headers/access-control-allow-origin/index.html | 8 +- files/fr/web/http/headers/authorization/index.html | 7 +- files/fr/web/http/headers/cache-control/index.html | 45 +++------- files/fr/web/http/headers/connection/index.html | 4 +- .../http/headers/content-disposition/index.html | 24 ++--- .../web/http/headers/content-encoding/index.html | 6 +- .../web/http/headers/content-language/index.html | 10 +-- .../content-security-policy-report-only/index.html | 12 +-- .../content-security-policy/base-uri/index.html | 10 +-- .../block-all-mixed-content/index.html | 12 +-- .../content-security-policy/child-src/index.html | 6 +- .../content-security-policy/connect-src/index.html | 8 +- .../content-security-policy/default-src/index.html | 25 ++---- .../content-security-policy/font-src/index.html | 6 +- .../content-security-policy/form-action/index.html | 12 +-- .../frame-ancestors/index.html | 10 +-- .../content-security-policy/frame-src/index.html | 6 +- .../content-security-policy/img-src/index.html | 8 +- .../headers/content-security-policy/index.html | 22 ++--- .../manifest-src/index.html | 6 +- .../content-security-policy/media-src/index.html | 6 +- .../content-security-policy/navigate-to/index.html | 8 +- .../content-security-policy/object-src/index.html | 10 ++- .../plugin-types/index.html | 10 +-- .../prefetch-src/index.html | 6 +- .../content-security-policy/referrer/index.html | 6 +- .../content-security-policy/report-to/index.html | 38 ++++---- .../content-security-policy/report-uri/index.html | 10 +-- .../require-sri-for/index.html | 8 +- .../require-trusted-types-for/index.html | 6 +- .../content-security-policy/sandbox/index.html | 4 +- .../script-src-attr/index.html | 8 +- .../script-src-elem/index.html | 8 +- .../content-security-policy/script-src/index.html | 28 +++--- .../style-src-attr/index.html | 10 +-- .../style-src-elem/index.html | 10 +-- .../content-security-policy/style-src/index.html | 26 +++--- .../trusted-types/index.html | 10 +-- .../upgrade-insecure-requests/index.html | 18 ++-- .../content-security-policy/worker-src/index.html | 6 +- .../feature-policy/accelerometer/index.html | 2 +- .../fr/web/http/headers/feature-policy/index.html | 8 +- files/fr/web/http/headers/index.html | 12 ++- files/fr/web/http/headers/location/index.html | 4 +- files/fr/web/http/headers/referer/index.html | 2 +- .../fr/web/http/headers/referrer-policy/index.html | 37 ++++---- files/fr/web/http/headers/server/index.html | 6 +- files/fr/web/http/headers/set-cookie/index.html | 43 +++++---- .../http/headers/set-cookie/samesite/index.html | 12 +-- files/fr/web/http/headers/tk/index.html | 4 +- files/fr/web/http/headers/trailer/index.html | 4 +- files/fr/web/http/headers/vary/index.html | 4 +- .../http/headers/x-content-type-options/index.html | 10 +-- .../fr/web/http/headers/x-frame-options/index.html | 2 +- files/fr/web/http/link_prefetching_faq/index.html | 44 +++++---- files/fr/web/http/methods/connect/index.html | 2 +- files/fr/web/http/methods/patch/index.html | 4 +- files/fr/web/http/methods/post/index.html | 2 +- files/fr/web/http/methods/trace/index.html | 2 +- files/fr/web/http/overview/index.html | 16 ++-- files/fr/web/http/public_key_pinning/index.html | 10 +-- files/fr/web/http/redirections/index.html | 16 ++-- files/fr/web/http/session/index.html | 71 +++++++-------- files/fr/web/http/status/103/index.html | 4 +- files/fr/web/http/status/206/index.html | 4 +- files/fr/web/http/status/303/index.html | 2 +- files/fr/web/http/status/308/index.html | 2 +- files/fr/web/http/status/402/index.html | 4 +- files/fr/web/http/status/403/index.html | 4 +- files/fr/web/http/status/405/index.html | 2 +- files/fr/web/http/status/422/index.html | 2 +- files/fr/web/http/status/502/index.html | 2 +- files/fr/web/http/status/503/index.html | 2 +- files/fr/web/http/status/506/index.html | 2 +- files/fr/web/http/status/507/index.html | 2 +- files/fr/web/http/status/508/index.html | 2 +- files/fr/web/http/status/index.html | 21 ++--- 100 files changed, 567 insertions(+), 619 deletions(-) diff --git a/files/fr/web/http/authentication/index.html b/files/fr/web/http/authentication/index.html index d7349947e0..005ef8ed1a 100644 --- a/files/fr/web/http/authentication/index.html +++ b/files/fr/web/http/authentication/index.html @@ -5,7 +5,7 @@ translation_of: Web/HTTP/Authentication ---
{{HTTPSidebar}}
-

HTTP fournit la structure permettant le contrôle d'accès ainsi que l'authentification. Le schéma d'authentification HTTP le plus courant est « l'authentification basique » (« Basic authentication » en anglais). Cette page a pour but de présenter ce schéma d'authentification, et montre comment l'utiliser pour restreindre l'accès à votre serveur.

+

HTTP fournit la structure permettant le contrôle d'accès ainsi que l'authentification. Le schéma d'authentification HTTP le plus courant est « l'authentification basique » (« Basic authentication » en anglais). Cette page a pour but de présenter ce schéma d'authentification, et montre comment l'utiliser pour restreindre l'accès à votre serveur.

La structure d'authentification HTTP

diff --git a/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html b/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html index e7282738fa..0775a812bb 100644 --- a/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html +++ b/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html @@ -10,7 +10,7 @@ original_slug: Web/HTTP/Basics_of_HTTP/Choisir_entre_les_URLs_www_sans_www ---
{{HTTPSidebar}}
-

Une question récurrente chez les propriétaires de sites web est de choisir entre utiliser des URLs qui débutent ou non par www. Cette page fournit quelques conseils sur la meilleure approche à envisager.

+

Une question récurrente chez les propriétaires de sites web est de choisir entre utiliser des URLs qui débutent ou non par www. Cette page fournit quelques conseils sur la meilleure approche à envisager.

Que sont les noms de domaines ?

@@ -21,8 +21,8 @@ original_slug: Web/HTTP/Basics_of_HTTP/Choisir_entre_les_URLs_www_sans_www

Donc je dois choisir l'un ou l'autre pour mon site web ?

Ainsi, choisissez un de vos domaines comme domaine canonique. Les deux techniques ci-dessous permettent de maintenir le domaine non-canonique en état de marche.

@@ -61,7 +61,7 @@ original_slug: Web/HTTP/Basics_of_HTTP/Choisir_entre_les_URLs_www_sans_www

Choisir www ou non

-

Il s'agit d'un sujet subjectif âprement débattu. S vous souhaitez approfondir, vous pouvez lire de nombreux articles sur ce sujet.

+

Il s'agit d'un sujet subjectif âprement débattu. S vous souhaitez approfondir, vous pouvez lire de nombreux articles sur ce sujet.

Voir aussi

diff --git a/files/fr/web/http/basics_of_http/data_uris/index.html b/files/fr/web/http/basics_of_http/data_uris/index.html index 418099cb90..5922ae68e0 100644 --- a/files/fr/web/http/basics_of_http/data_uris/index.html +++ b/files/fr/web/http/basics_of_http/data_uris/index.html @@ -14,7 +14,7 @@ translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs

Les URLs de données, les URLs préfixées par le schéma data:, permettent aux créateurs de contenu d'intégrer de petits fichiers dans des documents.

-

Remarque : Les URLs de données sont traitées comme des origines opaques uniques par les navigateurs modernes, ainsi, contrairement aux autres objets classiques, ces URLs n'héritent pas des propriétés de l'objet ayant mené à cette URL.

+

Note : Les URLs de données sont traitées comme des origines opaques uniques par les navigateurs modernes, ainsi, contrairement aux autres objets classiques, ces URLs n'héritent pas des propriétés de l'objet ayant mené à cette URL.

Syntaxe

diff --git a/files/fr/web/http/basics_of_http/evolution_of_http/index.html b/files/fr/web/http/basics_of_http/evolution_of_http/index.html index 30f3797c38..759eb3679a 100644 --- a/files/fr/web/http/basics_of_http/evolution_of_http/index.html +++ b/files/fr/web/http/basics_of_http/evolution_of_http/index.html @@ -183,7 +183,7 @@ Server: Apache
  • Il permet au serveur de remplir le cache du client avant qu'il ne soit demandé par ce dernier, on parle alors d'évènements générés par le serveur.
    • -

    Devenu un standard officiel en mai 2015, HTTP/2 a rencontré un large succès. En janvier 2018, 23.9% des sites web utilisent HTTP/2 (8.7% en 2016)[1]. Ce qui représentait en 2015 plus de 68% des requêtes[2]. Les sites web générant beaucoup de trafic montre un taux d'adoption très rapide, ce qui s'explique par le gain de bande passante et les économies ainsi générées.

    +

    Devenu un standard officiel en mai 2015, HTTP/2 a rencontré un large succès. En janvier 2018, 23.9% des sites web utilisent HTTP/2 (8.7% en 2016) (source). Ce qui représentait en 2015 plus de 68% des requêtes (source). Les sites web générant beaucoup de trafic montre un taux d'adoption très rapide, ce qui s'explique par le gain de bande passante et les économies ainsi générées.

    Cette adoption fulgurante de HTTP/2 s'explique probablement par le fait que cette nouvelle version ne nécessite pas de mise à jour des sites web et des applications, l'utilisation de HTTP/1.x ou HTTP/2 étant transparente. Il suffit qu'un serveur à jour et un navigateur moderne communiquent pour que cela fonctionne. La traction générée par les premiers utilisateurs ainsi que le renouvellement des serveurs devenant obsolètes entraînent la croissance de HTTP/2 sans que cela requiert des efforts supplémentaires.

    diff --git a/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html b/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html index f03b6a1f47..113f4f10b2 100644 --- a/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html +++ b/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html @@ -8,7 +8,7 @@ original_slug: Web/HTTP/Basics_of_HTTP/Identifier_des_ressources_sur_le_Web ---
    {{HTTPSidebar}}
    -

    La cible d'une requête HTTP est appelée une "ressource", elle ne possède pas de type particulier. Il peut s'agir d'un document, d'une photo ou de n'importe quoi d'autre. Chaque ressource est identifiée à l'aide d'une Uniform Resource Identifier ({{Glossary("URI")}}) utilisé au sein de HTTP pour identifier les ressources.

    +

    La cible d'une requête HTTP est appelée une "ressource", elle ne possède pas de type particulier. Il peut s'agir d'un document, d'une photo ou de n'importe quoi d'autre. Chaque ressource est identifiée à l'aide d'une Uniform Resource Identifier ({{Glossary("URI")}}) utilisé au sein de HTTP pour identifier les ressources.

    L'identité et l'emplacement d'une ressource sur le Web sont souvent déterminées via une URL (Uniform Resource Locator° un type d'URI. Il existe des cas valides où l'identité et l'emplacement d'une ressource ne sont pas obtenus par la même URI comme lorsque l'en-tête {{HTTPHeader("Alt-Svc")}} est utilisé. La ressource requise par le client doit alors être récupérée à partir d'un emplacement différent.

    @@ -48,7 +48,7 @@ urn:ietf:rfc:7230

    Schéma ou protocole

    -
    Protocole
    +
    Protocole
    http:// constitue le protocole, il indique le protocole qui doit être utilisé par le navigateur. Il s'agit généralement de HTTP ou de sa variante sécurisée HTTPS. Le Web nécessite l'un ou l'autre de ces protocoles néanmoins, les navigateurs sont capables de gérer d'autres protocoles tels que mailto: (pour ouvrir un client mail) or ftp: pour gérer un transfert de fichier. Essayez, lorsque vous naviguez, d'identifier les protocoles utilisés. Les schémas usuels sont :
    @@ -106,35 +106,35 @@ urn:ietf:rfc:7230

    Autorité

    -
    Nom de domaine
    +
    Nom de domaine
    www.exemple.com est le nom de domaine ou l'autorité qui gère cet espace de noms. Il indique quel serveur Web est appelé. Il est aussi possible d'utiliser directement une adresse IP ({{Glossary("IP address")}}), néanmoins elles sont moins pratiques à manipuler pour des humains et sont donc moins fréquemment utilisées pour accéder à une ressource sur le Web.

    Port

    -
    Port
    +
    Port
    :80 constitue le port. Il indique la "porte" technique à utiliser pour accéder à une ressource sur un serveur web. Il est généralement omis puisque le serveur web utilisera par défaut les ports standards pour HTTP (port 80 pour HTTP et 443 pour HTTPS) pour permettre l'accès aux ressources qu'il héberge. Dans le cas où le port par défaut n'est pas celui utilisé, il est obligatoire de le spécifier.

    Chemin

    -
    Chemin d'accès au fichier
    +
    Chemin du fichier
    /chemin/du/fichier.html constitue le chemin d'accès à la ressource sur le serveur web. Au début du Web, le chemin représentait un emplacement physique où le fichier était stocké, à l'heure actuelle il s'agit d'une abstraction gérée par le serveur web sans réelle existence physique..

    Requête

    -
    Paramètre
    +
    Paramètres
    ?key1=value1&key2=value2 sont des paramètres additionnels fournis au serveur web. Ces paramètres sont un ensemble de clés/valeurs séparé par le symbole &. Le serveur web peut utiliser ces paramètres pour effectuer des tâches avant de retourner une ressource au client. Chaque serveur web possède ses propres règles en ce qui concerne la gestion des paramètres.

    Fragment

    -
    Ancre
    +
    Ancre
    #QuelquePartDansLeDocument est une ancre vers un morceau de la ressource en particulier, elle constitue une sorte de marque-page à l'intérieur de la ressource. Cela permet au navigateur de savoir où aller pour afficher le contenu à l'emplacement de l'ancre. Au sein d'une page HTML par exemple, le navigateur défilera jusqu'à ce point. Pour un document vidéo ou audio, le navigateur essaiera d'accéder au temps indiqué par l'ancre. On notera que la partie située après le caractère #, aussi appelé le fragment, n'est jamais envoyé au serveur avec la requête.
    diff --git a/files/fr/web/http/basics_of_http/mime_types/index.html b/files/fr/web/http/basics_of_http/mime_types/index.html index e114c7584f..7669f3e3c9 100644 --- a/files/fr/web/http/basics_of_http/mime_types/index.html +++ b/files/fr/web/http/basics_of_http/mime_types/index.html @@ -83,7 +83,7 @@ application/octet-stream 
    multipart/form-data
 multipart/byteranges
    -

    Les types composés, aussi appelés types multipart indiquent une catégorie de document qui sont constitués de différents éléments. A l'exception de multipart/form-data, utilisé en association avec des formulaires HTML et la méthode {{HTTPMethod("POST")}} et de multipart/byteranges, utilisé avec le statut HTTP {{HTTPStatus("206")}} Partial Content renvoyant uniquement une sous-partie du document ce qui entraînera vraisemblablement l'apparition d'une fenêtre "Enregistrer sous" étant donné que HTTP ne gère pas ces documents de manière différente et que le navigateur ne saura pas commment afficher ce document incomplet.

    +

    Les types composés, aussi appelés types multipart indiquent une catégorie de document qui sont constitués de différents éléments. A l'exception de multipart/form-data, utilisé en association avec des formulaires HTML et la méthode {{HTTPMethod("POST")}} et de multipart/byteranges, utilisé avec le statut HTTP {{HTTPStatus("206")}} Partial Content renvoyant uniquement une sous-partie du document ce qui entraînera vraisemblablement l'apparition d'une fenêtre "Enregistrer sous" étant donné que HTTP ne gère pas ces documents de manière différente et que le navigateur ne saura pas commment afficher ce document incomplet.

    Types MIME utiles pour les développeurs web

    @@ -96,7 +96,7 @@ multipart/byteranges

    Il s'agit de la valeur par défaut pour les fichiers texte. Bien qu'il signifie fichier texte de format inconnu, les navigateurs prendront pour hypothèse qu'ils peuvent l'afficher.

    -

    Il est important de noter que text/plain ne signifie pas tous les formats de fichiers textuels. Si le client s'attend à recevoir un format particulier de données textuelles, il est vraisemblable que le type text/plain ne soit pas considéré comme valide à la réception. Par exemple, si le client télécharge un fichier text/plain à partir d'un {{HTMLElement("link")}} déclarant des fichiers CSS, ce dernier ne sera pas considéré comme un CSS, le type MIME à utiliser étant text/css.

    +

    Note : Il est important de noter que text/plain ne signifie pas tous les formats de fichiers textuels. Si le client s'attend à recevoir un format particulier de données textuelles, il est vraisemblable que le type text/plain ne soit pas considéré comme valide à la réception. Par exemple, si le client télécharge un fichier text/plain à partir d'un {{HTMLElement("link")}} déclarant des fichiers CSS, ce dernier ne sera pas considéré comme un CSS, le type MIME à utiliser étant text/css.

    text/css

    diff --git a/files/fr/web/http/basics_of_http/resource_urls/index.html b/files/fr/web/http/basics_of_http/resource_urls/index.html index 30207ff2e8..62e578b91a 100644 --- a/files/fr/web/http/basics_of_http/resource_urls/index.html +++ b/files/fr/web/http/basics_of_http/resource_urls/index.html @@ -48,7 +48,7 @@ original_slug: Web/HTTP/Basics_of_HTTP/URLs_de_type_ressource

    Firefox nécessite néanmoins le chargement des ressources au sein d'un contenu web dans certains cas. Ainsi lorsque l'on souhaite accéder au code source d'une page à l'aide de "Code source de la page", un appel à viewsource.css via une URI resource: est nécessaire. Les ressources auxquelles le contenu web a besoin d'accéder ont été déplacées sous resource://content-accessible/, une partie isolée et ne contenant que des ressources n'étant pas confidentielles. De cette manière, il est possible d'exposer des ressources tout en réduisant la plupart des menaces.

    -

    Note : Il est recommandé de ne plus utiliser les URLs de type ressource lors du développement web ou de celui d'un module. Leur utilisation était peu fiable et la plupart ne fonctionnent plus.

    +

    Note : Il est recommandé de ne plus utiliser les URLs de type ressource lors du développement web ou de celui d'un module. Leur utilisation était peu fiable et la plupart ne fonctionnent plus.

    Spécifications

    diff --git a/files/fr/web/http/browser_detection_using_the_user_agent/index.html b/files/fr/web/http/browser_detection_using_the_user_agent/index.html index 59a3c01395..072103ebd8 100644 --- a/files/fr/web/http/browser_detection_using_the_user_agent/index.html +++ b/files/fr/web/http/browser_detection_using_the_user_agent/index.html @@ -14,7 +14,7 @@ original_slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent

    Les navigateurs et les standards ne sont cependant pas parfaits, il reste certains cas limites pour lesquels connaître le navigateur utilisé peut s'avérer utile. Utiliser le User-Agent dans ce but paraît simple mais le faire de manière fiable est en réalité très difficile. Ce document va vous guider pour lire le User-Agent aussi précisément que possible.

    -

    Il est important de rappeler que contrôler le contenu du User-Agent est rarement une bonne idée. Il est presque toujours possible de trouver une solution plus générique et compatible avec un plus grand nombre de navigateurs et d'appareils !

    +

    Note : Il est important de rappeler que contrôler le contenu du User-Agent est rarement une bonne idée. Il est presque toujours possible de trouver une solution plus générique et compatible avec un plus grand nombre de navigateurs et d'appareils !

    A prendre en compte avant d'identifier le navigateur

    @@ -58,13 +58,13 @@ original_slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent

    Faites aussi attention à ne pas utiliser une expression régulière trop simple sur le nom du navigateur car le User-Agent contient d'autres chaînes de caractères ne respectant pas le format clé/valeur. Par exemple, le User-Agent de Safari et Chrome contient une chaîne "like Gecko".

    - +
    - + - + @@ -101,15 +101,15 @@ original_slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent @@ -135,12 +135,12 @@ original_slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent

    Il y a cinq principaux moteurs de rendu : Trident, Gecko, Presto, Blink et Webkit. Puisque détecter le nom du moteur de rendu est courant, d'autres noms sont ajoutés dans beaucoup d'autres User-Agents. Il est donc important de faire attention aux faux positifs lorsqu'on cherche à détecter le moteur de rendu.

    -
     Moteur Doit contenir Ne doit pas contenir Notes
    Opera -

    OPR/xyz [1]

    +

    OPR/xyz>

    -

    Opera/xyz [2]

    +

    Opera/xyz

    		   -

    [1]  Opera 15+ (moteur de rendu Blink) 

    +

    Opera 15+ (moteur de rendu Blink)

    -

    [2] Opera 12- (moteur de rendu Presto)

    +

    Opera 12- (moteur de rendu Presto)
    +
    - + - + @@ -206,7 +206,7 @@ original_slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent - + @@ -221,10 +221,10 @@ original_slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent 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 ---
    {{HTTPSidebar}}
    -

    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.

    +

    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.

    Différents types de caches

    @@ -18,7 +18,7 @@ original_slug: Web/HTTP/Cache

    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 cache partagé est un cache qui stocke les réponses pour qu’elles soient réutilisées par plus d’un utilisateur. Un cache privé 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.

    -

    Ce que permet un cache, avantages et inconvénients des caches privés ou partagés.

    +

    Ce que permet un cache, avantages et inconvénients des caches privés ou partagés.

    Caches de navigateur privés

    @@ -42,29 +42,29 @@ original_slug: Web/HTTP/Cache

    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")}} ci-dessous.

    -

    Contrôle de la mise en cache

    +

    Contrôle de la mise en cache

    -

    L'en-tête Cache-control

    +

    L'en-tête Cache-control

    -

    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.

    +

    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.

    Pas du tout de cache mémoire

    -

    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.

    +

    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.

    Cache-Control: no-store
 Cache-Control: no-cache, no-store, must-revalidate
    -

    Pas de cache

    +

    Pas de cache

    -

    Un cache enverra la demande au serveur d'origine pour validation avant de publier une copie en cache.

    +

    Un cache enverra la demande au serveur d'origine pour validation avant de publier une copie en cache.

    Cache-Control: no-cache
    -

    Caches privées et publiques

    +

    Caches privées et publiques

    -

    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.

    +

    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.

    Cache-Control: private
 Cache-Control: public
@@ -72,21 +72,21 @@ Cache-Control: public
 
 
    Expiration
    
 
-
    La directive la plus importante ici est "max-age = <secondes>", 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.
    
+
    La directive la plus importante ici est "max-age = <secondes>", 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.
    
 
-
    Pour plus de détails, voir aussi la section Freshness ci-dessous..
    
+
    Pour plus de détails, voir aussi la section Freshness ci-dessous..
    
 
 
    Cache-Control: max-age=31536000
    
 
 
    Validation
    
 
-
    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 Validation ci-dessous.
    
+
    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 Validation ci-dessous.
    
 
 
    Cache-Control: must-revalidate
    
 
-
    L'en-têtePragma
    
+
    L'en-têtePragma
    
 
-
    {{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.
    
+
    {{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.
    
 
 
    Fraîcheur (Freshness)
    
 
@@ -94,7 +94,7 @@ Cache-Control: public
 
 
    Ici un exemple de ce processus avec un cache de proxy partagé :
    
 
-
    Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale.
    
+
    Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale.
    
 
 
    Le calcul de la durée de vie de la fraîcheur est basé sur plusieurs en-têtes. Si une en-tête "Cache-control: max-age=N" 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 Expires 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 Date moins la valeur de l'en-tête Last-modified divisée par 10.
    
 
@@ -109,11 +109,11 @@ Cache-Control: public
 
 
    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.
    
 
-
    Les développeurs Web ont inventé une technique que Steve Sounders a appelée revving[1]. 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.
    
+
    Les développeurs Web ont inventé une technique que Steve Sounders a appelée revving (source). 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.
    
 
 
    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.
    
 
-
    
+
    How the revved cache mechanism works.
    
 
 
    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.
    
 
@@ -137,7 +137,7 @@ Cache-Control: public
 
 
    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  Vary il ne devra pas utiliser cette réponse à moins que tous les champs d'en-tête cités dans l'en-tête Vary ne soient communs aux deux : la requête originale (en cache) et la nouvelle requête.
    
 
-
    The Vary header leads cache to use more HTTP headers as key for the cache.
    
+
    The Vary header leads cache to use more HTTP headers as key for the cache.
    
 
 
    Cela peut être trés utile pour servir du contenu dynamique par exemple. Quand on se sert de l'en-tête  Vary: User-Agent, 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" (Cloaking) n'est à craindre.
    
 
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.
    
 
diff --git a/files/fr/web/http/conditional_requests/index.html b/files/fr/web/http/conditional_requests/index.html
index 5cd04d8440..4590846e91 100644
--- a/files/fr/web/http/conditional_requests/index.html
+++ b/files/fr/web/http/conditional_requests/index.html
@@ -10,7 +10,7 @@ original_slug: Web/HTTP/Requêtes_conditionnelles
 ---
 
    {{HTTPSidebar}}
    
 
-
    Il existe en HTTP un concept de requête conditionnelle où le résultat, et même le succès d'une requête, peut être changé en comparant les ressources affectées avec la valeur d'un validateur. De telles requêtes peuvent être utiles pour valider le contenu d'un cache et éviter un contrôle inutile, pour vérifier l'intégrité d'un document, par exemple pour la reprise d'un téléchargement ou pour éviter de perdre des mises à jour quand on uploade ou modifie un document sur le serveur.
    
+
    Il existe en HTTP un concept de requête conditionnelle où le résultat, et même le succès d'une requête, peut être changé en comparant les ressources affectées avec la valeur d'un validateur. De telles requêtes peuvent être utiles pour valider le contenu d'un cache et éviter un contrôle inutile, pour vérifier l'intégrité d'un document, par exemple pour la reprise d'un téléchargement ou pour éviter de perdre des mises à jour quand on uploade ou modifie un document sur le serveur.
    
 
 
    Principes
    
 
@@ -62,7 +62,6 @@ original_slug: Web/HTTP/Requêtes_conditionnelles
   
    Réussit si la ETag de la ressource distante est différent de tout ceux listés dans l'en-tête. Par défaut, à moins que l'ETag soit préfixé par 'W/', c'est une validation forte.
    
   
    If-Modified-Since
    
   
    Réussit si la date Last-Modified de la ressource distante est plus récente que celle donnée dans l'en-tête.
    
-  
    
   
    If-Unmodified-Since
    
   
    Réussit si la date Last-Modified de la ressource distante est plus ancienne ou égale à celle donnée dans l'en-tête.
    
   
    If-Range
    
diff --git a/files/fr/web/http/content_negotiation/index.html b/files/fr/web/http/content_negotiation/index.html
index 0a3b3d4427..a1fe95c477 100644
--- a/files/fr/web/http/content_negotiation/index.html
+++ b/files/fr/web/http/content_negotiation/index.html
@@ -5,13 +5,13 @@ translation_of: Web/HTTP/Content_negotiation
 ---
 
    {{HTTPSidebar}}
    
 
-
    En HTTP, la négociation de contenu est le mécanisme utilisé pour fournir différentes représentations d'une ressource à la même URI, afin que l'agent utilisateur puisse spécifier celle qui convient le mieux à l'utilisateur (par exemple, la langue d'un document, le format d'image, ou l'encodage du contenu).
    
+
    En HTTP, la négociation de contenu est le mécanisme utilisé pour fournir différentes représentations d'une ressource à la même URI, afin que l'agent utilisateur puisse spécifier celle qui convient le mieux à l'utilisateur (par exemple, la langue d'un document, le format d'image, ou l'encodage du contenu).
    
 
 
    Principes de la négociation de contenu
    
 
 
    Un document spécifique s'appelle une ressource. Lorsqu'un client veut y accéder, il le demande en utilisant son URL. Le serveur utilise cette URL pour choisir une des différentes versions qu'il peut fournir - chaque version étant appelée une représentation - et renvoie cette représentation spécifique au client. La ressource globale, ainsi que chacune de ses représentations, ont une URL spécifique. La façon dont une représentation spécifique est choisie est déterminée par la négociation de contenu et il existe plusieurs façons de négocier entre le client et le serveur.
    
 
-
    
+
    
 
 
    La sélection de la représentation la mieux adaptée se fait par l'un des deux mécanismes suivants:
    
 
@@ -28,7 +28,7 @@ translation_of: Web/HTTP/Content_negotiation
 
 
    Dans la négociation de contenu gérée par le serveur, ou négociation proactive de contenu, le navigateur (ou tout autre type de client) envoie plusieurs en-têtes HTTP avec l'URL décrivant les choix préférés de l'utilisateur. Le serveur les utilise comme indications et un algorithme interne choisit le meilleur contenu à servir au client. L'algorithme est spécifique au serveur et n'est pas défini dans la norme. Voir, par exemple, l'algorithme de négociation d'Apache 2.2.
    
 
-
    
+
    
 
 
    La norme HTTP/1.1 définit la liste des en-têtes standard qui initient la négociation pilotée par le serveur ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}). Bien qu'à proprement parler {{HTTPHeader("User-Agent")}} ne figure pas dans la liste, il est aussi parfois utilisé pour envoyer une représentation spécifique de la ressource demandée, bien que cela ne soit pas considéré comme une bonne pratique. Le serveur utilise l'en-tête {{HTTPHeader("Vary")}} pour indiquer quels en-têtes il a effectivement utilisés pour la négociation de contenu (ou plus précisément les en-têtes de réponse associés), pour que les caches puissent fonctionner de manière optimale.
    
 
@@ -51,7 +51,7 @@ translation_of: Web/HTTP/Content_negotiation
 
    The Accept-CH header {{experimental_inline}}
    
 
 
    
-
    This is part of an experimental technology called Client Hints. Initial support is in Chrome 46 or later. The Device-Memory value is in Chrome 61 or later.
    
+
    Note : This is part of an experimental technology called Client Hints. Initial support is in Chrome 46 or later. The Device-Memory value is in Chrome 61 or later.
    
 
    
 
 
    The experimental {{HTTPHeader("Accept-CH")}} lists configuration data that can be used by the server to select an appropriate response. Valid values are:
    
@@ -92,7 +92,7 @@ translation_of: Web/HTTP/Content_negotiation
 
    The Accept-CH-Lifetime header
    
 
 
    
-
    This is part of an experimental technology called Client Hints  and is only available in Chrome 61 or later.
    
+
    Note : This is part of an experimental technology called Client Hints  and is only available in Chrome 61 or later.
    
 
    
 
 
    The {{HTTPHeader("Accept-CH-Lifetime")}} header is used with the Device-Memory value of the Accept-CH header and indicates the amount of time the device should opt-in to sharing the amount of device memory with the server. The value is given in miliseconds and it's use is optional.
    
@@ -117,7 +117,7 @@ translation_of: Web/HTTP/Content_negotiation
 
    The User-Agent header
    
 
 
    
-
    Though there are legitimate uses of this header for selecting content, it is considered bad practice to rely on it to define what features are supported by the user agent.
    
+
    Note : Though there are legitimate uses of this header for selecting content, it is considered bad practice to rely on it to define what features are supported by the user agent.
    
 
    
 
 
    The {{HTTPHeader("User-Agent")}} header identifies the browser sending the request. This string may contain a space-separated list of product tokens and comments.
    
@@ -138,6 +138,6 @@ translation_of: Web/HTTP/Content_negotiation
 
 
    From the beginnings of HTTP, the protocol allowed another negotiation type: agent-driven negotiation or reactive negotiation. In this negotiation, when facing an ambiguous request, the server sends back a page containing links to the available alternative resources. The user is presented the resources and choose the one to use.
    
 
-
    
+
    
 
 
    Unfortunately, the HTTP standard does not specify the format of the page allowing to choose between the available resource, which prevents to easily automatize the process. Besides falling back to the server-driven negotiation, this method is almost always used in conjunction with scripting, especially with JavaScript redirection: after having checked for the negotiation criteria, the script performs the redirection. A second problem is that one more request is needed in order to fetch the real resource, slowing the availability of the resource to the user.
    
diff --git a/files/fr/web/http/cookies/index.html b/files/fr/web/http/cookies/index.html
index 334217f6db..1568fcf41d 100644
--- a/files/fr/web/http/cookies/index.html
+++ b/files/fr/web/http/cookies/index.html
@@ -9,7 +9,8 @@ translation_of: Web/HTTP/Cookies
 ---
 
    {{HTTPSidebar}}
    
 
-
    Un cookie HTTP (cookie web, cookie de navigateur) est un petit ensemble de données qu'un serveur envoie au navigateur web de l'utilisateur. Le navigateur peut alors le stocker localement, puis le renvoyer à la prochaine requête vers le même serveur. Typiquement, cette méthode est utilisée par le serveur pour déterminer si deux requêtes proviennent du même navigateur — pour exemple pour garder un utilisateur connecté. Les cookies permettent de conserver de l'information en passant par le procotole HTTP qui est lui "sans état".
    
+
    Un cookie HTTP (cookie web, cookie de navigateur) est un petit ensemble de données qu'un serveur envoie au navigateur web de l'utilisateur. Le navigateur peut alors le stocker localement, puis le renvoyer à la prochaine requête vers le même serveur. Typiquement, cette méthode est utilisée par le serveur pour déterminer si deux requêtes proviennent du même navigateur.
    
+
    Cela permet, par exemple, de garder un utilisateur connecté. Les cookies permettent de conserver de l'information en passant par le procotole HTTP qui est lui "sans état".
    
 
 
    Les cookies sont utilisés pour 3 raisons principales :
    
 
@@ -25,7 +26,7 @@ translation_of: Web/HTTP/Cookies
 
    Les cookies étaient auparavant utilisés pour le stockage côté client. C'était légitime lorsque les cookies étaient la seule manière de stocker des données côté client, mais il est aujourd'hui recommandé de préférer les APIs modernes de stockage. Les cookies sont envoyés avec chaque requête, ils peuvent donc avoir un impact négatif sur les performances (particulièrement pour des connexions mobiles). Les APIs modernes de stockage côté client sont l'API Web storage (localStorage et sessionStorage) et IndexedDB.
    
 
 
    
-
    Pour voir les cookies stockés (et d'autres stockages que le navigateur peut conserver), vous ouvrez l'Inspecteur de stockage des Outils Développeur et sélectionnez Cookies dans l'onglet stockage (pour Firefox).
    
+
    Note : Pour voir les cookies stockés (et d'autres stockages que le navigateur peut conserver), vous ouvrez l'Inspecteur de stockage des Outils Développeur et sélectionnez Cookies dans l'onglet stockage (pour Firefox).
    
 
    
 
 
    Création de cookies
    
@@ -38,14 +39,15 @@ translation_of: Web/HTTP/Cookies
 
 
    Set-Cookie: <nom-du-cookie>=<valeur-du-cookie>
    
 
-
    Note : Voici comme utiliser l'en-tête Set-Cookie dans divers langages de programmation côté serveur :
-
-
+
    
+  
    Note : Voici comme utiliser l'en-tête Set-Cookie dans divers langages de programmation côté serveur :
+    
    
+  
    
 
    
 
 
    Exemple de réponse HTTP complète:
    
@@ -57,7 +59,7 @@ Set-Cookie: tasty_cookie=strawberry
 
 [contenu de la page]
    -

    Maintenant, à chaque requête vers le serveur, le navigateur va renvoyer au serveur tous les cookies stockés, avec l'entête {{HTTPHeader("Cookie")}}:

    +

    Maintenant, à chaque requête vers le serveur, le navigateur va renvoyer au serveur tous les cookies stockés, avec l'entête {{HTTPHeader("Cookie")}}:

    GET /sample_page.html HTTP/1.1
 Host: www.example.org
@@ -74,7 +76,7 @@ Cookie: yummy_cookie=choco; tasty_cookie=strawberry
    Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
    -

    Note: Quand une date d'expiration est définie, le temps et l'heure définis sont relatifs au client auquel le cookie est envoyé, et non au serveur.

    +

    Note : Quand une date d'expiration est définie, le temps et l'heure définis sont relatifs au client auquel le cookie est envoyé, et non au serveur.

    Cookies Secure et HttpOnly

    @@ -117,7 +119,7 @@ console.log(document.cookie);

    Sécurité

    -

    Les informations confidentielles ou sensibles ne devraient jamais être stockée ou transmises avec les Cookies HTTP, car le mécanisme entier est intrinsèquement insécurisé.

    +

    Note : Les informations confidentielles ou sensibles ne devraient jamais être stockée ou transmises avec les Cookies HTTP, car le mécanisme entier est intrinsèquement insécurisé.

    Piratage de session et XSS

    diff --git a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html index 0f178e49eb..e113a3438b 100644 --- a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html +++ b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html @@ -16,7 +16,7 @@ original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginNeCorrespondPas

    Symptomes

    -
    Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « xyz »
    +
    Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « xyz »

    Quel est le problème ?

    @@ -28,11 +28,11 @@ original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginNeCorrespondPas

    Par exemple, dans Apache, ajoutez une ligne comme celle qui suit à la configuration du serveur (dans la section appropriée <Directory>, <Location>, <Files>, ou <VirtualHost>). La configuration se trouve généralement dans un fichier .conf (httpd.conf et apache.conf sont des noms couramment attribués à ces fichiers), ou dans un fichier .htaccess.

    -
    Header set Access-Control-Allow-Origin 'origin-list'
    +
    Header set Access-Control-Allow-Origin 'origin-list'

    Pour Nginx, la commande pour mettre en place cet entête est :

    -
    add_header 'Access-Control-Allow-Origin' 'origin-list'
    +
    add_header 'Access-Control-Allow-Origin' 'origin-list'

    Voir aussi

    diff --git a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html index 42b23087d6..1745ec854f 100644 --- a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html +++ b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html @@ -22,7 +22,7 @@ original_slug: Web/HTTP/CORS/Errors/CORSNAPasRéussi 
    Raison: la requête CORS a échoué
    -

    Qu'est ce qui ne s'est pas bien passé ?

    +

    Qu'est ce qui ne s'est pas bien passé ?

    La requête {{Glossary("HTTP")}} qui utilise le CORS a échoué à cause de la connection HTTP qui n'a pas aboutie soit au niveau du réseau, soit du protocole. L'erreur n'est pas directement lié au CORS, mais est une quelconque erreur réseau de base.

    diff --git a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html index 9eda6df7ea..e49b01ae2a 100644 --- a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html +++ b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html @@ -8,7 +8,7 @@ original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginManquant

    Symptomes

    -
     Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.
    +
     Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.

    Quel est le problème ?

    @@ -18,25 +18,25 @@ original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginManquant

    Par exemple, pour autoriser le site https://amazing.site à accéder aux resources avec CORS, le header doit être comme suit :

    -
    Access-Control-Allow-Origin: https://amazing.site
    +
    Access-Control-Allow-Origin: https://amazing.site

    Vous pouvez aussi configurer le serveur pour autoriser tous les domaines à accéder aux ressources avec le caractère générique *. Ceci ne devrait être utilisé que pour des APIs publiques. Les APIs privées ne devraient jamais utiliser *, et devraient à la place utiliser un domaine ou un ensemble de domaines. De plus, l'astérisque ne fonctionne que pour les requêtes avec l'attribut {{htmlattrxref("crossorigin")}} ayant comme valeur anonymous.

    -
    Access-Control-Allow-Origin: *
    +
    Access-Control-Allow-Origin: *
    -

    Attention: Autoriser n'importe quel site à accéder à une API privée est une mauvaise idée.

    +

    Attention : Autoriser n'importe quel site à accéder à une API privée est une mauvaise idée.

    Pour autoriser n'importe quel site à faire des requêtes CORS sans utiliser le caractère générique * (par exemple, pour fournir des authentifiants), votre serveur doit lire la valeur de l'entête Origin de la requête et l'utiliser dans Access-Control-Allow-Origin, tout en ajoutant une entête Vary: Origin pour indiquer que certaines entêtes sont définies dynamiquement selon leur origine.

    L'instruction exacte pour définir les entêtes dépend de votre serveur Web. Par exemple, avec Apache, ajouter (dans la section <Directory>, <Location>, <Files>, ou <VirtualHost> appropriée) la ligne ci-dessous au fichier de configuration. Le fichier de configuration est en général un .conf (httpd.conf et apache.conf sont les noms les plus communs) ou un fichier nommé .htaccess.

    -
    Header set Access-Control-Allow-Origin 'origin-list'
    +
    Header set Access-Control-Allow-Origin 'origin-list'

    Avec Nginx, la commande pour créer l'en-tête est :

    -
    add_header 'Access-Control-Allow-Origin' 'origin-list'
    +
    add_header 'Access-Control-Allow-Origin' 'origin-list'
    diff --git a/files/fr/web/http/cors/errors/index.html b/files/fr/web/http/cors/errors/index.html index 30bb82d87f..17fa5f8e9b 100644 --- a/files/fr/web/http/cors/errors/index.html +++ b/files/fr/web/http/cors/errors/index.html @@ -16,7 +16,7 @@ translation_of: Web/HTTP/CORS/Errors ---
    {{HTTPSidebar}}
    -

    Cross-Origin Resource Sharing ({{Glossary("CORS")}}) est une norme qui permet à un serveur d'assouplir la politique de même origine.

    +

    Cross-Origin Resource Sharing ({{Glossary("CORS")}}) est une norme qui permet à un serveur d'assouplir la politique de même origine.

    Celle-ci est utilisée pour autoriser explicitement certaines requêtes provenant d'autres sources tout en en rejetant d'autres. Par exemple, si un site offre un service intégrable, il peut être nécessaire d'assouplir certaines restrictions. La configuration d'une telle configuration CORS n'est pas nécessairement facile et peut présenter certains défis. Dans ces pages, nous examinerons quelques messages d'erreur CORS courants et comment les résoudre.

    @@ -33,16 +33,16 @@ translation_of: Web/HTTP/CORS/Errors
  • Essayez de reproduir la requête qui échoue et vérifiez la console pour trouver les messages de violation CORS, ce qui tournerait autours de:
    • -

    Firefox console showing CORS error

    +

    Firefox console showing CORS error

    Le text de l'erreur sera probablement similaire à:

    -
    Cross-Origin Request Blocked: The Same Origin Policy disallows
+
    Cross-Origin Request Blocked: The Same Origin Policy disallows
 reading the remote resource at https://some-url-here. (Reason:
-additional information here).
    
+additional information here).
    -

    Note: Pour des raisons de sécurité, il est impossible d'analyser les causes de l'erreur CORS via JavaScript. Seule une indication de l'échec de la requête sera fournie. Il faut donc absolument regarder manuellement les messages d'erreur de la console pour débugger.

    +

    Note : Pour des raisons de sécurité, il est impossible d'analyser les causes de l'erreur CORS via JavaScript. Seule une indication de l'échec de la requête sera fournie. Il faut donc absolument regarder manuellement les messages d'erreur de la console pour débugger.

    Messages d'erreur CORS

    diff --git a/files/fr/web/http/cors/index.html b/files/fr/web/http/cors/index.html index 6be35f1aaf..24d38600ac 100644 --- a/files/fr/web/http/cors/index.html +++ b/files/fr/web/http/cors/index.html @@ -18,7 +18,7 @@ translation_of: Web/HTTP/CORS

    Pour des raisons de sécurité, les requêtes HTTP multi-origine émises depuis les scripts sont restreintes. Ainsi, {{domxref("XMLHttpRequest")}} et l'API Fetch respectent la règle d'origine unique. Cela signifie qu'une application web qui utilise ces API peut uniquement émettre des requêtes vers la même origine que celle à partir de laquelle l'application a été chargée, sauf si des en-têtes CORS sont utilisés.

    -

    +

    Le CORS permet de prendre en charge des requêtes multi-origines sécurisées et des transferts de données entre des navigateurs et des serveurs web. Les navigateurs récents utilisent le CORS dans une API contenante comme {{domxref("XMLHttpRequest")}} ou Fetch pour aider à réduire les risques de requêtes HTTP multi-origines.

    @@ -55,9 +55,9 @@ translation_of: Web/HTTP/CORS

    Les fragments de code JavaScript (ainsi que les instances serveurs qui gèrent ces requêtes) se trouvent sur http://arunranga.com/examples/access-control/ et fonctionnent pour les navigateurs qui prennent en charge {{domxref("XMLHttpRequest")}} dans un contexte multi-site.

    -

    Un aperçu « côté serveur » des fonctionnalités CORS se trouve dans l'article Contrôle d'accès côté serveur.

    +

    Un aperçu « côté serveur » des fonctionnalités CORS se trouve dans l'article Contrôle d'accès côté serveur.

    -

    Requêtes simples

    +

    Requêtes simples

    Certaines requêtes ne nécessitent pas de requête CORS préliminaire. Dans le reste de cet article, ce sont ce que nous appellerons des requêtes « simples » (bien que la spécification {{SpecName('Fetch')}} (qui définit le CORS) n'utilise pas ce terme). Une requête simple est une requête qui respecte les conditions suivantes :

    @@ -88,13 +88,17 @@ translation_of: Web/HTTP/CORS
  • Aucun objet {{domxref("ReadableStream")}} n'est utilisé dans la requête.
    • -
    Note : Cela correspond aux classes de requêtes généralement produites par du contenu web. Aucune donnée de réponse n'est envoyée au client qui a lancé la requête sauf si le serveur envoie un en-tête approprié. Aussi, les sites qui empêchent les requêtes étrangères falsifiées ne craignent rien de nouveau.
    +
    +

    Note : Cela correspond aux classes de requêtes généralement produites par du contenu web. Aucune donnée de réponse n'est envoyée au client qui a lancé la requête sauf si le serveur envoie un en-tête approprié. Aussi, les sites qui empêchent les requêtes étrangères falsifiées ne craignent rien de nouveau.

    +
    -
    Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.
    +
    +

    Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.

    +
    -

    Si, par exemple, on a un contenu web situé sous le domaine http://toto.example qui souhaite invoquer du contenu situé sous le domaine http://truc.autre, on pourrait utiliser du code JavaScript semblable à ce qui suit sur toto.example :

    +

    Si, par exemple, on a un contenu web situé sous le domaine http://toto.example qui souhaite invoquer du contenu situé sous le domaine http://truc.autre, on pourrait utiliser du code JavaScript semblable à ce qui suit sur toto.example :

    -
    var invocation = new XMLHttpRequest();
+
    var invocation = new XMLHttpRequest();
 var url = 'http://truc.autre/resources/public-data/';
 
 function callOtherDomain() {
@@ -108,11 +112,11 @@ function callOtherDomain() {
 
 
    Cela entraînera un échange simple entre le client et le serveur laissant aux en-têtes CORS le soin de gérer les privilèges d'accès :
    
 
-
    
+
    
 
 
    Voyons dans le détail ce que le navigateur envoie au serveur et quelle sera sa réponse :
    
 
-
    GET /resources/public-data/ HTTP/1.1
+
    GET /resources/public-data/ HTTP/1.1
 Host: truc.autre
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
@@ -136,15 +140,15 @@ Content-Type: application/xml
 [XML Data]
 
    
 
-
    Les lignes 1 à 10 correspondent aux en-têtes envoyés. L'en-tête qui nous intéresse particulièrement ici est {{HTTPHeader("Origin")}}, situé à la ligne 10 : on y voit que l'invocation provient du domaine http://toto.example.
    
+
    Les lignes 1 à 10 correspondent aux en-têtes envoyés. L'en-tête qui nous intéresse particulièrement ici est {{HTTPHeader("Origin")}}, situé à la ligne 10 : on y voit que l'invocation provient du domaine http://toto.example.
    
 
-
    Les lignes 13 à 22 détaillent la réponse HTTP du serveur situé sous le domaine http://truc.autre. Dans la réponse, le serveur renvoie un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} (visible à la ligne 16). On voit ici les en-têtes {{HTTPHeader("Origin")}} et {{HTTPHeader("Access-Control-Allow-Origin")}} pour un contrôle d'accès dans sa forme la plus simple. Ici, le serveur répond avec Access-Control-Allow-Origin: * ce qui signifie que la ressource peut être demandée par n'importe quel domaine. Si les propriétés de la ressource située sous http://truc.autre souhaitaient restreindre l'accès à la ressource à l'origine http://toto.example, ils auraient renvoyé :
    
+
    Les lignes 13 à 22 détaillent la réponse HTTP du serveur situé sous le domaine http://truc.autre. Dans la réponse, le serveur renvoie un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} (visible à la ligne 16). On voit ici les en-têtes {{HTTPHeader("Origin")}} et {{HTTPHeader("Access-Control-Allow-Origin")}} pour un contrôle d'accès dans sa forme la plus simple. Ici, le serveur répond avec Access-Control-Allow-Origin: * ce qui signifie que la ressource peut être demandée par n'importe quel domaine. Si les propriétés de la ressource située sous http://truc.autre souhaitaient restreindre l'accès à la ressource à l'origine http://toto.example, ils auraient renvoyé :
    
 
-
    Access-Control-Allow-Origin: http://toto.example
    
+
    Access-Control-Allow-Origin: http://toto.example
    
 
-
    On notera que, dans ce cas, aucun autre domaine que http://toto.example (tel qu'identifié par l'en-tête Origin) ne pourra accéder à la ressource. L'en-tête Access-Control-Allow-Origin devrait contenir la valeur qui a été envoyée dans l'en-tête  Origin de la requête.
    
+
    On notera que, dans ce cas, aucun autre domaine que http://toto.example (tel qu'identifié par l'en-tête Origin) ne pourra accéder à la ressource. L'en-tête Access-Control-Allow-Origin devrait contenir la valeur qui a été envoyée dans l'en-tête  Origin de la requête.
    
 
-
    Requêtes nécessitant une requête préliminaire
    
+
    Requêtes nécessitant une requête préliminaire
    
 
 
    À la différence des requêtes simples, les requêtes préliminaires envoient d'abord une requête HTTP avec la méthode {{HTTPMethod("OPTIONS")}} vers la ressource de l'autre domaine afin de déterminer quelle requête peut être envoyée de façon sécurisée. Les requêtes entre différents sites peuvent notamment utiliser ce mécanisme de vérification préliminaire lorsque des données utilisateurs sont impliquées.
    
 
@@ -185,11 +189,13 @@ Content-Type: application/xml
  
  • Ou si un objet {{domxref("ReadableStream")}} est utilisé dans la requête.
    • 
 
 
-
    Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.
    
+
    
+  
    Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.
    
+
    
 
 
    Voici un exemple d'une requête qui devra être précédée d'une requête préliminaire :
    
 
-
    var invocation = new XMLHttpRequest();
+
    var invocation = new XMLHttpRequest();
 var url = 'http://truc.autre/resources/post-here/';
 var body = '<?xml version="1.0"?><personne><nom>Toto</nom></personne>';
 
@@ -209,7 +215,7 @@ function callOtherDomain(){
 
 
    Dans le fragment de code ci-avant, à la ligne 3, on crée un corps XML envoyé avec la requête POST ligne 8. Sur la ligne 9, on voit également un en-tête de requête HTTP non standard : X-PINGOTHER: pingpong. De tels en-têtes ne sont pas décrits par le protocole HTTP/1.1 mais peuvent être utilisés par les applications web. La requête utilisant un en-tête Content-Type qui vaut application/xml et un en-tête spécifique, il est nécessaire d'envoyer au préalable une requête préliminaire.
    
 
-
    pre-flight CORS french
    
+
    
 
 
    
 
    Note : Comme décrit après, la vraie requête POST n'inclut pas les en-têtes Access-Control-Request-* qui sont uniquement nécessaires pour la requête OPTIONS.
    
@@ -217,7 +223,7 @@ function callOtherDomain(){
 
 
    Voyons ce qui se passe entre le client et le serveur. Le premier échange est la requête/réponse préliminaire :
    
 
-
    OPTIONS /resources/post-here/ HTTP/1.1
+
    OPTIONS /resources/post-here/ HTTP/1.1
 Host: truc.autre
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
@@ -247,7 +253,7 @@ Content-Type: text/plain
 
 
    Une fois que la requête préliminaire est effectuée, la requête principale est envoyée :
    
 
-
    POST /resources/post-here/ HTTP/1.1
+
    POST /resources/post-here/ HTTP/1.1
 Host: truc.autre
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
@@ -282,7 +288,7 @@ Content-Type: text/plain
 
 
    Entre les lignes 1 à 12 qui précèdent, on voit la requête préliminaire avec la méthode {{HTTPMethod("OPTIONS")}}. Le navigateur détermine qu'il est nécessaire d'envoyer cela à cause des paramètres de la requête fournie par le code JavaScript. De cette façon le serveur peut répondre si la requête principale est acceptable et avec quels paramètres. OPTIONS est une méthode HTTP/1.1 qui est utilisée afin de déterminer de plus amples informations à propos du serveur. La méthode OPTIONS est une méthode « sûre » (safe) et ne change aucune ressource. On notera, qu'avec la requête OPTIONS, deux autres en-têtes sont envoyés (cf. lignes 10 et 11) :
    
 
-
    Access-Control-Request-Method: POST
+
    Access-Control-Request-Method: POST
 Access-Control-Request-Headers: X-PINGOTHER, Content-Type
 
    
 
@@ -290,7 +296,7 @@ Access-Control-Request-Headers: X-PINGOTHER, Content-Type
 
 
    Dans les lignes 14 à 26 qui suivent, on voit la réponse renvoyée par le serveur qui indique que la méthode de la requête (POST) ainsi que ses en-têtes (X-PINGOTHER) sont acceptables. Voici ce qu'on peut notamment lire entre les lignes 17 et 20 :
    
 
-
    Access-Control-Allow-Origin: http://toto.example
+
    Access-Control-Allow-Origin: http://toto.example
 Access-Control-Allow-Methods: POST, GET
 Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
 Access-Control-Max-Age: 86400
    
@@ -331,13 +337,13 @@ Access-Control-Max-Age: 86400
    
 
 
    Toutefois, si la requête déclenche une requête préliminaire suite à l'absence de l'en-tête {{HTTPHeader("Authorization")}}, on ne pourra pas utiliser cette méthode de contournement et il sera nécessaire d'avoir accès au serveur pour contourner le problème.
    
 
-
    Requêtes avec informations d'authentification
    
+
    Requêtes avec informations d'authentification
    
 
 
    Une des fonctionnalités intéressante mise en avant par le CORS (via {{domxref("XMLHttpRequest")}} ou Fetch) est la possibilité d'effectuer des requêtes authentifiées reconnaissant les cookies HTTP et les informations d'authentification HTTP. Par défaut, lorsqu'on réalise des appels {{domxref("XMLHttpRequest")}} ou Fetch entre différents sites, les navigateurs n'enverront pas les informations d'authentification. Pour cela, il est nécessaire d'utiliser une option spécifique avec le constructeur {{domxref("XMLHttpRequest")}} ou {{domxref("Request")}} lorsqu'on l'appelle.
    
 
-
    Dans cet exemple, le contenu chargé depuis http://toto.example effectue une requête GET simple vers une ressource située sous http://truc.autre qui définit des cookies. Voici un exemple de code JavaScript qui pourrait se trouver sur toto.example :
    
+
    Dans cet exemple, le contenu chargé depuis http://toto.example effectue une requête GET simple vers une ressource située sous http://truc.autre qui définit des cookies. Voici un exemple de code JavaScript qui pourrait se trouver sur toto.example :
    
 
-
    var invocation = new XMLHttpRequest();
+
    var invocation = new XMLHttpRequest();
 var url = 'http://truc.autre/resources/credentialed-content/';
 
 function callOtherDomain(){
@@ -351,11 +357,11 @@ function callOtherDomain(){
 
 
    À la ligne 7, on voit que l'option withCredentials, du constructeur {{domxref("XMLHttpRequest")}}, doit être activée pour que l'appel utilise les cookies. Par défaut, l'appel sera réalisé sans les cookies. Cette requête étant une simple requête GET, il n'est pas nécessaire d'avoir une requête préliminaire. Cependant, le navigateur rejettera tout réponse qui ne possède pas l'en-tête {{HTTPHeader("Access-Control-Allow-Credentials")}}: true et la réponse correspondante ne sera pas disponible pour le contenu web qui l'a demandée.
    
 
-
    
+
    
 
 
    Voici un exemple d'échange entre le client et le serveur :
    
 
-
    GET /resources/access-control-with-credentials/ HTTP/1.1
+
    GET /resources/access-control-with-credentials/ HTTP/1.1
 Host: truc.autre
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
@@ -388,13 +394,13 @@ Content-Type: text/plain
 [text/plain payload]
 
    
 
-
    Bien que la ligne 11 contienne le cookie pour le contenu sous http://truc.autre, si truc.autre n'avait pas répondu avec {{HTTPHeader("Access-Control-Allow-Credentials")}}: true (cf. ligne 19), la réponse aurait été ignorée et n'aurait pas pu être consommée par le contenu web.
    
+
    Bien que la ligne 11 contienne le cookie pour le contenu sous http://truc.autre, si truc.autre n'avait pas répondu avec {{HTTPHeader("Access-Control-Allow-Credentials")}}: true (cf. ligne 19), la réponse aurait été ignorée et n'aurait pas pu être consommée par le contenu web.
    
 
 
    Requêtes authentifiées et jokers (wildcards)
    
 
 
    Lorsqu'il répond à une requête authentifiée, le serveur doit indiquer une origine via la valeur de l'en-tête Access-Control-Allow-Origin, il ne doit pas utiliser le joker "*".
    
 
-
    Avec la requête précédente, on voit la présence d'un en-tête Cookie mais la requête échouerait si la valeur de l'en-tête de réponse Access-Control-Allow-Origin était "*". Ici, ce n'est pas le cas : Access-Control-Allow-Origin vaut "http://toto.example" et le contenu récupéré par la requête est alors envoyé au contenu web.
    
+
    Avec la requête précédente, on voit la présence d'un en-tête Cookie mais la requête échouerait si la valeur de l'en-tête de réponse Access-Control-Allow-Origin était "*". Ici, ce n'est pas le cas : Access-Control-Allow-Origin vaut "http://toto.example" et le contenu récupéré par la requête est alors envoyé au contenu web.
    
 
 
    Dans cet exemple, on notera également que l'en-tête de réponse Set-Cookie définit un autre cookie. En cas d'échec, une exception (dépendant de l'API utilisée) sera levée.
    
 
@@ -410,14 +416,14 @@ Content-Type: text/plain
 
 
    Une ressource de réponse peut avoir un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} avec la syntaxe suivante :
    
 
-
    Access-Control-Allow-Origin: <origin> | *
+
    Access-Control-Allow-Origin: <origin> | *
 
    
 
 
    Le paramètre origin définit un URI qui peut accéder à la ressource. Le navigateur doit respecter cette contrainte. Pour les requêtes qui n'impliquent pas d'informations d'authentification, le serveur pourra indiquer un joker ("*") qui permet à n'importe quelle origine d'accéder à la ressource.
    
 
 
    Si on souhaite, par exemple, autoriser http://mozilla.org à accéder à la ressource, on pourra répondre avec :
    
 
-
    Access-Control-Allow-Origin: http://mozilla.org
    
+
    Access-Control-Allow-Origin: http://mozilla.org
    
 
 
    Si le serveur indique une origine spécifique plutôt que "*", il pourra également inclure la valeur Origin dans l'en-tête de réponse {{HTTPHeader("Vary")}} pour indiquer au client que la réponse du serveur variera selon la valeur de l'en-tête de requête {{HTTPHeader("Origin")}}.
    
 
@@ -425,7 +431,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Expose-Headers")}} fournit une liste blanche des en-têtes auxquels les navigateurs peuvent accéder. Ainsi :
    
 
-
    Access-Control-Expose-Headers: X-Mon-En-tete-Specifique, X-Un-Autre-En-tete
+
    Access-Control-Expose-Headers: X-Mon-En-tete-Specifique, X-Un-Autre-En-tete
 
    
 
 
    Cela permettra que les en-têtes X-Mon-En-tete-Specifique et X-Un-Autre-En-tete soient utilisés par le navigateur.
    
@@ -434,7 +440,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Max-Age")}} indique la durée pendant laquelle le résultat de la requête préliminaire peut être mis en cache (voir les exemples ci-avant pour des requêtes impliquant des requêtes préliminaires).
    
 
-
    Access-Control-Max-Age: <delta-en-secondes>
+
    Access-Control-Max-Age: <delta-en-secondes>
 
    
 
 
    Le paramètre delta-en-seconds indique le nombre de secondes pendant lesquelles les résultats peuvent être mis en cache.
    
@@ -443,16 +449,16 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Allow-Credentials")}} indique si la réponse à la requête doit être exposée lorsque l'option credentials vaut true. Lorsque cet en-tête est utilisé dans une réponse préliminaire, cela indique si la requête principale peut ou non être effectuée avec des informations d'authentification. On notera que les requêtes GET sont des requêtes simples et si une requête est effectuée, avec des informations d'authentification pour une ressource, et que cet en-tête n'est pas renvoyé, la réponse sera ignorée par le navigateur et sa charge ne pourra pas être consommée par le contenu web.
    
 
-
    Access-Control-Allow-Credentials: true
+
    Access-Control-Allow-Credentials: true
 
    
 
-
    Voir les scénarios ci-avant pour des exemples.
    
+
    Voir les scénarios ci-avant pour des exemples.
    
 
 
    Access-Control-Allow-Methods
    
 
 
    L'en-tête {{HTTPHeader("Access-Control-Allow-Methods")}} indique la ou les méthodes qui sont autorisées pour accéder à la ressoure. Cet en-tête est utilisé dans la réponse à la requête préliminaire (voir ci-avant les conditions dans lesquelles une requête préliminaire est nécessaire).
    
 
-
    Access-Control-Allow-Methods: <methode>[, <methode>]*
+
    Access-Control-Allow-Methods: <methode>[, <methode>]*
 
    
 
 
    Voir un exemple ci-avant pour l'utilisation de cet en-tête.
    
@@ -461,7 +467,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Allow-Headers")}} est utilisé dans une réponse à une requête préliminaire afin d'indiquer les en-têtes HTTP qui peuvent être utilisés lorsque la requête principale est envoyée.
    
 
-
    Access-Control-Allow-Headers: <nom-champ>[, <nom-champ>]*
+
    Access-Control-Allow-Headers: <nom-champ>[, <nom-champ>]*
 
    
 
 
    En-têtes de requête HTTP
    
@@ -472,12 +478,14 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Origin")}} indique l'origine de la requête (principale ou préliminaire) pour l'accès multi-origine.
    
 
-
    Origin: <origine>
+
    Origin: <origine>
 
    
 
 
    L'origine est un URI qui indique le serveur à partir duquel la requête a été initiée. Elle n'inclut aucune information relative au chemin mais contient uniquement le nom du serveur.
    
 
-
    Note : origine peut être une chaîne vide (ce qui s'avère notamment utile lorsque la source est une URL de donnée).
    
+
    
+  
    Note : origine peut être une chaîne vide (ce qui s'avère notamment utile lorsque la source est une URL de donnée).
    
+
    
 
 
    Pour chaque requête avec contrôle d'accès, l'en-tête {{HTTPHeader("Origin")}} sera toujours envoyé.
    
 
@@ -485,7 +493,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Request-Method")}} est utilisé lorsqu'on émet une requête préliminaire afin de savoir quelle méthode HTTP pourra être utilisée avec la requête principale.
    
 
-
    Access-Control-Request-Method: <methode>
+
    Access-Control-Request-Method: <methode>
 
    
 
 
    Voir ci-avant pour des exemples d'utilisation de cet en-tête.
    
@@ -494,7 +502,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Request-Headers")}} est utilisé lorsqu'on émet une requête préliminaire afin de communiquer au serveur les en-têtes HTTP qui seront utilisés avec la requête principale.
    
 
-
    Access-Control-Request-Headers: <nom-champ>[, <nom-champ>]*
+
    Access-Control-Request-Headers: <nom-champ>[, <nom-champ>]*
 
    
 
 
    Voir ci-avant pour des exemples d'utilisation de cet en-tête.
    
@@ -532,7 +540,7 @@ Content-Type: text/plain
 
  
-
-
-
    
-
-
-
-
    
+
\ No newline at end of file
diff --git a/files/fr/web/http/csp/index.html b/files/fr/web/http/csp/index.html
index 6a5c7dedd4..fa2f565dd8 100644
--- a/files/fr/web/http/csp/index.html
+++ b/files/fr/web/http/csp/index.html
@@ -10,7 +10,7 @@ translation_of: Web/HTTP/CSP
 ---
 
    {{HTTPSidebar}}
    
 
-
    Une Content Security Policy ({{Glossary("CSP")}}) ou stratégie de sécurité du contenu permet d'améliorer la sécurité des sites web en permettant de détecter et réduire certains types d'attaques, dont les attaques {{Glossary("XSS")}} (Cross Site Scripting) et les injections de contenu. Ces attaques peuvent être utilisées dans divers buts, comme le vol de données, le défacement de site ou la diffusion de malware.
    
+
    Une Content Security Policy ({{Glossary("CSP")}}) ou stratégie de sécurité du contenu permet d'améliorer la sécurité des sites web en permettant de détecter et réduire certains types d'attaques, dont les attaques {{Glossary("XSS")}} (Cross Site Scripting) et les injections de contenu. Ces attaques peuvent être utilisées dans divers buts, comme le vol de données, le défacement de site ou la diffusion de malware.
    
 
 
    CSP a été conçu pour être complètement rétro-compatible (à l'exception de la version 2 dans laquelle existent des incompatibilités décrites explicitement comme telles ; pour plus d'informations, se référer à la documentation du w3c (en anglais)). D'une part : les navigateurs qui ne prennent pas en charge le CSP fonctionnent parfaitement avec les serveurs qui l'implémentent et inversement. D'autre part, lorsque les sites ne fournissent pas les en-têtes correspondant, les navigateurs utilisent la règle de même origine (same-origin policy) pour les contenus.
    
 
diff --git a/files/fr/web/http/feature_policy/index.html b/files/fr/web/http/feature_policy/index.html
index 7629bf0d21..1061068d8c 100644
--- a/files/fr/web/http/feature_policy/index.html
+++ b/files/fr/web/http/feature_policy/index.html
@@ -19,10 +19,10 @@ translation_of: Web/HTTP/Feature_Policy
 ---
 
    {{HTTPSidebar}}
    
 
-
    Feature Policy ("réglementation des fonctionnalités" en français) permet aux développeurs web d'activer, de modifier ou de désactiver spécifiquement le comportement de certaines fonctionnalités et API dans le navigateur. Elle est similaire à {{Glossary("CSP", "Content Security Policy")}} mais contrôle les fonctionnalités plus que la sécurité.
    
+
    Feature Policy ("réglementation des fonctionnalités" en français) permet aux développeurs web d'activer, de modifier ou de désactiver spécifiquement le comportement de certaines fonctionnalités et API dans le navigateur. Elle est similaire à {{Glossary("CSP", "Content Security Policy")}} mais contrôle les fonctionnalités plus que la sécurité.
    
 
 
    
-
    L'en-tête Feature-Policy a maintenant été renommé Permissions-Policy dans la spécification, et cet article va possiblement être modifié en conséquence.
    
+
    Note : L'en-tête Feature-Policy a maintenant été renommé Permissions-Policy dans la spécification, et cet article va possiblement être modifié en conséquence.
    
 
    
 
 
    En résumé
    
diff --git a/files/fr/web/http/headers/accept-charset/index.html b/files/fr/web/http/headers/accept-charset/index.html
index b3dba30be4..e832f5b513 100644
--- a/files/fr/web/http/headers/accept-charset/index.html
+++ b/files/fr/web/http/headers/accept-charset/index.html
@@ -5,12 +5,12 @@ translation_of: Web/HTTP/Headers/Accept-Charset
 ---
 
    {{HTTPSidebar}}
    
 
-
    L'en-tête HTTP de la requêteAccept-Charset indique le jeu de caractères que le client est capable de comprendre. À l'aide de la  content negotiation, le serveur sélectionne l'une des propositions, l'utilise et informe le client de son choix dans l'en-tête de réponse {{HTTPHeader ("Content-Type")}}. Les navigateurs ne définissent généralement pas cet en-tête car la valeur par défaut de chaque type de contenu est généralement correcte et sa transmission permettrait une empreinte digitale plus facile.
    
+
    L'en-tête HTTP de la requêteAccept-Charset indique le jeu de caractères que le client est capable de comprendre. À l'aide de la  content negotiation, le serveur sélectionne l'une des propositions, l'utilise et informe le client de son choix dans l'en-tête de réponse {{HTTPHeader ("Content-Type")}}. Les navigateurs ne définissent généralement pas cet en-tête car la valeur par défaut de chaque type de contenu est généralement correcte et sa transmission permettrait une empreinte digitale plus facile.
    
 
-
    Si le serveur ne peut servir aucun jeu de caractères correspondant, il peut théoriquement renvoyer un code d'erreur {{HTTPStatus ("406")}} (non acceptable). Cependant, pour une meilleure expérience utilisateur, cela est rarement fait et le moyen le plus courant consiste à ignorer l'en-tête Accept-Charset dans ce cas.
    
+
    Si le serveur ne peut servir aucun jeu de caractères correspondant, il peut théoriquement renvoyer un code d'erreur {{HTTPStatus ("406")}} (non acceptable). Cependant, pour une meilleure expérience utilisateur, cela est rarement fait et le moyen le plus courant consiste à ignorer l'en-tête Accept-Charset dans ce cas.
    
 
 
    
-
    Dans les premières versions de HTTP / 1.1, un jeu de caractères par défaut (ISO-8859-1) était défini. Ce n'est plus le cas et maintenant chaque type de contenu peut avoir sa propre valeur par défaut.
    
+
    Note : Dans les premières versions de HTTP / 1.1, un jeu de caractères par défaut (ISO-8859-1) était défini. Ce n'est plus le cas et maintenant chaque type de contenu peut avoir sa propre valeur par défaut.
     Moteur Doit contenir Ne doit pas contenir
    Mozilla (Gecko, Firefox) Chaîne Mobile ou Tablet dans le commentaireMozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0Mozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0
    Basé sur WebKit (Android, Safari)
    Basé sur Presto (Opera 12-) -

    Chaîne Opera Mobi/xyz dans le commentaire (Opera 12-)

    +

    Chaîne Opera Mobi/xyz dans le commentaire (Opera 12-)

    		 -

    Opera/9.80 (Android 2.3.3; Linux; Opera Mobi/ADR-1111101157; U; es-ES) Presto/2.9.201 Version/11.50

    +

    Opera/9.80 (Android 2.3.3; Linux; Opera Mobi/ADR-1111101157; U; es-ES) Presto/2.9.201 Version/11.50
    @@ -33,15 +33,15 @@ translation_of: Web/HTTP/Headers/Accept-Charset // Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax: Accept-Charset: utf-8, iso-8859-1;q=0.5 -

    Les directives

    +

    Les directives

    <charset>
    -
    Un jeu de caractères comme utf-8 ou iso-8859-15.
    +
    Un jeu de caractères comme utf-8 ou iso-8859-15.
    *
    -
    Tout jeu de caractères non mentionné ailleurs dans l'en-tête; '*' utilisé comme un joker.
    +
    Tout jeu de caractères non mentionné ailleurs dans l'en-tête; '*' utilisé comme un joker.
    ;q= (q-factor weighting)
    -
    Toute valeur est placée dans un ordre de préférence exprimé à l'aide d'une valeur de qualité relative appelée  weight.
    +
    Toute valeur est placée dans un ordre de préférence exprimé à l'aide d'une valeur de qualité relative appelée  weight.

    Examples

    @@ -59,7 +59,7 @@ Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1 - + @@ -72,10 +72,10 @@ Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1

    {{Compat("http.headers.Accept-Charset")}}

    -

    Voir également

    +

    Voir également

    diff --git a/files/fr/web/http/headers/accept-encoding/index.html b/files/fr/web/http/headers/accept-encoding/index.html index f19e6316d0..42d6228260 100644 --- a/files/fr/web/http/headers/accept-encoding/index.html +++ b/files/fr/web/http/headers/accept-encoding/index.html @@ -18,14 +18,14 @@ translation_of: Web/HTTP/Headers/Accept-Encoding

    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 : - - +
    +

    Note : +

      +
    • Un dépôt IANA garde à jour une liste complète des encodages de contenu. +
      • +
    • Deux autres encodages, bzip et bzip2, sont parfois utilisés, bien que non-standards. Ils implémentent l'algorithme utilisé par les deux programmes UNIX respectifs. À noter que le premier n'est plus maintenu suite à des problèmes de licence.
      • +
    +

    SpecificationTitreTitre
    {{RFC("7231", "Accept-Charset", "5.3.3")}}
    diff --git a/files/fr/web/http/headers/accept/index.html b/files/fr/web/http/headers/accept/index.html index 438652ed62..2f27ede072 100644 --- a/files/fr/web/http/headers/accept/index.html +++ b/files/fr/web/http/headers/accept/index.html @@ -10,7 +10,7 @@ translation_of: Web/HTTP/Headers/Accept ---
    {{HTTPSidebar}}
    -

    Le paramètre d'entête de requête HTTP Accept indique quels sont les types de contenu, exprimés sous la forme de types MIME, que le client sera capable d'interpréter. Par le biais de la résolution de contenu -(content negotiation), le serveur sélectionne ensuite une proposition parmi toutes, l'utilise et informe le client de son choix avec l'entête de réponse {{HTTPHeader("Content-Type")}}. Les navigateurs fixent des valeurs adéquates pour cet entête selon le contexte où la requête a été exécutée : selon que l'utilisateur souhaite récupérer une feuille de style css,  ou qu'il souhaite récupérer une image, une vidéo ou un script, la valeur fixée pour la requête ne sera pas la même.

    +

    Le paramètre d'entête de requête HTTP Accept indique quels sont les types de contenu, exprimés sous la forme de types MIME, que le client sera capable d'interpréter. Par le biais de la résolution de contenu -(content negotiation), le serveur sélectionne ensuite une proposition parmi toutes, l'utilise et informe le client de son choix avec l'entête de réponse {{HTTPHeader("Content-Type")}}. Les navigateurs fixent des valeurs adéquates pour cet entête selon le contexte où la requête a été exécutée : selon que l'utilisateur souhaite récupérer une feuille de style css,  ou qu'il souhaite récupérer une image, une vidéo ou un script, la valeur fixée pour la requête ne sera pas la même.

    diff --git a/files/fr/web/http/headers/access-control-allow-origin/index.html b/files/fr/web/http/headers/access-control-allow-origin/index.html index d235454ac7..359319cc18 100644 --- a/files/fr/web/http/headers/access-control-allow-origin/index.html +++ b/files/fr/web/http/headers/access-control-allow-origin/index.html @@ -22,7 +22,7 @@ translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin

    Syntaxe

    -
    Access-Control-Allow-Origin: *
+
    Access-Control-Allow-Origin: *
 Access-Control-Allow-Origin: <origin>
 Access-Control-Allow-Origin: null
 
    
@@ -40,17 +40,17 @@ Access-Control-Allow-Origin: null
 
 
    Pour permettre à n'importe quelle ressource d'accéder à vos ressources, vous pouvez indiquer :
    
 
-
    Access-Control-Allow-Origin: *
    
+
    Access-Control-Allow-Origin: *
    
 
 
    Pour permettre https://developer.mozilla.org d'accéder à vos ressources, vous pouvez indiquer :
    
 
-
    Access-Control-Allow-Origin: https://developer.mozilla.org
    
+
    Access-Control-Allow-Origin: https://developer.mozilla.org
    
 
 
    CORS et le cache
    
 
 
    Si le serveur spécifie un hôte d'origine plutôt que "*", il doit également inclure "Origin" dans l'en-tête de réponse "Vary" pour indiquer aux clients que les réponses du serveur seront différentes en fonction de la valeur de la demande d'origine entête.
    
 
-
    Access-Control-Allow-Origin: https://developer.mozilla.org
+
    Access-Control-Allow-Origin: https://developer.mozilla.org
 Vary: Origin
    
 
 
    Caractéristiques
    
diff --git a/files/fr/web/http/headers/authorization/index.html b/files/fr/web/http/headers/authorization/index.html
index 7e597dc96e..065c4fc78a 100644
--- a/files/fr/web/http/headers/authorization/index.html
+++ b/files/fr/web/http/headers/authorization/index.html
@@ -33,20 +33,19 @@ translation_of: Web/HTTP/Headers/Authorization
 
 
    
  
    <type>
    
- 
    Le type d'authentification. Le type "Basic" est souvent utilisé. Pour connaître les autres types :
+ 
    Le type d'authentification. Le type "Basic" est souvent utilisé. Pour connaître les autres types :
    
  
  
    
  
    <credentials>
    
- 
    Si c'est le type d'authentification "Basic" qui est utilisé, les identifiants sont construits de la manière suivante :
+ 
    Si c'est le type d'authentification "Basic" qui est utilisé, les identifiants sont construits de la manière suivante :
    
  
      
   
    • L'identifiant de l'utilisateur et le mot de passe sont combinés avec deux-points : (aladdin:sesameOuvreToi).
      • 
   
    • Cette chaîne de caractères est ensuite encodée en base64 (YWxhZGRpbjpzZXNhbWVPdXZyZVRvaQ==).
      • 
  
    
-
  
    
- 
    Note: L'encodage en Base64 n'est pas un chiffrement ou un hachage ! Cette méthode est aussi peu sûre que d'envoyer les identifiants en clair (l'encodage base64 est un encodage réversible). Il faudra privilégier HTTPS lorsqu'on emploie une authentification "basique".
    
+ 
    Note : L'encodage en Base64 n'est pas un chiffrement ou un hachage ! Cette méthode est aussi peu sûre que d'envoyer les identifiants en clair (l'encodage base64 est un encodage réversible). Il faudra privilégier HTTPS lorsqu'on emploie une authentification "basique".
    
  
    
  
    
 
    
diff --git a/files/fr/web/http/headers/cache-control/index.html b/files/fr/web/http/headers/cache-control/index.html
index 254df474ee..de82079b83 100644
--- a/files/fr/web/http/headers/cache-control/index.html
+++ b/files/fr/web/http/headers/cache-control/index.html
@@ -11,7 +11,7 @@ translation_of: Web/HTTP/Headers/Cache-Control
 ---
 
    {{HTTPSidebar}}
    
 
-
    L'en-tête HTTP Cache-Control contient des directives (ou instructions) pour la mise en cache tant dans les requêtes que dans les réponses. Une directive donnée dans une requête ne signifie pas que la même directive doit se trouver dans la réponse.
    
+
    L'en-tête HTTP Cache-Control contient des directives (ou instructions) pour la mise en cache tant dans les requêtes que dans les réponses. Une directive donnée dans une requête ne signifie pas que la même directive doit se trouver dans la réponse.
    @@ -104,15 +104,7 @@ Cache-Control: stale-if-error=<seconds>
    no-cache
    Indique de renvoyer systématiquement la requête au serveur et ne servir une éventuelle version en cache que dans le cas où le serveur le demande.
    no-store
    -
    La réponse ne peut être stockée dans aucune mémoire cache. Bien que d'autres directives puissent être définies, C'est la seule directive dont vous avez besoin pour empêcher le réponses en cache sur les navigateurs modernes. max-age=0 est déjà implicite. La définition de la directive must-revalidate n'a pas de sens car pour passer la revalidation,  vous devez stocker la réponse dans un cache, ce que n'empêche no-store.
    -
    Ne pas copier-coller les spécifications Internet-Explorer pre-check=0,post-check=0 Si vous le voyez en ligne car il est entièrement ignoré, ce que confirme le tweet du développeur Edge.
    -
    Désactive le cache par Cache-Control
    -
    - 
    no-store
    -
    -
    - 
    no-cache,no-store,must-revalidate,pre-check=0,post-check=0
    -
    +

    La réponse ne peut être stockée dans aucune mémoire cache. Bien que d'autres directives puissent être définies, C'est la seule directive dont vous avez besoin pour empêcher le réponses en cache sur les navigateurs modernes. max-age=0 est déjà implicite. La définition de la directive must-revalidate n'a pas de sens car pour passer la revalidation, vous devez stocker la réponse dans un cache, ce que n'empêche no-store.Ne pas copier-coller les spécifications Internet-Explorer pre-check=0,post-check=0 Si vous le voyez en ligne car il est entièrement ignoré, ce que confirme le tweet du développeur Edge.

    Expiration

    @@ -158,42 +150,27 @@ Cache-Control: stale-if-error=<seconds>

    Pour désactiver la mise en cache, vous pouvez envoyer l'en-tête de réponse suivant. En outre, voir aussi les en-têtes Expires et Pragma.

    -
    -
    - 
    Cache-Control: no-store
+
    Cache-Control: no-store
 
    
-
    -
    - 
    Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0
+
+
    Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0
 
    
-
    -

    Mise en cache d'actifs statiques

    Pour les fichiers de l'application qui ne seront pas modifiés, vous pouvez généralement ajouter une mise en cache agressive en envoyant l'en-tête de réponse ci-dessous. Cela inclut les fichiers statiques qui sont servis par l'application comme les images, les fichiers CSS et les fichiers JavaScript, par exemple. En outre, voir l'en-tête Expires.

    -
    -
    - 
    Cache-Control: public, max-age=604800, immutable
+
    Cache-Control: public, max-age=604800, immutable
 
    
-
    -

    Nécessitant une revalidation

    -

    Le fait de spécifier no-cache ou max-age=0 indique que les clients peuvent mettre une ressource en cache et doivent la revalider à chaque fois avant de l'utiliser. Cela signifie que la requête HTTP se produit à chaque fois, mais qu'elle peut sauter le téléchargement du corps HTTP si le contenu est valide.

    +

    Le fait de spécifier no-cache ou max-age=0 indique que les clients peuvent mettre une ressource en cache et doivent la revalider à chaque fois avant de l'utiliser. Cela signifie que la requête HTTP se produit à chaque fois, mais qu'elle peut sauter le téléchargement du corps HTTP si le contenu est valide.

    -
    -
    - 
    Cache-Control: no-cache
+
    Cache-Control: no-cache
 Cache-Control: no-cache, max-age=0
 Cache-Control: no-cache, max-age=0, stale-while-revalidate=300
 
    
-
    -
    - -

    Spécifications

    @@ -208,17 +185,17 @@ Cache-Control: no-cache, max-age=0, stale-while-revalidate=300 - + - + - + diff --git a/files/fr/web/http/headers/connection/index.html b/files/fr/web/http/headers/connection/index.html index 83183257bb..3ea2071137 100644 --- a/files/fr/web/http/headers/connection/index.html +++ b/files/fr/web/http/headers/connection/index.html @@ -12,7 +12,9 @@ translation_of: Web/HTTP/Headers/Connection

    L'en-tête général Connection contrôle la façon dont la connexion reste ouverte ou non après que la transaction courante soit terminée. Si la valeur envoyée est keep-alive, la connexion est persistente et n'est pas fermée, permettant aux requêtes qui suivent et s'adressent au même serveur d'être envoyées.

    -
    Note : Les champs d'en-tête spécifiques à la connexion (tels que Connection) ne doivent pas être utilisés avec HTTP/2.
    +
    +

    Note :Les champs d'en-tête spécifiques à la connexion (tels que Connection) ne doivent pas être utilisés avec HTTP/2.

    +

    Except for the standard hop-by-hop headers ({{HTTPHeader("Keep-Alive")}}, {{HTTPHeader("Transfer-Encoding")}}, {{HTTPHeader("TE")}}, {{HTTPHeader("Connection")}}, {{HTTPHeader("Trailer")}}, {{HTTPHeader("Upgrade")}}, {{HTTPHeader("Proxy-Authorization")}} and {{HTTPHeader("Proxy-Authenticate")}}), any hop-by-hop headers used by the message must be listed in the Connection header, so that the first proxy knows it has to consume them and not forward them further. Standard hop-by-hop headers can be listed too (it is often the case of {{HTTPHeader("Keep-Alive")}}, but this is not mandatory).

    diff --git a/files/fr/web/http/headers/content-disposition/index.html b/files/fr/web/http/headers/content-disposition/index.html index f0d79129f3..1dffadd807 100644 --- a/files/fr/web/http/headers/content-disposition/index.html +++ b/files/fr/web/http/headers/content-disposition/index.html @@ -13,7 +13,7 @@ translation_of: Web/HTTP/Headers/Content-Disposition

    Dans un corps multipart / form-data, l'en-tête général HTTP Content-Disposition est un en-tête qui peut être utilisé sur la sous-partie d'un corps multipart pour donner des informations sur le champ auquel il s'applique. La sous-partie est délimitée par la limite boundary définie dans l'en-tête {{HTTPHeader ("Content-Type")}}. Utilisé sur le corps même, Content-Disposition n'a aucun effet.

    -

    L'en-tête Content-Disposition est défini dans le contexte plus large des messages MIME pour le courrier électronique, mais seul un sous-ensemble des paramètres possibles s'applique aux formulaires HTTP et {{HTTPMethod ("POST")}}. Seules les données de forme de valeur, ainsi que le nom de la directive optionnelle et le nom de fichier, peuvent être utilisés dans le contexte HTTP.

    +

    L'en-tête Content-Disposition est défini dans le contexte plus large des messages MIME pour le courrier électronique, mais seul un sous-ensemble des paramètres possibles s'applique aux formulaires HTTP et {{HTTPMethod ("POST")}}. Seules les données de forme de valeur, ainsi que le nom de la directive optionnelle et le nom de fichier, peuvent être utilisés dans le contexte HTTP.

    {{RFC(8246, "HTTP Immutable Responses")}}IETF RFCIETF RFC
    {{RFC(7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching")}}IETF RFCIETF RFC
    {{RFC(5861, "HTTP Cache-Control Extensions for Stale Content")}}IETF RFCIETF RFC Initial definition
    @@ -41,40 +41,40 @@ translation_of: Web/HTTP/Headers/Content-Disposition

    En tant qu'entête de réponse pour le corps principal 

    -

    Le premier paramètre dans le contexte HTTP est en ligne (valeur par défaut, indiquant qu'il peut être affiché à l'intérieur de la page Web ou en tant que page Web) ou pièce jointe (en indiquant qu'il devrait être téléchargé), la plupart des navigateurs présentant une boîte de dialogue "Enregistrer sous" Avec la valeur des paramètres du nom de
    +

    Le premier paramètre dans le contexte HTTP est en ligne (valeur par défaut, indiquant qu'il peut être affiché à l'intérieur de la page Web ou en tant que page Web) ou pièce jointe (en indiquant qu'il devrait être téléchargé), la plupart des navigateurs présentant une boîte de dialogue "Enregistrer sous" Avec la valeur des paramètres du nom de
    fichier si présent.

    -
    Content-Disposition: inline
+
    Content-Disposition: inline
 Content-Disposition: attachment
 Content-Disposition: attachment; filename="filename.jpg"
    
 
 
    En tant qu'en-tête pour un corps à plusieurs parties 
    
 
-
    Le premier paramètre dans le contexte HTTP est toujours une donnée de forme. Les paramètres supplémentaires sont insensibles à la casse et ont des arguments, qui utilisent la syntaxe de chaîne cité après le signe '='. Les paramètres multiples sont
    
+
    Le premier paramètre dans le contexte HTTP est toujours une donnée de forme. Les paramètres supplémentaires sont insensibles à la casse et ont des arguments, qui utilisent la syntaxe de chaîne cité après le signe '='. Les paramètres multiples sont
    
  séparés par un point-virgule (';').
    
 
-
    Content-Disposition: form-data Content-Disposition: form-data;
+
    Content-Disposition: form-data Content-Disposition: form-data;
 name="fieldName" Content-Disposition: form-data;
 name="fieldName"; filename="filename.jpg"
    
 
-
    Directives
    
+
    Directives
    
 
-
    <name>
    
+
    <name>
    
  Est suivie d'une chaîne contenant le nom du champ HTML dans la forme dont le contenu de cette sous-partie se réfère. Lorsqu'il s'agit de plusieurs fichiers dans le même champ (par exemple, l'attribut {{htmlattrxref("multiple", "input")}} d'un {{HTMLElement("input","<input type=file>")}} element), il peut y avoir plusieurs sous-parties portant le même nom.
    
 
-
    Un name avec une valeur de '_charset_' indique que la partie n'est pas un champ HTML, mais le jeu de caractères par défaut à utiliser pour les pièces sans informations de charset explicites.
    
+
    Un name avec une valeur de '_charset_' indique que la partie n'est pas un champ HTML, mais le jeu de caractères par défaut à utiliser pour les pièces sans informations de charset explicites.
    
 
-
    <filename>
    
+
    <filename>
    
  Est suivi d'une chaîne contenant le nom d'origine du fichier transmis. Le nom de fichier est toujours facultatif et ne doit pas être utilisé aveuglément par l'application: l'information du chemin doit être rayée et la conversion aux règles du système de fichiers du serveur doit être effectuée. Ce paramètre fournit principalement des informations indicatives. Lorsqu'il est utilisé en combinaison avec Content-Disposition: attachement, il est utilisé comme nom de fichier par défaut pour une éventuelle boîte de dialogue "Enregistrer sous" présentée à l'utilisateur.
    
 
-
    <filename*>
    
+
    <filename*>
    
  Les paramètres filename et filename* diffèrent uniquement en ce que filename* utilise l'encodage défini dans la RFC 5987. Lorsque filename et filename* sont présents dans une seule valeur de champ d'en-tête, filename* est préféré à filename lorsque les deux sont présents et compris.
    
 
 
    Exemples
    
 
 
    Une réponse déclanchant le dialogue "Enregistrer sous":
    
 
-
    200 OK
+
    200 OK
 Content-Type: text/html; charset=utf-8
 Content-Disposition: attachment; filename="cool.html"
 Content-Length: 22
@@ -86,7 +86,7 @@ Content-Length: 22
 
 
    Un exemple de formulaire HTML, publié à l'aide du format multipart / form-data qui utilise l'en-tête Content-Disposition:
    
 
-
    POST /test.html HTTP/1.1
+
    POST /test.html HTTP/1.1
 Host: example.org
 Content-Type: multipart/form-data;boundary="boundary"
 
diff --git a/files/fr/web/http/headers/content-encoding/index.html b/files/fr/web/http/headers/content-encoding/index.html
index 710f2b96d4..3d52ddfac5 100644
--- a/files/fr/web/http/headers/content-encoding/index.html
+++ b/files/fr/web/http/headers/content-encoding/index.html
@@ -28,7 +28,7 @@ translation_of: Web/HTTP/Headers/Content-Encoding
 
 
    Syntaxe
    
 
-
    Content-Encoding: gzip
+
    Content-Encoding: gzip
 Content-Encoding: compress
 Content-Encoding: deflate
 Content-Encoding: identity
@@ -60,11 +60,11 @@ Content-Encoding: deflate, gzip
 
 
    Côté client, on peut fournir la liste des mécanismes de compression pris en charge en envoyant l'en-tête {{HTTPHeader("Accept-Encoding")}} lors de la négociation de l'encodage.
    
 
-
    Accept-Encoding: gzip, deflate
    
+
    Accept-Encoding: gzip, deflate
    
 
 
    Le serveur répondra avec le schéma utilisé avec l'en-tête de réponse Content-Encoding.
    
 
-
    Content-Encoding: gzip
    
+
    Content-Encoding: gzip
    
 
 
    À noter que le serveur n'est pas obligé d'utiliser de méthode de compression. La compression dépend fortement des paramètres du serveur et des modules de serveur utilisés.
    
 
diff --git a/files/fr/web/http/headers/content-language/index.html b/files/fr/web/http/headers/content-language/index.html
index a31053cc56..002c307908 100644
--- a/files/fr/web/http/headers/content-language/index.html
+++ b/files/fr/web/http/headers/content-language/index.html
@@ -40,7 +40,7 @@ translation_of: Web/HTTP/Headers/Content-Language
 
 
    Syntaxe
    
 
-
    Content-Language: de-DE
+
    Content-Language: de-DE
 Content-Language: en-US
 Content-Language: de-DE, en-CA
 
    
@@ -53,7 +53,7 @@ Content-Language: de-DE, en-CA
 
 
 
    
-
    Note: Les tags de langues sont formellement définis dans la RFC 5646, qui repose sur la norme ISO 639 (très souvent la liste de codes ISO 639-1) pour les codes de langue à utiliser.
    
+
    Note : Les tags de langues sont formellement définis dans la RFC 5646, qui repose sur la norme ISO 639 (très souvent la liste de codes ISO 639-1) pour les codes de langue à utiliser.
    
 
    
 
 
    Exemples
    
@@ -62,18 +62,18 @@ Content-Language: de-DE, en-CA
 
 
    L'attribut global lang est utilisé sur des éléments HTML pour indiquer la langue d'une page HTML entière ou une partie de celle-ci.
    
 
-
    <html lang="de">
    
+
    <html lang="de">
    
 
 
    N'utilisez pas le meta tag comme ceci pour déclarer la langue d'un document:
    
 
-
    <!-- /!\ C'est une mauvaise pratique -->
+
    <!-- /!\ C'est une mauvaise pratique -->
 <meta http-equiv="content-language" content="de">
    
 
 
    Indiquer un public cible pour une ressource
    
 
 
    L'en-tête Content-Language est utilisé pour spécifier le public destiné à la page, et peut indiquer si cela est plus qu'une seule langue.
    
 
-
    Content-Language: de, en
    
+
    Content-Language: de, en
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/headers/content-security-policy-report-only/index.html b/files/fr/web/http/headers/content-security-policy-report-only/index.html
index 63116cb71a..7524dab5f1 100644
--- a/files/fr/web/http/headers/content-security-policy-report-only/index.html
+++ b/files/fr/web/http/headers/content-security-policy-report-only/index.html
@@ -36,7 +36,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy-Report-Only
 
 
    Syntaxe
    
 
-
    Content-Security-Policy-Report-Only: <policy-directive>; <policy-directive>
+
    Content-Security-Policy-Report-Only: <policy-directive>; <policy-directive>
 
    
 
 
    Directives
    
@@ -49,11 +49,11 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy-Report-Only
 
 
    Cet en-tête rapporte les violations qui seront constatées. Vous pouvez l'utiliser pour améliorer vos CSP. Vous pouvez observer comment votre site fonctionne en consultant les rapports ou redirections malicieuses, puis choisir les règles voulues pour bloquer le contenu avec l'en-tête {{HTTPHeader("Content-Security-Policy")}}.
    
 
-
    Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
    
+
    Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
    
 
 
    Si vous voulez toujours recevoir des rapports, mais aussi imposer des règles, utilisez l'en-tête {{HTTPHeader("Content-Security-Policy")}} avec la directive {{CSP("report-uri")}}.
    
 
-
    Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
    
+
    Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
    
 
 
    Syntaxe d'un rapport de violation
    
 
@@ -85,12 +85,12 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy-Report-Only
 
    Considérons une page à l'adresse http://example.com/signup.html. Elle utilise la règle CSP suivante, interdisant tout excepté les feuilles de styles chargées depuis cdn.example.com.
    
 
 
    
-
    Content-Security-Policy-Report-Only: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
    
+
    Content-Security-Policy-Report-Only: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
    
 
    
 
 
    La page HTML correspondant à l'adresse signup.html ressemble à :
    
 
-
    <!DOCTYPE html>
+
    <!DOCTYPE html>
 <html>
   <head>
     <title>Sign Up</title>
@@ -105,7 +105,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy-Report-Only
 
 
    Les feuilles de styles ne sont acceptées que si elles sont chargées depuis cdn.example.com, et pourtant le site tente d'en charger une depuis sa propre origine (http://example.com). Un navigateur capable d'imposer des règles CSP enverra le rapport de violation suivant sous la forme d'une requête POST à l'adresse http://example.com/_/csp-reports quand la page sera visitée :
    
 
-
    {
+
    {
   "csp-report": {
     "document-uri": "http://example.com/signup.html",
     "referrer": "",
diff --git a/files/fr/web/http/headers/content-security-policy/base-uri/index.html b/files/fr/web/http/headers/content-security-policy/base-uri/index.html
index 018167226e..714cfb2f7b 100644
--- a/files/fr/web/http/headers/content-security-policy/base-uri/index.html
+++ b/files/fr/web/http/headers/content-security-policy/base-uri/index.html
@@ -37,7 +37,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/base-uri
 
 
    Une ou plusieurs sources peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: base-uri <source>;
+
    Content-Security-Policy: base-uri <source>;
 Content-Security-Policy: base-uri <source> <source>;
 
    
 
@@ -51,23 +51,23 @@ Content-Security-Policy: base-uri <source> <source>;
 
 
    Configuration par balise <meta>
    
 
-
    <meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
    
+
    <meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
    
 
 
    Configuration par Apache
    
 
-
    <IfModule mod_headers.c>
+
    <IfModule mod_headers.c>
 Header set Content-Security-Policy "base-uri 'self'";
 </IfModule>
    
 
 
    Configuration par Nginx
    
 
-
    add_header Content-Security-Policy "base-uri 'self';"
    
+
    add_header Content-Security-Policy "base-uri 'self';"
    
 
 
    Cas de violation
    
 
 
    À partir du moment où votre domaine n'est pas example.com, un élément {{HTMLElement("base")}} avec son attribut href défini à https://example.com résultera en une violation de CSP.
    
 
-
    <meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
+
    <meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
 <base href="https://example.com/">
 
 // Error: Refused to set the document's base URI to 'https://example.com/'
diff --git a/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.html b/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.html
index 1d5670728a..92897ebaf9 100644
--- a/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.html
+++ b/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.html
@@ -15,28 +15,28 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content
 ---
 
    {{HTTPSidebar}}
    
 
-
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) block-all-mixed-content bloque le chargement de ressources via HTTP lorsque la page utilise HTTPS.
    
+
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) block-all-mixed-content bloque le chargement de ressources via HTTP lorsque la page utilise HTTPS.
    
 
 
    Toutes les requêtes vers des contenus mixtes sont alors bloquées, y compris les ressources actives et passives. Cela s'applique aussi aux documents {{HTMLElement("iframe")}}, assurant que la page est complètement protégée contre les contenus mixtes.
    
 
-
    
-
    Note : La directive {{CSP("upgrade-insecure-requests")}} est évaluée avant block-all-mixed-content. Si elle est définie, alors block-all-mixed-content n'est pas nécessaire, à moins que vous souhaitiez forcer HTTPS sur les anciens navigateurs qui ne le font pas après une redirection vers HTTP.
    
+
    
+
    Note : La directive {{CSP("upgrade-insecure-requests")}} est évaluée avant block-all-mixed-content. Si elle est définie, alors block-all-mixed-content n'est pas nécessaire, à moins que vous souhaitiez forcer HTTPS sur les anciens navigateurs qui ne le font pas après une redirection vers HTTP.
    
 
    
 
 
    Syntaxe
    
 
-
    Content-Security-Policy: block-all-mixed-content;
    
+
    Content-Security-Policy: block-all-mixed-content;
    
 
 
    Exemples
    
 
-
    Content-Security-Policy: block-all-mixed-content;
+
    Content-Security-Policy: block-all-mixed-content;
 
 <meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">
 
    
 
 
    Pour interdire l'usage de HTTP de manière plus fine, vous pouvez aussi configurer individuellement chaque directive sur https:. Par exemple, pour interdire les images HTTP non sécurisées :
    
 
-
    Content-Security-Policy: img-src https:
    
+
    Content-Security-Policy: img-src https:
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/child-src/index.html b/files/fr/web/http/headers/content-security-policy/child-src/index.html
index 09f25eb420..8cf2d1ab7a 100644
--- a/files/fr/web/http/headers/content-security-policy/child-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/child-src/index.html
@@ -39,7 +39,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/child-src
 
 
    Une ou plusieurs sources peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: child-src <source>;
+
    Content-Security-Policy: child-src <source>;
 Content-Security-Policy: child-src <source> <source>;
 
    
 
@@ -53,11 +53,11 @@ Content-Security-Policy: child-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: child-src https://example.com/
    
+
    Content-Security-Policy: child-src https://example.com/
    
 
 
    Cet {{HTMLElement("iframe")}} et ce worker seront bloqués et ne se chargeront pas :
    
 
-
    <iframe src="https://not-example.com"></iframe>
+
    <iframe src="https://not-example.com"></iframe>
 
 <script>
   var blockedWorker = new Worker("data:application/javascript,...");
diff --git a/files/fr/web/http/headers/content-security-policy/connect-src/index.html b/files/fr/web/http/headers/content-security-policy/connect-src/index.html
index 9914f70cf4..845f46f7b0 100644
--- a/files/fr/web/http/headers/content-security-policy/connect-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/connect-src/index.html
@@ -27,7 +27,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/connect-src
 
 
 
    
-
    Note: connect-src 'self' ne s'applique pas aux schémas de websocket pour tous les navigateurs. Pour plus d'informations, consulter : https://github.com/w3c/webappsec-csp/issues/7.
    
+
    Note : connect-src 'self' ne s'applique pas aux schémas de websocket pour tous les navigateurs. Pour plus d'informations, consulter : https://github.com/w3c/webappsec-csp/issues/7.
    @@ -51,7 +51,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/connect-src

    Une ou plusieurs sources peuvent être autorisées pour cette directive :

    -
    Content-Security-Policy: connect-src <source>;
+
    Content-Security-Policy: connect-src <source>;
 Content-Security-Policy: connect-src <source> <source>;
 
    
 
@@ -65,11 +65,11 @@ Content-Security-Policy: connect-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: connect-src https://example.com/
    
+
    Content-Security-Policy: connect-src https://example.com/
    
 
 
    Les connexions suivantes seront bloquées et ne se chargeront pas :
    
 
-
    <a ping="https://not-example.com">
+
    <a ping="https://not-example.com">
 
 <script>
   var xhr = new XMLHttpRequest();
diff --git a/files/fr/web/http/headers/content-security-policy/default-src/index.html b/files/fr/web/http/headers/content-security-policy/default-src/index.html
index 4111dc6de1..9f2d9d6cb8 100644
--- a/files/fr/web/http/headers/content-security-policy/default-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/default-src/index.html
@@ -16,7 +16,9 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/default-src
 ---
 
    {{HTTPSidebar}}
    
 
-
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) default-src sert de valeur par défaut pour les autres directives CSP {{Glossary("fetch directive", "fetch directives")}}. Pour chacune des directives suivantes, l'agent utilisateur consultera la directive default-src et utilisera sa valeur pour la directive demandée si celle-ci est absente :
    
+
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) default-src sert de valeur par défaut pour les autres directives CSP {{Glossary("fetch directive", "fetch directives")}}.
    
+
+
    Pour chacune des directives suivantes, l'agent utilisateur consultera la directive default-src et utilisera sa valeur pour la directive demandée si celle-ci est absente :
    
 
 
      
  
    • {{CSP("child-src")}}
      • 
@@ -54,13 +56,12 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/default-src
 
 
      Une ou plusieurs sources peuvent être autorisées pour cette directive :
      
 
-
      Content-Security-Policy: default-src <source>;
+
      Content-Security-Policy: default-src <source>;
 Content-Security-Policy: default-src <source> <source>;
 
      
 
 
      Sources
      
 
-
      
 
      La <source> peut être une des suivantes :
      
 
 
      
@@ -87,7 +88,7 @@ Content-Security-Policy: default-src <source> <source>;
  
      Cette valeur fait référence au domaine dont est originaire le document protégé, y compris le protocole et le numéro de port. Vous devez mettre cette valeur entre guillemets. Certains navigateurs excluent spécifiquement les valeurs blob et filesystem des directives de source. Les sites nécessitant une permission pour ces types de contenu peuvent les spécifier en utilisant l'attribut Data.
      
  
      'unsafe-eval'
      
  
      Permet l'usage de la fonction eval() et de méthodes similaires pour créer du code à partir de chaines de caractères. Vous devez mettre cette valeur entre guillemets.
      
- 
      'unsafe-hashes'
      
+ 
      'unsafe-hashes'
      
  
      Permet l'usage de certains écouteurs d'évènements par attributs. Si vous n'avez besoin que d'écouteurs d'évènements par attributs et non d'éléments {{HTMLElement("script")}} embarqués ou d'URL javascript:, cette valeur est plus sécurisée que unsafe-inline.
      
  
      'unsafe-inline'
      
  
      Permet l'usage de ressources embarquées, tels que des éléments {{HTMLElement("script")}} (sans src), d'URL javascript:, de gestionnaire d'évènement par attributs (on<eventName>), et d'éléments {{HTMLElement("style")}}. Vous devez mettre cette valeur entre guillemets.
      
@@ -97,22 +98,12 @@ Content-Security-Policy: default-src <source> <source>;
  
      Une liste de permissions pour des scripts embarqués spécifiques en utilisant un nonce (number used once, nombre à usage unique) cryptographique. Le serveur doit générer un nonce à chaque fois qu'il transmet une réponse. Il est extrèmement important de fournir des nonces non prédictibles, puisque le contraire permettrait aisément de contourner la stratégie de sécurité. Voir inline script non fiables pour avoir un exemple. Spécifier un nonce implique que les navigateurs modernes ignoreront la valeur 'unsafe-inline', qui peut toutefois être laissée pour les anciens navigateurs ne supportant pas les nonces.
      
  
      '<hash-algorithm>-<base64-value>'
      
  
      Un hash sha256, sha384 ou sha512 d'un <script> ou d'un <style>. Cette source est composée de deux parties séparées par un tiret : le nom de l'algorithme de chiffrage utilisé pour générer le hash à gauche et le hash encodé en base 64 à droite. Lors de la génération du hash, il ne faut pas inclure les balises <script> or <style> et tenir compte de la casse et des caractères blancs (espaces, retours à la ligne, etc.). Voir inline script non fiables pour en avoir un exemple. En CSP 2.0, cette valeur ne s'applique qu'aux scripts embarqués. CSP 3.0 le permet aussi dans le cas de scripts externes.
      
-
      
-
      
-
-
      
-
      
  
      'strict-dynamic'
      
  
      La valeur strict-dynamic spécifie que la confiance explicitement donnée à un script de la page, par le biais d'un nonce ou d'un hash, doit être propagée à tous les scripts chargés par celui-ci. En conséquence, toute les valeurs telles que 'self' ou 'unsafe-inline' et listes de permissions sont ignorées. Voir script-src pour en avoir un exemple.
      
-
      
-
      
-
-
      
-
      
  
      'report-sample'
      
  
      Requiert qu'un échantillon du code violant la directive soit inclus dans le rapport envoyé.
      
 
      
-
      
+
 
 
      Exemples
      
 
@@ -120,11 +111,11 @@ Content-Security-Policy: default-src <source> <source>;
 
 
      S'il y a d'autres directives spécifiées, default-src ne les affecte pas. Soit l'en-tête suivant :
      
 
-
      Content-Security-Policy: default-src 'self'; script-src https://example.com
      
+
      Content-Security-Policy: default-src 'self'; script-src https://example.com
      
 
 
      Est identique à :
      
 
-
      Content-Security-Policy: connect-src 'self';
+
      Content-Security-Policy: connect-src 'self';
                          font-src 'self';
                          frame-src 'self';
                          img-src 'self';
diff --git a/files/fr/web/http/headers/content-security-policy/font-src/index.html b/files/fr/web/http/headers/content-security-policy/font-src/index.html
index 9e50fb7307..d5f2317624 100644
--- a/files/fr/web/http/headers/content-security-policy/font-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/font-src/index.html
@@ -38,7 +38,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/font-src
 
 
      Une ou plusieurs sources peuvent être autorisées pour cette directive :
      
 
-
      Content-Security-Policy: font-src <source>;
+
      Content-Security-Policy: font-src <source>;
 Content-Security-Policy: font-src <source> <source>;
 
      
 
@@ -52,11 +52,11 @@ Content-Security-Policy: font-src <source> <source>;
 
 
      Soit cet en-tête CSP :
      
 
-
      Content-Security-Policy: font-src https://example.com/
      
+
      Content-Security-Policy: font-src https://example.com/
      
 
 
      Cette définition de police sera bloquée et ne se chargera pas :
      
 
-
      <style>
+
      <style>
   @font-face {
     font-family: "MyFont";
     src: url("https://not-example.com/font");
diff --git a/files/fr/web/http/headers/content-security-policy/form-action/index.html b/files/fr/web/http/headers/content-security-policy/form-action/index.html
index cd09bd3cbc..fee4d1839f 100644
--- a/files/fr/web/http/headers/content-security-policy/form-action/index.html
+++ b/files/fr/web/http/headers/content-security-policy/form-action/index.html
@@ -17,7 +17,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/form-action
 
      La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) form-action restreint les URL pouvant être utilisées comme cibles de soumissions de formulaires depuis un contexte donné.
      
 
 
      
-
      La question de savoir si form-action doit bloquer les redirections après une soumission de formulaire est encore débattue et les implantations des navigateurs sur cet aspect sont incohérentes (par exemple Firefox 57 ne les bloque pas, contrairement à Chrome 63).
      
+
      Attention : La question de savoir si form-action doit bloquer les redirections après une soumission de formulaire est encore débattue et les implantations des navigateurs sur cet aspect sont incohérentes (par exemple Firefox 57 ne les bloque pas, contrairement à Chrome 63).
    @@ -41,7 +41,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/form-action

    Une ou plusieurs sources peuvent être utilisées pour cette directive :

    -
    Content-Security-Policy: form-action <source>;
+
    Content-Security-Policy: form-action <source>;
 Content-Security-Policy: form-action <source> <source>;
 
    
 
@@ -53,23 +53,23 @@ Content-Security-Policy: form-action <source> <source>;
 
 
    Configuration par balise <meta>
    
 
-
    <meta http-equiv="Content-Security-Policy" content="form-action 'none'">
    
+
    <meta http-equiv="Content-Security-Policy" content="form-action 'none'">
    
 
 
    Configuration par Apache
    
 
-
    <IfModule mod_headers.c>
+
    <IfModule mod_headers.c>
 Header set Content-Security-Policy "form-action 'none';"
 </IfModule>
    
 
 
    Configuration par Nginx
    
 
-
    add_header Content-Security-Policy "form-action 'none';"
    
+
    add_header Content-Security-Policy "form-action 'none';"
    
 
 
    Cas de violation
    
 
 
    Utiliser un élément {{HTMLElement("form")}} avec un attribut action défini à un script embarqué JavaScript résultera en une violation de CSP :
    
 
-
    <meta http-equiv="Content-Security-Policy" content="form-action 'none'">
+
    <meta http-equiv="Content-Security-Policy" content="form-action 'none'">
 
 <form action="javascript:alert('Foo')" id="form1" method="post">
   <input type="text" name="fieldName" value="fieldValue">
diff --git a/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.html b/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.html
index c512933db4..756e247616 100644
--- a/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.html
+++ b/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.html
@@ -43,7 +43,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/frame-ancestors
 
 
    Une ou plusieurs sources peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: frame-ancestors <source>;
+
    Content-Security-Policy: frame-ancestors <source>;
 Content-Security-Policy: frame-ancestors <source> <source>;
 
    
 
@@ -52,7 +52,7 @@ Content-Security-Policy: frame-ancestors <source> <source>;
 
    La <source> peut être une des suivantes :
    
 
 
    
-
    The frame-ancestors directive’s syntax is similar to a source list of other directives (e.g. {{CSP("default-src")}}), but doesn't allow 'unsafe-eval' or 'unsafe-inline' for example. It will also not fall back to a default-src setting. Only the sources listed below are allowed:
    
+
    Note : The frame-ancestors directive’s syntax is similar to a source list of other directives (e.g. {{CSP("default-src")}}), but doesn't allow 'unsafe-eval' or 'unsafe-inline' for example. It will also not fall back to a default-src setting. Only the sources listed below are allowed:
    
 
    
 
 
    
@@ -65,8 +65,8 @@ Content-Security-Policy: frame-ancestors <source> <source>;
   
  • https://store.example.com: correspondra à toutes les tentatives d'accès à store.example.com via le protocole https:.
    • 
  
 
- 
    
- 
    Si aucun schéma d'URL n'est spécifié comme host-source et que l'{{HTMLElement("iframe")}} est chargée via une URL https:, la page chargeant l'iframe doit aussi être chargée en https:, selon la spécification du W3C sur les correspondances de valeurs de sources.
    
+ 
    
+ 
    Attention : Si aucun schéma d'URL n'est spécifié comme host-source et que l'{{HTMLElement("iframe")}} est chargée via une URL https:, la page chargeant l'iframe doit aussi être chargée en https:, selon la spécification du W3C sur les correspondances de valeurs de sources.
    
  
    
  
  
    <scheme-source>
    
@@ -86,7 +86,7 @@ Content-Security-Policy: frame-ancestors <source> <source>;
 
 
    Exemples
    
 
-
    Content-Security-Policy: frame-ancestors 'none';
+
    Content-Security-Policy: frame-ancestors 'none';
 
 Content-Security-Policy: frame-ancestors 'self' https://www.example.org;
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/frame-src/index.html b/files/fr/web/http/headers/content-security-policy/frame-src/index.html
index 34aa799481..e5d7566d81 100644
--- a/files/fr/web/http/headers/content-security-policy/frame-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/frame-src/index.html
@@ -39,7 +39,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/frame-src
 
 
    Une ou plusieurs sources peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: frame-src <source>;
+
    Content-Security-Policy: frame-src <source>;
 Content-Security-Policy: frame-src <source> <source>;
 
    
 
@@ -53,11 +53,11 @@ Content-Security-Policy: frame-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: frame-src https://example.com/
    
+
    Content-Security-Policy: frame-src https://example.com/
    
 
 
    Cet élément {{HTMLElement("iframe")}} est bloqué et ne se chargera pas :
    
 
-
    <iframe src="https://not-example.com/"></iframe>
    
+
    <iframe src="https://not-example.com/"></iframe>
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/img-src/index.html b/files/fr/web/http/headers/content-security-policy/img-src/index.html
index d398bf7930..cbaf0a5798 100644
--- a/files/fr/web/http/headers/content-security-policy/img-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/img-src/index.html
@@ -16,7 +16,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/img-src
 ---
 
    {{HTTPSidebar}}
    
 
-
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} img-src sépcifie les sources valides d'images et de favicons.
    
+
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} img-src sépcifie les sources valides d'images et de favicons.
    @@ -39,7 +39,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/img-src

    Une ou plusieurs sources peuvent être autorisées pour cette directive :

    -
    Content-Security-Policy: img-src <source>;
+
    Content-Security-Policy: img-src <source>;
 Content-Security-Policy: img-src <source> <source>;
 
    
 
@@ -53,11 +53,11 @@ Content-Security-Policy: img-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: img-src https://example.com/
    
+
    Content-Security-Policy: img-src https://example.com/
    
 
 
    Cet élément {{HTMLElement("img")}} est bloqué et ne se chargera pas :
    
 
-
    <img src="https://not-example.com/foo.jpg" alt="example picture">
    
+
    <img src="https://not-example.com/foo.jpg" alt="example picture">
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/index.html b/files/fr/web/http/headers/content-security-policy/index.html
index 4ffcff7b78..2cd4912372 100644
--- a/files/fr/web/http/headers/content-security-policy/index.html
+++ b/files/fr/web/http/headers/content-security-policy/index.html
@@ -30,7 +30,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy
 
 
    Syntaxe
    
 
-
    Content-Security-Policy: <policy-directive>; <policy-directive>
+
    Content-Security-Policy: <policy-directive>; <policy-directive>
 
    
 
 
    Directives
    
@@ -44,7 +44,9 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy
  
    Définit les sources valides pour les web workers et les éléments qui représentent des contextes de navigation imbriqués tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}.
    
 
 
-
    Plutôt que la directive child-src, si vous souhaitez réguler les contextes de navigation imbriqués et les workers séparément, vous pouvez utiliser respectivement les directives {{CSP("frame-src")}} et {{CSP("worker-src")}}.
    
+
    
+  
    Attention :Plutôt que la directive child-src, si vous souhaitez réguler les contextes de navigation imbriqués et les workers séparément, vous pouvez utiliser respectivement les directives {{CSP("frame-src")}} et {{CSP("worker-src")}}.
    
+
    
 
 
    
  
    {{CSP("connect-src")}}
    
@@ -65,8 +67,8 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy
  
    Définit les sources valides pour les ressources des éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}}.
    
 
    
 
-
    
-
    Les éléments contrôlés pa ar object-src sont considérés peut-être par coïcidence comme des éléments HTML du passé et ne recevront de nouvelles fonctionnalités normalisées (comme les attributs de sécurité sandbox et allow pour <iframe>). De ce fait, il est recommandé de restreindre cette directive, c'est-à-dire la définir explicitement à object-src 'none' dans la mesure du possible.
    
+
    
+
    Note : Les éléments contrôlés pa ar object-src sont considérés peut-être par coïcidence comme des éléments HTML du passé et ne recevront de nouvelles fonctionnalités normalisées (comme les attributs de sécurité sandbox et allow pour <iframe>). De ce fait, il est recommandé de restreindre cette directive, c'est-à-dire la définir explicitement à object-src 'none' dans la mesure du possible.
    
 
    
 
 
    
@@ -124,9 +126,9 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy
 
    
 
 
    
-
    Bien que la directive report-to est prévue remplacer la directive report-uri maintenant dépréciée, report-to n'est pas encore supportée par la plupart des navigateurs modernes. Par rétrocompatibilité avec les navigateurs courants et tout en prévoyant une compatibilité future quand les navigateurs supporteront report-to, vous pouvez spécifier les deux directives report-uri et report-to:
    
+
    Attention : Bien que la directive report-to est prévue remplacer la directive report-uri maintenant dépréciée, report-to n'est pas encore supportée par la plupart des navigateurs modernes. Par rétrocompatibilité avec les navigateurs courants et tout en prévoyant une compatibilité future quand les navigateurs supporteront report-to, vous pouvez spécifier les deux directives report-uri et report-to:
    
 
-
    Content-Security-Policy: ...; report-uri https://endpoint.com; report-to groupname
    
+
    Content-Security-Policy: ...; report-uri https://endpoint.com; report-to groupname
    
 
 
    Dans les navigateurs qui supportent report-to, la directive report-uri sera ignorée.
    
 
    
@@ -163,7 +165,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy
 
 
    L'en-tête Content-Security-Policy peut être utilisé plus d'une fois comme illustré ci-après. On notera la directive {{CSP("connect-src")}} utilisée ici. Bien que la deuxième règle autorise la connexion, la première contient connect-src 'none'. L'ajout de règles supplémentaires permet uniquement d'augmenter les protections. Les niveaux les plus stricts pour chaque règle sont alors utilisés. Dans l'exemple qui suit, cela signifie que la directive connect-src 'none' sera respectée.
    
 
-
    Content-Security-Policy: default-src 'self' http://example.com;
+
    Content-Security-Policy: default-src 'self' http://example.com;
                          connect-src 'none';
 Content-Security-Policy: connect-src http://example.com/;
                          script-src http://example.com/
    
@@ -174,7 +176,7 @@ Content-Security-Policy: connect-src http://example.com/;
 
 
    Dans cet exemple, on désactive les scripts écrits à même le document (inline), les opérations eval() et les ressources (images, polices, scripts, etc.) peuvent uniquement être chargées via HTTPS :
    
 
-
    // en-tête HTTP
+
    // en-tête HTTP
 Content-Security-Policy: default-src https:
 
 // version avec la balise HTML meta
@@ -185,13 +187,13 @@ Content-Security-Policy: default-src https:
 
 
    Cet exemple est plutôt adapté pour un site historique qui utilise de nombreux scripts écrits dans les documents mais pour lequel on veut s'assurer que les ressources sont chargées via HTTPS et pour lequel on veut désactiver les plugins :
    
 
-
    Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
    
+
    Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
    
 
 
    Exemple 3
    
 
 
    On ne met pas en place la règle de sécurité mais on récolte les enfreintes qui se seraient produites pour cette règle :
    
 
-
    Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
    
+
    Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
    
 
 
    Pour plus d'exemples, consulter les recommandations de Mozilla pour la sécurité web.
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/manifest-src/index.html b/files/fr/web/http/headers/content-security-policy/manifest-src/index.html
index 227cbbd03a..a99cf41e12 100644
--- a/files/fr/web/http/headers/content-security-policy/manifest-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/manifest-src/index.html
@@ -39,7 +39,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/manifest-src
 
 
    Une ou plusieurs sources peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: manifest-src <source>;
+
    Content-Security-Policy: manifest-src <source>;
 Content-Security-Policy: manifest-src <source> <source>;
 
    
 
@@ -53,11 +53,11 @@ Content-Security-Policy: manifest-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: manifest-src https://example.com/
    
+
    Content-Security-Policy: manifest-src https://example.com/
    
 
 
    Cet élément {{HTMLElement("link")}} sera bloqué et ne se chargera pas :
    
 
-
    <link rel="manifest" href="https://not-example.com/manifest">
    
+
    <link rel="manifest" href="https://not-example.com/manifest">
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/media-src/index.html b/files/fr/web/http/headers/content-security-policy/media-src/index.html
index ed0bd0f4ab..9efb6aef2d 100644
--- a/files/fr/web/http/headers/content-security-policy/media-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/media-src/index.html
@@ -39,7 +39,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/media-src
 
 
    Une ou plusieurs sources peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: media-src <source>;
+
    Content-Security-Policy: media-src <source>;
 Content-Security-Policy: media-src <source> <source>;
 
    
 
@@ -53,11 +53,11 @@ Content-Security-Policy: media-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: media-src https://example.com/
    
+
    Content-Security-Policy: media-src https://example.com/
    
 
 
    Ces éléments {{HTMLElement("audio")}}, {{HTMLElement("video")}} et {{HTMLElement("track")}} seront bloqués et ne se chargeront pas :
    
 
-
    <audio src="https://not-example.com/audio"></audio>
+
    <audio src="https://not-example.com/audio"></audio>
 
 <video src="https://not-example.com/video">
   <track kind="subtitles" src="https://not-example.com/subtitles">
diff --git a/files/fr/web/http/headers/content-security-policy/navigate-to/index.html b/files/fr/web/http/headers/content-security-policy/navigate-to/index.html
index 79478e5691..2a715438a3 100644
--- a/files/fr/web/http/headers/content-security-policy/navigate-to/index.html
+++ b/files/fr/web/http/headers/content-security-policy/navigate-to/index.html
@@ -17,7 +17,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/navigate-to
 
 
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) navigate-to restreint les URL vers lesquelles un document peut initier une navigation de quelque manière que ce soit, dont {{HTMLElement("form")}} (si {{CSP("form-action")}} n'est pas spécifié), {{HTMLElement("a")}}, {{DOMxRef("window.location")}}, {{DOMxRef("window.open")}}, etc. Elle permet de renforcer les navigations que le document peut initier et non les adresses vers lesquelles ce document peut naviguer.
    
 
-
    
+
    
 
    Note : Si la directive {{CSP("form-action")}} est présente, la directive navigate-to ne sera pas appliquée sur la navigation par la soumission de formulaire.
    
 
    
 
@@ -42,7 +42,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/navigate-to
 
 
    Une ou plusieurs sources peuvent être utilisées pour cette directive :
    
 
-
    Content-Security-Policy: navigate-to <source>;
+
    Content-Security-Policy: navigate-to <source>;
 Content-Security-Policy: navigate-to <source> <source>;
 
    
 
@@ -54,14 +54,14 @@ Content-Security-Policy: navigate-to <source> <source>;
 
 
    Configuration par balise <meta>
    
 
-
    <meta http-equiv="Content-Security-Policy" content="navigate-to 'none'">
+
    <meta http-equiv="Content-Security-Policy" content="navigate-to 'none'">
 
    
 
 
    Cas de violation
    
 
 
    Utiliser l'élément {{HTMLElement("form")}} avec un attribut action défini à un script embarqué en JavaScript résultera en une violation de CSP :
    
 
-
    <meta http-equiv="Content-Security-Policy" content="navigate-to 'none'">
+
    <meta http-equiv="Content-Security-Policy" content="navigate-to 'none'">
 
 <form action="javascript:alert('Foo')" id="form1" method="post">
   <input type="text" name="fieldName" value="fieldValue">
diff --git a/files/fr/web/http/headers/content-security-policy/object-src/index.html b/files/fr/web/http/headers/content-security-policy/object-src/index.html
index 0111f1cf61..46cca9c2ee 100644
--- a/files/fr/web/http/headers/content-security-policy/object-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/object-src/index.html
@@ -20,7 +20,9 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/object-src
 
 
    Pour définir des types autorisés pour les éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}}, voir la directive {{CSP("plugin-types")}}.
    
 
-
    Les éléments contrôlés par object-src sont considérés peut-être par coïcidence comme des éléments HTML du passé et ne recevront de nouvelles fonctionnalités normalisées (comme les attributs de sécurité sandbox et allow pour <iframe>). De ce fait, il est recommandé de restreindre cette directive, c'est-à-dire la définir explicitement à object-src 'none' dans la mesure du possible.
    
+
    
+  
    Note : Les éléments contrôlés par object-src sont considérés peut-être par coïcidence comme des éléments HTML du passé et ne recevront de nouvelles fonctionnalités normalisées (comme les attributs de sécurité sandbox et allow pour <iframe>). De ce fait, il est recommandé de restreindre cette directive, c'est-à-dire la définir explicitement à object-src 'none' dans la mesure du possible.
    
+
    @@ -43,7 +45,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/object-src

    Une ou plusieurs sources peuvent être autorisées pour cette directive :

    -
    Content-Security-Policy: object-src <source>;
+
    Content-Security-Policy: object-src <source>;
 Content-Security-Policy: object-src <source> <source>;
 
    
 
@@ -57,11 +59,11 @@ Content-Security-Policy: object-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: object-src https://example.com/
    
+
    Content-Security-Policy: object-src https://example.com/
    
 
 
    Ces éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}} seront bloqués et ne se chargeront pas :
    
 
-
    <embed src="https://not-example.com/flash"></embed>
+
    <embed src="https://not-example.com/flash"></embed>
 <object data="https://not-example.com/plugin"></object>
 <applet archive="https://not-example.com/java"></applet>
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/plugin-types/index.html b/files/fr/web/http/headers/content-security-policy/plugin-types/index.html
index 76e7cf1e38..188eccaf9e 100644
--- a/files/fr/web/http/headers/content-security-policy/plugin-types/index.html
+++ b/files/fr/web/http/headers/content-security-policy/plugin-types/index.html
@@ -47,7 +47,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/plugin-types
 
 
    Un ou plusieurs types MIME peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: plugin-types <type>/<subtype>;
+
    Content-Security-Policy: plugin-types <type>/<subtype>;
 Content-Security-Policy: plugin-types <type>/<subtype> <type>/<subtype>;
 
    
 
@@ -62,23 +62,23 @@ Content-Security-Policy: plugin-types <type>/<subtype> <type>/
 
 
    Pour intedire tous les greffons, la directive {{CSP("object-src")}} doit être définie à 'none'. La directive plugin-types n'est utilisée que si vous autorisez au préalable les greffons avec object-src.
    
 
-
    <meta http-equiv="Content-Security-Policy" content="object-src 'none'">
    
+
    <meta http-equiv="Content-Security-Policy" content="object-src 'none'">
    
 
 
    Autoriser le contenu Flash
    
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: plugin-types application/x-shockwave-flash
    
+
    Content-Security-Policy: plugin-types application/x-shockwave-flash
    
 
 
    Cet objet Flash sera autorisé et se chargera (dans la mesure où le navigateur gère Flash) :
    
 
-
    <object data="https://example.com/flash" type="application/x-shockwave-flash"></object>
    
+
    <object data="https://example.com/flash" type="application/x-shockwave-flash"></object>
    
 
 
    Autoriser les applets Java
    
 
 
    Pour charger une {{HTMLElement("applet")}}, vous devez spécifier la valeur application/x-java-applet :
    
 
-
    Content-Security-Policy: plugin-types application/x-java-applet
    
+
    Content-Security-Policy: plugin-types application/x-java-applet
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/prefetch-src/index.html b/files/fr/web/http/headers/content-security-policy/prefetch-src/index.html
index 81d2f5f0fa..62abcf4068 100644
--- a/files/fr/web/http/headers/content-security-policy/prefetch-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/prefetch-src/index.html
@@ -36,7 +36,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/prefetch-src
 
 
    Une ou plusieurs sources peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: prefetch-src <source>;
+
    Content-Security-Policy: prefetch-src <source>;
 Content-Security-Policy: prefetch-src <source> <source>;
 
    
 
@@ -50,12 +50,12 @@ Content-Security-Policy: prefetch-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: prefetch-src https://example.com/
+
    Content-Security-Policy: prefetch-src https://example.com/
 
    
 
 
    Les requêtes émises par ce code généreront des erreurs de réseau puisque les URL demandées ne correspondant pas à la liste de permissions de la directive prefetch-src :
    
 
-
    <link rel="prefetch" src="https://example.org/"></link>
+
    <link rel="prefetch" src="https://example.org/"></link>
 <link rel="prerender" src="https://example.org/"></link>
    
 
 
    Spécification
    
diff --git a/files/fr/web/http/headers/content-security-policy/referrer/index.html b/files/fr/web/http/headers/content-security-policy/referrer/index.html
index dc3b894b7c..ee12abb78d 100644
--- a/files/fr/web/http/headers/content-security-policy/referrer/index.html
+++ b/files/fr/web/http/headers/content-security-policy/referrer/index.html
@@ -18,14 +18,14 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/referrer
 
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) referrer spécifie des informations dans l'en-tête HTTP {{HTTPHeader("Referer")}} (avec un seul r) pour les liens externes d'une page. Cette API est dépréciée et supprimée des navigateurs.
    
 
 
    
-
    Utilisez plutôt l'en-tête HTTP {{HTTPHeader("Referrer-Policy")}}.
    
+
    Note : Utilisez plutôt l'en-tête HTTP {{HTTPHeader("Referrer-Policy")}}.
    
 
    
 
 
    Syntaxe
    
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: referrer <referrer-policy>;
    
+
    Content-Security-Policy: referrer <referrer-policy>;
    
 
 
    Où <referrer-policy> peut être une valeur parmi :
    
 
@@ -45,7 +45,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/referrer
 
 
    Exemples
    
 
-
    Content-Security-Policy: referrer "none";
    
+
    Content-Security-Policy: referrer "none";
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/report-to/index.html b/files/fr/web/http/headers/content-security-policy/report-to/index.html
index fe1286dbe1..3011486ccb 100644
--- a/files/fr/web/http/headers/content-security-policy/report-to/index.html
+++ b/files/fr/web/http/headers/content-security-policy/report-to/index.html
@@ -14,9 +14,9 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/report-to
 ---
 
    {{HTTPSidebar}}
    
 
-
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) report-to demande à l'agent utilisateur de rapporter les violations de règles CSP à l'adresse fournie dans un groupe de l'en-tête HTTP Report-To.
    
+
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) report-to demande à l'agent utilisateur de rapporter les violations de règles CSP à l'adresse fournie dans un groupe de l'en-tête HTTP Report-To.
    
 
-
    Content-Security-Policy: ...; report-to groupname
+
    Content-Security-Policy: ...; report-to groupname
 
    
 
 
    Cette directive n'a aucun effet en elle-même, mais prend tout son sens en étant combinée à d'autres directives.
    
@@ -39,38 +39,36 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/report-to
 
 
    Syntaxe
    
 
-
    Content-Security-Policy: report-to <json-field-value>;
    
+
    Content-Security-Policy: report-to <json-field-value>;
    
 
 
    Exemples
    
 
 
    Voir {{HTTPHeader("Content-Security-Policy-Report-Only")}} pour plus d'informations et d'exemples.
    
 
-
    Report-To: { "group": "csp-endpoint",
-             "max_age": 10886400,
-             "endpoints": [
-               { "url": "https://example.com/csp-reports" }
+
    Report-To: { "group": "csp-endpoint",
+             "max_age": 10886400,
+             "endpoints": [
+               { "url": "https://example.com/csp-reports" }
              ] },
-           { "group": "hpkp-endpoint",
-             "max_age": 10886400,
-             "endpoints": [
-               { "url": "https://example.com/hpkp-reports" }
+           { "group": "hpkp-endpoint",
+             "max_age": 10886400,
+             "endpoints": [
+               { "url": "https://example.com/hpkp-reports" }
              ] }
-Content-Security-Policy: ...; report-to csp-endpoint
+Content-Security-Policy: ...; report-to csp-endpoint
 
    
 
-
    Report-To: { "group": "endpoint-1",
-             "max_age": 10886400,
-             "endpoints": [
-               { "url": "https://example.com/reports" },
-               { "url": "https://backup.com/reports" }
+
    Report-To: { "group": "endpoint-1",
+             "max_age": 10886400,
+             "endpoints": [
+               { "url": "https://example.com/reports" },
+               { "url": "https://backup.com/reports" }
              ] }
 
-Content-Security-Policy: ...; report-to endpoint-1
    
+Content-Security-Policy: ...; report-to endpoint-1
    
 
 
    Compatibilité des navigateurs
    
 
-
    diff --git a/files/fr/web/http/headers/content-security-policy/script-src-elem/index.html b/files/fr/web/http/headers/content-security-policy/script-src-elem/index.html index 5bebc3b3a7..7d29bbef41 100644 --- a/files/fr/web/http/headers/content-security-policy/script-src-elem/index.html +++ b/files/fr/web/http/headers/content-security-policy/script-src-elem/index.html @@ -41,13 +41,13 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src-elem

    Une ou plusieurs sources peuvent être autorisées pour cette directive :

    -
    Content-Security-Policy: script-src-elem <source>;
+
    Content-Security-Policy: script-src-elem <source>;
 Content-Security-Policy: script-src-elem <source> <source>;
 
    
 
 
    script-src-elem peut être utilisée conjointement à {{CSP("script-src")}} :
    
 
-
    Content-Security-Policy: script-src <source>;
+
    Content-Security-Policy: script-src <source>;
 Content-Security-Policy: script-src-elem <source>;
 
    
 
@@ -61,10 +61,6 @@ Content-Security-Policy: script-src-elem <source>;
 
 
    Si la directive script-src-elem est absente, l'agent utilisateur se rabat sur la valeur de la directive {{CSP("script-src")}}, qui elle-même a pour valeur par défaut celle de la directive {{CSP("default-src")}}.
    
 
-
-
 
    Spécifications
    diff --git a/files/fr/web/http/headers/content-security-policy/script-src/index.html b/files/fr/web/http/headers/content-security-policy/script-src/index.html index d050eefcaa..a6b2659ae9 100644 --- a/files/fr/web/http/headers/content-security-policy/script-src/index.html +++ b/files/fr/web/http/headers/content-security-policy/script-src/index.html @@ -40,7 +40,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src

    Une ou plusieurs sources peuvent être autorisées pour cette directive :

    -
    Content-Security-Policy: script-src <source>;
+
    Content-Security-Policy: script-src <source>;
 Content-Security-Policy: script-src <source> <source>;
 
    
 
@@ -54,19 +54,19 @@ Content-Security-Policy: script-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: script-src https://example.com/
    
+
    Content-Security-Policy: script-src https://example.com/
    
 
 
    Ces scripts seront bloqués et ne seront pas chargés ou exécutés :
    
 
-
    <script src="https://not-example.com/js/library.js"></script>
    
+
    <script src="https://not-example.com/js/library.js"></script>
    
 
 
    Notez que les gestionnaires d'évènements par attributs sont aussi bloqués :
    
 
-
    <button id="btn" onclick="doSomething()">
    
+
    <button id="btn" onclick="doSomething()">
    
 
 
    Vous devez les remplacer par des appels à la méthode {{domxref("EventTarget.addEventListener", "addEventListener")}} :
    
 
-
    document.getElementById("btn").addEventListener('click', doSomething);
    
+
    document.getElementById("btn").addEventListener('click', doSomething);
    
 
 
    Scripts embarqués non fiables
    
 
@@ -76,32 +76,32 @@ Content-Security-Policy: script-src <source> <source>;
 
 
    Vous pouvez autoriser les scripts embarqués et les gestionnaires d'évènements par attributs en spécifiant la valeur 'unsafe-inline', des nonces ou des hashs correspondant au script.
    
 
-
    Content-Security-Policy: script-src 'unsafe-inline';
+
    Content-Security-Policy: script-src 'unsafe-inline';
 
    
 
 
    Cette directive CSP autorisera tous les scripts {{HTMLElement("script")}} embarqués :
    
 
-
    <script>
+
    <script>
   var inline = 1;
 </script>
    
 
 
    Vous pouvez aussi utiliser un nonce pour autoriser spécifiquement certains éléments {{HTMLElement("script")}} embarqués :
    
 
-
    Content-Security-Policy: script-src 'nonce-2726c7f26c'
    
+
    Content-Security-Policy: script-src 'nonce-2726c7f26c'
    
 
 
    Vous devrez alors définir ce nonce sur l'élément {{HTMLElement("script")}} :
    
 
-
    <script nonce="2726c7f26c">
+
    <script nonce="2726c7f26c">
   var inline = 1;
 </script>
    
 
 
    Autrement, vous pouvez créer des hashs à partir de vos scripts. CSP accepte les algorithmes sha256, sha384 et sha512.
    
 
-
    Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='
    
+
    Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='
    
 
 
    Lors de la génération du hash, vous ne devez pas inclure les balises et tenir compte de la casse et des caractères blancs (espaces, retours à la ligne, etc.).
    
 
-
    <script>var inline = 1;</script>
    
+
    <script>var inline = 1;</script>
    
 
 
    Expressions d'évaluation non fiables
    
 
@@ -124,15 +124,15 @@ Content-Security-Policy: script-src <source> <source>;
 
 
    La valeur 'strict-dynamic' spécifie que la confiance explicitement donnée à un script de la page, par le biais d'un nonce ou d'un hash, doit être propagée à tous les scripts chargés par celui-ci. En conséquence, toute liste de permissions ou expressions de sources telles que 'self' ou 'unsafe-inline' sont ignorées. Par exemple, une règle telle que script-src 'strict-dynamic' 'nonce-R4nd0m' https://whitelisted.com/ autoriserait le chargement de scripts comme <script nonce="R4nd0m" src="https://example.com/loader.js"> et s'appliquerait ensuite à tous les scripts chargés par loader.js, mais interdirait les scripts chargés depuis https://whitelisted.com/ à moins qu'ils soient accompagnés d'un nonce ou chargés depuis un script dont la source est de confiance.
    
 
-
    script-src 'strict-dynamic' 'nonce-someNonce'
    
+
    script-src 'strict-dynamic' 'nonce-someNonce'
    
 
 
    Ou
    
 
-
    script-src 'strict-dynamic' 'sha256-base64EncodedHash'
    
+
    script-src 'strict-dynamic' 'sha256-base64EncodedHash'
    
 
 
    Il est possible de déployer strict-dynamic de manière rétrocompatible, sans chercher à connaitre l'agent utilisateur. Cette directive :
    
 
-
    script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'
    
+
    script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'
    
 
 
    fonctionnera comme 'unsafe-inline' https: pour les navigateurs supportant CSP1, https: 'nonce-abcdefg' pour ceux supportant CSP2 et comme 'nonce-abcdefg' 'strict-dynamic' pour ceux supportant CSP3.
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/style-src-attr/index.html b/files/fr/web/http/headers/content-security-policy/style-src-attr/index.html
index 55ef02df71..efe3b11c9a 100644
--- a/files/fr/web/http/headers/content-security-policy/style-src-attr/index.html
+++ b/files/fr/web/http/headers/content-security-policy/style-src-attr/index.html
@@ -43,13 +43,13 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/style-src-attr
 
 
    Une ou plusieurs sources peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: style-src-attr <source>;
+
    Content-Security-Policy: style-src-attr <source>;
 Content-Security-Policy: style-src-attr <source> <source>;
 
    
 
 
    style-src-attr peut être utilisée conjointement à {{CSP("style-src")}} :
    
 
-
    Content-Security-Policy: style-src <source>;
+
    Content-Security-Policy: style-src <source>;
 Content-Security-Policy: style-src-attr <source>;
    
 
 
    Sources
    
@@ -61,12 +61,6 @@ Content-Security-Policy: style-src-attr <source>;
    
  
    Requiert qu'un échantillon du code violant la directive soit inclus dans le rapport envoyé.
    
 
 
-
    Exemples
    
-
-
-
 
    Spécifications
    diff --git a/files/fr/web/http/headers/content-security-policy/style-src-elem/index.html b/files/fr/web/http/headers/content-security-policy/style-src-elem/index.html index 49f0a0c7d4..ae88af89c0 100644 --- a/files/fr/web/http/headers/content-security-policy/style-src-elem/index.html +++ b/files/fr/web/http/headers/content-security-policy/style-src-elem/index.html @@ -43,13 +43,13 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/style-src-elem

    Une ou plusieurs sources peuvent être autorisées pour cette directive :

    -
    Content-Security-Policy: style-src-elem <source>;
+
    Content-Security-Policy: style-src-elem <source>;
 Content-Security-Policy: style-src-elem <source> <source>;
 
    
 
 
    style-src-elem peut être utilisée conjointement à {{CSP("style-src")}} :
    
 
-
    Content-Security-Policy: style-src <source>;
+
    Content-Security-Policy: style-src <source>;
 Content-Security-Policy: style-src-elem <source>;
    
 
 
    Sources
    
@@ -61,12 +61,6 @@ Content-Security-Policy: style-src-elem <source>;
    
  
    Requiert qu'un échantillon du code violant la directive soit inclus dans le rapport envoyé.
    
 
 
-
    Exemples
    
-
-
-
 
    Spécifications
    diff --git a/files/fr/web/http/headers/content-security-policy/style-src/index.html b/files/fr/web/http/headers/content-security-policy/style-src/index.html index d373fa8477..a8fa19ef1c 100644 --- a/files/fr/web/http/headers/content-security-policy/style-src/index.html +++ b/files/fr/web/http/headers/content-security-policy/style-src/index.html @@ -40,7 +40,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/style-src

    Une ou plusieurs sources peuvent être autorisées pour cette directive :

    -
    Content-Security-Policy: style-src <source>;
+
    Content-Security-Policy: style-src <source>;
 Content-Security-Policy: style-src <source> <source>;
 
    
 
@@ -54,11 +54,11 @@ Content-Security-Policy: style-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: style-src https://example.com/
    
+
    Content-Security-Policy: style-src https://example.com/
    
 
 
    Ces feuilles de style seront bloquées et ne se chargeront pas :
    
 
-
    <link href="https://not-example.com/styles/main.css" rel="stylesheet" type="text/css" />
+
    <link href="https://not-example.com/styles/main.css" rel="stylesheet" type="text/css" />
 
 <style>
 #inline-style { background: red; }
@@ -70,21 +70,21 @@ Content-Security-Policy: style-src <source> <source>;
 
 
    De même que les styles chargés avec l'en-tête {{HTTPHeader("Link")}} :
    
 
-
    Link: <https://not-example.com/styles/stylesheet.css>;rel=stylesheet
+
    Link: <https://not-example.com/styles/stylesheet.css>;rel=stylesheet
 
    
 
 
    Les attributes de style seront aussi bloqués :
    
 
-
    <div style="display:none">Foo</div>
    
+
    <div style="display:none">Foo</div>
    
 
 
    De même que les styles ajoutés par JavaScript en définissant l'attribut style directement, ou en définissant la propriété {{domxref("CSSStyleDeclaration.cssText", "cssText")}} :
    
 
-
    document.querySelector('div').setAttribute('style', 'display:none;');
+
    document.querySelector('div').setAttribute('style', 'display:none;');
 document.querySelector('div').style.cssText = 'display:none;';
    
 
 
    Toutefois, les propriétés de styles qui sont définies directement dans l'attribut {{domxref("HTMLElement.style", "style")}} ne seront pas bloquées, permettant aux utilisateurs de manipuler sainement les styles avec JavaScript :
    
 
-
    document.querySelector('div').style.display = 'none';
    
+
    document.querySelector('div').style.display = 'none';
    
 
 
    Ce genre de manipulations peut être bloqué en désactivant JavaScript au moyen de la directive CSP {{CSP("script-src")}}.
    
 
@@ -96,12 +96,12 @@ document.querySelector('div').style.cssText = 'display:none;';
    
 
 
    Vous pouvez autoriser les styles embarqués en spécifiant la valeur 'unsafe-inline', des nonces ou des hashs correspondant à la feuille de style.
    
 
-
    Content-Security-Policy: style-src 'unsafe-inline';
+
    Content-Security-Policy: style-src 'unsafe-inline';
 
    
 
 
    Cette directive CSP autorisera toutes les feuilles de styles embarquées telles que l'élément {{HTMLElement("style")}} et l'attribut style sur tous les éléments :
    
 
-
    <style>
+
    <style>
 #inline-style { background: red; }
 </style>
 
@@ -110,21 +110,21 @@ document.querySelector('div').style.cssText = 'display:none;';
    
 
 
    Vous pouvez aussi utiliser un nonce pour autoriser spécifiquement certains éléments {{HTMLElement("style")}} :
    
 
-
    Content-Security-Policy: style-src 'nonce-2726c7f26c'
    
+
    Content-Security-Policy: style-src 'nonce-2726c7f26c'
    
 
 
    Vous devrez alors définir ce nonce sur l'élément {{HTMLElement("style")}} :
    
 
-
    <style nonce="2726c7f26c">
+
    <style nonce="2726c7f26c">
 #inline-style { background: red; }
 </style>
    
 
 
    Autrement, vous pourrez créer des hashs à partir de vos feuilles de styles. CSP accepte les algorithmes sha256, sha384 et sha512.
    
 
-
    Content-Security-Policy: style-src 'sha256-a330698cbe9dc4ef1fb12e2ee9fc06d5d14300262fa4dc5878103ab7347e158f'
    
+
    Content-Security-Policy: style-src 'sha256-a330698cbe9dc4ef1fb12e2ee9fc06d5d14300262fa4dc5878103ab7347e158f'
    
 
 
    Lors de la génération du hash, vous ne devez pas inclure les balises et tenir compte de la casse et des caractères blancs (espaces, retours à la ligne, etc.).
    
 
-
    <style>#inline-style { background: red; }</style>
    
+
    <style>#inline-style { background: red; }</style>
    
 
 
    Style non fiables
    
 
diff --git a/files/fr/web/http/headers/content-security-policy/trusted-types/index.html b/files/fr/web/http/headers/content-security-policy/trusted-types/index.html
index 447823ede5..f1c5d12b6d 100644
--- a/files/fr/web/http/headers/content-security-policy/trusted-types/index.html
+++ b/files/fr/web/http/headers/content-security-policy/trusted-types/index.html
@@ -14,13 +14,13 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/trusted-types
 ---
 
    {{HTTPSidebar}}
    
 
-
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) trusted-types {{experimental_inline}} informe l'agent utilisateur qu'il faut restreindre la création de règles Trusted Types (fonctions qui créent des valeurs typées non falsifiables, dans le but de les passer au puits XSS du DOM au lieu de chaines de caractères).
    
+
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) trusted-types {{experimental_inline}} informe l'agent utilisateur qu'il faut restreindre la création de règles Trusted Types (fonctions qui créent des valeurs typées non falsifiables, dans le but de les passer au puits XSS du DOM au lieu de chaines de caractères).
    
 
-
    Conjointement à la directive require-trusted-types-for, cette directive permet aux auteurs de définir des règles empêchant d'injecter des données dans le DOM et donc de réduire la fenêtre de tir pour les attaques XSS sur le DOM à quelques pans isolés de la base de code d'une application, facilitant donc son contrôle et sa relecture. Cette directive déclare une liste de permissions de noms de règles de Trusted Types créée avec TrustedTypes.createPolicy à partir de l'API Trusted Types.
    
+
    Conjointement à la directive require-trusted-types-for, cette directive permet aux auteurs de définir des règles empêchant d'injecter des données dans le DOM et donc de réduire la fenêtre de tir pour les attaques XSS sur le DOM à quelques pans isolés de la base de code d'une application, facilitant donc son contrôle et sa relecture. Cette directive déclare une liste de permissions de noms de règles de Trusted Types créée avec TrustedTypes.createPolicy à partir de l'API Trusted Types.
    
 
 
    Syntaxe
    
 
-
    Content-Security-Policy: trusted-types;
+
    Content-Security-Policy: trusted-types;
 Content-Security-Policy: trusted-types 'none';
 Content-Security-Policy: trusted-types <policyName>;
 Content-Security-Policy: trusted-types <policyName> <policyName> 'allow-duplicates';
@@ -39,11 +39,11 @@ Content-Security-Policy: trusted-types <policyName> <policyName> 'al
 
 
    Soit l'en-tête CSP :
    
 
-
    Content-Security-Policy: trusted-types foo bar 'allow-duplicates';
    
+
    Content-Security-Policy: trusted-types foo bar 'allow-duplicates';
    
 
 
    Ce code génèrera une erreur car une des règles créées a un nom non autorisé :
    
 
-
    if (typeof trustedTypes !== 'undefined') {
+
    if (typeof trustedTypes !== 'undefined') {
   const policyFoo = trustedTypes.createPolicy('foo', {});
   const policyFoo2 = trustedTypes.createPolicy('foo', {});
   const policyBaz = trustedTypes.createPolicy('baz', {}); // Throws and dispatches a SecurityPolicyViolationEvent.
diff --git a/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.html b/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.html
index fd0c579403..3b0defb999 100644
--- a/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.html
+++ b/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.html
@@ -19,45 +19,47 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-reques
 
 
    La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) upgrade-insecure-requests informe l'agent utilisateur de traiter toutes les URL non sécurisées d'un site (servies avec HTTP) comme si elles avaient été remplacées par des URL sécurisées (servies avec HTTPS). Cette directive est prévue pour les sites web ayant un grand nombre d'URL non sécurisées héritées du passé et qui ont besoin d'être récrites.
    
 
-
    La directive upgrade-insecure-requests est évaluée avant la directive {{CSP("block-all-mixed-content")}} et si cette elle est définie, cette dernière est effectivement ignorée. Il est recommendé de ne définir que l'une des deux directives mais non les deux, à moins que vous souhaitiez forcer HTTPS sur les anciens navigateurs qui ne le font pas après une redirection vers HTTP.
    
+
    
+  
    Note : La directive upgrade-insecure-requests est évaluée avant la directive {{CSP("block-all-mixed-content")}} et si cette elle est définie, cette dernière est effectivement ignorée. Il est recommendé de ne définir que l'une des deux directives mais non les deux, à moins que vous souhaitiez forcer HTTPS sur les anciens navigateurs qui ne le font pas après une redirection vers HTTP.
    
+
    
 
 
    The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the {{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}}) header, which should still be set with an appropriate max-age to ensure that users are not subject to SSL stripping attacks.
    
 
 
    Syntaxe
    
 
-
    Content-Security-Policy: upgrade-insecure-requests;
    
+
    Content-Security-Policy: upgrade-insecure-requests;
    
 
 
    Exemples
    
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: upgrade-insecure-requests;
+
    Content-Security-Policy: upgrade-insecure-requests;
 
    
 
 
    Et cette balise meta :
    
 
-
    <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
    
+
    <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
    
 
 
    Avec cet en-tête défini sur le domaine example.com voulant migrer d'HTTP à HTTPS, les requêtes pour des ressources non sécurisées et non navigationnelles sont automatiquement converties (qu'elles soient internes ou externes).
    
 
-
    <img src="http://example.com/image.png">
+
    <img src="http://example.com/image.png">
 <img src="http://not-example.com/image.png">
    
 
 
    Ces URL seront récrites avant que la requête soit envoyée, signifiant qu'aucune requête non sécurisée ne sera envoyée. Notez que si la ressource demandée n'est pas actuellement disponible via HTTPS, la requête échouera sans se rabattre sur HTTP.
    
 
-
    <img src="https://example.com/image.png">
+
    <img src="https://example.com/image.png">
 <img src="https://not-example.com/image.png">
    
 
 
    Les conversions navigationnelles vers des ressources externes amènent un risque significatif  de dysfonctionnement étant donné que des requêtes peuvent n'être pas converties, par exemple celles-ci :
    
 
-
    <a href="https://example.com/">Home</a>
+
    <a href="https://example.com/">Home</a>
 <a href="http://not-example.com/">Home</a>
    
 
 
    Identifier des requêtes non sécurisées
    
 
 
    À l'aide de l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} et de la directive {{CSP("report-uri")}}, vous pouvez mettre en place une stratégie de rapportage de violations sans bloquage conjointement à une stratégie de conversion comme :
    
 
-
    Content-Security-Policy: upgrade-insecure-requests; default-src https:
+
    Content-Security-Policy: upgrade-insecure-requests; default-src https:
 Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint
    
 
 
    De cette manière, vous convertirez toujours les requêtes non sécurisées sur votre site sécurisé mais la stratégie de rapportage identifiera les requêtes non sécurisées et les rapportera à l'adresse fournie.
    
diff --git a/files/fr/web/http/headers/content-security-policy/worker-src/index.html b/files/fr/web/http/headers/content-security-policy/worker-src/index.html
index 5854d16fc7..fd9ee4f21f 100644
--- a/files/fr/web/http/headers/content-security-policy/worker-src/index.html
+++ b/files/fr/web/http/headers/content-security-policy/worker-src/index.html
@@ -42,7 +42,7 @@ translation_of: Web/HTTP/Headers/Content-Security-Policy/worker-src
 
 
    Une ou plusieurs sources peuvent être autorisées pour cette directive :
    
 
-
    Content-Security-Policy: worker-src <source>;
+
    Content-Security-Policy: worker-src <source>;
 Content-Security-Policy: worker-src <source> <source>;
 
    
 
@@ -56,11 +56,11 @@ Content-Security-Policy: worker-src <source> <source>;
 
 
    Soit cet en-tête CSP :
    
 
-
    Content-Security-Policy: worker-src https://example.com/
    
+
    Content-Security-Policy: worker-src https://example.com/
    
 
 
    {{domxref("Worker")}}, {{domxref("SharedWorker")}} et {{domxref("ServiceWorker")}} seront bloqués et ne se chargeront pas :
    
 
-
    <script>
+
    <script>
   var blockedWorker = new Worker("data:application/javascript,...");
   blockedWorker = new SharedWorker("https://not-example.com/");
   navigator.serviceWorker.register('https://not-example.com/sw.js');
diff --git a/files/fr/web/http/headers/feature-policy/accelerometer/index.html b/files/fr/web/http/headers/feature-policy/accelerometer/index.html
index 370adce84c..20d123a97b 100644
--- a/files/fr/web/http/headers/feature-policy/accelerometer/index.html
+++ b/files/fr/web/http/headers/feature-policy/accelerometer/index.html
@@ -16,7 +16,7 @@ translation_of: Web/HTTP/Headers/Feature-Policy/accelerometer
 
 
    Syntaxe
    
 
-
    Feature-Policy: accelerometer <listePermissions>;
    
+
    Feature-Policy: accelerometer <listePermissions>;
    
 
 
    
  
    <listePermissions>
    
diff --git a/files/fr/web/http/headers/feature-policy/index.html b/files/fr/web/http/headers/feature-policy/index.html
index 597355cd84..355056996d 100644
--- a/files/fr/web/http/headers/feature-policy/index.html
+++ b/files/fr/web/http/headers/feature-policy/index.html
@@ -16,10 +16,10 @@ translation_of: Web/HTTP/Headers/Feature-Policy
 ---
 
    {{HTTPSidebar}}
    
 
-
    L'en-tête HTTP Feature-Policy est un mécanisme permettant de permettre ou d'interdire l'utilisation de fonctionnalités du navigateur dans son propre cadre et dans ceux de tous les éléments {{HTMLElement("iframe")}} que le document contient.
    
+
    L'en-tête HTTP Feature-Policy est un mécanisme permettant de permettre ou d'interdire l'utilisation de fonctionnalités du navigateur dans son propre cadre et dans ceux de tous les éléments {{HTMLElement("iframe")}} que le document contient.
    
 
 
    
-
    Cet en-tête est toujours au stade expérimental, et est sujet à être modifié à tout moment. Méfiez-vous en si vous souhaitez l'implanter sur vos sites. Il a maintenant été renommé Permissions-Policy dans la spécification, et cet article sera mis à jour pour refléter ce changement.
    
+
    Note : Cet en-tête est toujours au stade expérimental, et est sujet à être modifié à tout moment. Méfiez-vous en si vous souhaitez l'implanter sur vos sites. Il a maintenant été renommé Permissions-Policy dans la spécification, et cet article sera mis à jour pour refléter ce changement.
    
 
    
 
 
    Pour plus d'informations, vour l'article principal sur Feature Policy.
    
@@ -39,7 +39,7 @@ translation_of: Web/HTTP/Headers/Feature-Policy
 
 
    Syntaxe
    
 
-
    Feature-Policy: <directive> <allowlist>
    
+
    Feature-Policy: <directive> <allowlist>
    
 
 
    
  
    <directive>
    
@@ -126,7 +126,7 @@ translation_of: Web/HTTP/Headers/Feature-Policy
 
 
    SecureCorp Inc. souhaite désactiver les API du microphone et de géolocalisation dans son application. Elle peut le faire en délivrant l'en-tête de réponse HTTP suivant pour définir une réglementation des fonctionnalités :
    
 
-
    Feature-Policy: microphone 'none'; geolocation 'none'
    
+
    Feature-Policy: microphone 'none'; geolocation 'none'
    
 
 
    En spécifiant la valeur 'none' pour liste des origines, les fonctionnalités auquel la valeur est appliquée seront désactivées pour tous les contextes de navigation (incluant tout les cadres <iframe>), quelle que soit leur origine.
    
 
diff --git a/files/fr/web/http/headers/index.html b/files/fr/web/http/headers/index.html
index 95bcc91ab5..3233fecdb2 100644
--- a/files/fr/web/http/headers/index.html
+++ b/files/fr/web/http/headers/index.html
@@ -83,13 +83,13 @@ translation_of: Web/HTTP/Headers
 
 
    
  
    {{HTTPHeader("Accept-CH")}} {{experimental_inline}}
    
- 
    les serveurs peuvent informer de leur niveau de support pour les Client Hints en utilisant l'en-tête Accept-CH ou en HTML avec l'élément <meta> ayant l'attribut http-equiv ([HTML5]).
    
+ 
    les serveurs peuvent informer de leur niveau de support pour les Client Hints en utilisant l'en-tête Accept-CH ou en HTML avec l'élément <meta> ayant l'attribut http-equiv ([HTML5]).
    
  
    {{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}
    
- 
    les serveurs peuvent demander au client de mémoriser l'ensemble des Client Hints que le serveur supporte pour une période de temps donnée, afin de permettre la livraison de Client Hints sur les requêtes suivantes vers l'origine du serveur ([RFC6454]).
    
+ 
    les serveurs peuvent demander au client de mémoriser l'ensemble des Client Hints que le serveur supporte pour une période de temps donnée, afin de permettre la livraison de Client Hints sur les requêtes suivantes vers l'origine du serveur ([RFC6454]).
    
  
    {{HTTPHeader("Content-DPR")}} {{experimental_inline}}
    
  
    un nombre indiquant le rapport entre le nombre de pixels physiques et le nombre de pixels CSS de l'image réponse sélectionnée.
    
  
    {{HTTPHeader("DPR")}} {{experimental_inline}}
    
- 
    un nombre indiquant le Device Pixel Ratio (DPR) actuel du client, qui est le rapport du nombre de pixels physiques sur le nombre de pixels CSS (Section 5.2 of [CSSVAL]) de la zone d'affichage (Section 9.1.1 of [CSS2]) sur l'appareil.
    
+ 
    un nombre indiquant le Device Pixel Ratio (DPR) actuel du client, qui est le rapport du nombre de pixels physiques sur le nombre de pixels CSS (Section 5.2 of [CSSVAL]) de la zone d'affichage (Section 9.1.1 of [CSS2]) sur l'appareil.
    
  
    {{HTTPHeader("Device-Memory")}} {{experimental_inline}}
    
  
    faisant techniquement partie de l'API Device Memory, cet en-tête représente la quantité approximative de mémoire vive dont le client dispose.
    
  
    {{HTTPHeader("Early-Data")}} {{experimental_inline}}
    
@@ -97,11 +97,9 @@ translation_of: Web/HTTP/Headers
  
    {{HTTPHeader("Save-Data")}} {{experimental_inline}}
    
  
    booléen indiquant les préférences de l'agent utilisateur pour réduire la quantité de données transmises.
    
  
    {{HTTPHeader("Viewport-Width")}} {{experimental_inline}}
    
- 
    la largeur de la zone d'affichage, soit le nombre de pixels CSS. La valeur fournise est arrondie au plus grand proche supérieur.
    
- 
    Si Viewport-Width apparait dans un message plus d'une fois, la dernière valeur écrase toutes les valeurs précédentes.
    
+ 
    la largeur de la zone d'affichage, soit le nombre de pixels CSS. La valeur fournise est arrondie au plus grand proche supérieur. Si Viewport-Width apparait dans un message plus d'une fois, la dernière valeur écrase toutes les valeurs précédentes.
    
  
    {{HTTPHeader("Width")}} {{experimental_inline}}
    
- 
    l'en-tête de requête Width représente la largeur de la ressource voulue en nombre de pixels physiques. La valeur fournise est arrondie au plus proche entier supérieur.
    
- 
    Si la largeur de la ressource voulue est inconnue quand la requête ou la ressource n'a pas de largeur d'affichage, l'en-tête Width peut être omise. Si Width apparait dans un message plus d'une fois, la dernière valeur écrase toutes les valeurs précédentes.
    
+ 
    l'en-tête de requête Width représente la largeur de la ressource voulue en nombre de pixels physiques. La valeur fournise est arrondie au plus proche entier supérieur. Si la largeur de la ressource voulue est inconnue quand la requête ou la ressource n'a pas de largeur d'affichage, l'en-tête Width peut être omise. Si Width apparait dans un message plus d'une fois, la dernière valeur écrase toutes les valeurs précédentes.
    
 
    
 
 
    Conditionnels
    
diff --git a/files/fr/web/http/headers/location/index.html b/files/fr/web/http/headers/location/index.html
index ce0c29f00f..2a6447e69e 100644
--- a/files/fr/web/http/headers/location/index.html
+++ b/files/fr/web/http/headers/location/index.html
@@ -35,7 +35,7 @@ translation_of: Web/HTTP/Headers/Location
 
 
    Syntaxe
    
 
-
    Location: <url>
+
    Location: <url>
 
    
 
 
    Directives
    
@@ -47,7 +47,7 @@ translation_of: Web/HTTP/Headers/Location
 
 
    Exemples
    
 
-
    Location: /index.html
    
+
    Location: /index.html
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/headers/referer/index.html b/files/fr/web/http/headers/referer/index.html
index 085e7602c5..17a4b3cbd9 100644
--- a/files/fr/web/http/headers/referer/index.html
+++ b/files/fr/web/http/headers/referer/index.html
@@ -14,7 +14,7 @@ translation_of: Web/HTTP/Headers/Referer
 
    L'en-tête de requête Referer contient l'adresse de la page web précédente à partir de laquelle un lien a été suivi pour demander la page courante. L'en-tête Referer permet aux serveurs d'identifier la provenance des visiteurs d'une page et cette information peut être utilisée à des fins d'analyse, de journalisation ou pour améliorer la politique de cache par exemple.
    
 
 
    
-
    Important : Bien que cet en-tête puisse être utilisé à de nombreuses fins légitimes, il peut avoir des effets indésirables sur la sécurité et la vie privée. Voir la page Questions de sécurité et de vie privée : quid de l'en-tête referer pour plus d'informations et des méthodes d'atténuation.
    
+
    Attention : Bien que cet en-tête puisse être utilisé à de nombreuses fins légitimes, il peut avoir des effets indésirables sur la sécurité et la vie privée. Voir la page Questions de sécurité et de vie privée : quid de l'en-tête referer pour plus d'informations et des méthodes d'atténuation.
    
 
    
 
 
    Note : le terme referer est orthographié ainsi bien qu'il s'agisse d'une erreur à partir du mot anglais "referrer". Voir {{interwiki("wikipedia", "HTTP_referer", "L'en-tête referer HTTP sur Wikipédia")}} pour plus de détails.
    
diff --git a/files/fr/web/http/headers/referrer-policy/index.html b/files/fr/web/http/headers/referrer-policy/index.html
index b439879863..0020ea23fb 100644
--- a/files/fr/web/http/headers/referrer-policy/index.html
+++ b/files/fr/web/http/headers/referrer-policy/index.html
@@ -16,7 +16,7 @@ translation_of: Web/HTTP/Headers/Referrer-Policy
 ---
 
    {{HTTPSidebar}}
    
 
-
    L'en-tête {{glossary("HTTP header")}} Referrer-Policy contrôle la quantité d'informations sur le référent (referrer) (envoyées par l'en-tête {{HTTPHeader("Referer")}}) incluses dans la requête.
    
+
    L'en-tête {{glossary("HTTP header")}} Referrer-Policy contrôle la quantité d'informations sur le référent (referrer) (envoyées par l'en-tête {{HTTPHeader("Referer")}}) incluses dans la requête.
    @@ -33,11 +33,11 @@ translation_of: Web/HTTP/Headers/Referrer-Policy

    Syntaxe

    -
    -

    Le nom originel de l'en-tête, {{HTTPHeader("Referer")}}, est une faute de frappe du mot anglais "referrer". L'en-tête Referrer-Policy ne comporte pas cette erreur.

    +
    +

    Note : Le nom originel de l'en-tête, {{HTTPHeader("Referer")}}, est une faute de frappe du mot anglais "referrer". L'en-tête Referrer-Policy ne comporte pas cette erreur.

    -
    Referrer-Policy: no-referrer
+
    Referrer-Policy: no-referrer
 Referrer-Policy: no-referrer-when-downgrade
 Referrer-Policy: origin
 Referrer-Policy: origin-when-cross-origin
@@ -54,7 +54,9 @@ Referrer-Policy: unsafe-url
  
    L'en-tête {{HTTPHeader("Referer")}} sera entièrement omis. Aucune information sur le référent ne sera envoyée avec les requêtes.
    
  
    no-referrer-when-downgrade (default)
    
  
    C'est le comportement par défaut si aucune valeur n'est spécifiée ou quelle celle donnée est invalide. L'{{glossary("origin")}}, le {{glossary("path")}}, et la {{glossary("querystring")}} de l'URL sont envoyés comme référent quand le niveau de sécurité du protocole reste le même (HTTP vers HTTP, HTTPS vers HTTPS) ou s'améliore (HTTP vers HTTPS) mais ne sont pas envoyés quand si la destination est moins sécurisée (HTTPS vers HTTP).
- 
    Les navigateurs tentent d'adopter une valeur par défaut plus stricte, précisément strict-origin-when-cross-origin (voir https://github.com/whatwg/fetch/pull/952), envisagez d'utiliser cette valeur (ou une autre encore plus stricte) si possible si vous définissez la valeur de Referrer-Policy.
    
+  
    
+   
    Note : Les navigateurs tentent d'adopter une valeur par défaut plus stricte, précisément strict-origin-when-cross-origin (voir https://github.com/whatwg/fetch/pull/952), envisagez d'utiliser cette valeur (ou une autre encore plus stricte) si possible si vous définissez la valeur de Referrer-Policy.
    
+  
    
  
    
  
    origin
    
  
    N'envoie que l'{{glossary("origin")}} du document comme référent.
    
@@ -69,8 +71,8 @@ Referrer-Policy: unsafe-url
  
    Envoie l'origine, le chemin et les paramètres de requête pour les requêtes de même origine, n'envoie que l'origine quand le niveau de sécurité du protocole reste le même pour les requêtes vers des adresses externes (HTTPS vers HTTPS) et n'envoie rien si la destination est moins sécurisée (HTTPS vers HTTP).
    
  
    unsafe-url
    
  
    Envoie l'origine, le chemin et les paramètres de requête pour toutes les requêtes sans tenir compte du niveau de sécurité.
- 
    
- 
    Cette valeur divulgera des informations potentiellement confidentielles de la part des URL de ressources HTTPS vers des origines non sécurisées. Considérez les conséquences de ce paramétrage avant de vous en servir.
    
+ 
    
+ 
    Attention : Cette valeur divulgera des informations potentiellement confidentielles de la part des URL de ressources HTTPS vers des origines non sécurisées. Considérez les conséquences de ce paramétrage avant de vous en servir.
    
  
    
  
    
 
@@ -79,18 +81,18 @@ Referrer-Policy: unsafe-url
 
 
    Vous pouvez aussi définir des règles de référent au sein d'HTML. Par exemple, vous pouvez définir la règle de référent pour le document entier avec un élément {{HTMLElement("meta")}} dont le name est referrer :
    
 
-
    <meta name="referrer" content="origin">
    
+
    <meta name="referrer" content="origin">
    
 
 
    Ou le définit pour des requêtes spécifiques avec l'attribut referrerpolicy sur les éléments {{HTMLElement("a")}}, {{HTMLElement("area")}}, {{HTMLElement("img")}}, {{HTMLElement("iframe")}}, {{HTMLElement("script")}}, ou {{HTMLElement("link")}} :
    
 
-
    <a href="http://example.com" referrerpolicy="origin">
    
+
    <a href="http://example.com" referrerpolicy="origin">
    
 
 
    Autrement, une relation de lien définie à noreferrer sur un élément a, area, ou link peut être défini :
    
 
-
    <a href="http://example.com" rel="noreferrer">
    
+
    <a href="http://example.com" rel="noreferrer">
    
 
-
    
-
    Comme vu précédemment, la relation de lien noreferrer s'écrit sans trait d'union. Toutefois, quand la règle de référent est spécifiée pour le document entier avec un élément {{HTMLElement("meta")}}, il faut mettre le trait d'union : <meta name="referrer" content="no-referrer">.
    
+
    
+
    Attention : Comme vu précédemment, la relation de lien noreferrer s'écrit sans trait d'union. Toutefois, quand la règle de référent est spécifiée pour le document entier avec un élément {{HTMLElement("meta")}}, il faut mettre le trait d'union : <meta name="referrer" content="no-referrer">.
    
 
    
 
 
    Intégration avec CSS
    
@@ -206,11 +208,13 @@ Referrer-Policy: unsafe-url
 
 
    Si vous voulez spécifier une règle à appliquer par défaut dans les où la règle voulue n'est pas supportée par les navigateurs, utilisez un liste de valeurs séparées par des virgules avec la règle voulue fournie en dernière position :
    
 
-
    Referrer-Policy: no-referrer, strict-origin-when-cross-origin
    
+
    Referrer-Policy: no-referrer, strict-origin-when-cross-origin
    
 
 
    Ici, no-referrer ne sera utilisée que si strict-origin-when-cross-origin n'est pas supportée par le navigateur.
    
 
-
    Spécifier plusieurs valeurs n'est supporté que dans l'en-tête HTTP Referrer-Policy et non dans l'attribut referrerpolicy.
    
+
    
+  
    Note : Spécifier plusieurs valeurs n'est supporté que dans l'en-tête HTTP Referrer-Policy et non dans l'attribut referrerpolicy.
    
+
    
 
 
    Spécifications
    
 
@@ -234,8 +238,9 @@ Referrer-Policy: unsafe-url
 
    {{Compat("http.headers.Referrer-Policy")}}
    
 
 
    
+  
    Note :
    
 
      
- 
    • Version 53 et plus, Gecko offre la possibilité aux utilisateurs de définir leur valeur par défaut de Referrer-Policy dans about:config, l'option s'appelant  network.http.referer.userControlPolicy.
      • 
+ 
    • Version 53 et plus, Gecko offre la possibilité aux utilisateurs de définir leur valeur par défaut de Referrer-Policy dans about:config, l'option s'appelant  network.http.referer.userControlPolicy.
      • 
  
    • Version 59 et plus (Voir #587523), il a été remplacé par network.http.referer.defaultPolicy et network.http.referer.defaultPolicy.pbmode.
      • 
 
    
 
@@ -254,7 +259,7 @@ Referrer-Policy: unsafe-url
 
      
  
    • {{interwiki("wikipedia", "HTTP_referer", "HTTP referer on Wikipedia")}}
      • 
  
    • En utilisant Fetch : {{domxref("Request.referrerPolicy")}}
      • 
- 
    • La directive obsolète {{HTTPHeader("Content-Security-Policy/referrer", "referrer")}} {{Obsolete_Inline}} de l'en-tête {{HTTPHeader("Content-Security-Policy")}}.
      • 
+ 
    • La directive obsolète {{HTTPHeader("Content-Security-Policy/referrer", "referrer")}} {{Obsolete_Inline}} de l'en-tête {{HTTPHeader("Content-Security-Policy")}}.
      • 
  
    • Same-origin policy
      • 
  
    • 
   
      Tighter Control Over Your Referrers – Mozilla Security Blog
      
diff --git a/files/fr/web/http/headers/server/index.html b/files/fr/web/http/headers/server/index.html
index d29601ba61..5aa0a27da7 100644
--- a/files/fr/web/http/headers/server/index.html
+++ b/files/fr/web/http/headers/server/index.html
@@ -14,7 +14,7 @@ original_slug: Web/HTTP/Headers/Serveur
 
 
      Le paramètre d'entête Server contient des informations à propos du système (ou sous-système) en place sur le serveur qui s'occupe de la requête.
      
 
-
      Il est préférable d'éviter les valeurs excessivement longues et/ou détaillées : elles peuvent révéler des détails internes qui pourraient rendre (un peu) plus facile une attaque et l'exploitation d'une éventuelle faille de sécurité.
      
+
      Il est préférable d'éviter les valeurs excessivement longues et/ou détaillées : elles peuvent révéler des détails internes qui pourraient rendre (un peu) plus facile une attaque et l'exploitation d'une éventuelle faille de sécurité.
    @@ -38,7 +38,7 @@ original_slug: Web/HTTP/Headers/Serveur
    <valeur>
    -
    Le nom du système (ou sous-système) qui gère les requêtes.
    +
    Le nom du système (ou sous-système) qui gère les requêtes.

    Exemples

    @@ -64,7 +64,7 @@ original_slug: Web/HTTP/Headers/Serveur

    {{Compat("http.headers.Server")}}

    -

    Voir également

    +

    Voir également

    @@ -83,7 +83,7 @@ Expires: Wed, 21 Oct 2015 07:28:00 GMT
    -

    Compatibilités

    +

    Compatibilités

    {{Compat("http/headers/trailer")}}

    diff --git a/files/fr/web/http/headers/vary/index.html b/files/fr/web/http/headers/vary/index.html index 9cacf3ee12..9686318de5 100644 --- a/files/fr/web/http/headers/vary/index.html +++ b/files/fr/web/http/headers/vary/index.html @@ -30,7 +30,7 @@ translation_of: Web/HTTP/Headers/Vary

    Syntaxe

    -
    Vary: *
+
    Vary: *
 Vary: <header-name>, <header-name>, ...
 
    
 
@@ -49,7 +49,7 @@ Vary: <header-name>, <header-name>, ...
 
 
    Lorsque l'en-tête Vary: User-Agent est utilisée, les serveurs de cache doivent prendre en compte l'agent de l'utilisateur pour décider de servir la page depuis le cache ou non. Par exemple, si vous servez du contenu différent pour les utilisateurs sur mobile, il aide à éviter qu'une version ordinateur de votre site ne soit distribuée à un utilisateur sur mobile. Il peut aider google et d'autres moteurs de recherche à prendre en compte la version pour mobile d'un site, ainsi que de signaler que le Cloaking n'est pas intentionel.
    
 
-
    Vary: User-Agent
    
+
    Vary: User-Agent
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/headers/x-content-type-options/index.html b/files/fr/web/http/headers/x-content-type-options/index.html
index 3ece5740a7..cadeb86472 100644
--- a/files/fr/web/http/headers/x-content-type-options/index.html
+++ b/files/fr/web/http/headers/x-content-type-options/index.html
@@ -16,7 +16,9 @@ translation_of: Web/HTTP/Headers/X-Content-Type-Options
 
 
    Les testeurs de sécurité du site s'attendent généralement à ce que cet en-tête soit défini.
    
 
-
    Note: X-Content-Type-Options ne s'appliquent qu'au blocage des demandes par nosniff pour les destinations de demandes de  "script" et "style". Il permet également le blocage en lecture croisé (CORB) pour les fichiers HTML, TXT, JSON, et XML (à l'exception des images SVG image/svg+xml).
    
+
    
+  
    Note : X-Content-Type-Options ne s'appliquent qu'au blocage des demandes par nosniff pour les destinations de demandes de  "script" et "style". Il permet également le blocage en lecture croisé (CORB) pour les fichiers HTML, TXT, JSON, et XML (à l'exception des images SVG image/svg+xml).
    
+
    
 
 
@@ -40,14 +42,12 @@ translation_of: Web/HTTP/Headers/X-Content-Type-Options
 
 
    
  
    nosniff
    
- 
    
- 
    Bloque une requête si la destination de la requête est de type
+ 
    Bloque une requête si la destination de la requête est de type
    
  
      
   
    • "style" et le MIME n'est pas de type text/css, ou
      • 
   
    • "script" et le MIME n'est pas de type JavaScript MIME type
      • 
  
    
- 
    
- 
    Permet le blocage de la lecture croisée pour les types MIME
+ 
    Permet le blocage de la lecture croisée pour les types MIME
    
  
      
   
    • text/html
      • 
   
    • text/plain
      • 
diff --git a/files/fr/web/http/headers/x-frame-options/index.html b/files/fr/web/http/headers/x-frame-options/index.html
index 6569babd24..b47e3918b5 100644
--- a/files/fr/web/http/headers/x-frame-options/index.html
+++ b/files/fr/web/http/headers/x-frame-options/index.html
@@ -15,7 +15,7 @@ translation_of: Web/HTTP/Headers/X-Frame-Options
 
      Ce complément de sécurité est uniquement valable lorsque l'utilisateur final visite le document avec un navigateur prenant en charge X-Frame-Options.
      
 
 
      
-
      Note : L'en-tête {{HTTPHeader("Content-Security-Policy")}} possède une directive frame-ancestors qui supplante cet en-tête pour les navigateurs compatibles.
      
+
      Note : L'en-tête {{HTTPHeader("Content-Security-Policy")}} possède une directive frame-ancestors qui supplante cet en-tête pour les navigateurs compatibles.
      
 
      
 
 
    
  
    
diff --git a/files/fr/web/http/link_prefetching_faq/index.html b/files/fr/web/http/link_prefetching_faq/index.html
index a6f603701d..a2e02a0876 100644
--- a/files/fr/web/http/link_prefetching_faq/index.html
+++ b/files/fr/web/http/link_prefetching_faq/index.html
@@ -9,7 +9,7 @@ tags:
 translation_of: Web/HTTP/Link_prefetching_FAQ
 original_slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens
 ---
-
    Qu’est ce que le préchargement de liens ?
    
+
    Qu’est ce que le préchargement de liens ?
    Le préchargement de liens est un mécanisme du navigateur qui utilise le temps disponible du navigateur pour télécharger ou précharger les documents que les utilisateurs pourraient visiter juste après. Une page web fournit un ensemble de cibles à précharger au navigateur. Une fois que le navigateur a fini de charger la page, il commence, de façon transparente, à précharger les documents spécifiés et les emmagasine dans son cache. Quand l’utilisateur visite un de ces documents préchargés, il peut être ressorti rapidement du cache du navigateur.
    
 
@@ -17,7 +17,7 @@ original_slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens
 
 
    À partir de Gecko 1.9.1 (Firefox 3.5), le contenu HTTPS peut être préchargé.
    
 
-
    Quelles sont les cibles à précharger ?
    
+
    Quelles sont les cibles à précharger ?
    Le navigateur cherche soit une balise HTML link, soit un en-tête HTTP Link: avec un type de relation next ou prefetch. Ci-dessous, un exemple d’utilisation de la balise link :
    
 
@@ -36,7 +36,9 @@ original_slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens
 
 
    Le format pour l’en-tête Link:est décrit dans le RFC 2068 section 19.6.2.4.
    
 
-
    Note : Nous avons intentionnellement pris pour référence une version dépassée de la spécification HTTP/1.1 car la plus récente RFC 2616 ne décrit pas l’en-tête Link:. Bien que les en-têtes Link: ne fassent pas partie du standard révisé, ils sont toujours utilisés en pratique par les serveurs, pour renseigner les feuilles de styles CSS. Donc nous faisons usage de la même fonction ici.
    
+
    
+  
    Note : Nous avons intentionnellement pris pour référence une version dépassée de la spécification HTTP/1.1 car la plus récente RFC 2616 ne décrit pas l’en-tête Link:. Bien que les en-têtes Link: ne fassent pas partie du standard révisé, ils sont toujours utilisés en pratique par les serveurs, pour renseigner les feuilles de styles CSS. Donc nous faisons usage de la même fonction ici.
    
+
    Le navigateur surveille toutes ces cibles et met en attente chaque requête unique qui doit ensuite être préchargée quand le navigateur est disponible. Il peut y avoir de multiples cibles par page, ainsi on peut comprendre l'utilité de précharger de multiples documents. Par exemple, le document suivant peut contenir plusieurs images lourdes.
    
 
@@ -46,41 +48,41 @@ original_slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens
 <link rel="next" href="2.html">
 
 
-
    Les balises ancres (<a>) sont-elles préchargées ?
    
+
    Les balises ancres (<a>) sont-elles préchargées ?
    Non, seulement les balises <link> avec une relation de type next ou prefetch sont préchargées. Toutefois, si l'intérêt en est suffisant, on peut étendre le support du préchargement de liens pour inclure le préchargement des balises <a>, lesquelles devront inclure un type de relation next ou prefetch. Cela aiderait probablement les fournisseurs de contenus à éviter le problème du préchargement de liens morts.
    
 
-
    Le préchargement de liens est-il respectueux des standards ?
    
+
    Le préchargement de liens est-il respectueux des standards ?
    Oui, le préchargement de liens, comme exposé dans ce document, ne viole aucun standard Web existant. En fait, la spécification HTML 4.01 prend explicitement en compte la définition de nouveaux types de relation pour les liens (Section 6.12: types de liens (fr)). Toutefois, le mécanisme exact employé par Mozilla n’est pas encore standardisé. Une ébauche de spécification est en cours.
    
 
-
    Comment le temps disponible du navigateur est-il déterminé ?
    
+
    Comment le temps disponible du navigateur est-il déterminé ?
    Dans l’implémentation actuelle (Mozilla 1.2), le temps disponible est déterminé par l’utilisation de l’API nsIWebProgressListener. On attache un écouteur à l’objet de haut-niveau nsIWebProgress ("@mozilla.org/docloaderservice;1"). De celui-ci, on reçoit les notifications de lancement et d’arrêt du document et nous estimons le temps disponible comme étant la période entre l’arrêt du dernier document et le lancement du document suivant. La dernière notification d’arrêt apparaît à peu près lorsque le gestionnaire onLoad se lance pour le document parent. C’est à ce moment que démarrent les requêtes de préchargement. Si une sous-frame contient des cibles à précharger, le préchargement ne commencera que lorsque la frame la plus haute et toutes ses frames filles auront fini de charger.
    
 
-
    Que se passe-t-il si je clique sur un lien pendant un préchargement ?
    
+
    Que se passe-t-il si je clique sur un lien pendant un préchargement ?
    Quand un utilisateur clique sur un lien ou initie toutes sortes de chargements de page, le préchargement des liens s’arrête et les préchargements de cibles sont abandonnés. Si un document préchargé est partiellement stocké, alors il est emmagasiné dans le cache à condition que le serveur envoie un en-tête de réponse de type Accept-Ranges: bytes. Cet en-tête est typiquement généré par les serveurs web quand ils gèrent du contenu statique. Quand l’utilisateur visite réellement un document préchargé, la portion restante est chargée en utilisant une requête HTTP byte-range.
    
 
-
    Et si je télécharge quelque chose en tâche de fond ? Le préchargement de liens viendra-t-il en concurrence pour la bande passante ?
    
+
    Et si je télécharge quelque chose en tâche de fond ? Le préchargement de liens viendra-t-il en concurrence pour la bande passante ?
    Oui et non. Si vous téléchargez quelque chose en utilisant Mozilla, le préchargement de liens sera retardé jusqu'à ce que les téléchargements en arrière-plan soit complets. Par exemple, si vous chargez un groupe de marque-pages (qui ouvre plusieurs onglets), toutes les requêtes de préchargement initiées par une de ces marque-pages ne se lanceront que lorsque tous les onglets auront fini de se charger. Si vous avez lancé une autre application qui utilise le réseau, le préchargement de liens dans Mozilla sera en compétition pour la bande passante, avec l’autre application. C’est un problème que nous espérons régler dans le futur en s’appuyant sur les services du système d’exploitation pour contrôler le temps disponible sur le réseau.
    
 
-
    Existe-t-il des restrictions sur ce qui peut être préchargé ?
    
+
    Existe-t-il des restrictions sur ce qui peut être préchargé ?
    Oui, uniquement les URL http:// (et, à partir de {{ Gecko("1.9.1") }}, https://) peuvent être préchargées. Les autres protocoles (comme FTP) ne fournissent pas de support suffisamment riche pour la gestion du cache côté client. En plus de cette restriction, les URL ayant une chaîne de paramètres ne sont pas préchargées. Ceci parce que de telles URL sont souvent dans des documents qui ne peuvent pas être réutilisés en dehors du cache du navigateur. Donc précharger de telles URL n’apporterait pas grand chose. Nous avons constaté que des sites existants utilisent la balise <link rel="next"> avec des URL contenant des chaînes de paramètres pour référencer le document suivant dans une série de documents. Bugzilla est un de ces sites et il s'avère que les rapports de bug dans Bugzilla ne peuvent être mis en cache, aussi précharger ces URL reviendrait à peu près à doubler la charge de ce pauvre Bugzilla ! On peut se douter que d’autres sites ont été conçus comme Bugzilla donc on ne fait explicitement pas de préchargement d’URL contenant des chaînes de paramètres. (Il pourrait être sensé d’autoriser le préchargement de ces documents avec une relation de type rel=prefetch, puisque cela n'apparait pas dans aucun contenu existant). Il n’y a pas d’autres restrictions en ce qui concerne les URL préchargées.
    
 
-
    Mozilla peut-il précharger un document d’un hôte différent ?
    
+
    Mozilla peut-il précharger un document d’un hôte différent ?
    Oui. Il n’est pas nécessaire que les documents aient la même origine pour le préchargement de liens. Limiter le préchargement uniquement à des URL du même serveur n’augmenterait pas la sécurité du navigateur.
    
 
-
    Les requêtes préchargées contiennent-elles un en-tête Referer: ?
    
+
    Les requêtes préchargées contiennent-elles un en-tête Referer: ?
    Oui, les requêtes préchargées incluent une entête HTTP Referer: qui indique le document duquel la cible de préchargement a été extraite.
    Cela peut impacter l'analyse de l'affluence qui est communément utilisée sur de nombreux sites. Pour cette raison, le préchargement de liens peut ne pas être approprié pour toutes sortes de contenus. Toutefois, il est possible de contraindre Mozilla à valider un document préchargé quand l'utilisateur suit un href vers le document préchargé en spécifiant un en-tête de réponse HTTP Cache-control: must-revalidate. Cet en-tête permet la mise en cache mais requiert une requête de validation If-Modified-Since ou If-None-Match pour que le document soit servi à partir du cache du navigateur.
    
 
-
    En tant qu'administrateur serveur, puis-je distinguer les requêtes préchargées, des requêtes normales ?
    
+
    En tant qu'administrateur serveur, puis-je distinguer les requêtes préchargées, des requêtes normales ?
    Oui, l'en-tête suivant est envoyé avec chaque requête préchargée :
    
 
@@ -89,7 +91,7 @@ original_slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens
 
 
    Bien sûr, cet en-tête de requête n'est absolument pas standardisé et il peut changer dans les futures versions de Mozilla.
    
 
-
    Existe-t-il une préférence pour désactiver le préchargement de liens ?
    
+
    Existe-t-il une préférence pour désactiver le préchargement de liens ?
    Oui, il existe une préférence cachée pour désactiver le préchargement de liens. Ajoutez cette ligne dans votre fichier prefs.js qui se trouve dans votre répertoire de profil (ou faite le changement approprié via about:config) :
    
 
@@ -98,7 +100,7 @@ original_slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens
 
 
    Toutefois, la théorie est que si le préchargement de liens a besoin d'être désactivé c'est qu'il doit y avoir un problème dans l'implémentation. On doit améliorer l'implémentation si ça ne marche pas correctement plutôt que d'attendre que l'utilisateur trouve et modifie une obscure préférence.
    
 
-
    Et pour les gens qui payent à la bande passante utilisée ?
    
+
    Et pour les gens qui payent à la bande passante utilisée ?
    En fait, il y a deux façons d'aborder ce problème :
    
 
@@ -109,27 +111,23 @@ original_slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens
 
 
    Il est important que les sites web adoptent la balise <link> pour le préchargement, plutôt que d'essayer d'initier le chargement en tâche de fond avec des hacks JS/DOM. La balise <link> donne au navigateur la capacité de savoir quels sites sont à charger et on peut utiliser cette information pour améliorer le système de priorité du préchargement des liens. La préférence utilisateur pour désactiver le préchargement par la balise <link> encourage simplement les sites Web à s'abstenir d'utiliser des hacks JS/DOM. Cela n'apporterait rien de positif aux utilisateurs. C'est une des raisons pour lesquelles le préchargement est activé par défaut.
    
 
-
    Quels navigateurs supportent le préchargement de liens ?
    
+
    Quels navigateurs supportent le préchargement de liens ?
    Les navigateurs basés sur Mozilla 1.2 (ou +) aussi bien que ceux basés sur Mozilla 1.0.2 (ou +) supportent le préchargement. Cela inclut Firefox et Netscape 7.02+. Les compilations Camino, en Mars 2003, sont basées sur Mozilla 1.0.1 et donc ne supportent pas le préchargement. Testez votre navigateur pour vérifier s'il supporte le préchargement de liens.
    
 
-
    D'autres questions ?
    
+
    D'autres questions ?
    Si vous avez des questions ou des commentaires sur le préchargement de liens, n'hésitez pas à me les envoyer :-)
    
 
-
    Voir également
    
+
    Voir également
    
 
-
    
-
    Informations sur le document original
    
+
    Informations sur le document original
    
 
 
      
- 
    • Auteur(s) : Darin Fisher (darin@meer.net)
      • 
+ 
    • Auteur(s) :Darin Fisher (darin at meer dot net)
      • 
  
    • Date de dernière mise à jour : 3 mars 2003
      • 
 
    
-
    
-
-
    {{ languages( { "en": "en/Link_prefetching_FAQ", "it": "it/Link_prefetching_FAQ", "ja": "ja/Link_prefetching_FAQ" } ) }}
    
diff --git a/files/fr/web/http/methods/connect/index.html b/files/fr/web/http/methods/connect/index.html
index db70367783..08e8ec6a12 100644
--- a/files/fr/web/http/methods/connect/index.html
+++ b/files/fr/web/http/methods/connect/index.html
@@ -54,7 +54,7 @@ original_slug: Web/HTTP/Méthode/CONNECT
 
 
    Certains serveurs proxy pourraient avoir besoin d'une autorisation pour créer un tunnel. Voir aussi l'en-tête {{HTTPHeader("Proxy-Authorization")}}.
    
 
-
    CONNECT server.example.com:80 HTTP/1.1
+
    CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80
 Proxy-Authorization: basic aGVsbG86d29ybGQ=
    
 
diff --git a/files/fr/web/http/methods/patch/index.html b/files/fr/web/http/methods/patch/index.html
index 0f6c6bf8e6..79eb5d483d 100644
--- a/files/fr/web/http/methods/patch/index.html
+++ b/files/fr/web/http/methods/patch/index.html
@@ -50,7 +50,7 @@ original_slug: Web/HTTP/Méthode/PATCH
 
 
    Requête
    
 
-
    PATCH /file.txt HTTP/1.1
+
    PATCH /file.txt HTTP/1.1
 Host: www.example.com
 Content-Type: application/example
 If-Match: "e0023aa4e"
@@ -62,7 +62,7 @@ Content-Length: 100
 
 
    Une requête traitée avec succès retourne une réponse accompagnée d'un code de réponse {{HTTPStatus("204")}}. Dans ce cas-ci, la réponse ne contient un corps de message.
    
 
-
    HTTP/1.1 204 No Content
+
    HTTP/1.1 204 No Content
 Content-Location: /file.txt
 ETag: "e0023aa4f"
    
 
diff --git a/files/fr/web/http/methods/post/index.html b/files/fr/web/http/methods/post/index.html
index 82bd30d64f..a40217492e 100644
--- a/files/fr/web/http/methods/post/index.html
+++ b/files/fr/web/http/methods/post/index.html
@@ -69,7 +69,7 @@ original_slug: Web/HTTP/Méthode/POST
 
 
    Un formulaire simple utilisant le type de contenu par défaut application/x-www-form-urlencoded :
    
 
-
    POST / HTTP/1.1
+
    POST / HTTP/1.1
 Host: foo.com
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 13
diff --git a/files/fr/web/http/methods/trace/index.html b/files/fr/web/http/methods/trace/index.html
index 50422020f7..d095495f3c 100644
--- a/files/fr/web/http/methods/trace/index.html
+++ b/files/fr/web/http/methods/trace/index.html
@@ -45,7 +45,7 @@ original_slug: Web/HTTP/Méthode/TRACE
 
 
    Syntaxe
    
 
-
    TRACE /index.html
+
    TRACE /index.html
 
    
 
 
    Specifications
    
diff --git a/files/fr/web/http/overview/index.html b/files/fr/web/http/overview/index.html
index b1d9916b04..ff6c0c8b68 100644
--- a/files/fr/web/http/overview/index.html
+++ b/files/fr/web/http/overview/index.html
@@ -11,13 +11,13 @@ original_slug: Web/HTTP/Aperçu
 ---
 
    {{HTTPSidebar}}
    
 
-
    HTTP est un {{glossary("protocole")}} qui permet de récupérer des ressources telles que des documents HTML. Il est à la base de tout échange de données sur le Web. C'est un protocole de type client-serveur, ce qui signifie que les requêtes sont initiées par le destinataire (qui est généralement un navigateur web). Un document complet est construit à partir de différents sous-documents qui sont récupérés, par exemple du texte, des descriptions de mise en page, des images, des vidéos, des scripts et bien plus.
    
+
    HTTP est un {{glossary("protocole")}} qui permet de récupérer des ressources telles que des documents HTML. Il est à la base de tout échange de données sur le Web. C'est un protocole de type client-serveur, ce qui signifie que les requêtes sont initiées par le destinataire (qui est généralement un navigateur web). Un document complet est construit à partir de différents sous-documents qui sont récupérés, par exemple du texte, des descriptions de mise en page, des images, des vidéos, des scripts et bien plus.
    
 
-
    Un document web se compose de différentes ressources
    
+
    Un document web se compose de différentes ressources
    
 
 
    Les clients et serveurs communiquent par l'échange de messages individuels (en opposition à un flux de données). Les messages envoyés par le client, généralement un navigateur web, sont appelés des requêtes et les messages renvoyés par le serveur sont appelés réponses.
    
 
-
    HTTP est un protocole de la couche d'application fonctionnant au-dessus de TCP (pour la couche de transport) et IP (pour la couche réseau). HTTP est en dessous de la couche de présentation. Conçu au début des années 1990, HTTP est un protocole extensible qui a évolué au cours du temps. C'est un protocole de la couche application dont les données transitent via {{glossary("TCP")}} ou à travers une connexion TCP chiffrée avec {{glossary("TLS")}}. En théorie, tout protocole de transport fiable pourrait être utilisé. En raison de son extensibilité, il n'est pas seulement utilisé pour récupérer des documents, mais aussi pour des images, des vidéos ou bien pour renvoyer des contenus vers des serveurs, comme des résultats de formulaires HTML. HTTP peut aussi être utilisé pour récupérer des parties de documents pour mettre à jour à la demande des pages web.
    
+
    HTTP est un protocole de la couche d'application fonctionnant au-dessus de TCP (pour la couche de transport) et IP (pour la couche réseau). HTTP est en dessous de la couche de présentation. Conçu au début des années 1990, HTTP est un protocole extensible qui a évolué au cours du temps. C'est un protocole de la couche application dont les données transitent via {{glossary("TCP")}} ou à travers une connexion TCP chiffrée avec {{glossary("TLS")}}. En théorie, tout protocole de transport fiable pourrait être utilisé. En raison de son extensibilité, il n'est pas seulement utilisé pour récupérer des documents, mais aussi pour des images, des vidéos ou bien pour renvoyer des contenus vers des serveurs, comme des résultats de formulaires HTML. HTTP peut aussi être utilisé pour récupérer des parties de documents pour mettre à jour à la demande des pages web.
    
 
 
    Composants des systèmes basés sur HTTP
    
 
@@ -25,7 +25,7 @@ original_slug: Web/HTTP/Aperçu
 
 
    Chaque requête individuelle est envoyée au serveur, qui la traite et fournit une réponse. Entre cette requête et la réponse se trouve de nombreuses entités qu'on désignera de façon générique sous le terme {{glossary("Proxy", "proxies")}}. Celles-ci exécutent différentes opérations et agissent comme passerelles ou comme {{glossary("Cache", "caches")}} par exemple.
    
 
-
    chaîne client serveur
    
+
    chaîne client serveur
    
 
 
    En réalité, il y a plus d'un ordinateur entre un navigateur et le serveur qui traite la requête : il y a les routeurs, les modems et bien plus. Grâce à la construction en couche du Web, ces intermédiaires sont cachés dans les couches réseau et transport. HTTP est bâti sur la couche applicative. Bien qu'elles puissent s'avérer importantes lorsqu'il s'agit de diagnostiquer des problèmes réseau, les couches inférieures ne sont pas pertinentes ici pour décrire HTTP.
    
 
@@ -107,12 +107,12 @@ original_slug: Web/HTTP/Aperçu
 
      
  
    1. Il ouvre une connexion TCP : la connexion TCP va être utilisée pour envoyer une ou plusieurs requêtes et pour recevoir une réponse. Le client peut ouvrir une nouvelle connexion, réutiliser une connexion existante ou ouvrir plusieurs connexions TCP vers le serveur.
      2. 
  
    2. Il envoie un message HTTP : les messages HTTP (avant HTTP/2) sont lisibles par les humains. Avec HTTP/2, ces simples messages sont en-capsulés dans des trames, rendant la lecture directe impossible, mais le principe reste le même.
-  
      GET / HTTP/1.1
+  
      GET / HTTP/1.1
 Host: developer.mozilla.org
 Accept-Language: fr
      
  
      3. 
  
    3. Il lit la réponse envoyée par le serveur :
-  
      HTTP/1.1 200 OK
+  
      HTTP/1.1 200 OK
 Date: Sat, 09 Oct 2010 14:28:02 GMT
 Server: Apache
 Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
@@ -138,7 +138,7 @@ Content-Type: text/html
 
 
      Un exemple de requête HTTP :
      
 
-
      Une requête HTTP basique
      
+
      Une requête HTTP basique
      
 
 
      Une requête comprend les éléments suivants :
      
 
@@ -154,7 +154,7 @@ Content-Type: text/html
 
 
      Un exemple de réponse :
      
 
-
      une réponse HTTP
      
+
      une réponse HTTP
      
 
 
      Une réponse comprend les éléments suivants:
      
 
diff --git a/files/fr/web/http/public_key_pinning/index.html b/files/fr/web/http/public_key_pinning/index.html
index 165ea5f0ca..b378e93471 100644
--- a/files/fr/web/http/public_key_pinning/index.html
+++ b/files/fr/web/http/public_key_pinning/index.html
@@ -8,7 +8,7 @@ tags:
 translation_of: Web/HTTP/Public_Key_Pinning
 original_slug: Web/Security/Public_Key_Pinning
 ---
-
      L'extention Public Key Pinning pour HTTP (HPKP) est une fonctionnalité de sécurité qui dit au client web d'associer une clé publique cryptographique avec un certain serveur web pour éviter les attaques MITM avec des certificats contrefaits.
      
+
      L'extention Public Key Pinning pour HTTP (HPKP) est une fonctionnalité de sécurité qui dit au client web d'associer une clé publique cryptographique avec un certain serveur web pour éviter les attaques MITM avec des certificats contrefaits.
      
 
 
      
 
      Note : La Public Key Pinning décrite ici est différente du limité preload list based key pinning introduit dans Firefox 32.
      
@@ -18,7 +18,9 @@ original_slug: Web/Security/Public_Key_Pinning
 
 
      HPKP est une technique qui s'appuie sur la confiance au premier accès (TOFU, Trust on First Use). La première fois un serveur web dit au client en utilisant l'en-tête HTTP HPKP quelles clés publiques lui appartiennent, le client sauvegarde cette information pour une période de temps donnée. Quand le client visite le serveur à nouveau, il s'attend à un certificat contenant une clé publique dont l'empreinte est sauvegardée. Si le serveur présente une clé publique inconnue, le client doit présenter un avertissement à l'utilisateur.
      
 
-
      Firefox (and Chrome) désactivent la vérification de l'épinglage lorsqu'un site épinglé présentent une chaine de certificats qui se termine par un certificat racine installé par l'utilisateur (et non un certificat racine de base).
      
+
      
+  
      Note : Firefox (et Chrome) désactivent la vérification de l'épinglage lorsqu'un site épinglé présentent une chaine de certificats qui se termine par un certificat racine installé par l'utilisateur (et non un certificat racine de base).
      
+
      
 
 
      Activer HPKP
      
 
@@ -51,8 +53,6 @@ original_slug: Web/Security/Public_Key_Pinning
 
 
      
 
-
       
      
-
 
      Extraire la clé publique encodé en Base64
      
 
 
      En premier, vous devez extraire la clé publique depuis votre fichier de certificats ou de clés puis l'encoder en base 64.
      
@@ -80,7 +80,7 @@ original_slug: Web/Security/Public_Key_Pinning
 
      Les étapes concrètes nécessaires pour délivrer l'en-tête HPKP dépendent du serveur web que vous utilisez.
      
 
 
      
-
      Note: Ces exemples utilisent un a max-age de deux mois et incluent aussi tous les sous-domaines. Il est conseillé de vérifier que cela convient à votre serveur.
      
+
      Note : Ces exemples utilisent un a max-age de deux mois et incluent aussi tous les sous-domaines. Il est conseillé de vérifier que cela convient à votre serveur.
      
 
      
 
 
      Inclure une ligne similaire à votre configuration activera HPKP, en remplaçant les valeurs en pointillé des lignes pin-sha256="..." :
      
diff --git a/files/fr/web/http/redirections/index.html b/files/fr/web/http/redirections/index.html
index d3a809e3c3..88118a2292 100644
--- a/files/fr/web/http/redirections/index.html
+++ b/files/fr/web/http/redirections/index.html
@@ -15,7 +15,7 @@ translation_of: Web/HTTP/Redirections
 
 
      En HTTP, une redirection est déclenchée par le serveur en envoyant des réponses spéciales à une requête : les redirections. Les redirections HTTP sont des réponses avec un code d'état de 3xx. Un navigateur, lorsqu'il reçoit une réponse de redirection, utilise la nouvelle URL fournie et la charge immédiatement : la plupart du temps, la redirection est transparente pour l'utilisateur, si ce n'est un petit impact de performance.
      
 
-
      
+
      
 
 
      Il existe plusieurs types de redirections et elles se répartissent en trois catégories : les redirections permanentes, les temporaires et les spéciales.
      
 
@@ -37,7 +37,7 @@ translation_of: Web/HTTP/Redirections
    
    
+    Les autres peuvent être changés ou non en {{HTTPMethod("GET")}}.
@@ -49,7 +49,7 @@ translation_of: Web/HTTP/Redirections
  
    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    301
    Moved Permanently
    Requêtes {{HTTPMethod("GET")}} inchangées.
    
-    Les autres peuvent être changés ou non en {{HTTPMethod("GET")}}.[1]    		
    Réorganisation d'un site Web.
   
    
   
    
 
    
 
-
    [1] La spécification n'avait pas l'intention de permettre des changements de méthode, mais il y a en pratique des agents utilisateurs qui le font. 308 a été créé pour supprimer l'ambiguïté du comportement lors de l'utilisation de méthodes autres que GET.
    
+
    La spécification n'avait pas l'intention de permettre des changements de méthode, mais il y a en pratique des agents utilisateurs qui le font. 308 a été créé pour supprimer l'ambiguïté du comportement lors de l'utilisation de méthodes autres que GET.
    
 
 
    Redirections temporaires
    
 
@@ -69,7 +69,7 @@ translation_of: Web/HTTP/Redirections
    302
    Found
    Requêtes {{HTTPMethod("GET")}} inchangées.
    
-    Les autres peuvent être changés ou non en {{HTTPMethod("GET")}}.[2]
+    Les autres peuvent être changés ou non en {{HTTPMethod("GET")}}.
    La page Web n'est temporairement pas disponible pour des raisons qui n'ont pas été imprévues. De cette façon, les moteurs de recherche ne mettent pas à jour leurs liens.
   
   
@@ -88,7 +88,7 @@ translation_of: Web/HTTP/Redirections
  
 
 
-
    [2] La spécification n'avait pas l'intention de permettre des changements de méthode, mais il y a en pratique des agents utilisateurs qui le font. 307 a été créé pour supprimer l'ambiguïté du comportement lors de l'utilisation de méthodes autres que GET
    
+
    La spécification n'avait pas l'intention de permettre des changements de méthode, mais il y a en pratique des agents utilisateurs qui le font. 307 a été créé pour supprimer l'ambiguïté du comportement lors de l'utilisation de méthodes autres que GET
    
 
 
    Redirections spéciales
    
 
@@ -134,7 +134,7 @@ translation_of: Web/HTTP/Redirections
 
    Bien entendu, cette méthode ne fonctionne qu'avec des pages HTML (ou similaires) et ne peut être utilisée pour des images ou tout autre type de contenu.
    
 
 
    
-
    Notez que ces redirections cassent le bouton de retour dans un navigateur : vous pouvez revenir à une page avec cet en-tête mais mais vous serez de nouveau instantanément rediriger.
    
+
    Note : Ces redirections cassent le bouton de retour dans un navigateur : vous pouvez revenir à une page avec cet en-tête mais mais vous serez de nouveau instantanément rediriger.
    
 
    
 
 
    Redirections JavaScript
    
@@ -178,7 +178,7 @@ translation_of: Web/HTTP/Redirections
 
    Lorsque vous restructurez des sites Web, les URL des ressources changent. Même si vous pouvez mettre à jour les liens internes de votre site Web pour qu'ils correspondent au nouveau schéma de nommage, vous n'avez aucun contrôle sur les URL utilisées par les ressources externes. Vous ne voulez pas briser ces liens, car ils vous apportent des utilisateurs précieux (et aident votre référencement), donc vous configurez des redirections depuis les anciennes URL vers les nouvelles.
    
 
 
    
-
    Même si cette technique fonctionne également pour les liens internes, vous devriez éviter d'avoir des redirections internes. Une redirection a un coût significatif sur les performances (car une requête HTTP supplémentaire est faite) et si vous pouvez l'éviter en corrigeant les liens internes, vous devez corriger ces liens.
    
+
    Note : Même si cette technique fonctionne également pour les liens internes, vous devriez éviter d'avoir des redirections internes. Une redirection a un coût significatif sur les performances (car une requête HTTP supplémentaire est faite) et si vous pouvez l'éviter en corrigeant les liens internes, vous devez corriger ces liens.
    
 
    
 
 
    Réponses temporaires aux requêtes non sécurisées
    
@@ -249,7 +249,7 @@ rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;
 
 
    Parfois, le serveur ne le détecte pas : une boucle de redirection peut s'étendre sur plusieurs serveurs qui n'ont pas une vue globale de ce qui se passe. Dans ce cas, les navigateurs le détecteront et afficheront un message d'erreur. Firefox affichera:
    
 
-
    Firefox a détecté que le serveur redirige la demande pour cette adresse d'une manière qui n'aboutira pas.
+
    Firefox a détecté que le serveur redirige la demande pour cette adresse d'une manière qui n'aboutira pas.
 
    
 
 
    tandis que Chrome affichera:
    
diff --git a/files/fr/web/http/session/index.html b/files/fr/web/http/session/index.html
index d0a0d231de..28fd60d637 100644
--- a/files/fr/web/http/session/index.html
+++ b/files/fr/web/http/session/index.html
@@ -12,40 +12,43 @@ translation_of: Web/HTTP/Session
 
    Dans les protocoles client-serveur, comme HTTP, les sessions se composent de trois phases :
    
 
 
      
- 
    1. Le client établit une connexion TCP (ou la connexion appropriée si la couche de transport n'est pas TCP).
      2. 
- 
    2. Le client envoie sa requête et attend la réponse.
      3. 
- 
    3. Le serveur traite la requête, renvoyant sa réponse, fournissant un code d'état et des données appropriées.
      4. 
+ 
    4. Le client établit une connexion TCP (ou la connexion appropriée si la couche de transport n'est pas TCP).
      5. 
+ 
    5. Le client envoie sa requête et attend la réponse.
      6. 
+ 
    6. Le serveur traite la requête, renvoyant sa réponse, fournissant un code d'état et des données appropriées.
      7. 
 
    
 
-
    À partir de HTTP / 1.1, la connexion n'est plus fermée après avoir terminé la troisième phase, et le client peut à nouveau effectuer une requête : cela signifie que la deuxième et la troisième phases peuvent maintenant être effectuées à tout moment.
    
+
    À partir de HTTP / 1.1, la connexion n'est plus fermée après avoir terminé la troisième phase, et le client peut à nouveau effectuer une requête : cela signifie que la deuxième et la troisième phases peuvent maintenant être effectuées à tout moment.
    
 
-
    Établir une connexion
    
+
    Établir une connexion
    
 
-
    Dans les protocoles client-serveur, c'est le client qui établit la connexion. L'ouverture d'une connexion en HTTP signifie l'initiation d'une connexion dans la couche de transport sous-jacente, généralement TCP.
    
+
    Dans les protocoles client-serveur, c'est le client qui établit la connexion. L'ouverture d'une connexion en HTTP signifie l'initiation d'une connexion dans la couche de transport sous-jacente, généralement TCP.
    
 
-
    Avec TCP, le port par défaut, pour un serveur HTTP sur un ordinateur, est le port 80. D'autres ports peuvent également être utilisés, comme 8000 ou 8080. L'URL d'une page à récupérer contient à la fois le nom de domaine et le numéro de port, Ce dernier peut être omis s'il en est à 80. Voir Identifying resources on the Web pour plus de details.
    
+
    Avec TCP, le port par défaut, pour un serveur HTTP sur un ordinateur, est le port 80. D'autres ports peuvent également être utilisés, comme 8000 ou 8080. L'URL d'une page à récupérer contient à la fois le nom de domaine et le numéro de port, Ce dernier peut être omis s'il en est à 80. Voir Identifying resources on the Web pour plus de details.
    
 
-
    Note: Le modèle client-serveur n'autorise pas le serveur à envoyer des données au client sans une demande explicite. Pour contourner ce problème, les développeurs Web utilisent plusieurs techniques: effectuer un ping sur le serveur périodiquement via le {{domxref("XMLHTTPRequest")}}, {{domxref("Fetch")}} API, en utilisant le HTML WebSockets API, ou des protocoles similaires.
    
+
    
+  
    Note : Le modèle client-serveur n'autorise pas le serveur à envoyer des données au client sans une demande explicite. Pour contourner ce problème, les développeurs Web utilisent plusieurs techniques: effectuer un ping sur le serveur périodiquement via le {{domxref("XMLHTTPRequest")}}, {{domxref("Fetch")}} API, en utilisant le HTML WebSockets API, ou des protocoles similaires.
+  
    
+
    
 
-
    Envoi d'une demande client
    
+
    Envoi d'une demande client
    
 
-
    Une fois la connexion établie, l'agent utilisateur peut envoyer la demande (un agent utilisateur est généralement un navigateur Web, mais peut être autre chose, un robot d'exploration, par exemple). Une demande de client consiste en des directives de texte, séparées par CRLF (retour de chariot, suivi d'une alimentation en ligne), divisé en trois blocs :
    
+
    Une fois la connexion établie, l'agent utilisateur peut envoyer la demande (un agent utilisateur est généralement un navigateur Web, mais peut être autre chose, un robot d'exploration, par exemple). Une demande de client consiste en des directives de texte, séparées par CRLF (retour de chariot, suivi d'une alimentation en ligne), divisé en trois blocs :
    
 
 
      
- 
    1. La première ligne contient une méthode de demande suivie de ses paramètres:
+ 
    2. La première ligne contient une méthode de demande suivie de ses paramètres:
 
   
        
-   
      • le chemin d'accès du document, c'est-à-dire une URL absolue sans le protocole ou le nom de domaine
        • 
-   
      • la version du protocole HTTP
        • 
+   
      • le chemin d'accès du document, c'est-à-dire une URL absolue sans le protocole ou le nom de domaine
        • 
+   
      • la version du protocole HTTP
        • 
   
      
  
      3. 
- 
    3. Les lignes subséquentes représentent un en-tête HTTP, ce qui donne aux informations du serveur quel type de données est approprié (par exemple, quelle langue, quels types MIME) ou d'autres données modifient son comportement (par exemple, ne pas envoyer de réponse s'il est déjà mis en cache). Ces en-têtes HTTP forment un bloc qui se termine par une ligne vide.
      4. 
- 
    4. Le bloc final est un bloc de données facultatif, qui peut contenir d'autres données principalement utilisées par la méthode POST.
      5. 
+ 
    5. Les lignes subséquentes représentent un en-tête HTTP, ce qui donne aux informations du serveur quel type de données est approprié (par exemple, quelle langue, quels types MIME) ou d'autres données modifient son comportement (par exemple, ne pas envoyer de réponse s'il est déjà mis en cache). Ces en-têtes HTTP forment un bloc qui se termine par une ligne vide.
      6. 
+ 
    6. Le bloc final est un bloc de données facultatif, qui peut contenir d'autres données principalement utilisées par la méthode POST.
      7. 
 
    
 
-
    Demandes d'exemple
    
+
    Demandes d'exemple
    
 
-
    Obtenir la page racine de developer.mozilla.org, c'est-à-dire http://developer.mozilla.org/, et dire au serveur que l'utilisateur-agent préférerait la page en français si possible :
    
+
    Obtenir la page racine de developer.mozilla.org, c'est-à-dire http://developer.mozilla.org/, et dire au serveur que l'utilisateur-agent préférerait la page en français si possible :
    
 
 
    GET / HTTP/1.1
 Host: developer.mozilla.org
@@ -53,9 +56,9 @@ Accept-Language: fr
 
 
    
 
-
    Observez cette dernière ligne vide, ceci sépare le bloc de données du bloc d'en-tête. Comme il n'y a pas de Content-Length fourni dans un en-tête HTTP, ce bloc de données est présenté vide, marquant la fin des en-têtes, permettant au serveur de traiter la demande le moment où elle reçoit cette ligne vide.
    
+
    Observez cette dernière ligne vide, ceci sépare le bloc de données du bloc d'en-tête. Comme il n'y a pas de Content-Length fourni dans un en-tête HTTP, ce bloc de données est présenté vide, marquant la fin des en-têtes, permettant au serveur de traiter la demande le moment où elle reçoit cette ligne vide.
    
 
-
    Par exemple, en envoyant le résultat d'un formulaire :
    
+
    Par exemple, en envoyant le résultat d'un formulaire :
    
 
 
    POST /contact_form.php HTTP/1.1
 Host: developer.mozilla.org
@@ -65,13 +68,13 @@ Content-Type: application/x-www-form-urlencoded
 name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
 
    
 
-
    Méthodes de demande
    
+
    Méthodes de demande
    
 
 
    HTTP définit un ensemble de méthodes de requête indiquant l'action souhaitée à effectuer sur une ressource. Bien qu'ils puissent également être des noms, ces méthodes de requêtes sont parfois appelées verbes HTTP. Les requêtes les plus courantes sont GET et POST :
    
 
 
      
- 
    • La méthode {{HTTPMethod ("GET")}} demande une représentation de données de la ressource spécifiée. Les requêtes utilisant GET ne doivent que récupérer les données.
      • 
- 
    • La méthode {{HTTPMethod ("POST")}} envoie des données à un serveur afin qu'il puisse changer son état. C'est la méthode souvent utilisée pour les formulaires HTML.
      • 
+ 
    • La méthode {{HTTPMethod ("GET")}} demande une représentation de données de la ressource spécifiée. Les requêtes utilisant GET ne doivent que récupérer les données.
      • 
+ 
    • La méthode {{HTTPMethod ("POST")}} envoie des données à un serveur afin qu'il puisse changer son état. C'est la méthode souvent utilisée pour les formulaires HTML.
      • 
 
    
 
 
    Structure d'une réponse du serveur
    
@@ -80,17 +83,15 @@ name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
 
 
      
  
    1. 
-  
      
-  
      La première ligne, la ligne d'état, consiste en une reconnaissance de la version HTTP utilisée, suivie d'une demande d'état (et sa brève signification dans un texte lisible par l'homme).
      
-  
      
+  La première ligne, la ligne d'état, consiste en une reconnaissance de la version HTTP utilisée, suivie d'une demande d'état (et sa brève signification dans un texte lisible par l'homme).
  
      2. 
- 
    2. Les lignes suivantes représentent des en-têtes HTTP spécifiques, en donnant aux clients des informations sur les données envoyées (par exemple, type, taille de données, algorithme de compression utilisé, conseils sur la mise en cache). De la même manière que le bloc d'en-têtes HTTP pour une demande de client, ces en-têtes HTTP forment un bloc se terminant par une ligne vide.
      3. 
- 
    3. Le dernier bloc est un bloc de données, qui contient les données facultatives.
      4. 
+ 
    4. Les lignes suivantes représentent des en-têtes HTTP spécifiques, en donnant aux clients des informations sur les données envoyées (par exemple, type, taille de données, algorithme de compression utilisé, conseils sur la mise en cache). De la même manière que le bloc d'en-têtes HTTP pour une demande de client, ces en-têtes HTTP forment un bloc se terminant par une ligne vide.
      5. 
+ 
    5. Le dernier bloc est un bloc de données, qui contient les données facultatives.
      6. 
 
    
 
 
    Examples de réponses
    
 
-
    Réponse réussie de la page Web :
    
+
    Réponse réussie de la page Web :
    
 
 
    HTTP/1.1 200 OK
 Date: Sat, 09 Oct 2010 14:28:02 GMT
@@ -105,7 +106,7 @@ Content-Type: text/html
 
 
    
 
-
    Notification selon laquelle la ressource demandée a été définitivement déplacé ( en permanence ) :
    
+
    Notification selon laquelle la ressource demandée a été définitivement déplacé ( en permanence ) :
    
 
 
    HTTP/1.1 301 Moved Permanently
 Server: Apache/2.2.3 (Red Hat)
@@ -132,7 +133,7 @@ Content-Length: 325 (the content contains a default page to display
 
 
    
 
-
    Notification selon laquelle la ressource demandée n'existe pas :
    
+
    Notification selon laquelle la ressource demandée n'existe pas :
    
 
 
    HTTP/1.1 404 Not Found
 Date: Sat, 09 Oct 2010 14:33:02 GMT
@@ -147,14 +148,14 @@ Content-Type: text/html
 
 
    
 
-
    Codes d'état de réponse
    
+
    Codes d'état de réponse
    
 
-
    Les codes d'état de réponse HTTP indiquent si une requête HTTP spécifique a été effectuée avec succès. Les réponses sont regroupées en cinq classes: réponses d'information, réponses réussies, redirections, erreurs de client et erreurs de serveurs.
    
+
    Les codes d'état de réponse HTTP indiquent si une requête HTTP spécifique a été effectuée avec succès. Les réponses sont regroupées en cinq classes: réponses d'information, réponses réussies, redirections, erreurs de client et erreurs de serveurs.
    
 
 
      
- 
    • {{HTTPStatus(200)}}: OK. La demande a réussi.
      • 
- 
    • {{HTTPStatus(301)}}: Moved Permanently. Ce code de réponse signifie que l'URL de la ressource demandée a été modifiée.
      • 
- 
    • {{HTTPStatus(404)}}: Not Found. Le serveur ne peut pas trouver la ressource demandée.
      • 
+ 
    • {{HTTPStatus(200)}}: OK. La demande a réussi.
      • 
+ 
    • {{HTTPStatus(301)}}: Moved Permanently. Ce code de réponse signifie que l'URL de la ressource demandée a été modifiée.
      • 
+ 
    • {{HTTPStatus(404)}}: Not Found. Le serveur ne peut pas trouver la ressource demandée.
      • 
 
    
 
 
    Voir aussi
    
diff --git a/files/fr/web/http/status/103/index.html b/files/fr/web/http/status/103/index.html
index cc3acded03..a3ae54084a 100644
--- a/files/fr/web/http/status/103/index.html
+++ b/files/fr/web/http/status/103/index.html
@@ -17,7 +17,7 @@ translation_of: Web/HTTP/Status/103
 
 
    Spécifications
    
 
-
+
    
@@ -28,7 +28,7 @@ translation_of: Web/HTTP/Status/103
  
-   
+   
diff --git a/files/fr/web/http/status/206/index.html b/files/fr/web/http/status/206/index.html
index 41a72c6fda..1d975a9ed9 100644
--- a/files/fr/web/http/status/206/index.html
+++ b/files/fr/web/http/status/206/index.html
@@ -22,7 +22,7 @@ translation_of: Web/HTTP/Status/206
 
 
    Une réponse qui contient une seule plage :
    
 
-
    HTTP/1.1 206 Partial Content
+
    HTTP/1.1 206 Partial Content
 Date: Wed, 15 Nov 2015 06:25:24 GMT
 Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
 Content-Range: bytes 21010-47021/47022
@@ -33,7 +33,7 @@ Content-Type: image/gif
 
 
    Une réponse qui contient plusieurs plages :
    
 
-
    HTTP/1.1 206 Partial Content
+
    HTTP/1.1 206 Partial Content
 Date: Wed, 15 Nov 2015 06:25:24 GMT
 Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
 Content-Length: 1741
diff --git a/files/fr/web/http/status/303/index.html b/files/fr/web/http/status/303/index.html
index 1cb095f2ce..5e6def829e 100644
--- a/files/fr/web/http/status/303/index.html
+++ b/files/fr/web/http/status/303/index.html
@@ -13,7 +13,7 @@ translation_of: Web/HTTP/Status/303
 
 
    Statut
    
 
-
    303 See Other
    
+
    303 See Other
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/status/308/index.html b/files/fr/web/http/status/308/index.html
index 3328ec709a..b6986ad4f7 100644
--- a/files/fr/web/http/status/308/index.html
+++ b/files/fr/web/http/status/308/index.html
@@ -14,7 +14,7 @@ translation_of: Web/HTTP/Status/308
 
    La méthode de requête et son corps ne sont pas modifiés, toutefois {{HTTPStatus("301")}} peut parfois changer la méthode vers {{HTTPHeader("GET")}}.
    
 
 
    
-
    Note : Certaines applications Web peuvent utiliser 308 Permanent Redirect de façon non standard et pour d'autres usages. Par exemple, Google Drive utilise la réponse 308 Resume Incomplete pour indiquer au client un chargement incomplet qui est bloqué.[1]
    
+
    Note : Certaines applications Web peuvent utiliser 308 Permanent Redirect de façon non standard et pour d'autres usages. Par exemple, Google Drive utilise la réponse 308 Resume Incomplete pour indiquer au client un chargement incomplet qui est bloqué (source).
    
 
    
 
 
    Statut
    
diff --git a/files/fr/web/http/status/402/index.html b/files/fr/web/http/status/402/index.html
index 257b479eca..8120dd443d 100644
--- a/files/fr/web/http/status/402/index.html
+++ b/files/fr/web/http/status/402/index.html
@@ -5,9 +5,9 @@ translation_of: Web/HTTP/Status/402
 ---
 
    {{SeeCompatTable}}
    
 
-
    Le code de statut de réponse HTTP 402 Payment Required est une erreur non standard réservée pour un usage futur.
    
+
    Le code de statut de réponse HTTP 402 Payment Required est une erreur non standard réservée pour un usage futur.
    
 
-
    En général ce code indique que la requete ne peut pas etre traitée avant que le client fasse un paiement. Initialement il a été créé afin de permettre des (micro) paiements numériques et indiquerait que le contenu demandé n'est pas disponible avant que le client ne fasse un paiement. Cependant, aucune convention d'usage commune n'existe et différentes entités l'utilisent dans différents contextes.
    
+
    En général ce code indique que la requete ne peut pas etre traitée avant que le client fasse un paiement. Initialement il a été créé afin de permettre des (micro) paiements numériques et indiquerait que le contenu demandé n'est pas disponible avant que le client ne fasse un paiement. Cependant, aucune convention d'usage commune n'existe et différentes entités l'utilisent dans différents contextes.
    
 
 
    Statut
    
 
diff --git a/files/fr/web/http/status/403/index.html b/files/fr/web/http/status/403/index.html
index 9bf9f04287..060427d7a6 100644
--- a/files/fr/web/http/status/403/index.html
+++ b/files/fr/web/http/status/403/index.html
@@ -16,11 +16,11 @@ translation_of: Web/HTTP/Status/403
 
 
    Statut
    
 
-
    403 Forbidden
    
+
    403 Forbidden
    
 
 
    Exemple de réponse
    
 
-
    HTTP/1.1 403 Forbidden
+
    HTTP/1.1 403 Forbidden
 Date: Wed, 21 Oct 2015 07:28:00 GMT
 
    
 
diff --git a/files/fr/web/http/status/405/index.html b/files/fr/web/http/status/405/index.html
index 819656237b..bccc745b4e 100644
--- a/files/fr/web/http/status/405/index.html
+++ b/files/fr/web/http/status/405/index.html
@@ -12,7 +12,7 @@ translation_of: Web/HTTP/Status/405
 
 
    Le code de statut de réponse HTTP 405 Method Not Allowed indique que la méthode utilisée pour la requête est connue du serveur mais qu'elle n'est pas supportée par la ressource ciblée. 
    
 
-
    Le serveur doit générer un champ Allow dans le header en cas de réponse 405, contenant la liste des méthodes supportées par la ressource ciblée.
    
+
    Le serveur doit générer un champ Allow dans le header en cas de réponse 405, contenant la liste des méthodes supportées par la ressource ciblée.
    
 
 
    Statut
    
 
diff --git a/files/fr/web/http/status/422/index.html b/files/fr/web/http/status/422/index.html
index 5aabeae4e4..c79b1e9f78 100644
--- a/files/fr/web/http/status/422/index.html
+++ b/files/fr/web/http/status/422/index.html
@@ -15,7 +15,7 @@ translation_of: Web/HTTP/Status/422
 
    Le code de statut de réponse HTTP 422 Unprocessable Entity indique que le serveur a compris le type de contenu de la requête et que la syntaxe de la requête est correcte mais que le serveur n'a pas été en mesure de réaliser les instructions demandées.
    
 
 
    
-
    Important : Le client ne doit pas renvoyer cette requête sans modification.
    
+
    Attention : Le client ne doit pas renvoyer cette requête sans modification.
    
 
    
 
 
    Statut
    
diff --git a/files/fr/web/http/status/502/index.html b/files/fr/web/http/status/502/index.html
index 3a125a68c5..931b6c20d5 100644
--- a/files/fr/web/http/status/502/index.html
+++ b/files/fr/web/http/status/502/index.html
@@ -15,7 +15,7 @@ translation_of: Web/HTTP/Status/502
 
 
    Statut
    
 
-
    502 Bad Gateway
    
+
    502 Bad Gateway
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/status/503/index.html b/files/fr/web/http/status/503/index.html
index 4436a30059..11535dcc5e 100644
--- a/files/fr/web/http/status/503/index.html
+++ b/files/fr/web/http/status/503/index.html
@@ -17,7 +17,7 @@ translation_of: Web/HTTP/Status/503
 
 
    Statut
    
 
-
    503 Service Unavailable
    
+
    503 Service Unavailable
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/status/506/index.html b/files/fr/web/http/status/506/index.html
index 010112acf8..431d3dae17 100644
--- a/files/fr/web/http/status/506/index.html
+++ b/files/fr/web/http/status/506/index.html
@@ -15,7 +15,7 @@ translation_of: Web/HTTP/Status/506
 
 
    Status
    
 
-
    506 Variant Also Negotiates
    
+
    506 Variant Also Negotiates
    
 
 
    Specifications
    
 
diff --git a/files/fr/web/http/status/507/index.html b/files/fr/web/http/status/507/index.html
index 51d3061a4a..35f2b1ebda 100644
--- a/files/fr/web/http/status/507/index.html
+++ b/files/fr/web/http/status/507/index.html
@@ -15,7 +15,7 @@ translation_of: Web/HTTP/Status/507
 
 
    Status
    
 
-
    507 Insufficient Storage
    
+
    507 Insufficient Storage
    
 
 
    Specifications
    
 
diff --git a/files/fr/web/http/status/508/index.html b/files/fr/web/http/status/508/index.html
index 7e97a0ac05..181ba09d36 100644
--- a/files/fr/web/http/status/508/index.html
+++ b/files/fr/web/http/status/508/index.html
@@ -16,7 +16,7 @@ translation_of: Web/HTTP/Status/508
 
 
    Statut
    
 
-
    508 Loop Detected
    
+
    508 Loop Detected
    
 
 
    Spécifications
    
 
diff --git a/files/fr/web/http/status/index.html b/files/fr/web/http/status/index.html
index 3d30883fd2..4d7ec75019 100644
--- a/files/fr/web/http/status/index.html
+++ b/files/fr/web/http/status/index.html
@@ -34,11 +34,7 @@ translation_of: Web/HTTP/Status
 
 
    
  
    {{HTTPStatus(200, "200 OK")}}
    
- 
    La requête a réussi. Le signification du succès peut varier selon la méthode HTTP :
    
- 
    GET : La ressource a été récupérée et est retransmise dans le corps du message.
    
- HEAD : Les en-têtes d'entité sont dans le corps du message.
    
- POST : La ressource décrivant le résultat de l'action est transmise dans le corps du message.
    
- TRACE : Le corps du message contient le message de requête tel que reçu par le serveur
    
+ 
    La requête a réussi. Le signification du succès peut varier selon la méthode HTTP : GET : La ressource a été récupérée et est retransmise dans le corps du message. HEAD : Les en-têtes d'entité sont dans le corps du message. POST : La ressource décrivant le résultat de l'action est transmise dans le corps du message. TRACE : Le corps du message contient le message de requête tel que reçu par le serveur
    
  
    {{HTTPStatus(201, "201 Created")}}
    
  
    La requête a réussi et une nouvelle ressource a été créée en guise de résultat. Il s'agit typiquement de la réponse envoyée après une requête PUT.
    
  
    {{HTTPStatus(202, "202 Accepted")}}
    
@@ -170,19 +166,18 @@ translation_of: Web/HTTP/Status
  
    {{HTTPStatus(506, "506 Variant Also Negotiates")}}
    
  
    Le serveur a une erreur de configuration interne : la négociation de contenu transparente pour la requête aboutit à une dépendance circulaire.
    
  
    {{HTTPStatus(507, "507 Insufficient Storage")}}
    
- 
    Le serveur a une erreur de configuration interne : la ressource sélectionnée est configurée pour participer elle-même à une négociation de contenu transparente, et n'est par conséquent pas un nœud terminal valable dans le processus de négociation.
    
+ 
    Le serveur a une erreur de configuration interne : la ressource sélectionnée est configurée pour participer elle-même à une négociation de contenu transparente, et n'est par conséquent pas un nœud terminal valable dans le processus de négociation.
    
  
    {{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})
    
  
    Le serveur a détecté une boucle infinie en traitant la requête.
    
  
    {{HTTPStatus(510, "510 Not Extended")}}
    
  
    Des extensions supplémentaires sont requises afin que le serveur puisse satisfaire la requête.
    
  
    {{HTTPStatus(511, "511 Network Authentication Required")}}
    
  
    Le code de statut 511 indique que le client doit s'authentifier afin de pouvoir accéder au réseau.
    
- 
    
- 
    Voir aussi
    
+
    
+
+
    Voir aussi
    
 
- 
\ No newline at end of file
-- 
cgit v1.2.3-54-g00ecf


    
  
   
    
    Spécification
    
   
    
    {{RFC(8297, "103 Early Hints")}}IETF RFCIETF RFC
    Première version